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

Michael Perdue michael_perdue at yahoo.ca
Wed Nov 22 01:25:18 EST 2006


Hi Roberto,

I did a cvs update on my linux machine and the seg fault bug is  
fixed. Cheers!
I've also done a bunch more experimenting on both my linux machine  
and my mac and found out that the error that I reported is not  
specific to the mac. It occurs on my SUSE 10.1 machine as well. At  
first I thought it was related to the size of my vector files, but  
after severe decimation of one of the input files I realized that it  
was related to the region bounds for the mapset. More specifically,  
it seems to be related to the relationship between the size of the  
region and the spline interpolation step value.

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.

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.

Anyways, I hope this info helps.

Cheers,

Mike





On 13-Nov-06, at 3:52 AM, Roberto Antolin wrote:

> Hi Mike and all,
> I resolved the v.outlier bug successfully(?) and now it is not  
> necessary setting the "qgis=" parameter any more. Only if you want,  
> of course ;-)
>
> The dbf driver error is very bizarre. This morning I made some  
> tests with both dbf driver and db and I had the same problem. I was  
> trying to understand it when the computer shutdown because of a non  
> related problem. The point is that after the restart, I did the  
> same tests and everything run ok.
>
> It's a pity that I haven't got a mac to make some tests, so I'm not  
> able to say you anything. Anyway, I'll try to understand better  
> which is the real problem with dbf. I'll let you know if I find out  
> something
>
> Michael Perdue ha scritto:
>
>>
>> Hi Roberto,
>>
>> Thanks for the info. I'm still pretty new to macintosh and so far   
>> haven't had much luck (read lazy) at setting up the environment  
>> for  building binaries myself. I did run it with the qgis option  
>> however,  and although it didn't complain about a "bus error", it  
>> did shut down  with the same error reported by v.lidar.edgedetection;
>>
>>>> DBMI-DBF driver error:
>>>> Table 'Auxiliar_edge_table' doesn't exist.
>>>> Error in db_execute_immediate()
>>>>
>>>> ERROR: Impossible to write in the database
>>>
>>
>> So, it seems that what ever is causing the error is specific to  
>> mac  and may be common to all the v.lidar.* programs. I have a  
>> linux  workstation in the office and I did a cvs update earlier  
>> today. The  binaries were building when I left so in the morning  
>> I'll run  everything through it and then move the files over to my  
>> mac and see  if the issue also affects v.lidar.* and  
>> v.surf.bspline. I'll let you  know what I find out. Let me know if  
>> there is anything I can do to be  of assistance.
>>
>> Cheers and thanks again!
>>
>> Mike
>
>
>
> -- 
> Roberto Antolín Sánchez
> Politecnico di Milano – Polo Regionale di Como
> (Laboratorio di Geomatica V2.8)
> Via Valleggio, 11 – 22100 Como, Italy
> tel: +39 031 332 7533 || fax: +39 031 332 7519 email:  
> roberto.antolin at polimi.it
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 




More information about the grass-user mailing list