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_edge@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
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_edge@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
On Wed, Apr 22, 2009 at 11:09 PM, Jack Lonsdale <lonsdale@unbc.ca> wrote:
If this helps:
Tried this on Ubuntu 8.10 using both GRASS 6.3 and 6.4 svn
ok - if also in 6.4 present then the "already fixed" argument isn't valid 
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?
To my knowledge, no.
AFAIK it is the *last* return which is input to v.lidar.growing.
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).
Secondly, if I run the following:
v.lidar.growing input=alrf_subs_edge@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.
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
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_edge@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
On Thu, Apr 23, 2009 at 12:08 AM, Jack Lonsdale <lonsdale@unbc.ca> wrote:
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
Ah, you are right. Wrong in the manual, fixed now.
>> 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?
Uhm, then I don't know - you have no indication at all about the
pulses order?
>> Secondly, if I run the following:
>> v.lidar.growing input=alrf_subs_edge@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'
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.
You could run v.lidar.edgedetection without troubles?
The map alrf_subs_edge was created by v.lidar.edgedetection, right?
please
v.info -c alrf_subs_edge
v.info -h alrf_subs_edge
Markus
On Thu, Apr 23, 2009 at 12:38 AM, Markus Neteler <neteler@osgeo.org> wrote:
On Thu, Apr 23, 2009 at 12:08 AM, Jack Lonsdale <lonsdale@unbc.ca> 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?
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
On Thu, 2009-04-23 at 00:42 +0200, Markus Neteler wrote:
On Thu, Apr 23, 2009 at 12:38 AM, Markus Neteler <neteler@osgeo.org> wrote:
> On Thu, Apr 23, 2009 at 12:08 AM, Jack Lonsdale <lonsdale@unbc.ca> 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
On Thu, Apr 23, 2009 at 1:13 AM, Jack Lonsdale <lonsdale@unbc.ca> wrote:
On Thu, 2009-04-23 at 00:42 +0200, Markus Neteler wrote:
On Thu, Apr 23, 2009 at 12:38 AM, Markus Neteler <neteler@osgeo.org> wrote:
> On Thu, Apr 23, 2009 at 12:08 AM, Jack Lonsdale <lonsdale@unbc.ca> 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
?
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
On Thu, 2009-04-23 at 01:29 +0200, Markus Neteler wrote:
On Thu, Apr 23, 2009 at 1:13 AM, Jack Lonsdale <lonsdale@unbc.ca> wrote:
> On Thu, 2009-04-23 at 00:42 +0200, Markus Neteler wrote:
>> On Thu, Apr 23, 2009 at 12:38 AM, Markus Neteler <neteler@osgeo.org> wrote:
>> > On Thu, Apr 23, 2009 at 12:08 AM, Jack Lonsdale <lonsdale@unbc.ca> 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
On Thu, Apr 23, 2009 at 1:37 AM, Jack Lonsdale <lonsdale@unbc.ca> wrote:
On Thu, 2009-04-23 at 01:29 +0200, Markus Neteler wrote:
On Thu, Apr 23, 2009 at 1:13 AM, Jack Lonsdale <lonsdale@unbc.ca> wrote:
> On Thu, 2009-04-23 at 00:42 +0200, Markus Neteler wrote:
>> On Thu, Apr 23, 2009 at 12:38 AM, Markus Neteler <neteler@osgeo.org> wrote:
>> > On Thu, Apr 23, 2009 at 12:08 AM, Jack Lonsdale <lonsdale@unbc.ca> 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'
...
...
db.select alrf_subs_edge_edge_Interpolation | head -n 20
?
ID|Interp
1|667.828431
2|668.15324
...
apparently also fine (at least, columns and data are there).
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?
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
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_edge@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
On Wed, Apr 22, 2009 at 10:58 PM, Jack Lonsdale <lonsdale@unbc.ca> 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_edge@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
On Fri, 2009-04-24 at 23:51 +0200, Markus Neteler wrote:
On Wed, Apr 22, 2009 at 10:58 PM, Jack Lonsdale <lonsdale@unbc.ca> 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_edge@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
