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

Markus Neteler neteler at osgeo.org
Sun Aug 2 09:26:03 EDT 2009


On Sun, Apr 26, 2009 at 10:02 AM, Markus Neteler<neteler at osgeo.org> wrote:
> (moved here from grass-user)
>
> On Fri, Apr 24, 2009 at 11:51 PM, Markus Neteler <neteler at osgeo.org> wrote:
>> On Wed, Apr 22, 2009 at 10:58 PM, Jack Lonsdale <lonsdale at 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 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!
>>
>> 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...
>
> Fix proposal attached, using G__name_is_fully_qualified().
> I still don't like to use a G__ function but it seems to work.
>
> Submit?

Done.

Markus


More information about the grass-dev mailing list