[GRASS-user] Creating LiDAR first pulse vector map
I am still fighting with the LiDAR tools, but I feel like I am close... I thought I had sorted the v.lidar.growing problem as it appears to run when using sqlite backend. But the resulting output was only a small portion of the output? For v.lidar.growing, is there any special way to create the first pulse vector map? I feel this may be where my problem comes from. (Currently I was just using the raw data from the lidar text file which includes X Y Z and intensity readings for all points.) Thanks -- Jack Lonsdale, ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.lidar.growing dbmi: Protocol error
On Fri, 2009-04-24 at 23:51 +0200, Markus Neteler wrote: > On Wed, Apr 22, 2009 at 10:58 PM, Jack Lonsdale wrote: > > I am continuing to try and use Grass to process my LiDAR data. However, > > having completed v.lidar.edgedetect successfully I am unable to complete > > v.lidar.growing > > > > firstly, just to check, the 'first' parameter is the raw dataset? If not > > how do I create the first return dataset? > > > > Secondly, if I run the following: > > v.lidar.growing input=alrf_subs_e...@lonsdale output=alrf_subs_grow > > first=alrf_subs_raw tj=0.2 td=0.6 > > > > All I get is a dbmi:Protocol error, It was impossible to open this > > table! > > ha! I guess I found the error. > Please try again *without* specifying the mapset (@lonsdale). If it is > not in the path, use g.mapsets (-s for GUI) to add it. > Runs, right? > > The bug is here: > sprintf(buf, "SELECT Interp,ID FROM %s_edge_Interpolation", > in_opt->answer); > db_append_string(&sql, buf); > > in_opt->answer contains (in your case) the @mapset part which causes > the DBMI engine to crash. So that should be easy to fix in the module. > > @devs: how to strip off the mapset part of a name? Don't remember... > > Markus Brilliant! Works now. Thanks so much, Jack ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: v.lidar.growing dbmi: Protocol error
> First we need to know what you use: > > db.connect -p > > The db.connect manual page also shows how to switch to the > SQLite backend: ideally done in a new mapset. Then add the > previous mapset to the search path with g.mapsets and > repeat there the v.lidar.* commands the in new mapset. > > Otherwise I would need the reduced location to look at the > problem. No idea so far why it fails for you. > > Markus OK, So changed to the SQLite backend and managed to run the v.lidar.edgedetection (although took much longer to process - all day yesterday) Now when I run v.lidar.growing I get the following error:DBMI-SQLite driver error: Error in sqlite3_prepare():SELECT Interp,ID FROM alrf_subs_e...@sqlite_edge_interpolation near "@sqlite_edge_Interpolation": syntax error It was impossible to open table What is the best way to compress & send the location? Thanks once again, Jack ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: v.lidar.growing dbmi: Protocol error
On Thu, 2009-04-23 at 01:29 +0200, Markus Neteler wrote: > On Thu, Apr 23, 2009 at 1:13 AM, Jack Lonsdale wrote: > > On Thu, 2009-04-23 at 00:42 +0200, Markus Neteler wrote: > >> On Thu, Apr 23, 2009 at 12:38 AM, Markus Neteler wrote: > >> > On Thu, Apr 23, 2009 at 12:08 AM, Jack Lonsdale wrote: > >> >> On Wed, 2009-04-22 at 23:26 +0200, Markus Neteler wrote: > >> ... > >> >> The precise error message is as above 'dbmi:Protocol error, It was > >> >> impossible to open this table' > ... > >> > You could run v.lidar.edgedetection without troubles? > > > > Yes, no problems here > > ok good. > > >> please instead: > >> db.describe -c alrf_subs_edge_edge_Interpolation > >> > >> v.lidar.growing expects here the columns Interp,ID according to the source > >> code. Otherwise fails as you have seen. > >> > > Seems that those exist: db.describe yields the following: > > > > ncols: 2 > > nrows: 3268897 > > Column 1: ID:INTEGER:11 > > Column 2: Interp:DOUBLE PRECISION:20 > > ok, and check for content: > > db.select alrf_subs_edge_edge_Interpolation | head -n 20 > ? > ID|Interp 1|667.828431 2|668.15324 3|667.76812 4|667.544762 5|667.436508 6|671.106558 7|670.506428 8|670.393883 9|669.995136 10|668.356896 11|668.00097 12|667.822109 13|667.750172 14|667.990251 15|668.405321 16|668.22414 17|668.850224 18|669.299805 19|669.426165 > Do you use DBF? If not too fat could you package the location with > *relevant* files and make it available to me? > And/or otherwise, make a test with the SQLite DBMI engine? > > Markus Sorry, I don't know how to do either of those things. Is there an easy way to do them? Thanks, Jack ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: v.lidar.growing dbmi: Protocol error
On Thu, 2009-04-23 at 00:42 +0200, Markus Neteler wrote: > On Thu, Apr 23, 2009 at 12:38 AM, Markus Neteler wrote: > > On Thu, Apr 23, 2009 at 12:08 AM, Jack Lonsdale wrote: > >> On Wed, 2009-04-22 at 23:26 +0200, Markus Neteler wrote: > ... > >> The precise error message is as above 'dbmi:Protocol error, It was > >> impossible to open this table' > > > > Perfect, so I could find it: it fails on opening the > > table associated to the input vector map. I.e., the output of > > v.lidar.edgedetection. > > Correction (what luck that is it open source and I can see what >happens in the code authored by someone else!): > > v.lidar.edgedetection creates a table "%s_edge_Interpolation", so > in your case > > alrf_subs_edge_edge_Interpolation > > > You could run v.lidar.edgedetection without troubles? > Yes, no problems here > please instead: > db.describe -c alrf_subs_edge_edge_Interpolation > > v.lidar.growing expects here the columns Interp,ID according to the source > code. Otherwise fails as you have seen. > > Markus Seems that those exist: db.describe yields the following: ncols: 2 nrows: 3268897 Column 1: ID:INTEGER:11 Column 2: Interp:DOUBLE PRECISION:20 Thanks, Jack ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: v.lidar.growing dbmi: Protocol error
On Wed, 2009-04-22 at 23:26 +0200, Markus Neteler wrote: > >> firstly, just to check, the 'first' parameter is the raw dataset? > > To my knowledge, no. > AFAIK it is the *last* return which is input to v.lidar.growing. Just to clarify: by 'first' I mean the first pulse vector map. On the help page the usage example only states you need an input and an ouput vector, but upon trying this the software insists on the input of a 'first=' parameter > > >> If not how do I create the first return dataset? > > You can use v.extract to separate a mixed map into the different > returns (eg based on an attribute identifying the pulse). > I don't know how I could manage this, the only inputs I have are the x,y,z and intensity? > >> Secondly, if I run the following: > >> v.lidar.growing input=alrf_subs_e...@lonsdale output=alrf_subs_grow > >> first=alrf_subs_raw tj=0.2 td=0.6 > >> > >> All I get is a dbmi:Protocol error, It was impossible to open this > >> table! > > Please send the precise error message. > But it may be that the (if so) previous error of using the wrong input > isn't ideally trapped. The precise error message is as above 'dbmi:Protocol error, It was impossible to open this table' > >> I have seen someone else had this problem on the list in the past but no > >> definitive solution seemed to occur. > > In our book we have successfully used the modules to produce > http://www.grassbook.org/gallery/chapters/s070302f010_cutplanes.jpg > so it worked for us. > > Markus > Thanks for the help so far though ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: v.lidar.growing dbmi: Protocol error
If this helps: Tried this on Ubuntu 8.10 using both GRASS 6.3 and 6.4 svn On Wed, 2009-04-22 at 13:58 -0700, Jack Lonsdale wrote: > I am continuing to try and use Grass to process my LiDAR data. However, > having completed v.lidar.edgedetect successfully I am unable to complete > v.lidar.growing > > firstly, just to check, the 'first' parameter is the raw dataset? If not > how do I create the first return dataset? > > Secondly, if I run the following: > v.lidar.growing input=alrf_subs_e...@lonsdale output=alrf_subs_grow > first=alrf_subs_raw tj=0.2 td=0.6 > > All I get is a dbmi:Protocol error, It was impossible to open this > table! > I have seen someone else had this problem on the list in the past but no > definitive solution seemed to occur. > > Thanks, > Jack ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.lidar.growing dbmi: Protocol error
I am continuing to try and use Grass to process my LiDAR data. However, having completed v.lidar.edgedetect successfully I am unable to complete v.lidar.growing firstly, just to check, the 'first' parameter is the raw dataset? If not how do I create the first return dataset? Secondly, if I run the following: v.lidar.growing input=alrf_subs_e...@lonsdale output=alrf_subs_grow first=alrf_subs_raw tj=0.2 td=0.6 All I get is a dbmi:Protocol error, It was impossible to open this table! I have seen someone else had this problem on the list in the past but no definitive solution seemed to occur. Thanks, Jack ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Clipping LiDAR data
Is there an easy way to clip a LiDAR data file? I have a 2GB raw dataset which I imported with v.in.ascii without topology or creating database because that caused memory to get full. I was going to just run the v.lidar.edgedetection for the whole dataset, but that seems to take forever.. So I thought I could clip down the vector to a subsample using v.in.region and then v.overlay, but this produces an error because of no topology, fair enough! So maybe I can build the topology with v.build...again memory runs out. Any ideas? Thanks, Jack ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
