[GRASS-dev] Re: [GRASS GIS] #831: v.category options sum, del, and add do nothing

[GRASS GIS]

#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>