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