[GRASS-dev] How many points in a point layer and v.surf.bspline questions

GRASS GRASS developer
1

Hi Folks,

I aggregated all of the bare earth lidar points for the state of North Carolina into a single file Imported all 8.5 billion points for NC into one point layer with no topology. I was sort of curious to see if I could generate a seamless 20 ft elevation grid for the State of North Carolina from a single data layerusing bspline and tried the following command:

GRASS 6.5.svn (ncstpft_nad83):~ > v.surf.bspline input=all_nc_be_pts2 raster=all_nc_be_20ft_bspline sie=40 sin=40 layer=0
WARNING: Coor files of vector map all_nc_be_pts2@statewide is larger than
it should be (158913789952 bytes excess)
Cells for raster map <all_nc_be_20ft_bspline> will be interpolated
ERROR: G_calloc: unable to allocate 18446744071812941729 * 8 bytes of
memory at dalloc.c:66

This was for a region with the following settings:

projection: 99 (Lambert Conformal Conic) - North Carolina State Plane Feet NAD83
zone: 0
datum: nad83
ellipsoid: grs80
north: 1050000
south: 30000
west: 400000
east: 3060000
nsres: 20
ewres: 20
rows: 51000
cols: 133000
cells: 6783000000

I then zoomed into the northeast corner of the state and set the region to :
north: 1047363
south: 795102
west: 2505067
east: 3007693
nsres: 20.00007928
ewres: 20.00023875
rows: 12613
cols: 25131
cells: 316977303

and tried again for this area

GRASS 6.5.svn (ncstpft_nad83):~ > v.surf.bspline input=all_nc_be_pts2 raster=ne_nc_be_20ft_bspline sie=40 sin=40 layer=0
WARNING: Coor files of vector map all_nc_be_pts2@statewide is larger than
it should be (158913789952 bytes excess)
Cells for raster map <ne_nc_be_20ft_bspline> will be interpolated
subregion 1 of 5459

I killed that one and set the sin and sie to 400 rather than 40 . This dropped the regions down to 66.

GRASS 6.5.svn (ncstpft_nad83):~ > v.surf.bspline input=all_nc_be_pts2 raster=ne_nc_be_20ft_bspline sie=400 sin=400 layer=0
WARNING: Coor files of vector map all_nc_be_pts2@statewide is larger than
it should be (158913789952 bytes excess)
Cells for raster map <ne_nc_be_20ft_bspline> will be interpolated
subregion 1 of 66

This is about halfway done, so I should see the results in another 1.5 days or so.

I have two questions. First, is there a problem with importing large point datasets that is being highlighted by the warning? I did notice that the size of the coords and hist files did not match for the point data set.

Second, is about v.surf.bspline and sin and sie. I have seen in the documentation that the sie an sin needs to be twice as large as the spacing between points as a good starting point. The density of the lidar data sets that make up this ground point layer varies between 1m and 5 m . Obviously, making sin and sie larger reduces the number of subregions, but how does that affect the accuracy of the surface generated? If I’m trying to generate a 20ft grid, is using sin and sie options of 400 absurd? ( I.E., It works faster but the results are less accurate)

The version of GRASS used was the weekly snapshot from 12/25/2010. The computer has a 1.6 GHz Xeon quad-core cpu with 16 GB RAM.

Doug

Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb@fws.gov

The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.

2

hi Doug,

On Mon, Jan 3, 2011 at 2:26 PM, <Doug_Newcomb@fws.gov> wrote:

Hi Folks,

I aggregated all of the bare earth lidar points for the state of North
Carolina into a single file Imported all 8.5 billion points for NC into one
point layer with no topology. I was sort of curious to see if I could
generate a seamless 20 ft elevation grid for the State of North Carolina
from a single data layerusing bspline and tried the following command:

GRASS 6.5.svn (ncstpft_nad83):~ > v.surf.bspline input=all_nc_be_pts2
raster=all_nc_be_20ft_bspline sie=40 sin=40 layer=0
WARNING: Coor files of vector map <all_nc_be_pts2@statewide> is larger than
it should be (158913789952 bytes excess)
Cells for raster map <all_nc_be_20ft_bspline> will be interpolated
ERROR: G_calloc: unable to allocate 18446744071812941729 * 8 bytes of
memory at dalloc.c:66

