v.category options sum, del, and add do nothing

[isaacullah]

In grass 6.4 on both windows and linux (ubuntu9.10), v.category seems to be broken. It'll make a new file, but none of the cats will be modified they way specified. Following the directions to patch to vector maps while keeping the data in their two databases intact, I used the "sum" function to renumber the cats of the second file starting from where the cats in the first one left off. The output vector file (from v.category) has the same cat numbers as the input! I then tried the "del" function. Same result. I tried even adding cats to a vector with no cats. Same result. Apparently, at the moment, v.category does nothing but make a new vector that is identical to the input vector.

[martinl]

Can you attach some sample commands describing this behaviour using data from nc_spm_08 dataset ​http://grass.osgeo.org/download/data.php ?

[isaacullah]

Here are text line outputs for v.category operation:

First display initial cats:

GRASS 6.4.0RC5 (nc_spm_08):~ > v.category input=busroute1@PERMANENT option=report
Layer/table: 1/busroute1
type       count        min        max
point          0          0          0
line           3          1          2
boundary       0          0          0
centroid       0          0          0
area           0          0          0
all            3          1          2

GRASS 6.4.0RC5 (nc_spm_08):~ > v.category input=busroute11@PERMANENT option=report
Layer/table: 1/busroute11
type       count        min        max
point          0          0          0
line           1          1          1
boundary       0          0          0
centroid       0          0          0
area           0          0          0
all            1          1          1

Next attempt to use sum function to add "2" to cats in busroute11@PERMANENT:

GRASS 6.4.0RC5 (nc_spm_08):~ > v.category input=busroute11@PERMANENT output=busroute11_mod_cats option=sum cat=2 --overwrite
WARNING: Vector map <busroute11_mod_cats> already exists and will be
         overwritten
Processing features...
Copying attribute table(s)...
Building topology for vector map <busroute11_mod_cats>...
Registering primitives...
1 primitives registered
434 vertices registered
Building areas...
 100%
0 areas built
0 isles built
Attaching islands...
Attaching centroids...
 100%
Number of nodes: 1
Number of primitives: 1
Number of points: 0
Number of lines: 1
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
v.category complete. 1 features modified.

Now report what v.category thinks it has done:

GRASS 6.4.0RC5 (nc_spm_08):~ > v.category input=busroute11_mod_cats@PERMANENT option=report
Layer/table: 1/busroute11_mod_cats
type       count        min        max
point          0          0          0
line           1          3          3
boundary       0          0          0
centroid       0          0          0
area           0          0          0
all            1          3          3

You can see, everything appears to work fine, but output of db.select shows cat not changed in table:

GRASS 6.4.0RC5 (nc_spm_08):~ > db.select table=busroute11_mod_cats
cat|ROUTE
1|11

The cat in the table is not changed!

[martinl]

v.category doesn't modify linked attribute table, the module just modifies vector feature categories. Use v.to.db to modify attribute data if required.

[cmbarton]

This is worth keeping open as an enhancement request rather than a defect. v.category dates to an era when vectors did not routinely have attribute tables, but only cat and label values like rasters.

For vectors with attribute tables, v.category becomes highly problematic. If it alters the cat values without altering the corresponding cat values in the associated attribute table, all links between the vector objects and their attribute data are irretrievably lost (or lost with out a great amount of work to retrieve them).

My suggestion is to add a flag that will allow v.category to simultaneously change the cat value in the vector AND the corresponding cat in the linked attribute table of same layer.

Because this enhancement request is a change in functionality, I've also bumped this to milestone 7.0

[martinl]

Replying to cmbarton:

This is worth keeping open as an enhancement request rather than a defect. v.category dates to an era when vectors did not routinely have attribute tables, but only cat and label values like rasters.

v.category is dedicated for modifying category values in 'coor' (geometry) file, it's not touching attribute data.

For vectors with attribute tables, v.category becomes highly problematic. If it alters the cat values without altering the corresponding cat values in the associated attribute table, all links between the vector objects and their attribute data are irretrievably lost (or lost with out a great amount of work to retrieve them).

Use v.to.db option=cat to add new records to attribute table.

My suggestion is to add a flag that will allow v.category to simultaneously change the cat value in the vector AND the corresponding cat in the linked attribute table of same layer.

v.category should do one thing - to manage layer/categories in geometry file.

Because this enhancement request is a change in functionality, I've also bumped this to milestone 7.0

I would not incline to modify v.category in this way.

[cmbarton]

v.to.db won't work for this. If a cat value was originally 3 and has been changed to 5, the link with the corresponding attribute record will be lost, because the attribute record still has cat=3. With this link gone, there is no way for v.to.db to know which is the correct record to upload the new cat value to. Example with new cat numbers incremented by 2 using v.category (this needs to be seen in the bug tracker for the formatting to make any sense).

---

'monospace'

OLD         NEW

vect  db    vect  db
1-----1     2--\   1
2-----2     4-\ \--2
3-----3     6  \   3
4-----4     8   \--4 

[isaacullah]

