v.surf.bspline column option broken

This has set broken for many months now. Should we remove it from the main GRASS distribution until someone is able to work on it? It would be a nice addition to GRASS interpolation tools, but it doesn't seem like a good idea to ship a module that doesn't work and is not being fixed.

Michael

bugfix patch for testing from Roberto

I got a bugfix from Roberto which needs to be tested (patch attached). It includes G_percent() output and two message cosmetics from me.

Test case for North Carolina data set:

g.region res=500 vect=precip_30ynormals -ap
v.surf.bspline precip_30ynormals colum=annual rast=precip_30ynormals_surf layer=1 sin=1000 sie=1000

Markus

Can be the patch applied in SVN for better testing?

This is fixed, but needs better documentation now--in progress.

The bug is back... (interpolation of annual rainfall):

GRASS 6.5.svn (nc_spm_07):~ > g.region res=500 vect=precip_30ynormals -ap      
projection: 99 (Lambert Conformal Conic)                                       
zone:       0                                                                  
datum:      nad83                                                              
ellipsoid:  a=6378137 es=0.006694380022900787                                  
north:      307000                                                             
south:      27500                                                              
west:       151500                                                             
east:       917500                                                             
nsres:      500                                                                
ewres:      500                                                                
rows:       559                                                                
cols:       1532                                                               
cells:      856388                                                             

v.univar precip_30ynormals column=annual type=point
number of features with non NULL attribute: 136
number of missing attributes: 0
number of NULL attributes: 0
minimum: 947.42
maximum: 2329.18
range: 1381.76
mean: 1289.31
mean of absolute values: 1289.31
population standard deviation: 198.572
population variance: 39431
population coefficient of variation: 0.154014
sample standard deviation: 199.306
sample variance: 39723.1
kurtosis: 8.48418
skewness: 2.48352

v.surf.bspline precip_30ynormals rast=precip_30ynormals_surf column=annual layer=1 sin=1000 sie=1000
No vector map of sparse points to interpolate. Interpolation will be done with <precip_30ynormals> vector map
[136] records selected from table
 100%
v.surf.bspline complete.

r.univar precip_30ynormals_surf
 100%
total null and non-null cells: 856388
total null cells: 0

Of the non-null cells:
----------------------
n: 856388
minimum: 0
maximum: 0
range: 0
mean: 0
mean of absolute values: 0
standard deviation: 0
variance: 0
variation coefficient: nan %
sum: 0

bugfix proposal for use of attribute column

I found suspicious code which was introduced in the last fix round. Commenting that out attributes are taken again. I don't understand the purpose of the part which I have commented in attached patch v.surf.bspline_fix_attribs.diff. AFAIK "type" is defined but not set. There is another "type" in main() - perhaps a different variable was supposed to be used to test against GV_POINTS?

Markus

With that patch, the result of the precip vector map interpolation is now:

r.univar precip_30ynormals_surf
 100%
total null and non-null cells: 54144
total null cells: 0

Of the non-null cells:
----------------------
n: 54144
minimum: 1133.44
maximum: 1858.02
range: 724.578
mean: 1338.21
mean of absolute values: 1338.21
standard deviation: 153.479
variance: 23555.8
variation coefficient: 11.469 %
sum: 72456125.5301044583

which has a reasonable range. Artefacts are visible but that will require parameter tuning.

Markus

Replying to neteler:

I found suspicious code which was introduced in the last fix round. Commenting that out attributes are taken again. I don't understand the purpose of the part which I have commented in attached patch v.surf.bspline_fix_attribs.diff. AFAIK "type" is defined but not set. There is another "type" in main() - perhaps a different variable was supposed to be used to test against GV_POINTS? Markus

Original code (almost) makes sense (r21982).

/*type = Vect_read_line (&In, points, Cats, observ[i].lineID);*/ 
if ( !(type & GV_POINTS ) ) continue; 

Still I have no idea how to fix this module (I'm lazy) (fix == does it needs that check or not). Also I looked at P_Read_Vector_Region_Map (lidarlib/zones.c) and it seemed somehow fishy - it reads vector line and then uses only first coordinate of that line, still as code lacks any comments about it's design specifics (and it has them i.e. as it crunches over all vector lines on every function call instad of using standart V_* functions) I can only suggest to somebody who understands that code to add comments and, probably, line type check.

I was just able to test this with an sqlite attribute database. The column option is still broken in all versions. If this is non-functional and no way to fix it, perhaps we should just take it out of the interface and manual.

Michael

Forgot to give an example of the command I used--that did not work.

Michael

v.surf.bspline --overwrite input=elev_pts1000_sql@sqlite_test raster=aaa_splintest@sqlite_test sie=400 sin=400 layer=1 column=elevation