[GRASS-dev] v.surf.bspline: bugs and issues

Dear All,

There is bunch of bugs and issues with v.surf.bspline which make it
non-functional.

1. What value does it actually use for the interpolation? The Z
coordinate? An attribute? If attribute - what column?

As there is no reference to attribute columns at all in documentation,
I assume Z coord is used.

2. But, trying to interpolate 3d points it always quits with an "ERROR:
G_calloc: out of memory":

In spearfish60:

$ g.region county res=1000 -a
$ v.random -z output=points_3d zmin=100 zmax=1000 n=100
$ v.surf.bspline input=points_3d raster_out=points_3d_bspline

WARNING: No vector map to interpolate. Interpolation will be done with
         <points_3d> vector map
ERROR: G_calloc: out of memory

This is only 16x20 cells area, and the input is only 100 points. Why
out of memory?

3. Why does it have options for database name and driver? There are
specific Grass modules for dealing with these (doubled functionality).

4. Mayve this is supposed to be a workaround for the fact, that:

$ v.surf.bspline input=points_3d output=points_3d_bspline_vect

ERROR: Sorry, <dbf> driver is not allowed for vector output in this module.
       Try with a raster output or other driver

It is not mentioned in manual. Besides, why actually can't dbf be
supported?

5. If only the 'input' vector is specified, and the 'input_ext' is not,
a strange message is given:

"WARNING: No vector map to interpolate. Interpolation will be done with
<hipso03> vector map"

So is there or is there not a vector map to interpolate?

6. Besides the first sentence alone, I don't understand the DESCRIPTION
paragraph (quoted below) at all. Could somebody fix it, or explain it
to me so I could fix it?

---
v.surf.bspline makes a bilinear/bicubic interpolation with Tykhonov
regularization. The required input is a vector of only points that will
be used for interpolate a reference surface. If an extra input vector
is used, an estimation using the reference surface will be done on the
points of this last vector. In other case, the interpolation will be
done with the points of the former vector. The output format can be a
vector in which case the interpolation will be done on the sparse
points, or a raster map. In this last case, the interpolation will be
on a regular grid.
---

7. No progress indicator.

8. In the CVS, 'v.surf.bspline' source is still in the 'v.bspline'
directory. The dir should be renamed to 'v.surf.bspline', and propbaly
moved out of the 'lidar' directory directly to 'vector', where all the
vector modules are.

9. The input, input_ext, output and raster_out should be reffered to as
"string"s, not "name"s, to conform with other Grass modules.

Maciek

Hi all,
I was in the foss4g meeting last week so I read the mail but I couldn't do anything. Now I'm back and I'm working on it.

As a basic thing, I see that the description file is not the best. So, I'm trying to improve it.
I'm also working on the bug of G_calloc.

Just one explanation for the bug: in the example given, you are working with 100 points and with an area of 16x20 cells. On the module, the splines don't care about the cells area, but about the spline steps: "sie=" and "sin=". The unit for these parameters is the same that the region's one. So, if you are working with an area 16000x20000 unit^2, you will have 4000x5000 splines (by default, sie=sin=4). Thus, you are not working with 100 points but with 20 millions splines. Inverting a regular matrix of 20 millions is not easy.

Regards,
Roberto

Maciej Sieczka ha scritto:

Dear All,

There is bunch of bugs and issues with v.surf.bspline which make it
non-functional.

1. What value does it actually use for the interpolation? The Z
coordinate? An attribute? If attribute - what column?

As there is no reference to attribute columns at all in documentation,
I assume Z coord is used.

2. But, trying to interpolate 3d points it always quits with an "ERROR:
G_calloc: out of memory":

In spearfish60:

$ g.region county res=1000 -a
$ v.random -z output=points_3d zmin=100 zmax=1000 n=100
$ v.surf.bspline input=points_3d raster_out=points_3d_bspline

WARNING: No vector map to interpolate. Interpolation will be done with
        <points_3d> vector map
ERROR: G_calloc: out of memory

This is only 16x20 cells area, and the input is only 100 points. Why
out of memory?

3. Why does it have options for database name and driver? There are
specific Grass modules for dealing with these (doubled functionality).

4. Mayve this is supposed to be a workaround for the fact, that:

$ v.surf.bspline input=points_3d output=points_3d_bspline_vect

ERROR: Sorry, <dbf> driver is not allowed for vector output in this module.
      Try with a raster output or other driver

It is not mentioned in manual. Besides, why actually can't dbf be
supported?

5. If only the 'input' vector is specified, and the 'input_ext' is not,
a strange message is given:

"WARNING: No vector map to interpolate. Interpolation will be done with
<hipso03> vector map"

So is there or is there not a vector map to interpolate?

6. Besides the first sentence alone, I don't understand the DESCRIPTION
paragraph (quoted below) at all. Could somebody fix it, or explain it
to me so I could fix it?

---
v.surf.bspline makes a bilinear/bicubic interpolation with Tykhonov
regularization. The required input is a vector of only points that will
be used for interpolate a reference surface. If an extra input vector
is used, an estimation using the reference surface will be done on the
points of this last vector. In other case, the interpolation will be
done with the points of the former vector. The output format can be a
vector in which case the interpolation will be done on the sparse
points, or a raster map. In this last case, the interpolation will be
on a regular grid.
---

7. No progress indicator.

8. In the CVS, 'v.surf.bspline' source is still in the 'v.bspline'
directory. The dir should be renamed to 'v.surf.bspline', and propbaly
moved out of the 'lidar' directory directly to 'vector', where all the
vector modules are.

9. The input, input_ext, output and raster_out should be reffered to as
"string"s, not "name"s, to conform with other Grass modules.

Maciek

--
Roberto Antolin Sanchez
Politecnico di Milano – Polo Regionale di Como
Via Valleggio, 11 – 22100 Como, Italy
tel: +39 031 3327533
email: roberto.antolin@polimi.it