[GRASS-dev] topology model resume (and some proposals)

[Markus Metz]

G. Allegri wrote:
> I resume (first as a repeat to myself) what I've learned from the various
> email on the topic
>
> Vectors can be:
>
> LEVEL 1:
>  - no topology -> very limited use
> LEVEL 2:
>  - unclean topology -> limited use
>  - clean topology -> full support
>
> I previously thought that LEVEL 2 was only possible for clean topologies,
> and I was wrong...

I can see two reasons for this: 1) you need topology in order to
distinguish between topologically correct and incorrect features, e.g.
color coding in the vector digitizers, 2) topological cleaning and
building topology are two separate processes because topological
cleaning can be very time and resource consuming. Therefor topology
building assumes that vectors have been cleaned as much as possible.
>
> At the moment there isn't a tool to list the the uncorrect geometries from a
> topological point of view. v.build only checks some constraints, not all.
> The proposal is to extend it to check against all the rules that are
> required to consider a geometry topologically correct (an extended flag to v
> defaul.build maybe).

I'm working on it (new flag for extended checking for v.build).

>
> v.in.ogr builds and cleans (by default). It would be useful to have the
> "clean" phase available to be launched independently. I mean, something like
> an "automatic" flag for v.clean, that would operate the same cleaning as
> during the import of a vector.

Technically not possible because the cleaning procedures of v.in.ogr
can not be done with v.clean. One reason is that v.in.ogr
cross-checkes against the original OGR datasource, needed for proper
centroid attachment and adding overlapping areas (overlapping in the
original OGR datasource, not in the by then cleaned GRASS vector) to a
new layer.
>
> Conclusions: the topological correctness isn't a constraint for the vector
> topology data structure. GRASS haven't all the topology rules hard-coded
> (... or yes?). Most of thems (all?) are defined inside the code of v.build
> and v.clean, but I suppose that there isn't an autonomous
> library/functionality that provide the semantics of a "correct topology". Am
> I wrong?

v.build and v.clean mostly use library functions, plus some extra routines.

Markus M