AREA validation not working

[edigonzales]

There are a lot of polygon overlay errors which seem to be wrong. Or at least are not detectable without knowing where this should be.
npl_niederbuchsiten_vor_OP.xtf.zip

[beistehen]

Same problem here.

This was introduced with iox-ili-1.20.6 resp. ilivalidator-1.9.0 as topological checks are now calculated with rounded values.

As INTERLIS AREAs are stored as complete polygons in ILI2, these polygons might not overlap using the inital precision of the vertices. But when the vertices are rounded, overlapping may occur.

If you are working with FME and are allowed to alter the data, use the SliverRemover transformer (renamed AreaGapAndOverlapCleaner in FME 2018) to clean up the data before writing to xtf.

I havent't tested it but I guess this problem will not occur with ILI1 .itf files as the AREA geometry is stored in a different way as in ILI2. In ILI1 the boundary of an AREA geometry is stored only once for two adjoined polygons.

I think the check is done correctly using the rounded values (see discussion in #111). So the best solution would be to configure the production GIS in a way that the precision of the coordinates correspond to the precision of the model. Where this is not possible, the original data has to be preprocessed (using whatever tools like OGR/Python/FME) to round the coordinates to the model's precision and/or clean overlapping polygons.

Any other ideas?
Regards, Stefan

[edigonzales]

Wir haben immer noch Probleme mit AREA-Prüfungen. ilivalidator-1.11.0 meldet viele polygon overlay Fehler, z.B.:

Error: polygons overlay tid1 048b90c9-49f6-11e8-b58f-6c3be52716b4, tid2 38566449-4ee3-11e8-b58f-6c3be52716b4

Visuell sieht man keinen Fehler. Entlang der gemeinsamen Kante, habe ich im XTF die beiden Objekte punktweise verglichen. Auch da sehe ich keine Unterschiede.

Nach Rumsuchen im Code bin ich der Meinung, dass das Problem die https://github.com/claeis/iox-ili/blob/master/jtsext/src/main/java/ch/interlis/iom_j/itf/impl/jtsext/geom/CurvePolygon.java#L105 Methode ist. Im oben referenzierten Beispiel liefert e0.overlaps(e1) true zurück, obwohl sich die beiden Polygon m.E. nicht überlappen. Wenn ich e0.intersection(e1) berechne, liefert es mir eine GeometryCollection zurück mit vielen Linestrings aber auch auch einem sehr kleinen Polygon. Was nicht sein dürfte.

Testhalber reduziere ich die die Geometriegenauigkeit:

PrecisionModel pm = new PrecisionModel(0.00000001);
Polygon e0r = (Polygon) GeometryPrecisionReducer.reduce(e0, pm);
Polygon e1r = (Polygon) GeometryPrecisionReducer.reduce(e1, pm);

Die AREA-Prüfung liefert keine Fehler mehr zurück. Wo/wie genau jetzt sauber geschraubt werden muss, weiss ich nicht. Irgendwo gibt es sicher bereits einen Toleranzwert für numerische Fragestellungen.

Anbei das Original-XTF und die beiden Objekte in einer separaten Datei.

Archive.zip

[edigonzales]

Hier das Polygon, das bei der Intersection entsteht (und für den Overlap sorgt):

POLYGON ((2604206.5039950022 1257290.4653018722, 2604206.046209862 1257290.1045889524, 2604205.5837236517 1257289.749923546, 2604206.046209862 1257290.1045889526, 2604206.5039950022 1257290.4653018722))

Siehe 1257290.1045889524 vs 1257290.1045889526. Sonst wäre es wahrscheinlich für JTS (etc.) kein Polygon.

[edigonzales]

Tests mit claeis/iox-ili@144da26:

• Für den Datensatz aus dem ersten Kommentar werden noch drei Fehler gemeldet. Es handelt sich dabei um drei Polygone, die an einer Stelle zusammenkommen. Okolarkontrolle mit QGIS zeigt, dass es wohl wirklich noch Fehler handelt. Ein Kreisbogen ist sauber als Kreis definiert. Ein weitere wird bereits segmentiert geliefert.
• Mit dem Datensatz vom 8. April werden keine Fehler mehr gemeldet.
• Ebenfalls mit einem weiteren Datensatz, der vorher Fehler meldete.