[GRASS-dev] v.to.db problems if layer > 1

GRASS GRASS developer
1

I try to use v.db.addtable with a second layer but v.to.db apparently fails
(called by v.db.addtable):

# Spearfish
g.copy vect=roads,myroads --o
v.info -c myroads
v.db.addtable myroads table=extratab layer=2 columns="cat
integer,label varchar(100)"
...
Updating database...
100%
1 categories read from map <- BAD should be 6
...

v.db.select myroads layer=2
cat|label
                        <- empty, should have 6 cats

# compare layer1:
v.db.select myroads layer=1
cat|label
0|no data
1|interstate
2|primary highway, hard surface
3|secondary highway, hard surface
4|light-duty road, improved surface
5|unimproved road

-----------
# calling directly v.to.db
v.to.db myroads layer=2 option=cat col=cat qlayer=1
Updating database...
100%
1 categories read from map
6 records selected from table
0 records updated/inserted

There is something odd in vector/v.to.db/update.c if the layer>1 but I
cannot find it.
There is a loop
    for (i = 0; i < vstat.rcat; i++) {

I wonder why it doesn't loop over vstat.select.

?
Markus

PS: note today's changes in SVN of v.to.db

2

On 26/11/08 11:34, Markus Neteler wrote:

I try to use v.db.addtable with a second layer but v.to.db apparently fails
(called by v.db.addtable):

# Spearfish
g.copy vect=roads,myroads --o
v.info -c myroads
v.db.addtable myroads table=extratab layer=2 columns="cat
integer,label varchar(100)"
...
Updating database...
100%
1 categories read from map <- BAD should be 6

Why, roads has no features in layer two, so just by copying it and adding a new table to another layer, you do not add new categories in that layer. You would need 'v.category option=add layer=2' for that.

...

v.db.select myroads layer=2
cat|label
                        <- empty, should have 6 cats

# compare layer1:
v.db.select myroads layer=1
cat|label
0|no data
1|interstate
2|primary highway, hard surface
3|secondary highway, hard surface
4|light-duty road, improved surface
5|unimproved road

-----------
# calling directly v.to.db
v.to.db myroads layer=2 option=cat col=cat qlayer=1

Shouldn't this be:

v.to.db myroads layer=2 option=query col=cat qlayer=1 qcolumn=cat

?

Moritz

3

On Thu, Nov 27, 2008 at 12:10 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 26/11/08 11:34, Markus Neteler wrote:

I try to use v.db.addtable with a second layer but v.to.db apparently
fails
(called by v.db.addtable):

# Spearfish
g.copy vect=roads,myroads --o
v.info -c myroads
v.db.addtable myroads table=extratab layer=2 columns="cat
integer,label varchar(100)"
...
Updating database...
100%
1 categories read from map <- BAD should be 6

Why, roads has no features in layer two, so just by copying it and adding a
new table to another layer, you do not add new categories in that layer. You
would need 'v.category option=add layer=2' for that.

Well, I though v.db.addtable would take care of doing the v.category job for
me (see script).

...
v.db.select myroads layer=2
cat|label
                       <- empty, should have 6 cats

# compare layer1:
v.db.select myroads layer=1
cat|label
0|no data
1|interstate
2|primary highway, hard surface
3|secondary highway, hard surface
4|light-duty road, improved surface
5|unimproved road

-----------
# calling directly v.to.db
v.to.db myroads layer=2 option=cat col=cat qlayer=1

Shouldn't this be:

v.to.db myroads layer=2 option=query col=cat qlayer=1 qcolumn=cat

Ah, yes, sounds good.
Still I feel that v.db.addtable should add the cats.

Markus

4

On 27/11/08 09:36, Markus Neteler wrote:

On Thu, Nov 27, 2008 at 12:10 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 26/11/08 11:34, Markus Neteler wrote:

I try to use v.db.addtable with a second layer but v.to.db apparently
fails
(called by v.db.addtable):

# Spearfish
g.copy vect=roads,myroads --o
v.info -c myroads
v.db.addtable myroads table=extratab layer=2 columns="cat
integer,label varchar(100)"
...
Updating database...
100%
1 categories read from map <- BAD should be 6

Why, roads has no features in layer two, so just by copying it and adding a
new table to another layer, you do not add new categories in that layer. You
would need 'v.category option=add layer=2' for that.

Well, I though v.db.addtable would take care of doing the v.category job for
me (see script).

AFAIKS, it doesn't. I'm not sure I think that this would be a good idea, either, as it would indiscriminately attribute categories to all features in the map (e.g. boundaries and centroids, not only centroids), unless you add a type option.

I have the feeling that this would only complicate issues as too much would happen without the user really knowing, so I have a preference for leaving it to the responsibility of the user to create category values.

Probably the docs could be better about all this, though.

...
v.db.select myroads layer=2
cat|label
                       <- empty, should have 6 cats

# compare layer1:
v.db.select myroads layer=1
cat|label
0|no data
1|interstate
2|primary highway, hard surface
3|secondary highway, hard surface
4|light-duty road, improved surface
5|unimproved road

-----------
# calling directly v.to.db
v.to.db myroads layer=2 option=cat col=cat qlayer=1

Shouldn't this be:

v.to.db myroads layer=2 option=query col=cat qlayer=1 qcolumn=cat

And to respond to Peter's original query, i.e:

I have a vector layer FOO which is linked to two tables in layers 1 and 2.
The categories for each vector element are different in layer 1 and (e.g. a certain area may have the cat value "51" in layer 1 and a cat value of "42" in layer 2).
Let's assume that layer one has a VARCHAR column containing the names of the region (e.g. database_layer_1: 51,"Wolfenstein" database_layer_2: 42 )

If a new VARCHAR column is added to layer 2 by v.db.adcol,
how can the the names from layer 1 be copied into it?

it should actually be (assuming that the varchar attribute in layer 1 is called 'name':

v.db.addcol FOO layer=2 col='name varchar(Size)'
v.to.db myroads layer=2 option=query col=name qlayer=1 qcolumn=name

Moritz

5

On 27/11/08 15:41, Patton, Eric wrote:

Well, I though v.db.addtable would take care of doing the v.category job for
me (see script).

AFAIKS, it doesn't. I'm not sure I think that this would be a good idea, either, as it would indiscriminately attribute categories to all features in the map (e.g. boundaries and centroids, not only centroids), unless you add a type option.

I have the feeling that this would only complicate issues as too much would happen without the user really knowing, so I have a preference for leaving it to the responsibility of the user to create category values.

Probably the docs could be better about all this, though.

I've added a note to the v.db.addtable docs about the need to use v.category to manually add cats to a new table in r34532 (trunk) and r34533 (grass6_devel).

It's not about adding cats to the table (v.db.addtable does this using v.to.db), but about the fact that if you add a table with v.db.addtable to a layer in which no feature has a category value, there won't be anything in the table you add. You have to first either run v.category option=add to add category values automatically, or use v.digit to add them, and then use v.db.addtable to see those cat values show up in the table.

Or you can use v.db.addtable first and then populate the table with a combination of v.category option=add + v.to.db or via v.digit.

I've attached a patch to description.html reflecting this, but am not sure that my formulation is very clear.

Moritz

(attachments)

v.db.addtable_desc.diff (1.1 KB)