you are hitting the limits :slight_smile: I dunno if large file support helps, but
for vector data
it is only available in GRASS 7 to my knowledge.

Cheers
Markus

3

On Mon, Jan 3, 2011 at 2:57 PM, Markus Neteler <neteler@osgeo.org> wrote:

hi Doug,

On Mon, Jan 3, 2011 at 2:26 PM, <Doug_Newcomb@fws.gov> wrote:

Hi Folks,

I aggregated all of the bare earth lidar points for the state of North
Carolina into a single file Imported all 8.5 billion points for NC into one
point layer with no topology. I was sort of curious to see if I could
generate a seamless 20 ft elevation grid for the State of North Carolina
from a single data layerusing bspline and tried the following command:

GRASS 6.5.svn (ncstpft_nad83):~ > v.surf.bspline input=all_nc_be_pts2
raster=all_nc_be_20ft_bspline sie=40 sin=40 layer=0
WARNING: Coor files of vector map <all_nc_be_pts2@statewide> is larger than
it should be (158913789952 bytes excess)
Cells for raster map <all_nc_be_20ft_bspline> will be interpolated
ERROR: G_calloc: unable to allocate 18446744071812941729 * 8 bytes of
memory at dalloc.c:66

you are hitting the limits :slight_smile: I dunno if large file support helps, but
for vector data
it is only available in GRASS 7 to my knowledge.

Large file support does not help here because 8.5 billion points
exceeds the number of supported features in GRASS vectors which is
about 2 billion (2,147,483,647 to be precise).

Further on, a region with 6.8 billion cells is a bit large since the
interpolated raster will be held in memory which would require about
50 GB RAM (that could be fixed for v.surf.bspline by keeping
intermediate data on disk). No idea where the request for
18446744071812941729 * 8 bytes comes from, this is astronomical.

Apart from that, spline steps of 40 seem ok, since the point distance
is 5 m or less, spline steps of 20 would also be ok. The larger the
spline steps, the smoother the resulting surface. Smoothing is also
controlled through lambda.

Markus M

4

Markus M.,

>Large file support does not help here because 8.5 billion points
>exceeds the number of supported features in GRASS vectors which is
>about 2 billion (2,147,483,647 to be precise).
I'll chop the inputfile into sections less than 2 billion then. Is there any reason that the 2 billion limit on GRASS vectors cannot be raised? ( variable change vs types of variable and lots of ugly fixes in various places?) If it's something simple, I can play with it, but I'm not a C programmer :-(.

>Further on, a region with 6.8 billion cells is a bit large since the
>interpolated raster will be held in memory which would require about
>50 GB RAM (that could be fixed for v.surf.bspline by keeping
>intermediate data on disk).
I know some folks with computers with 64GB+ of RAM, so that is not an insurmountable issue. However, it would probably be better to go the intermediate route.

> No idea where the request for
>18446744071812941729 * 8 bytes comes from, this is astronomical.
That was my reaction. Perhaps the computer was screaming in pain.:-)

>Apart from that, spline steps of 40 seem ok, since the point distance
>is 5 m or less, spline steps of 20 would also be ok. The larger the
>spline steps, the smoother the resulting surface. Smoothing is also
>controlled through lambda.

Thanks for the insight, I will need to change my approach to minimize the smoothing.

Doug

Markus M
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb@fws.gov

The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.

Markus Metz <markus.metz.giswork@googlemail.com>

01/03/2011 09:13 AM

To

Markus Neteler <neteler@osgeo.org>

cc

Doug_Newcomb@fws.gov, grass-dev@lists.osgeo.org

Subject

Re: [GRASS-dev] How many points in a point layer and v.surf.bspline questions

