why v.patch -e produces cat column starting from 2?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

why v.patch -e produces cat column starting from 2?

Nikos Alexandris
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?

This causes me  endless headaches(!) and mess with v.dissolve,
v.db.update (based on a varchar column) and more.

Thank you, Nikos

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: why v.patch -e produces cat column starting from 2?

Nikos Alexandris
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?



# 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@PERMANENT>...
Patching vector map <trier_test@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??

# simple patching: works fine but, as expected, does not keep attribute
tables
v.patch input=daun_test,trier_test out=patching_test2

Patching vector map <daun_test@PERMANENT>...
Patching vector map <trier_test@PERMANENT>...
Building topology for vector map <patching_test2>...
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

# head of test2
db.select patching_test2 | head -5

cat
1
2
3
4

an EXTRA question:

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

db.select patching_test1_DELETED | 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

# v.category option=report
v.category input=patching_test1_DELETED option=report
## no output for patching_test1_DELETED. I suppose this is correct

# 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

# and report
v.category input=patching_test1_DELETED2 option=report
## gives nothing, same as with patching_test1_DELETED above

# or
v.category patching_test1 out=patching_test1_DELETED3 option=del id=3

# again the same 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
## should this be the expected output here?

# report on DELETED3 gives something which is identical with the
"original" vector!?
## What is the option "id" doing exactly?

v.category input=patching_test1_DELETED3 option=report

Layer/table: 1/patching_test1_DELETED3
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

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: why v.patch -e produces cat column starting from 2?

Nikos Alexandris
On Wed, 2008-11-12 at 14:44 +0100, 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 WORKING example using "v.patch -a"


g.copy vect=block_trier,blocks --o

# using -a flag
v.patch -a input="block_daun" output="blocks" --o

# head of blocks is what I expect: cat(s) start with 1 :-)
db.select blocks | head -5

cat|AREA|PERIMETER|RAS2X2_|RAS2X2_ID|RAS2X2_NR|BLOCK|STAND|BEFL_DATUM|
BEFL_JAHR|QUALITAET|block_id
1|4000000|8000|13141|13140|2558_5524|trier|01.10.2006|19.06.2005|2005||1
2|4000000|8000|13308|13307|2552_5522|trier|01.10.2006|19.06.2005|2005||1
3|4000000|8000|13310|13309|2556_5522|trier|01.10.2006|19.06.2005|2005||1
4|4000000|8000|13311|13310|2558_5522|trier|01.10.2006|19.06.2005|2005||1

# clean I guess is necessary when features overlap eachother.
v.clean blocks tool=break,snap,rmdupl,rmdac thres=1,1,1 out=blocks_clean

My question(s) about why does "v.patch -e" remain :-)

Kind regards, Nikos

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: why v.patch -e produces cat column starting from 2?

Moritz Lennert
In reply to this post by Nikos Alexandris
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@PERMANENT>...
> Patching vector map <trier_test@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
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: why v.patch -e produces cat column starting from 2?

Nikos Alexandris
On Wed, 2008-11-12 at 15:29 +0100, Moritz Lennert wrote:

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

Moritz,

I appreciate your time to explain this. Thank you.

Well, I am sure now about categories and their role :-) but I am unsure
now about whether it is a problem or not :D

When I bomb again into a related problem I'll report back.

Cheers, Nikos

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: why v.patch -e produces cat column starting from 2?

Moritz Lennert
In reply to this post by Nikos Alexandris
On 12/11/08 15:05, Nikos Alexandris wrote:

> On Wed, 2008-11-12 at 14:44 +0100, 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 WORKING example using "v.patch -a"
>
>
> g.copy vect=block_trier,blocks --o
>
> # using -a flag
> v.patch -a input="block_daun" output="blocks" --o
>
> # head of blocks is what I expect: cat(s) start with 1 :-)

That is logical, as here you do not alter the first map.

