[GRASS-user] v.centroids and cat values

Benjamin Ducke benjamin.ducke at oxfordarch.co.uk
Wed Jan 7 05:25:27 EST 2009


[forwarding this to the list for Micha, as it ended up in my mailbox ;) 
- Ben]

Thanks for the suggestions. Some additional comments below:

Benjamin Ducke wrote:
> GRASS modules that create area type features should already be generating
> centroids and adding categories to them automatically, shouldn't they? 
> As far as I am aware, e.g., v.in.ogr does this, so we are talking mainly 
> about adding centroid generation to the interactive digitizing tool, aren't we?
> The GRASS Vector lib API should have a function that finds a good centroid automatically.
> Or am I misled here (guess I am getting a bit confused myself, now)?
>
>   
As far as I know, v.in.ogr creates centroids automatically when you 
import a vector as type=boundary, and gives the centroids the same cat 
values as the boundaries.
> To be quite honest, I have always been a bit bewildered about the choice
> of using a centroid point for linking attributes to area features.
> Could anyone here fill me in on what advantage that has?
>
> Cheers (and a good New Year, btw.),
>
> Ben
>
> Michael Barton wrote:
>   
>>
>>     
>>> 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.
>>>
>>>       
Yes, I understand that now.
>>> 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 follow what you're suggesting, but as a general solution it seems like 
quite a convoluted process to go thru just to get attribute values, 
which were already entered, to display correctely.

>> 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
>>     
Michael: I think you brought this up in the past?  This seems to me the 
most "natural" approach. So what would be needed is:
1- v.digit should automatically add a centroid in some reasonable place 
for each closed boundary, and give it the boundary's cat value.
2- v.centroid should also automatically assign cat values identical to 
the surrounding boundary's values.

Regards,
Micha





------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.



More information about the grass-user mailing list