On Mon, Jan 3, 2011 at 2:57 PM, Markus Neteler <neteler@osgeo.org> wrote:
> hi Doug,
>
> On Mon, Jan 3, 2011 at 2:26 PM, <Doug_Newcomb@fws.gov> wrote:
>>
>> Hi Folks,
>>
>> I aggregated all of the bare earth lidar points for the state of North
>> Carolina into a single file Imported all 8.5 billion points for NC into one
>> point layer with no topology. I was sort of curious to see if I could
>> generate a seamless 20 ft elevation grid for the State of North Carolina
>> from a single data layerusing bspline and tried the following command:
>>
>> GRASS 6.5.svn (ncstpft_nad83):~ > v.surf.bspline input=all_nc_be_pts2
>> raster=all_nc_be_20ft_bspline sie=40 sin=40 layer=0
>> WARNING: Coor files of vector map <all_nc_be_pts2@statewide> is larger than
>> it should be (158913789952 bytes excess)
>> Cells for raster map <all_nc_be_20ft_bspline> will be interpolated
>> ERROR: G_calloc: unable to allocate 18446744071812941729 * 8 bytes of
>> memory at dalloc.c:66
>
> you are hitting the limits :) I dunno if large file support helps, but
> for vector data
> it is only available in GRASS 7 to my knowledge.
>
Large file support does not help here because 8.5 billion points
exceeds the number of supported features in GRASS vectors which is
about 2 billion (2,147,483,647 to be precise).

Further on, a region with 6.8 billion cells is a bit large since the
interpolated raster will be held in memory which would require about
50 GB RAM (that could be fixed for v.surf.bspline by keeping
intermediate data on disk). No idea where the request for
18446744071812941729 * 8 bytes comes from, this is astronomical.

Apart from that, spline steps of 40 seem ok, since the point distance
is 5 m or less, spline steps of 20 would also be ok. The larger the
spline steps, the smoother the resulting surface. Smoothing is also
controlled through lambda.

Markus M

5

On Mon, Jan 3, 2011 at 4:01 PM, <Doug_Newcomb@fws.gov> wrote:

Markus M.,

>Large file support does not help here because 8.5 billion points
>exceeds the number of supported features in GRASS vectors which is
>about 2 billion (2,147,483,647 to be precise).

I'll chop the inputfile into sections less than 2 billion then. Is there any reason that the 2 billion limit on GRASS vectors cannot be raised? ( variable change vs types of variable and lots of ugly fixes in various places?) If it's something simple, I can play with it, but I'm not a C programmer :-(.

The limit can be raised, but, unfortunately, this is not simple, because portability across platforms must be maintained. It boils down to the problem that it is not simple to have a portable 64 bit integer type on at least Linux, Mac, Windows, both 32 bit and 64 bit architectures. I would like to have a portable 64 bit integer type for grass 7 though…

Markus M

>Further on, a region with 6.8 billion cells is a bit large since the
>interpolated raster will be held in memory which would require about
>50 GB RAM (that could be fixed for v.surf.bspline by keeping
>intermediate data on disk).

I know some folks with computers with 64GB+ of RAM, so that is not an insurmountable issue. However, it would probably be better to go the intermediate route.

> No idea where the request for
>18446744071812941729 * 8 bytes comes from, this is astronomical.

`That was my reaction. Perhaps the computer was screaming in pain.:slight_smile:

Apart from that, spline steps of 40 seem ok, since the point distance
is 5 m or less, spline steps of 20 would also be ok. The larger the
spline steps, the smoother the resulting surface. Smoothing is also
controlled through lambda.

Thanks for the insight, I will need to change my approach to minimize the smoothing.`

Doug

Markus M

Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb@fws.gov

The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.

Markus Metz <markus.metz.giswork@googlemail.com>

01/03/2011 09:13 AM

To

Markus Neteler <neteler@osgeo.org>

cc

Doug_Newcomb@fws.gov, grass-dev@lists.osgeo.org

Subject

Re: [GRASS-dev] How many points in a point layer and v.surf.bspline questions

