[GRASS-dev] v.external with PostGIS and categories issue

GRASS GIS GRASS GIS developer
,
1

Hi,

I am having problems with a PostGIS table containg points linked into GRASS using v.external.

Here is what I did:
v.external dsn=PG:dbname=mydb layer=mytable output=mytable_grass --o
v.db.addcolumn mytable_grass col="mycolumn double precision"
v.what.rast map=mytable_grass raster=myraster column= mycolumn

v.what.rast gives warning message:
WARNING: 1 points without category were skipped

With
v.db.select mytable_grass
I can see that only 35 of the 36 points got values, while the last one is missing values. However, all points should be covered by the raster

Then I tried to troubleshoot by going through some examples in the GUI. Here I used the where-option in d.vect and the information button in the map window.
When I selected id=25 the record with id=21. The attribute column "id" has the value 21 and id_0 (which Query results window says is key column has the value 20, same as category value btw.)
When I selected id=35 the record with id=35. The attribute column "id" has the value 38 and id_0 (which Query results window says is key column has the value 34, again same as category value)

The table has a column named id in PostGIS already (and v.db.select says there is no column cat.

I suspect there is a shift between "Category" and "id" (the id column used by GRASS) of 1.
Anyone who can confirm, should I file a ticket?

Thanks for helping,
Cheers
Stefan

2

Hi again,

I saw some sentences were a bit incomplete, sorry for that.

The point is:
d.vect mytable_grass where="id=21" returns the record where the attribute "id" has the value 20, cat has value 18 and the internal GRASS id has the value 19 and

Furthermore:
d.vect mytable_grass where="name='foo'" returns the record with name = 'bar', which has id 19 (while record foo had id 20).

And finally,
d.vect mytable_grass where="id=1" returns a record with id 1, but it does not have any attributes attached to it.

I am working with GRASS 7.0 (r5820, on Ubuntu 12.04 with PostGIS 2.1.2dev), so maybe this issue is already fixed in trunk?

Cheers
Stefan