[GRASS-dev] Re: [tlaronde: ticket #542: vector for GRASS 7]

[Markus Metz]

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,
>