On Mon, Jan 3, 2011 at 2:57 PM, Markus Neteler <[neteler@osgeo.org](mailto:neteler@osgeo.org)> wrote:
> hi Doug,
>
> On Mon, Jan 3, 2011 at 2:26 PM, <[Doug_Newcomb@fws.gov](mailto:Doug_Newcomb@fws.gov)> wrote:
>>
>> Hi Folks,
>>
>> I aggregated all of the bare earth lidar points for the state of North
>> Carolina into a single file Imported all 8.5 billion points for NC into one
>> point layer with no topology. I was sort of curious to see if I could
>> generate a seamless 20 ft elevation grid for the State of North Carolina
>> from a single data layerusing bspline and tried the following command:
>>
>> GRASS 6.5.svn (ncstpft_nad83):~ > v.surf.bspline input=all_nc_be_pts2
>> raster=all_nc_be_20ft_bspline sie=40 sin=40 layer=0
>> WARNING: Coor files of vector map <all_nc_be_pts2@statewide> is larger than
>> it should be (158913789952 bytes excess)
>> Cells for raster map <all_nc_be_20ft_bspline> will be interpolated
>> ERROR: G_calloc: unable to allocate 18446744071812941729 * 8 bytes of
>> memory at dalloc.c:66
>
> you are hitting the limits :) I dunno if large file support helps, but
> for vector data
> it is only available in GRASS 7 to my knowledge.
>
Large file support does not help here because 8.5 billion points
exceeds the number of supported features in GRASS vectors which is
about 2 billion (2,147,483,647 to be precise).

Further on, a region with 6.8 billion cells is a bit large since the
interpolated raster will be held in memory which would require about
50 GB RAM (that could be fixed for v.surf.bspline by keeping
intermediate data on disk). No idea where the request for
18446744071812941729 * 8 bytes comes from, this is astronomical.

Apart from that, spline steps of 40 seem ok, since the point distance
is 5 m or less, spline steps of 20 would also be ok. The larger the
spline steps, the smoother the resulting surface. Smoothing is also
controlled through lambda.

Markus M

6

>>>Large file support does not help here because 8.5 billion points
>>>exceeds the number of supported features in GRASS vectors which is
>>>about 2 billion (2,147,483,647 to be precise).
>>I'll chop the inputfile into sections less than 2 billion then. Is there any reason that the 2 billion limit on GRASS vectors >>cannot be raised? ( variable change vs types of variable and lots of ugly fixes in various places?) If it's something simple, I can play >>with it, but I'm not a C programmer :-(.

The limit can be raised, but, unfortunately, this is not simple, because portability across platforms must be maintained. It boils down to the problem that it is not simple to have a portable >64 bit integer type on at least Linux, Mac, Windows, both 32 bit and 64 bit architectures. I would like to have a portable 64 bit integer type for grass 7 though…

I see GRASS7 in my future :slight_smile:

In the short term, Can this limit be gotten around by putting the data in Postgresql/Postgis/Spatialite and using v.external or v.db.connect for the inputpoints for v.surf.bspline?

Doug

Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb@fws.gov

The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.

Markus Metz <markus.metz.giswork@googlemail.com>

01/04/2011 04:43 AM

To

Doug_Newcomb@fws.gov

cc

grass-dev@lists.osgeo.org, Markus Neteler <neteler@osgeo.org>

Subject

Re: [GRASS-dev] How many points in a point layer and v.surf.bspline questions

On Mon, Jan 3, 2011 at 4:01 PM, <Doug_Newcomb@fws.gov> wrote:

Markus M.,

>Large file support does not help here because 8.5 billion points
>exceeds the number of supported features in GRASS vectors which is
>about 2 billion (2,147,483,647 to be precise).
I'll chop the inputfile into sections less than 2 billion then. Is there any reason that the 2 billion limit on GRASS vectors cannot be raised? ( variable change vs types of variable and lots of ugly fixes in various places?) If it's something simple, I can play with it, but I'm not a C programmer :-(.

The limit can be raised, but, unfortunately, this is not simple, because portability across platforms must be maintained. It boils down to the problem that it is not simple to have a portable 64 bit integer type on at least Linux, Mac, Windows, both 32 bit and 64 bit architectures. I would like to have a portable 64 bit integer type for grass 7 though…

Markus M

>Further on, a region with 6.8 billion cells is a bit large since the
>interpolated raster will be held in memory which would require about
>50 GB RAM (that could be fixed for v.surf.bspline by keeping
>intermediate data on disk).
I know some folks with computers with 64GB+ of RAM, so that is not an insurmountable issue. However, it would probably be better to go the intermediate route.

> No idea where the request for
>18446744071812941729 * 8 bytes comes from, this is astronomical.
That was my reaction. Perhaps the computer was screaming in pain.:-)

