Zwei aufeinander folgende Stützpunkte (SegmentEndPoints) dürfen in der Projektion nicht aufeinander fallen.
Diese Vorschrift verhindert, dass man bei der Verwendung von 3D-Koordinaten zwei aufeinander folgende Stützpunkte lagemässig direkt übereinander platzieren kann (Differenz nur in der z-Koordinate, x- und y- identisch).
Ein Anwendungsfall für dieses Szenario wäre das Routing durch einen Lift:
Kann mir jemand einen Grund nennen, weshalb es diese Einschränkung im RefHB gibt?
Welche Nachteile ergäben sich, wenn dieser Satz aus dem RefHB gestrichen würde?
Natürlich könnte man den Linienzug in zwei Objekte auftrennen und dann wäre die Vorschrift erfüllt. Aber das bildet allenfalls die Realität nicht wie gewünscht ab und zieht andere Probleme nach sich bei der räumlichen Verknüpfung von Start- und Endpunkt.
Wenn man 3D-Daten oder 2.5D-Daten hat, dann gibt es im Modell wohl eine COORD3-Definition. In deinem Lift-Anwendungsfall sind die Z-Koordinaten verschieden, die (3D-)Punkte also nicht am gleichen Ort, auch wenn die Y- und X-Koordinate identisch sind. Genau so sollte man IMHO auch für die Ebene argumentieren können: Zwei Punkte können beispielsweise die identische Y-Koordinate haben, aber wenn die X-Koordinate verschieden ist, sind das zwei unterschiedliche Punkte.
Mir wäre nun nicht klar, wie man COORD3 in die Projektion bringen will, während die Z-Koordinate „verschwinden“ soll???
ein Nachteil bei Streichung aus dem RefHB wäre vermutlich, dass auch 2D-Punkte, deren Koordinaten sich weniger als die Koordinatenpräzision unterscheiden, gültig wären, was bei verarbeitenden GIS-Programmen oder Datenbanken zu Problemen führen dürfte.
Man müsste die Bestimmung so ändern, dass sie bezogen auf die Koordinatendimensionen gilt und nicht generell „in der Projektion“ – sprich: auf dem Plan.
In welchem GIS ist dies der Fall? Klar, es ist sicher nicht sehr schön, aber dass es einen Fehler verursacht, konnte ich noch nie feststellen. (Geomedia, ArcGIS, QGIS)
Alle geometrie Operationen wie z.B. die Gebietseinteilungs überprüfung (AREA und areArea) werden auf der 2D Projektion berechnet. Aufeinanderfallende Stützpunkte sind dabei nicht zulässig. Würde der entsprechende Statz aus dem RefHB gestrichen, müssten vor solchen Berechnungen die Überzähligen doppelten Punkte, die sich nur in der Z-Koordinate unterscheiden entfernt werden oder im RefHB bei jeder dahingehend eingeschränkten Funktion diese Einschränkung entsprechend dokumentieren. Ich gehe davon aus, dass bei der Erarbeitung des Standards einfacher gewesen ist, diese Einschränkung allgemein zu formulieren.
ah, ich habe gemeint, dass (z.B. in QGIS bzw. PostGIS) bei der Datenverarbeitung, Import/Export etc. beispielsiwese duplicate Nodes entstehen können, wenn die Daten gemäss Modell auf das Raster aus der Koordinatendefinition gesnappt werden – meist Millimeter.
Als «Direktbetroffene» klinken wir uns gerne mit ein:
Mit dem Projekt Verkehrsnetz CH bei swisstopo arbeiten wir mit topologischen Netzen in 3D. Das Produkt Basisnetz (swissTNE) ist speziell ein intermodales Netz, das somit die 3D-Verknüpfung verschiedener Verkehrsträger gewährleistet. Darin bilden wir beispielsweise Liftanlagen (mit exakt übereinaderliegenden Stützpunkten) ab, welche wir als gültige Geometrien validieren wollen.
Wenn wir SwissTNE im .xtf-Format exportieren und mit dem ilivalidator überprüfen, finden wir Fehler genau an den Stellen, an denen sich Vektoren mit identischen X,Y-Koordinaten in Z-Koordinaten unterscheiden.
Einen weiteren Aspekt (@emabike1977 ) möchten wir bei der Gelegenheit noch einbringen:
Wenn wir aus dem Kontext unseres spezifischen Projekts heraustreten und einen Blick auf die geplante Roadmap für den ÖREB-Kataster werfen, stellen wir fest dass ab 2027 ist ein schrittweiser Übergang zu 3D geplant ist.
Der Bundesrat hat am 10. Januar 2024 bei den Kantonen, den politischen Parteien, den gesamtschweizerischen Dachverbänden der Gemeinden, Städte und Berggebiete, den gesamtschweizerischen Dachverbänden der Wirtschaft und den interessierten Kreisen zur Änderung des Bundesgesetzes über Geoinformation (Geoinformationsgesetz, GeoIG) zwecks Schaffung der gesetzlichen Grundlagen für den Leitungskataster Schweiz ein Vernehmlassungsverfahren durchgeführt.
Die Umsetzung des Leitungskatasters, ähnlich wie die Anforderungen der kommenden Jahre im Zusammenhang mit dem ÖREB-Kataster, führen dazu, dass detaillierte Daten in drei Dimensionen verwaltet werden müssen, um die korrekten topologischen Beziehungen zwischen Objekten sicherzustellen. Es muss möglich sein, Geometrien zu prüfen, ohne dass aufgrund der Einschränkungen der Interlis-Check-Technik Fehler auftreten.
Wir verstehen die aktuelle Formulierung im Referenzhandbuch und die entsprechende Umsetzung im ilivalidator. Im Hinblick auf oben erläuterte, künftige Bedürfnisse möchten wir aber anregen, die unterschiedlichen Fälle auch im Referenzhandbuch zu unterscheiden/spezifischer zu beschreiben um künftig exakt übereinanderliegende Stützpunkte – wo notwendig und gewollt – zuzulassen.
@rmaron Heute (02.02.2024) wurde bei eCH die öffentliche Konsultation für Anpassungen am INTERLIS Referenzhandbuch gestartet. Dies scheint mir eine gute Gelegenheit, die Problematik einem grösseren Benutzerkreis darzulegen und von der eCH-Fachgruppe Geoinformation beurteilen zu lassen. Denn solange der erwähnte Satz bei der Definition eines Linienzuges in der heutigen Form im RefHB stehen bleibt, wird es wohl keine Anpassungen an den Validierungs-Werkzeugen geben.