In den Daten der amtlichen Vermessung existieren Liegenschaften (Insel-Liegenschaften), die genau in einem Punkt mit der Nachbarliegenschaft identisch sind (siehe CadastralWebMap). Dies führt dazu, dass der betroffene Stützpunkt mehrmals in der Definition der AREA aufgeführt wird und beim Datencheck eine Fehlermeldung verursacht (*** ERROR *** TOPO(AREA_TOUCH,errid=116) touching area at 2724898.872/1106523.778). Bietet INTERLIS eine Möglichkeit, solche Definitionen ohne Fehlermeldung zuzulassen? Wenn ja, wie lässt sich dies modellieren?
Kannst du den Datensatz auch mit ilivalidator prüfen?
Was meinst du mit „Grenzpunkt“. Den eigentlichen Grenzpunkt in der Tabelle „Grenzpunkt“ oder den Stützpunkt der Liniendefinition?
Kannst du eventuell das ITF zur Verfügung stellen?
Besten Dank für die rasche Antwort. Ich habe meine Fragestellung präzisiert (mit Grenzpunkt meinte ich den effektiven Stützpunkt der AREA). Sobald das ITF verfügbar ist, werde ich es gerne zur Verfügung stellen
Ich habe die Daten angeschaut. Ich glaube sie sind korrekt. Ich habe sie mit ilivalidator geprüft:
java -jar ilivalidator-1.13.0.jar --log ti.log --allowItfAreaHoles ti51920000md01_fed.itf
Die Option --allowItfAreaHoles ist wichtig, weil die Gemeinde Paradiso eine Enklave von Lugano ist. Sonst meldet ilivalidator, dass es ein Polygon gibt, dem ein Referenzpunkt fehlt.
Mit ili2gpkg das ITF in eine Geopackage-Datei umgewandelt, um sie in QGIS anzuschauen:
java -jarili2gpkg-4.10.0.jar --dbfile ti.gpkg --skipPolygonBuilding --disableValidation --models MD01MUCH24MN95I --keepAreaRef --defaultSrsCode 2056 --strokeArcs --nameByTopic --createTidCol --importTid --doSchemaImport --import ti51920000md01_fed.itf
--skipPolygonBuilding: Damit ich die einzelnen AREA-Linien erhalt.
--keepAreaRef: Damit der AREA-Referenzpunkt erhalten bleibt.
--createTidCol / --importTid: Damit die Original-TID (aus dem ITF) erhalten bleibt.
Es gibt im ITF 4 AREA-Linien mit besagter Koordinate. Diese findet man visuell auch in QGIS wieder (gelbe Linien):
Referenzpunkt sind ebenfalls vorhanden. Für mich sieht es i.O. aus. Eventuell mal beim Hersteller des anderen Checker nachfragen, was genau die Meldung bedeutet.
1 „Gefällt mir“
Das GIS-Team aus dem Kanton Neuenburg hat herausgefunden, dass es hierzu einen OGC-Standard gibt Dokument OGC-Standard welcher in Kapitel 6.1.11.1 Absatz c die Lösung beschreibt.
Laut OGC ist die folgende Definition nicht zulässig:
‚POLYGON((5 0, 10 0, 10 10, 0 10, 0 0, 5 0, 3 3, 5 6, 7 3, 5 0))‘
und ist folgendermassen zu definieren:
‚POLYGON((5 0, 10 0, 10 10, 0 10, 0 0, 5 0) , (5 0, 3 3, 5 6, 7 3, 5 0) )‘
Wie ist dies in INTERLIS 2.4 umgesetzt? Resp. hat dies überhaupt eine Auswirkung?
Im DMAV gibt es bei der Bodenbedeckung und den Liegenschaften vergleichbare Fehler.
Siehe auch ilivalidator Issue #331 und #442
Wie ist damit umzugehen?
Ich habe den DMAV-Datensatz von @Pascal mit 1.14.9 und der Option --simpleBoundary validiert, kriege jedoch genau denselben Fehler für diese Bodenbedeckung:
Error: line 18: DMAV_Bodenbedeckung_V1_0.Bodenbedeckung.Bodenbedeckung: tid 32354332-3139-3246-4535-433733343131: not a simple boundary (2755044.893, 1245915.725, NaN)
Info: see <valid.log> for more validation results
Info: AREA topology of attribute Geometrie not validated, validation of SURFACE topology failed in attribute Geometrie
Checke ich die Zusammenhänge nicht oder stimmt hier noch etwas nicht zusammen (oder beides)?
Weisst Du das @ceis ?
-
Wie ist das Polygon im XTF codiert?
-
Was genau erlaubt die Interlis-Spez?
Wie es in QGIS definiert ist, finde ich nicht primär wichtig. Ili2db versucht ja aus ili-validen Geometrien OGC-valide Geometrien zu machen.
Das Polygon ist rein über die äussere Umrandung definiert, siehe https://github.com/user-attachments/files/19651274/ili2db_topology_problem.zip
Für allgemeine Flächen ist diese Form m.E. gemäss INTERLIS 2.4 Referenzhandbuch erlaubt (“möglich”):
Wahrscheinlich liegts daran, dass der gemeinsame Punkt
<geom:c1>2755031.988</geom:c1>
<geom:c2>1245955.668</geom:c2>
ein Bogenpunkt ist. Und es darum wohl ein Bug ist?
(Der QGIS-Screenshot dient lediglich zur Visualisierung der Form - es bleibt ein ilivalidator-Thema)
Interessant. Der Bogenpunkt kann ja irgendwo auf dem Bogen sein und ist kein “richtiger” Stützpunkt. Darum würde ich dann sagen, ist das ein anderer Fall als wie in der Skizze und ein Datenfehler.
Ref-HB:
“Der Zwischenpunkt ist nur in der Lage von Bedeutung und gilt nicht als Stützpunkt des Linienzuges. Er soll möglichst exakt in der Mitte zwischen Anfangs- und Endpunkt liegen und mindestens die gleiche Genauigkeit (Anzahl Nachkommastellen) wie die Stützpunkte aufweisen. Ist kein Radius angegeben, ergibt sich der Kreisbogen aus Anfangs-, Zwischen- und Endpunkt des Kurvenstücks. Wird der effektive Radius angegeben, ist er für die Kreisbogendefinition massgebend. Der Zwischenpunkt legt nur noch fest, welcher der vier möglichen Kreisbogen der gewünschte ist.”
Das zitierte Bild aus dem 2.4 Referenzhandbuch ist falsch. Das richtige Bild ist:
Da sieht man: Variante c ist ungültig.
D.h. innerer Ränder müssen als eigene Randlinie definiert werden. (Das ist neu in 2.4 (und anders als in 2.3); die Motivation zu dieser Änderung war bessere Kompatibilität mit OGC/ISO Geometriecodierungen)
1 „Gefällt mir“
Danke @ceis ! Das erklärt auch meine Testergebnisse, bei welchen ich alle aufstossenden Bogenelemente aufgelöst und trotzdem dasselbe Validierungsresultat bekommen habe.
@Pascal Kontaktierst Du InfoGrips mit diesem Befund? Gemäss Header stammt die Codierung aus deren Feder:
<ili:sender>UNKNOWN</ili:sender>
<ili:comment>
dataset generated by xtfout version 2025.0, (c) infoGrips GmbH 2025
</ili:comment>
Die Figur 22 (Version 2.0 RefHB INTERLIS 2.4) und Abbildung 22 (Version 2.1 RefHB INTERLIS 2.4) haben unterschiedliche Beschreibungen. Jedoch beschreiben beide die Version 2.4 von INTERLIS. In Version 2.0 des INTERLIS 2.4 RefHB sind nach meiner Interpretation des Textes sowie der Bildbeschreibung alle Codierungen wie oben erlaubt. Dies Änderte sich mit Version 2.1 des INTERLIS 2.4 RefHB.
Wo werden solche Breaking Changes verwaltet und beschrieben, wenn nicht in der INTERLIS Sprach Version?
Siehe Seite 10 “Anmerkungen zur Version 2.1.0”: “Flächenberandung gemäss OGC/ISO”. Und in Kapitel 3.8.13.1 “INTER-
LIS schliesst sich aber einer verbreiteten Regelung (z.B. OGC/ISO) an und verlangt, dass alle
Punkte einer Randlinie (ausser Anfangs- /Endpunkt) disjunkt sein müssen. Die Varianten b und
c von Abbildung 22 sind im Transfer darum nicht zugelassen.”
1 „Gefällt mir“
Ein Test hat gezeigt, dass die besagte Geometrie aus Definition einer AREA mit Wiederholung von Stützpunktkoordinaten - #7 von Pascal so mit ili2db (ili2gpkg 5.3.1) importiert werden kann und beim Export in ein XTF (2.4) dann sauber mit einer exterior-Polyline und einer interior-Polyline beschrieben wird. Diese beiden polyline-Definitionen sind in diesem Beispiel in einem Stützpunkt identisch.
Diese Geometrie wird vom ilivalidator 1.14.9 dann auch fehlerfrei validiert.
(cc @Pascal )