On Jan 6, 2009, at 10:00 AM, <[email protected]> wrote:
Date: Tue, 06 Jan 2009 17:19:58 +0100
From: Moritz Lennert <[email protected]>
Subject: Re: [GRASS-user] v.centroids and cat values
To: Micha Silver <[email protected]>
Cc: GRASS user list <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 03/01/09 17:29, Micha Silver wrote:
I'd like to better understand the way cat values are assigned to
centroids when using v.centroids. I came across a problem when I
created
a new vector and digitized boundaries (v.digit -n) . Before
beginning
to digitize, I added some columns to the attribute table within
v.digit,
so that on completing each feature, I could fill in the values for
that
feature. I had one column for the label, and one column, GRASSRGB for
coloring. I did not bother to digitize centroids, but rather, after
completing the boundaries, and exiting v.digit, I ran v.centroids.
I was surprised to see that the cat value assigned to each centroid
*does not correspond* to the cat values of the surrounding boundary.
This has the unfortunate effect of showing incorrect labels when
running
d.vect with the display=shape,attr option, since the attribute is
taken
from centroid, and not from its surrounding boundary. In addition,
when
coloring with the d.vect -a option, the boundaries get the correct
color
from the GRASSRGB column, but the fill color is also wrong, since the
fill color is again taken from the attributes of the centroid. And
the
centroid, with a different cat value, goes to the wrong row of the
attached attribute table. This behavior is certainly undesirable,
unless I'm missing something basic??
My workaround was to delete all centroids, then go back into v.digit,
and digitize each centroid, while being careful to choose it's cat
value
manually, and set each one to the correct cat of the surrounding
boundary by choosing "Manual Entry" instead of "Next not used" mode
for
categories.
So, is there some way to create centroids, such that they
automatically
get the same cat value as the boundary?
Normally, the "best practice" is to digitize boundaries without
category
values (unless you specifically want information concerning the
boundary, not the area it contains) and then digitize the centroids
with
category values and relevant attribute data.
In your case, the easiest way out would seem to be v.distance, i.e.:
- v.centroid in=YourBoundaries out=YourMap
- v.db.addcol YourMap column="b_cat int"
- v.distance from=YourMap from_type=centroid to=YourMap
to_type=boundary
upload=cat column=b_cat #this should find the nearest boundary for
each
centroid
- v.category in=YourMap out=YourMap2 option=del type=boundary
- v.reclass in=YourMap2 out=YourMap3 type=centroid column=b_cat
- db.copy from_table=YourMap2 to_table=YourMap3
- db.dropcol YourMap3 col=b_cat
- Now you should have a YourMap3 with centroids that are linked to the
correct attributes. If this is the case, you can safely do the next
step:
- g.remove vect=YourMap,YourMap2
This should be quite easy to make into a script module, or maybe
extend
v.centroids to optionally do this for you.
I still think that when an area is created, a centroid should
automatically be placed at some standard and logical place for each
area. Area centroids should be an integral component of area topology,
not a separate point that must be manually placed and manipulated.
Michael
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
