[GRASS-user] Problems with v.outlier and v.lidar.edgedetection

[Roberto Antolin]

Hi Mike and all

> Hi Roberto,
>
> I did a cvs update on my linux machine and the seg fault bug is  
> fixed. Cheers!
>
Thanks :)

>
> In a nutshell, if the region dimensions are more than 250 times the  
> spline interpolation step value in either axis then v.outlier &  
> v.lidar.edgedetection (and probably v.lidar.correction, but havn't  
> tested) will fail with the driver error below. So for the command;
>
>     #Region size of 1000X2500m
>     GRASS 6.2.0 (Mudflats):~ > g.region n=5276000 s=5275000 e=581500  
> w=579000 ewres=1 nsres=1
>     GRASS 6.2.0 (Mudflats):~ > v.outlier input=pslc2k output=clean  
> outlier=outlier
>     v.outlier complete
> SUCCESS
>
>
>     #Region size of 1000x2501m
>     GRASS 6.2.0 (Mudflats):~ > g.region n=5276000 s=5275000 e=581501  
> w=579000 ewres=1 nsres=1
>     GRASS 6.2.0 (Mudflats):~ > v.outlier input=pslc2k output=clean  
> outlier=outlier  --o
>     DBMI-SQLite driver error:
>     Error in sqlite3_prepare():
>     no such table: Auxiliar_outlier_table
>     
>     ERROR: Impossible to write in the database
> FAILURE
>
> As does;
>     #Region size of 100X2501m
>     GRASS 6.2.0 (Mudflats):~ > g.region n=5275100 s=5275000 e=581501  
> w=579000 ewres=1 nsres=1
>     GRASS 6.2.0 (Mudflats):~ > v.outlier input=pslc2k output=clean  
> outlier=outlier  --o
>     DBMI-SQLite driver error:
>     Error in sqlite3_prepare():
>     no such table: Auxiliar_outlier_table
>     
>     ERROR: Impossible to write in the database
> FAILURE
>
> This is true for both my Mac and my Linux machine (both 32bit). Now  
> that I know how to trigger it, it's pretty easy to work around, but I  
> just though I'd let you know in case it gives you any ideas as to  
> what may be causing it.
>
Ok, thank you very much for the information, it is very useful. I think 
I'll find this bug, but I don't know when I'll do it, sorry. I'm doing 
my best but I'm one man alone Vs five big progrmas :)
Now, I'm working on improving v.surf.bspline and fixing some bugs 
reported by Maciek in the same module.
And also continue with my doctoral program.

> On a side note, I noticed that the parameter name for the spline  
> interpolation step is different for each program that uses it. Ie,  
> for the north-south interpolation step in v.outlier it is "son", in  
> v.surf.spline it is "sin", in v.lidar.edgedetection it is "sen" and  
> "scn" for v.lidar.correction. Is there some difference to it's use in  
> each of these commands? Otherwise, it might be better if they all  
> possessed the same name. Just a though.
>
Yes, it has its sense. It means, son = Spline Outlier North; sin = 
Spline Interpolation North; sen=Spline Edgedetection North, etc. It is 
also the same for soe = Spline Outlier East; sie=..., etc, etc.

It has historical reasons. Also in s.edgedetection, s.correction, etc 
from the version 5.4 it was so. I decided  maintain the same idea. I 
think the first authors do this reasoning: All these modules are part 
from a big process:
v.outlier -> v.lidar.edge -> v.lidar.growing -> v.lidar.correction -> 
v.surf.bspline
An all of them have their own spline steps. These splines steps would 
not be equal one to each other.

But you are right. The first time i used these modules with grass54 I 
found it a bit confusing.

> Anyways, I hope this info helps.
>
> Cheers,
>
> Mike


Thank you very much for your help, Mike

Regards,
Roberto.