G. Allegri wrote:
Mmm, sorry but I don't understand it.
The topological correctness (in a general meaning, beyond GRASS) states that
two polygons *cannot* overlap.
GRASS topological model admits overlapping areas (the build tool doesn't
complaint),
Only in special cases when areas were not cleaned, e.g. v.in.ogr -c.
Using the -c flag is not recommended and assumes that topological
cleaning will take place after import. If you continue working with a
not cleaned vector, you're on your own and GRASS assumes you have good
reasons for working with an unclean vector and that you know what you
are doing.
The build tool does not check for overlapping areas (in topological
terms, missing intersections where two boundaries cross each other),
for that you would need to use v.clean tool=break. Building topology
is a bit costly, therefore v.build (Vect_build()) does not check for
all possible violations, and it is recommended to use v.clean for
actual cleaning.
... but some modules produce wrong results with these areas. E.g.,
v.rast.stats collects data as if one of the areas were clipped and not
overlapping. I can explain it better, but it was just an example where GRASS
model admits a not clean area, but it silently fails...
Not surprising. v.rast.stats assumes non-overlapping areas. I guess
that if two areas overlap, the raster output will get the values from
the area processed last. A single cell can only hold one value.
So, GRASS is a bit "fuzzy" (*should* is an arbitrary proposition)... I
comment between your answer rows:
In some cases, overlapping polygons can be converted to a valid grass
vector, e.g. Landsat tiles (WRS2 coverage). The conditions are that
polygons are only partially overlapping, each polygon has a part that
does not overlap with any other polygon, the centroids are located in
that non-overlapping part, boundaries are not broken at intersections,
and it helps if nodes of boundaries are not not shared with nodes of
boundaries of other areas.
Overlapping areas *are* valid vectors, even if they aren't topologically
correct, right?
Overlapping areas are valid non-topological vectors and invalid
topological vectors, I would say.
You say "partially overlapping". What does it mean? My three polygons
overlap almost entirely (it is a synthetic layer for testing), the centroids
are located on the not-overlapping regions (i.e. the overlaps aren't areas,
nor have correctly broken boundaries) and v.build still accept them without
errors...
Almost entirely is not entirely, thus partially 
I don't understand where the rules you're listing are evaluated (and
described).
These rules are my understanding of the GRASS vector library and what
GRASS modules assume when processing vectors.
Nevertheless, even though these areas can be maintained in GRASS,
these areas are per definition topologically not clean.
Yes.
Ok, this confirms that GRASS model isn't strictly topological. It suggests
to be, to guarantee correct results (see the problem with v.rast.stats).
Well, you forced a topologically incorrect sample vector into GRASS,
overriding default settings and skipping the topological cleaning
step. If you did not do topological cleaning, you can not be assured
that the result is topologically clean.
In the case of your test vector, GRASS would be strictly topological
if v.in.ogr would not have the -c flag. Non-topological vectors (e.g.
anything coming from OGR) must be cleaned, otherwise the results is
not guaranteed to be topologically clean... The GRASS model is indeed
strictly topological for areas, but that means that non-topological
polygons must be converted to areas the way v.in.ogr does. Areas are
always constructed assuming topologically correct boundaries.
It seems to me that the confusion arises because you made use of
features that allow you to skip topological cleaning which is not the
default and not recommended.
Markus M
