[GRASS-user] Re: [GRASS-dev] Re: grass-user Digest, Vol 33, Issue 10

[Moritz Lennert]

On 06/01/09 22:18, Michael Barton wrote:
>> From: Benjamin Ducke <benjamin.ducke at oxfordarch.co.uk> Subject: Re:
>> [GRASS-user] v.centroids and cat values Cc: grass-user
>> <grass-user at lists.osgeo.org> Message-ID: 
>> <1559037892.138311231273729471.JavaMail.root at mail.thehumanjourney.net>
>> 
>> 
>> Content-Type: text/plain; charset=utf-8
>> 
>> GRASS modules that create area type features should already be
>> generating centroids and adding categories to them automatically,
>> shouldn't they?
> 
> I don't know.
> 
>> 
>> 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?
> 
> In this case yes. I don't know about other modules.
> 
>> 
>> 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)?
> 
> This is a good idea. If it exists, perhaps it should be accessed by
> the digitizing module as the default.
> 
>> 
>> 
>> 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?

In a topological model where a boundary is boundary of two adjacent
polygons, you cannot link polygon attributes to the boundary as there
would be ambiguity as to which polygon these attributes are referring
to. So you need some way of unambiguously identifying the polygon. A
pseudo-centroid (i.e. not the geometric centroid, but one that in all
cases lies within the polygon) is one way of doing it and the one chosen
in GRASS's vector model. There might be other ways, but I'm no expert on
that.

> My bet is that is is a legacy of early GRASS vector design--a
> convenient way to create a polygon and give it some data. I still
> find it strange that a "boundary" can exist that is not a "line" and
> not a part of an "area".

> On Jan 6, 2009, at 11:06 AM, Patton, Eric wrote:
>> If the user just wants to digitize a "boundary without areas", then
>> they could just digitize linework and snap the vertices, couldn't 
>> they?

You might have a case where you need information concerning areas, but
also information concerning their boundaries, i.e. just as an example
off the top of my head, you could have migration balances for countries 
(polygons) and information concerning the permeability of the borders 
(boundaries). You could obviously use a separate layer of lines to 
represent your borders and link the attributes to that, but the GRASS 
model allows you to have both in the same map, with centroids in one 
layer linked to their attributes, and the borders in a second layer 
linked to theirs.

I have no idea how frequent such usage is, though...

Moritz