Hi!
When starting to think about areas I played with v.digit a bit, and it seems that it creates different cat for the boundary and centroid. Is this what we want? I've always thought of them as kind of bound together, and thus would expect them to have the same cat. Am I totally off base here? What about islands? Should they have a cat at all, or should they have the same cat as the area that they belong to? Or something totally different?
--W
--
<:3 )---- Wolf Bergenheim ----( 8:>
On Mon, 29 May 2006 13:40:55 +0300 (EEST)
Wolf Bergenheim <wolf+grass@bergenheim.net> wrote:
Hi!
When starting to think about areas I played with v.digit a bit, and
it seems that it creates different cat for the boundary and centroid.
Only if you request it. You can digitize a boundary (any other feature
too) without category. Or with any cat you specify manually, eg. if you
want to attach the new feature to an existant datatable entry.
Is this what we want? I've always thought of them as kind of bound
together, and thus would expect them to have the same cat.
Am Itotally off base here? What about islands? Should they have a cat
at all, or should they have the same cat as the area that they belong
to? Or something totally different?
When digitising adjacent areas (sharing a common border line),
categories for boundaries are redundant, if not a disturbance. We
only need cats for centroids then. This also solves the problem of
islands. When the island boundary doesn't have a cat attached,
attributes belong only to centroids in the surroning areas - and no
problem.
That's at least the way I see it.
Maciek
--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/
At the risk of sounding naïve, don't boundaries without centroids behave
pretty much as lines? In this case the cat is attached to the boundary/line.
However, a boundary/centroid pair becomes an area. Then the cat is attached
to the centroid/point instead of the boundary/line.
It seems a good idea to somehow enforce this kind of organization as much as
possible to avoid the possibility of some weird hybrid of boundary with
attributes and centroids with attributes for the same area object. Althought
I'm sure someone can think of a real-world situation where this might be
useful, IMHO, it seems a better idea analytically and conceptually to keep
these separate. This leave us functionally with points, lines/arcs, and
areas/polygons. Boundaries are either lines (without centroids) or areas
(with centroids).
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Maciek Sieczka <werchowyna@epf.pl>
Date: Mon, 29 May 2006 21:46:47 +0200
To: Wolf Bergenheim <wolf+grass@bergenheim.net>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] AreasOn Mon, 29 May 2006 13:40:55 +0300 (EEST)
Wolf Bergenheim <wolf+grass@bergenheim.net> wrote:Hi!
When starting to think about areas I played with v.digit a bit, and
it seems that it creates different cat for the boundary and centroid.Only if you request it. You can digitize a boundary (any other feature
too) without category. Or with any cat you specify manually, eg. if you
want to attach the new feature to an existant datatable entry.Is this what we want? I've always thought of them as kind of bound
together, and thus would expect them to have the same cat.Am Itotally off base here? What about islands? Should they have a cat
at all, or should they have the same cat as the area that they belong
to? Or something totally different?When digitising adjacent areas (sharing a common border line),
categories for boundaries are redundant, if not a disturbance. We
only need cats for centroids then. This also solves the problem of
islands. When the island boundary doesn't have a cat attached,
attributes belong only to centroids in the surroning areas - and no
problem.That's at least the way I see it.
Maciek
--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko
najlepsze z nich!
http://katalog.panoramainternetu.pl/
When starting to think about areas I played with v.digit a bit, and
it seems that it creates different cat for the boundary and centroid.
Any feature has the ability to have a cat assigned to it (v.category
type=). That doesn't mean it _should_ have a cat assigned to it for
normal use.
Is this what we want? I've always thought of them as kind of bound
together, and thus would expect them to have the same cat.
boundaries typically won't have a cat number. An area takes on the
attributes of the centroid within it (which floats in the same space).
The boundary is just the boundary, the example was given of a boundary
that borders two areas - it's ambiguous to assign it to a given cat.
(but see "v.to.db option=sides" if you must)
Am I totally off base here? What about islands? Should they have a cat
at all,
no, they are "outside" or "not of" the main area.
It may be better to think of islands as holes in the area.
or should they have the same cat as the area that they belong to?
no, then they would be the same as the area. Think of labled "fields".
Or something totally different?
for most use the boundary is without cat, the islands/holes are without
centoriod (and thus no cat), and only the centroid provides cat and
attribute values for the surrounding area. AFAIU, "area" is a virtual
feature.
Hamish