#831: v.category options sum, del, and add do nothing
--------------------------+-------------------------------------------------
Reporter: isaacullah | Owner: martinl
Type: enhancement | Status: new
Priority: major | Milestone: 7.0.0
Component: Vector | Version: svn-develbranch6
Resolution: | Keywords: v.category
Platform: All | Cpu: All
--------------------------+-------------------------------------------------
Comment (by mlennert):
Replying to [comment:11 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
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/831#comment:12>
GRASS GIS <http://grass.osgeo.org>