[GRASS-user] Re: v.lidar.growing dbmi: Protocol error

[Markus Neteler]

On Thu, Apr 23, 2009 at 12:08 AM, Jack Lonsdale <lonsdale at 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 at 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