[GRASS-user] why v.patch -e produces cat column starting from 2?

[Moritz Lennert]

On 12/11/08 14:44, Nikos Alexandris wrote:
> On Wed, 2008-11-12 at 05:35 +0100, Nikos Alexandris wrote:
>> Why isn't the cat column starting from 1 after (v.)patching vector maps
>> (whose cat's start normally from 1)? Is it that my maps have somethig
>> wrong? Is there a specific reason?
> 
> (Following up with a long example)
> 
> I don't understand how v.patch and v.category work. Probably I
> misunderstand v.category. I kindly request for some assistance to
> clear-up my confusion.
> 
> Regards, Nikos
> 
> Help pages state:
> 
> 1. v,patch -e
> Copy also attribute table
> Only the table of layer 1 is currently supported
> 
> Question: Does this have anything to do with the cat starting from 2 in
> my example below?
> 
> 2. v.category option=del
> "v.category attaches, deletes or reports vector categories to map
> geometry. These categories (IDs) are used to link geometry object(s) to
> attribute record (from attribute table linked to vector map)."
> 
> del: delete category
> 
> Question: Do the v.category options have any "obvious" effect, i.e.
> something that the end-user can see in the attribute table?

No, v.category deals with the category number which are directly linked 
to the geometry. So, when you add, delete or alter category numbers, 
this does not affect the attribute table. It does, however, affect the 
way this table is linked to the geometry, as the category number 
attached to the geometry is the identifier linking this geometry to the 
key column in the table. In other words, if you delete the category from 
those features with category 5, then the line in the attribute table 
with key column = 5 has no geometry linked to it anymore.

> 
> 
> 
> # two imported shapefiles far away from each other (no overlaps)
> 
> # 1rst vector map: daun_test
> 
> # info of 1st map
> v.info -t daun_test
> 
> nodes=143
> points=0
> lines=0
> boundaries=142
> centroids=62
> areas=62
> islands=1
> faces=0
> kernels=0
> primitives=204
> 
> ## head of daun_test
> db.select daun_test | head -5
> 
> cat|RAS2X2_NR|BLOCK|BEFL_JAHR|block_id
> 1|2592_5562|daun|2005|3
> 2|2594_5562|daun|2005|3
> 3|2584_5560|daun|2005|3
> 4|2586_5560|daun|2005|3
> 
> ## tail of daun_test
> db.select daun_test | tail -5
> 
> 58|2578_5540|daun|2005|3
> 59|2580_5540|daun|2005|3
> 60|2582_5540|daun|2005|3
> 61|2584_5540|daun|2005|3
> 62|2586_5540|daun|2005|3
> 
> # 2nd vector map: trier_test
> 
> # topology of 2nd map
> v.info -t trier_test
> 
> nodes=240
> points=0
> lines=0
> boundaries=239
> centroids=110
> areas=110
> islands=1
> faces=0
> kernels=0
> primitives=349
> 
> ## head of trier_test
> db.select trier_test | head -5
> 
> cat|RAS2X2_NR|BLOCK|BEFL_JAHR|block_id
> 1|2558_5524|trier|2005|1
> 2|2552_5522|trier|2005|1
> 3|2556_5522|trier|2005|1
> 4|2558_5522|trier|2005|1
> 
> ## tail of trier_test
> db.select trier_test | tail -5
> 
> 106|2538_5492|trier|2005|1
> 107|2540_5492|trier|2005|1
> 108|2542_5492|trier|2005|1
> 109|2538_5490|trier|2005|1
> 110|2540_5490|trier|2005|1
> 
> # patching test1 with "-e" flag
> v.patch -e input=daun_test,trier_test out=patching_test1
> 
> Patching vector map <daun_test at PERMANENT>...
> Patching vector map <trier_test at PERMANENT>...
> Building topology for vector map <patching_test1>...
> 553 primitives registered            
> 954 vertices registered
> Building areas:  100%
> 172 areas built      
> 2 isles built
> Attaching islands:  100%
> Attaching centroids:  100%
> Topology was built
> Number of nodes     :   383
> Number of primitives:   553
> Number of points    :   0
> Number of lines     :   0
> Number of boundaries:   381
> Number of centroids :   172
> Number of areas     :   172
> Number of isles     :   2
> Intersections at borders will have to be snapped
> Lines common between files will have to be edited
> The header information also may have to be edited
> v.patch complete. 2 vector maps patched
> 
> # cat of patched map starts with 2
> db.select patching_test1 | head -5
> cat|RAS2X2_NR|BLOCK|BEFL_JAHR|block_id
> 2|2592_5562|daun|2005|3
> 3|2594_5562|daun|2005|3
> 4|2584_5560|daun|2005|3
> 5|2586_5560|daun|2005|3
> 
> ### Why not with 1??

I don't know, but is it a problem ? I don't have time to really dig into 
the v.patch code right, now...

In any case category numbers of a patch results using '-e' have no 
relation to category numbers in the original maps, as how would you 
handle the case with map 1 cats=1-3 and map 2 cats=1-3. At least the 
categories of map 2 will have to be changed.


[...]

> # v.category option=report
> v.category patching_test1 option=report
> 
> Layer/table: 1/patching_test1
> type       count        min        max
> point          0          0          0
> line           0          0          0
> boundary       0          0          0
> centroid     172          2        174
> area           0          0          0
> all          172          2        174




> # "v.category option=del" dos not remove categories in attribute table
> # Question: Is this right or wrong?

right. see above.

check with v.db.select instead of db.select and see what happens.


[...]

> # or
> v.category patching_test1 out=patching_test1_DELETED2 option=del cat=2
> 
> # gives the same attribute table output!?
> db.select patching_test1_DELETED2 | head -5
> 
> cat|RAS2X2_NR|BLOCK|BEFL_JAHR|block_id
> 2|2592_5562|daun|2005|3
> 3|2594_5562|daun|2005|3
> 4|2584_5560|daun|2005|3
> 5|2586_5560|daun|2005|3

again correct, as the table is not altered by v.category.

> ## What is the option "id" doing exactly?

It identifies features not by the category numbers, but by their 
internal id's. All features have id's, not all features have categories, 
but if you do, you can find out the id's of certain features with the 
help of v.edit tool=select, but normally, you won't ever have to worry 
about id's.

Moritz