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

Markus Neteler neteler at osgeo.org
Thu Apr 23 04:23:04 EDT 2009


On Thu, Apr 23, 2009 at 1:37 AM, Jack Lonsdale <lonsdale at 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 at 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 at osgeo.org> wrote:
>> >> > 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:
>> >> ...
>> >> >> 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


More information about the grass-user mailing list