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

GRASS GRASS user
1

Good Morning,

I've been playing with some tools for working with lidar data sets and I've encountered two problems. First, when I try to run v.outlier the module immediately exits with "Bus error" warning.

GRASS 6.2.0 (Mudflats):~ > v.outlier input=pslc2k_sub2 output=clean outlier=outlier
Bus error

Second, in my attempts to classify the point clouds v.lidar.edgedetection runs for a while and then exits with the following error;

GRASS 6.2.0 (Mudflats):~ > v.lidar.edgedetection input=Gldcrk_sub2 output=edge
DBMI-DBF driver error:
Table 'Auxiliar_edge_table' doesn't exist.
Error in db_execute_immediate()

ERROR: Impossible to write in the database

I'm running GRASS on an intel mac (OSX 10.4.8). Does anyone have any insight into either of these issues?

Cheers,

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

2

Hi Michael and all,
I'm the v.outlier and v.lidar.* developer. First of all, I'm very sorry for these bugs.

I knew the v.outlier bug from long time ago but I didn't fix it and I forgot it. I've just fixed and now I will send it to the CVS. So, you will able to download the new version from there. A dirty solution is:
~ > v.outlier input=pslc2k_sub2 output=clean outlier=outlier qgis=clean_qgis

This should run ok.

So, if you don't need the qgis output you can remove it. The qgis output vector parameter was done to allow the visualization of the point's color as a function of its height within qgis. But this approach needs that the topology is built and the height is considered as a category. However, the standard output ("outlier=" and "outlier=") are done without topology and with the height as the z-coord in a 3d-vector.

The v.lidar.edgedetection bug is a new one. I'll try to fix it as soon as possible. Another thing, I advice you about this module. It doesn't run with dbf driver and db because the sql setences used are not allow for them. But this is not the error in this case.

I'm sorry very much,
Roberto.

Michael Perdue ha scritto:

Good Morning,

I've been playing with some tools for working with lidar data sets and I've encountered two problems. First, when I try to run v.outlier the module immediately exits with "Bus error" warning.

GRASS 6.2.0 (Mudflats):~ > v.outlier input=pslc2k_sub2 output=clean outlier=outlier
Bus error

Second, in my attempts to classify the point clouds v.lidar.edgedetection runs for a while and then exits with the following error;

GRASS 6.2.0 (Mudflats):~ > v.lidar.edgedetection input=Gldcrk_sub2 output=edge
DBMI-DBF driver error:
Table 'Auxiliar_edge_table' doesn't exist.
Error in db_execute_immediate()

ERROR: Impossible to write in the database

I'm running GRASS on an intel mac (OSX 10.4.8). Does anyone have any insight into either of these issues?

Cheers,

Mike
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

--
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@polimi.it

3

Michael,

some minutes ago I have submitted a fix from Roberto Antolin
to fix a v.outlier problem. It fixes a crash if qgis=name
isn't used (so, maybe use that and it works)?

Concerning v.lidar.edgedetection I have no idea; have
added the author in CC.

Best,
Markus

On Thu, Nov 09, 2006 at 11:00:58AM -0700, Michael Perdue wrote:

Good Morning,

I've been playing with some tools for working with lidar data sets
and I've encountered two problems. First, when I try to run v.outlier
the module immediately exits with "Bus error" warning.

GRASS 6.2.0 (Mudflats):~ > v.outlier input=pslc2k_sub2 output=clean
outlier=outlier
Bus error

Second, in my attempts to classify the point clouds
v.lidar.edgedetection runs for a while and then exits with the
following error;

GRASS 6.2.0 (Mudflats):~ > v.lidar.edgedetection input=Gldcrk_sub2
output=edge
DBMI-DBF driver error:
Table 'Auxiliar_edge_table' doesn't exist.
Error in db_execute_immediate()

ERROR: Impossible to write in the database

I'm running GRASS on an intel mac (OSX 10.4.8). Does anyone have any
insight into either of these issues?

Cheers,

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

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

4

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

On 10-Nov-06, at 3:43 AM, Roberto Antolin wrote:

Hi Michael and all,
I'm the v.outlier and v.lidar.* developer. First of all, I'm very sorry for these bugs.

I knew the v.outlier bug from long time ago but I didn't fix it and I forgot it. I've just fixed and now I will send it to the CVS. So, you will able to download the new version from there. A dirty solution is:
~ > v.outlier input=pslc2k_sub2 output=clean outlier=outlier qgis=clean_qgis

This should run ok.

So, if you don't need the qgis output you can remove it. The qgis output vector parameter was done to allow the visualization of the point's color as a function of its height within qgis. But this approach needs that the topology is built and the height is considered as a category. However, the standard output ("outlier=" and "outlier=") are done without topology and with the height as the z-coord in a 3d-vector.

The v.lidar.edgedetection bug is a new one. I'll try to fix it as soon as possible. Another thing, I advice you about this module. It doesn't run with dbf driver and db because the sql setences used are not allow for them. But this is not the error in this case.

I'm sorry very much,
Roberto.

Michael Perdue ha scritto:

Good Morning,

I've been playing with some tools for working with lidar data sets and I've encountered two problems. First, when I try to run v.outlier the module immediately exits with "Bus error" warning.

GRASS 6.2.0 (Mudflats):~ > v.outlier input=pslc2k_sub2 output=clean outlier=outlier
Bus error

Second, in my attempts to classify the point clouds v.lidar.edgedetection runs for a while and then exits with the following error;

GRASS 6.2.0 (Mudflats):~ > v.lidar.edgedetection input=Gldcrk_sub2 output=edge
DBMI-DBF driver error:
Table 'Auxiliar_edge_table' doesn't exist.
Error in db_execute_immediate()

ERROR: Impossible to write in the database

I'm running GRASS on an intel mac (OSX 10.4.8). Does anyone have any insight into either of these issues?

Cheers,

Mike
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

--
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@polimi.it

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

5

Hi Roberto,

On a related note - have you succeded in fixing bugs mentioned in the
http://www.nabble.com/v.surf.bspline%3A-bugs-and-issues-tf2270748.html#a6302978
?

Thanks,
Maciek

6

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 :wink:

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@polimi.it

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

7

Hi Mike and all

Hi Roberto,

I did a cvs update on my linux machine and the seg fault bug is fixed. Cheers!

Thanks :slight_smile:

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 :slight_smile:
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.