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 <[EMAIL PROTECTED]>...
Patching vector map <[EMAIL PROTECTED]>...
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
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
