Open mcauer opened 2 years ago
I've added this to the corresponding ticket over at the oshdb repository: https://github.com/GIScience/oshdb/issues/311
I think we can agree that the is_valid
filter would work on the principles/definitions of the simple feature standard.
There is one additional aspect we have consider here: There is not always a 1:1 correspondence between invalid and valid OSM objects and the corresponding geometries produced by the OSHDB's geometry builder. This is because the OSHDB does perform a "best effort" to produce the most reasonable (and valid if possible) geometry output for every OSM input and also needs to perform some geometry "fixing" in cases where it is unavoidable. All of this also needs to be balanced with performance aspects.
input \ output | valid geometry | invalid geometry |
---|---|---|
valid OSM object | :heavy_check_mark: | "broken" by OSHDB geometry builder[^1] |
invalid OSM object | "fixed" by OSHDB geometry builder[^2] | :heavy_check_mark: |
[^1]: one example would be the non-handling of nested outer-inner-outer-inner situations – there are rare but actually valid OSM objects which can result in invalid geometries. [^2]: one example is that in order to associate inner rings with their corresponding outer part of a multi-polygon with more than one outer ring, the OSHDB needs to do an containment check which automatically removes all inner rings outside of any outer ring. This can produce a valid geometry for an actually invalid OSM object.
Use Case Description
An is_valid filter option would give the opportunity to:
Request Description
It would be very convenient to write a filter like:
fitler=geometry:polygon and geometry:is_valid and building=*
orfitler=geometry:valid_polygon and building=*
2nd option would even be more precise, because some cases (touching inner rings) are invalid for polygons but valid for osm-relations. On the other hands the first one is easier to negate and count all
not is_valid
objects.Additional Information
This is quite important for hex.ohsome.org because recently we computed a negative area aggregation value due to broken building geometries in the history.