[GRASS-dev] Re: [GRASS-user] v.centroids and cat values

Michael Barton michael.barton at asu.edu
Tue Jan 6 12:14:50 EST 2009



On Jan 6, 2009, at 10:00 AM, <grass-user-request at lists.osgeo.org> wrote:

> Date: Tue, 06 Jan 2009 17:19:58 +0100
> From: Moritz Lennert <mlennert at club.worldonline.be>
> Subject: Re: [GRASS-user] v.centroids and cat values
> To: Micha Silver <micha at arava.co.il>
> Cc: GRASS user list <grass-user at lists.osgeo.org>
> Message-ID: <496384AE.4000204 at club.worldonline.be>
> 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


More information about the grass-dev mailing list