I am pretty sure my description is correct with regard to grass6 vector
design.
The algorithms used to build and maintain topology will not change from
grass6 to grass7 (e.g. building areas from boundaries and centroids),
and the general design of grass topology will not change, it will merely
be stored much more efficiently. All topological features and functions
will be preserved, the API will not change much (apart from some new
functions that will hopefully do the same job faster), vector modules
will be largely compatible. I expect less conversion work than for
raster modules. IMO, the current grass6 vector design is stable and well
tested and I would change the inner workings only if there is a bug.
Correct me if I'm wrong, but it seems you disapprove of the current
grass6 vector design and would prefer to have the vector design of
grass4 (as in KerGIS, right?) back?
Markus M
t laronde wrote:
Hello,
I will only answer for some parts.
Except if Radim has radically changed the structure (and from a cursory
look some years ago, from the topology point of view, it was not the
case; but perhaps he had drastically changed things with the arcs
storage?), your description is not topologically correct. If your
description of the actual state is correct, then this is a mess
that has failed to capture the very nature of topology.
For example for this:
On Mon, Dec 07, 2009 at 09:37:55AM +0100, Markus Metz wrote:
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.
If you are right with the new vector engine, that is that the _mean_ to
add features that are not geometrical properties (that are arbitray
data), that is to _attribute_ (hence the correct name: attributes)
arbitrary information to geometrical elements, if this _mean_ has
been merged in the arcs file, it is an error.
There is no separate centroids and kernels (and what is the name for the
attribute of a geometrical line?), there are only a _topological mean_
to link external attributes to geometrical elements. It is (was at
least, and still is for KerGIS) a mean use to _store_ the information
about the link, just to be able to rebuild if needed from scratch, when
the geometrical elements do not exist (from arcs). But during run
time, an attribute can be linked to a geometrical element, or the
attribute can be changed without going by the "attribute insertion
point" (centroids, kernels and attribute point for a line are one
and only one thing; this is just the type of the geometrical element
they are used to link to that changes).
Yes this insertion point generally appears as the insertion point of
the label when drawing (on display or hardcopy). This is generally the
mean, by the GUI, to add an attribute to a geometrical feature. But
that's all.
If you think about the stuff, you see that it's not the only mean and it
has weaknesses. The first is that you need to search. The second is, if
you take a surface with overhangs, if you use only the planimetric
coordinates (x,y), the insertion points will match several objects (say
faces). One solution is to use a third coordinate, but the problem is
that the complexity increases (and the elevation is only generally
"half" a coordinate; it is not treated the same as x, y). Or you use the
index of the geometrical element to link. In this case, the attribute is
independant from the description of the geometry (since the building is
deterministic, rebuilding from the same geom file [coord] will lead to
the same indices). So in KerGIS, I use a separate file for linking
attributes, with _both_ the indices and an insertion point.
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.
If the support for Sites in vector means to handle them as a special
case without topology, this means that they have strictly nothing to do
there. The simple fact that you (GRASS) need to handle them in a special
way is because singularities, whether totally disconnected points
(sites, historical building etc. that have not really a link to the
other data except for "insertion points": the building is on this face)
or predefined connected points (mesh, triangulation), are special
and should not have been merged to start with.
Beauty is consistency. To put different logic in the vector stuff simply
because there is alien information is a highway to hell.
There is never a discover---for the discoverer at least---that is
unconnected to the existant. You find the next step; and from this the
next one, etc. There is a path. The topological stuff needs to be
profoundly understood first to see the strengths, the weaknesses
(strengths are more numerous than weaknesses for the GIS) and what can
be done, the questions arising and so on, to start wandering in the
vicinity. Start by studying CERL GRASS topology version. Then compare
with Radim's. And you will see what can be kept, what should be dropped
etc.
Before trying to "optimize" the current state, verify first that you are
not trying to "optimize" mistakes. When things are logical and work the
way they should, from the consistency standpoint, you can start thinking
about a way to speed. But this is a general solution, almost never hacks
(at least for a software like that; hardware drivers are another story.
Perhaps...).
Just my nickels,
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