>Apart from that, spline steps of 40 seem ok, since the point distance
>is 5 m or less, spline steps of 20 would also be ok. The larger the
>spline steps, the smoother the resulting surface. Smoothing is also
>controlled through lambda.

Thanks for the insight, I will need to change my approach to minimize the smoothing.

Doug

Markus M
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb@fws.gov

The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.

Markus Metz <markus.metz.giswork@googlemail.com>

01/03/2011 09:13 AM

To

Markus Neteler <neteler@osgeo.org>

cc

Doug_Newcomb@fws.gov, grass-dev@lists.osgeo.org

Subject

Re: [GRASS-dev] How many points in a point layer and v.surf.bspline questions

On Mon, Jan 3, 2011 at 2:57 PM, Markus Neteler <neteler@osgeo.org> wrote:
> hi Doug,
>
> On Mon, Jan 3, 2011 at 2:26 PM, <Doug_Newcomb@fws.gov> wrote:
>>
>> Hi Folks,
>>
>> I aggregated all of the bare earth lidar points for the state of North
>> Carolina into a single file Imported all 8.5 billion points for NC into one
>> point layer with no topology. I was sort of curious to see if I could
>> generate a seamless 20 ft elevation grid for the State of North Carolina
>> from a single data layerusing bspline and tried the following command:
>>
>> GRASS 6.5.svn (ncstpft_nad83):~ > v.surf.bspline input=all_nc_be_pts2
>> raster=all_nc_be_20ft_bspline sie=40 sin=40 layer=0
>> WARNING: Coor files of vector map <all_nc_be_pts2@statewide> is larger than
>> it should be (158913789952 bytes excess)
>> Cells for raster map <all_nc_be_20ft_bspline> will be interpolated
>> ERROR: G_calloc: unable to allocate 18446744071812941729 * 8 bytes of
>> memory at dalloc.c:66
>
> you are hitting the limits :) I dunno if large file support helps, but
> for vector data
> it is only available in GRASS 7 to my knowledge.
>
Large file support does not help here because 8.5 billion points
exceeds the number of supported features in GRASS vectors which is
about 2 billion (2,147,483,647 to be precise).

Further on, a region with 6.8 billion cells is a bit large since the
interpolated raster will be held in memory which would require about
50 GB RAM (that could be fixed for v.surf.bspline by keeping
intermediate data on disk). No idea where the request for
18446744071812941729 * 8 bytes comes from, this is astronomical.

Apart from that, spline steps of 40 seem ok, since the point distance
is 5 m or less, spline steps of 20 would also be ok. The larger the
spline steps, the smoother the resulting surface. Smoothing is also
controlled through lambda.

Markus M

7

On Tue, Jan 4, 2011 at 4:42 PM, <Doug_Newcomb@fws.gov> wrote:

>>>Large file support does not help here because 8.5 billion points
>>>exceeds the number of supported features in GRASS vectors which is
>>>about 2 billion (2,147,483,647 to be precise).
>>I'll chop the inputfile into sections less than 2 billion then. Is there any reason that the 2 billion limit on GRASS vectors >>cannot be raised? ( variable change vs types of variable and lots of ugly fixes in various places?) If it's something simple, I can play >>with it, but I'm not a C programmer :-(.

>The limit can be raised, but, unfortunately, this is not simple, because portability across platforms must be maintained. It boils down to the problem that it is not simple to have a portable >64 bit integer type on at least Linux, Mac, Windows, both 32 bit and 64 bit architectures. I would like to have a portable 64 bit integer type for grass 7 though...

I see GRASS7 in my future :slight_smile:

In the short term, Can this limit be gotten around by putting the data in Postgresql/Postgis/Spatialite and using v.external or v.db.connect for the inputpoints for v.surf.bspline?

I guess in this case v.external is worth a try, if
Postgresql/Postgis/Spatialite support that many entries. Make sure you
use v.external -b (no topology building).

Markus M

Markus Metz <markus.metz.giswork@googlemail.com>

01/04/2011 04:43 AM

To
Doug_Newcomb@fws.gov
cc
grass-dev@lists.osgeo.org, Markus Neteler <neteler@osgeo.org>
Subject
Re: [GRASS-dev] How many points in a point layer and v.surf.bspline questions

