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
