On 06/01/09 22:18, Michael Barton wrote:
From: Benjamin Ducke <benjamin.du...@oxfordarch.co.uk> Subject: Re:
[GRASS-user] v.centroids and cat values Cc: grass-user
<grass-u...@lists.osgeo.org> Message-ID: <1559037892.138311231273729471.javamail.r...@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
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Reply via email to