On Mon, Jan 3, 2011 at 4:01 PM, <Doug_Newcomb@fws.gov> wrote:

Markus M.,

>Large file support does not help here because 8.5 billion points
>exceeds the number of supported features in GRASS vectors which is
>about 2 billion (2,147,483,647 to be precise).
I'll chop the inputfile into sections less than 2 billion then. Is there any reason that the 2 billion limit on GRASS vectors cannot be raised? ( variable change vs types of variable and lots of ugly fixes in various places?) If it's something simple, I can play with it, but I'm not a C programmer :-(.

The limit can be raised, but, unfortunately, this is not simple, because portability across platforms must be maintained. It boils down to the problem that it is not simple to have a portable 64 bit integer type on at least Linux, Mac, Windows, both 32 bit and 64 bit architectures. I would like to have a portable 64 bit integer type for grass 7 though...

Markus M

>Further on, a region with 6.8 billion cells is a bit large since the
>interpolated raster will be held in memory which would require about
>50 GB RAM (that could be fixed for v.surf.bspline by keeping
>intermediate data on disk).
I know some folks with computers with 64GB+ of RAM, so that is not an insurmountable issue. However, it would probably be better to go the intermediate route.

> No idea where the request for
>18446744071812941729 * 8 bytes comes from, this is astronomical.
That was my reaction. Perhaps the computer was screaming in pain.:slight_smile:

>Apart from that, spline steps of 40 seem ok, since the point distance
>is 5 m or less, spline steps of 20 would also be ok. The larger the
>spline steps, the smoother the resulting surface. Smoothing is also
>controlled through lambda.

Thanks for the insight, I will need to change my approach to minimize the smoothing.

Doug

Markus M
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb@fws.gov
---------------------------------------------------------------------------------------------------------
The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.

Markus Metz <markus.metz.giswork@googlemail.com>

01/03/2011 09:13 AM

To
Markus Neteler <neteler@osgeo.org>
cc
Doug_Newcomb@fws.gov, grass-dev@lists.osgeo.org
Subject
Re: [GRASS-dev] How many points in a point layer and v.surf.bspline questions

On Mon, Jan 3, 2011 at 2:57 PM, Markus Neteler <neteler@osgeo.org> wrote:
> hi Doug,
>
> On Mon, Jan 3, 2011 at 2:26 PM, <Doug_Newcomb@fws.gov> wrote:
>>
>> Hi Folks,
>>
>> I aggregated all of the bare earth lidar points for the state of North
>> Carolina into a single file Imported all 8.5 billion points for NC into one
>> point layer with no topology. I was sort of curious to see if I could
>> generate a seamless 20 ft elevation grid for the State of North Carolina
>> from a single data layerusing bspline and tried the following command:
>>
>> GRASS 6.5.svn (ncstpft_nad83):~ > v.surf.bspline input=all_nc_be_pts2
>> raster=all_nc_be_20ft_bspline sie=40 sin=40 layer=0
>> WARNING: Coor files of vector map <all_nc_be_pts2@statewide> is larger than
>> it should be (158913789952 bytes excess)
>> Cells for raster map <all_nc_be_20ft_bspline> will be interpolated
>> ERROR: G_calloc: unable to allocate 18446744071812941729 * 8 bytes of
>> memory at dalloc.c:66
>
> you are hitting the limits :slight_smile: I dunno if large file support helps, but
> for vector data
> it is only available in GRASS 7 to my knowledge.
>
Large file support does not help here because 8.5 billion points
exceeds the number of supported features in GRASS vectors which is
about 2 billion (2,147,483,647 to be precise).

Further on, a region with 6.8 billion cells is a bit large since the
interpolated raster will be held in memory which would require about
50 GB RAM (that could be fixed for v.surf.bspline by keeping
intermediate data on disk). No idea where the request for
18446744071812941729 * 8 bytes comes from, this is astronomical.

Apart from that, spline steps of 40 seem ok, since the point distance
is 5 m or less, spline steps of 20 would also be ok. The larger the
spline steps, the smoother the resulting surface. Smoothing is also
controlled through lambda.

Markus M