> db.select blocks | head -5
>
> cat|AREA|PERIMETER|RAS2X2_|RAS2X2_ID|RAS2X2_NR|BLOCK|STAND|BEFL_DATUM|
> BEFL_JAHR|QUALITAET|block_id
> 1|4000000|8000|13141|13140|2558_5524|trier|01.10.2006|19.06.2005|2005||1
> 2|4000000|8000|13308|13307|2552_5522|trier|01.10.2006|19.06.2005|2005||1
> 3|4000000|8000|13310|13309|2556_5522|trier|01.10.2006|19.06.2005|2005||1
> 4|4000000|8000|13311|13310|2558_5522|trier|01.10.2006|19.06.2005|2005||1
>
> # clean I guess is necessary when features overlap eachother.
> v.clean blocks tool=break,snap,rmdupl,rmdac thres=1,1,1 out=blocks_clean
>
> My question(s) about why does "v.patch -e" remain :-)

There is a fundamental problem with '-a' if the cat numbers in the two
maps are overlapping, but the attributes linked to these overlapping
numbers are different in the two maps:

GRASS 7.0.svn (nc_spm_06):~ > v.category map1 option=print
1
2
2

GRASS 7.0.svn (nc_spm_06):~ > v.category map2 option=print
1
2

GRASS 7.0.svn (nc_spm_06):~ > v.patch -e in=map1,map2 out=result
GRASS 7.0.svn (nc_spm_06):~ > v.category result option=print
2
3
4
6
7

=>no ambiguities between cats, starts at 2, but that is not a problem as
such

GRASS 7.0.svn (nc_spm_06):~ > v.patch -a in=map2 out=map1 --overwrite
GRASS 7.0.svn (nc_spm_06):~ > v.category map1 option=print
1
2
3
1
2

=> ambiguities between cats

This creates the following problem:

GRASS 7.0.svn (nc_spm_06):~ > v.db.select map1
cat|test
1|one
2|two
3|three

GRASS 7.0.svn (nc_spm_06):~ > v.db.select map2
cat|test
1|ten
2|twenty

GRASS 7.0.svn (nc_spm_06):~ > v.patch -a in=map2 out=map1 --overwrite

GRASS 7.0.svn (nc_spm_06):~ > v.db.select map1 cat|test
1|one
2|two
3|three

=> attributes 'ten' and 'twenty from map are gone since key fields have
to be unique in attribute tables

So, unless you are sure that there are not overlapping cat's in the maps
you are planning to patch, steer away from '-a'.

Moritz
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: why v.patch -e produces cat column starting from 2?

Nikos Alexandris
On Wed, 2008-11-12 at 15:50 +0100, Moritz Lennert wrote:
> On 12/11/08 15:05, Nikos Alexandris wrote:
> > On Wed, 2008-11-12 at 14:44 +0100, Nikos Alexandris wrote:
> >> On Wed, 2008-11-12 at 05:35 +0100, Nikos Alexandris wrote:
[...]
>
> There is a fundamental problem with '-a' if the cat numbers in the two
> maps are overlapping, but the attributes linked to these overlapping
> numbers are different in the two maps:
>
[...]
>
> => attributes 'ten' and 'twenty from map are gone since key fields have
> to be unique in attribute tables
>
> So, unless you are sure that there are not overlapping cat's in the maps
> you are planning to patch, steer away from '-a'.
>
> Moritz

OK, even more clear now.

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: why v.patch -e produces cat column starting from 2?

Moritz Lennert
In reply to this post by Moritz Lennert
On 12/11/08 15:50, Moritz Lennert wrote:
>
> So, unless you are sure that there are not overlapping cat's in the maps
> you are planning to patch, steer away from '-a'.
>

I added a short note about the problem to the man page of v.patch.

Moritz
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: why v.patch -e produces cat column starting from 2?

Eric Patton
In reply to this post by Moritz Lennert
Moritz Lennert-2 wrote
> ## 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.
I've added notes about the id parameter, as well as a hint about using the v.edit tool=select to discover geometry feature ids to the v.category manpage. r34275 for 7.0, and r34276 for 6.4.

~ Eric.