If v.category will not be changed, there at least needs to be a NEW module that will update/change cat numbers in BOTH the coor file AND the associated table(s). Merging of multiple vector datasets with attribute data is currently VERY difficult to do in GRASS with the tools as is. This is a BIG turn off for potential users.

[martinl]

Replying to cmbarton:

v.to.db won't work for this. If a cat value was originally 3 and has been changed to 5, the link with the corresponding attribute record will be lost, because the attribute record still has cat=3. With this link gone, there is no way for v.to.db to know which is the correct recor

I this case use db.execute and UPDATE statement.

Martin

[martinl]

Replying to isaacullah:

If v.category will not be changed, there at least needs to be a NEW module that will update/change cat numbers in BOTH the coor file AND the associated table(s). Merging of multiple vector datasets with attribute data is currently VERY difficult to do in GRASS with the tools as is. This is a BIG turn off for potential users.

This can be easily implemented in wxGUI using set of existing modules. CLI users are usually advanced enough to call v.category, db.execute separately.

[cmbarton]

The point is that there is currently a module accessible to all users that when used as directed will destroy the linkage between a file of vector objects and the attribute data that are linked to those objects. If there is no connection between the vector file and an attribute table, as was the case in GRASS 5, the way v.category works is not at all a problem.

In the GRASS of today, where the default is to have attribute tables linked with vector objects, this is a big problem. Once executed, the linkage destruction is irrecoverable. Imagine a file with 10,000 points and 10,000 linked records. At the best, running v.category would result in hair-tearing crisis. At the worst, the wrong vector objects would become imperceptibly linked with the wrong attribute records producing serious data corruption.

I'm not sure how db.execute will help reconnect this either. Once the cats in the vector objects are changed, there is no way to reconnect them except to inspect them one at a time and redo the data table. In any setting with attribute data linked to vector objects, running v.category seems very dangerous.

[mlennert]

Replying to cmbarton:

The point is that there is currently a module accessible to all users that when used as directed will destroy the linkage between a file of vector objects and the attribute data that are linked to those objects. If there is no connection between the vector file and an attribute table, as was the case in GRASS 5, the way v.category works is not at all a problem.

In the GRASS of today, where the default is to have attribute tables linked with vector objects, this is a big problem. Once executed, the linkage destruction is irrecoverable. Imagine a file with 10,000 points and 10,000 linked records. At the best, running v.category would result in hair-tearing crisis. At the worst, the wrong vector objects would become imperceptibly linked with the wrong attribute records producing serious data corruption.

I'm not sure how db.execute will help reconnect this either. Once the cats in the vector objects are changed, there is no way to reconnect them except to inspect them one at a time and redo the data table. In any setting with attribute data linked to vector objects, running v.category seems very dangerous.

I know I've been absent from discussions lately, but let me jump in here to support Martin and to correct what seems to be some misunderstanding about v.category: At no point will v.category destroy the link to an attribute table as it creates a new vector map. So the existing information in the input map is not touched.

Second, this is once again a case of wanting a module to do thing that some think to be the "logical" choice, but I'm not sure if we can so easily say what this choice is. For example, should we delete a the entry in the attribute table concerning a category number that is deleted with v.category option=del ? And just because I want to add category numbers to my map, does this automatically mean that I want new lines in the attribute table ?

I think that if you want more "user-friendly" solutions to specific problems, create a new module scripting the existing modules (just as in e.g. v.db.update, v.db.addcol, v.centroids, etc) , but don't modify the existing modules assuming some form of "standard" behaviour.

For the task at hand, i.e. (if I understand correctly) merging several vector maps with overlapping category numbers, the easiest solution seems to be v.patch -e which alters category numbers to avoid overlap:

v.patch -e in=busroute11,busroute11 out=patch_test --overwrite

v.category patch_test option=reportLayer/table: 1/patch_test
type       count        min        max
point          0          0          0
line           2          2          4
boundary       0          0          0
centroid       0          0          0
area           0          0          0
face           0          0          0
kernel         0          0          0
all            2          2          4

v.db.select patch_test
cat|ROUTE
2|11
4|11

Or you could write a script combining v.category (change category numbers), db.execute (change values in key column in attribute table) and v.patch.

In the light of this discussion, I would actually rather plead for v.category not creating any attribute table than changing the contents of that table. And I would agree that the v.category man page could be more explicit about some of these issues.

Moritz

[martinl]

Milestone renamed

[martinl]

It's not clear what is a status of this issue. Can we close?

[neteler]

Ticket retargeted after milestone closed

[mmetz]

Replying to mlennert:

In the light of this discussion, I would actually rather plead for v.category not creating any attribute table than changing the contents of that table. And I would agree that the v.category man page could be more explicit about some of these issues.

I agree that not creating any attribute table is probably the safest solution: it will not overload the module and at the same time makes it more explicit that category values have been changed, thus the old attribute tables have become meaningless.

[martinl]

All enhancement tickets should be assigned to 7.6 milestone.

[martinl]

Ticket retargeted after milestone closed

[martinl]

Ticket retargeted after milestone closed