[GRASS-dev] db commands on vectors stored in another mapset

GRASS GIS GRASS GIS developer
1

Hi,

Using the spearfish dataset:

# start grass
grass63 grass/spearfish60/user1/

# dump the table associated with 'bugsites' in PERMANENT
db.select bugsites@PERMANENT

dbmi: Protocol error
dbmi: Protocol error

# one more try:
db.select bugsites

DBMI-DBF driver error:
Table 'bugsites' doesn't exist.
Error in db_open_select_cursor()

# now with some debugging:
db.select bugsites

D2/5: opendir /usr/local/grass-6.3.svn/driver/db/

D2/5: opendir /usr/local/grass-6.3.svn/driver/db/

D2/5: DBF: db__driver_open_database() name =
'$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/'
D3/5: tokens[0] = $GISDBASE
D3/5: -> /home/dylan/grass
D3/5: tokens[1] = $LOCATION_NAME
D3/5: -> spearfish60
D3/5: tokens[2] = $MAPSET
D3/5: -> user1
D3/5: tokens[3] = dbf
D2/5: db.name = /home/dylan/grass/spearfish60/user1/dbf/
D3/5: SQL statement parsed successfully: select * from bugsites
D2/5: find_table(): table = bugsites
DBMI-DBF driver error:
Table 'bugsites' doesn't exist.
Error in db_open_select_cursor()

# one more try with the @mapset notation:
db.select bugsites@PERMANENT
D2/5: opendir /usr/local/grass-6.3.svn/driver/db/

D2/5: opendir /usr/local/grass-6.3.svn/driver/db/

D2/5: DBF: db__driver_open_database() name =
'$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/'
D3/5: tokens[0] = $GISDBASE
D3/5: -> /home/dylan/grass
D3/5: tokens[1] = $LOCATION_NAME
D3/5: -> spearfish60
D3/5: tokens[2] = $MAPSET
D3/5: -> user1
D3/5: tokens[3] = dbf
D2/5: db.name = /home/dylan/grass/spearfish60/user1/dbf/
dbmi: Protocol error
dbmi: Protocol error

Is this the normal behavior? i.e. I can "use" raster and vector files
across mapsets, but why not vector attributes?

This is on GRASS SVN (31012) x86 and AMD.

As a work-around, it is possible to first copy the vector from one
mapset to another, and then the regular db.* commands will work.

Cheers,

Dylan

2

Dylan Beaudette pisze:

Is this the normal behavior? i.e. I can "use" raster and vector files
across mapsets, but why not vector attributes?

Because you are using DBF driver and your database is in:

$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/

(check with db.connect -p). This results in a different path from mapset to mapset. I guess this is a feature.

In order to use db.select cross-mapset with DBF driver you need to set database= explicitely.

Maciek

3

On Wednesday 16 April 2008, Maciej Sieczka wrote:

Dylan Beaudette pisze:
> Is this the normal behavior? i.e. I can "use" raster and vector files
> across mapsets, but why not vector attributes?

Because you are using DBF driver and your database is in:

$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/

(check with db.connect -p). This results in a different path from mapset
to mapset. I guess this is a feature.

In order to use db.select cross-mapset with DBF driver you need to set
database= explicitely.

Maciek

Thanks Maciek.

I see that the following works as expected:

# not logged into the 'PERMANENT' mapset
db.select bugsites database=/home/dylan/grass/spearfish60/PERMANENT/dbf/

I suppose that altering the behavior of the db.* commands would be dangerous,
and really should respect the current mapset's database connection.

How hard would it be to parse the @mapset, remove it in the actual SQL, but
pass it into the 'database' selection? Or more importantly, is there any way
to make typing 'database=/home/dylan/grass/spearfish60/PERMANENT/dbf/' any
less painfull?

Cheers,

Dylan

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

4

> Dylan Beaudette pisze:
> > Is this the normal behavior? i.e. I can "use" raster and vector
> > files across mapsets, but why not vector attributes?

Maciek:

> Because you are using DBF driver and your database is in:
>
> $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/
>
> (check with db.connect -p). This results in a different path from
> mapset to mapset. I guess this is a feature.
> In order to use db.select cross-mapset with DBF driver you need to
> set database= explicitely.

Dylan:

I see that the following works as expected:

# not logged into the 'PERMANENT' mapset
db.select bugsites
database=/home/dylan/grass/spearfish60/PERMANENT/dbf/

I suppose that altering the behavior of the db.* commands would be
dangerous, and really should respect the current mapset's database
connection.

How hard would it be to parse the @mapset, remove it in the actual SQL,
but pass it into the 'database' selection? Or more importantly, is
there any way to make typing
'database=/home/dylan/grass/spearfish60/PERMANENT/dbf/'
any less painfull?

you could try to use v.db.connect on the original vector and hard code
the database= there instead of using the variables. That would mean you
couldn't easily move/backup the map then and it would be tied to that
dir. Also I'm not sure it would work, but it might.

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