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

Nikos Alexandris nikos.alexandris at felis.uni-freiburg.de
Wed Nov 12 09:05:42 EST 2008


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



More information about the grass-user mailing list