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…
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).
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.
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?
Thanks everyone for the support 
giovanni
Ops, wrong post. I wanted to send it to the users maling list.
I’ll post it there.
sorry,
giovanni
2011/12/1 G. Allegri <giohappy@gmail.com>
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…
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).
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.
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?
Thanks everyone for the support
giovanni
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