[GRASS-user] overlapping areas seem valid to v.build: why?

[G. Allegri]

I forced the -c flag to understand the side effects of doing it ;)
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 :)

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.
Conclusion: a vector topology doesn't need to be clean to exist.

giovanni

2011/11/30 Markus Metz <markus.metz.giswork at googlemail.com>

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20111130/2980b07a/attachment.html