[GRASS-dev] v.edit

[David Finlayson]

I agree with Michael. I think that we should strive to make the
topologic model as orthogonal as possible. More importantly, it should
be easy to understand and implement. Tools should enforce the model
not add to the confusion. One of the problems of operational GIS are
broken/unclean topology.

If we need more sophisticated topological entities than point, line,
area; then we should develop a higher-order topologic model that is
built out of the three primitive objects rather than hack the simple
model. For example, boundary lines for a single area with distinct
categories are merging the behavior of line entity with the area
entity. I think that is confusing.



On 6/6/06, Michael Barton <michael.barton at asu.edu> wrote:
> Jachym,
>
> See below
>
> 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: Jachym Cepicky <jachym.cepicky at centrum.cz>
> > Date: Tue, 6 Jun 2006 11:43:05 +0200
> > To: Wolf Bergenheim <wolf+grass at bergenheim.net>
> > Cc: GRASS developers list <grass-dev at grass.itc.it>
> > Subject: Re: [GRASS-dev] v.edit
> >
> > Hallo,
> >
> > great work
> >
> > On Tue, Jun 06, 2006 at 10:30:47AM +0300, Wolf Bergenheim wrote:
> >> Ok now v.edit's add functionality is completed. One can add
> >> point,line,area,boundary,centroid. Boundaries will not be given a cat.
> >>
> >> Adding an area tries to put a centroid in the geographic mean, and if it
> >> fails it will exit, with nothing added.
> >>
> >> if you give many co-ordinates when adding a point many points will be
> >> generated.
> >>
> >> The cat support includes support for many cat's and ranges. This is for
> >> instance supported:
> >> v.edit map=test cat=267,347-350,353,356-359 coords=...
> >> And if there are more points then given cats, the cat will just be
> >> increased by one. The example above will result in 10 cats:
> >> 267,347,348,349,350,353,356,357,358 and 359. If you give 11 point the
> >> eleventh point will get the next cat (which is 360)
> >>
> >> --Wolf
> >
> > Why should a boundary NOT have category too? How would you distinguish
> > two different types of boundary arround one area? Example on
> >
> > http://les-ejk.cz/tmp/boundaries.gif
> >
> > One country (Sachsen) has 2 different types of boundaries (country and
> > state).
>
> You can also think of this conceptually as 2 different areas (country and
> state) that overlay. Or the area can simply have 2 attributes or even 2
> layers (a state layer and a country layer). So there are a number of ways
> to represent this situation.
>
> As I said earlier, while it sometimes might be convenient for a boundary to
> have a cat (with possibility of attributes) separate from that of an area, I
> think it is better to make boundaries different from lines.
>
> A line can be open or closed, has a cat and attributes. It is a vector
> entity.
>
> A boundary, while internally structured like a line, is part of a complex
> entity called area. The complex area entity is composed of a closed line and
> a point, and has a single cat for the closed line/point pair.
>
> I think this kind of definition would make entity creation and management
> easier than it is now. A boundary that is not part of an area and is not a
> closed line is an odd, confusing entity IMHO. Could be convenient, I admit,
> but I think that we are better off without it.
>
> Michael
> >
> > I thing, it is usefull to have a possibility for adding category number
> > (and attributes) to boundary too.
> >
> > Or do I understand it wrong?
> >
> > Jachym
> >
> >
> > --
> > Jachym Cepicky
> > e-mail: jachym.cepicky at centrum.cz
> > URL: http://les-ejk.cz
> > GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
> > -----------------------------------------
> > OFFICE:
> > GDF-Hannover
> > Mengendamm 16d
> > 30177 Hannover
> > Germany
> > e-mail: cepicky at gdf-hannover.de
> > URL:    http://gdf-hannover.de
> > Tel.:   +49 511-39088507
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>


-- 
David Finlayson