Markus Neteler wrote:
Forwarded to the list upon request from T Laronde.
On Fri, Dec 4, 2009 at 3:27 PM, <[email protected]> wrote:
IMO, the first thing you should do is to create a lexicon, that is a
list of normalised words for GRASS and their meaning; this will avoid
the confusion between "lines" and "arcs" for example. Particularly,
when, for GRASS, two things are clearly distinct, even if in current
speaking there are fuzzy, you must impose two distinct words. Example:
arcs are the primitives of the vector definition (level 0). "Lines" are
geometrical objects deduced from primitives, as are "points", "faces"
and, perhaps, "volumes". Nodes are not geometrical objects : they are
topological creations. Centroïds are not geometrical objects neither, but
just a topological mean to _store_ attribute information : this is
attributed to a _geometrical_ object (hence: a "point", a "line", a
"face" or a "volume") if the point is equal to a point, along a line, on
a face or inside a volume. Note: I use special words, distinct words for
the topological relations so that in the _code_ saying "equal" means
point; saying "along" means line; saying "on" means face and so on.
Always distinct words for distinct meanings, and when possible, the
first letter, or the two first letters are sufficient to tell the
complete word.
Regarding the creation of a lexicon, I too think that this would help
both developers and users to better understand the grass vector
architecture. The general objective of the proposed changes is to more
clearly distinguish between different types of geometry features present
in a grass vector. That starts with distinguishing between primitive
features that are always present and features that only exist in topology.
In grass, primitive features that are always present are points, lines,
boundaries, centroids, faces, kernels. These primitives could also be
called arcs or polylines. Hamish argued against the term arcs, I would
argue against the term polylines, because points, centroids and kernels
are by no means polylines, they have only one vertex. Also a line
consisting of two vertices only is not a polyline in the strict sense.
Not felling too strong about it, it's just that "lines" as term for all
the stuff in the coor file is a bit confusing because a line can be a
point, line, boundary, centroid, face, or kernel.
Derived features only present in topology, i.e. not available when
opening a grass vector on level 1, are nodes, areas, isles, volumes.
The description of centroids given by Thierry sounds much more like the
description of categories. In grass, categories, not centroids, are used
to store attribute information. Only primitives (points, lines,
boundaries, centroids, faces, kernels) can have one or more, also
shared, categories, derived features do not have categories. Thus areas
also do not have categories; in this case attributes are linked to a
centroid which in turn is linked to an area. Centroids are not
topological creations, they are also available on level 1.
The level 0 is just the storage of the _arcs_. Even geometrical elements
"points" are stored as _arcs_ (two vertices identical).
In grass, points, centroids and kernels are stored with one vertex only.
BTW, level 0 in grass means "try to open on level 2 (with topology), if
that fails, issue a warning and open on level 1 (no topology)", IOW
level 0 in grass is the highest level supported by the given vector.
Even if other vector topology implementations use different terminology,
I would prefer to use the current grass terminology in this discussion
to avoid confusion.
May I say that the main problems are not to "improve" your current (new)
vector handling, but to clean the problems introduced. Specifically,
merging the Sites as Points in the vector was, IMO, an error. There is a
need for the grid (also called: raster but this is a bad name),
singularities (Sites) and topological vector (arcs).
The core construction of topology will not be changed by the proposed
changes. One advantage of the proposed changes would be that massive
point datasets (that was the purpose of Sites I think) would be stored
with the bare minimum of topology, that is, there would be no topology
in the strict vectorial sense, but other support structures that in
grass come with topology will be available, namely the category index
and the spatial index, both of which are IMO useful also for point datasets.
As for 3D or 4D, the current grass vector structure is not ready for
full 3D support. While changing grass vector structure, a 3D framework
can be added and then activated only at a later stage or activated in
several steps without breaking backwards compatibility (3D topology
algorithms are still missing and it will probably take some time until
we get kernels and holes attached to volumes, equivalent to centroids
and isles attached to areas).
Just a try to clarify what grass is currently doing,
Markus M
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
