Aus Anlass meines Rückzugs aus der SOGI GGMM habe ich paar Gedanken zur Zukunft von Interlis festgehalten: Gedanken zur Zukunft von Interlis - Sourcepole
Auf Rückmeldungen gehe ich gerne in diesem Forum ein.
Pirmin Kalberer
4 „Gefällt mir“
“Ich würde mich deshalb auf gute Konverter für andere Schemaformate konzentrieren, …”: Was meinst du damit genau?
“sowie Tools zur Umwandlung in grafische Darstellungen zu entwickeln, welche wie z.B. Mermaid”: Gibt es bereits.
“Offizieller Datenaustasuch mit validierbaren GeoPackages”: Hier sehe ich das Problem, dass es mehrere Abbildungsmöglichkeiten von OO nach relational gibt. Ergo verschieden “richtige” Geopackages des gleiches Datensatzes. Finde ich nicht so toll. Ggf. binäres Format, wenn damit die Prüfung schneller geht oder die Datengrössen ridiculous gross werden (DMAV lässt grüssen).
Und mein Vorschlag: Weniger Arbeitsgruppen und dergleichen.
“Ich würde mich deshalb auf gute Konverter für andere Schemaformate konzentrieren, …”: Was meinst du damit genau?
Die Europäer haben Tools für Inspire, welche auf GML-Schemas basieren, der Rest der Welt baut Tools für JSON Schemas, die auch OGC im kommenden Modell-Standard verwendet. Die Schweiz könnte von diesen Tools profitieren, wenn es gute Transformationen zwischen Interlis- und GML/JSON/UML-Modellen gäbe. Als Nebeneffekt könnten Interlis-Modelle auch für andere interessant werden.
“sowie Tools zur Umwandlung in grafische Darstellungen zu entwickeln, welche wie z.B. Mermaid”
Ich habe mit Absicht Mermaid genannt, das in Github, Gitlab, JIRA, Obsidian, usw. unterstützt wird. Die VS Code Extension ist ein guter Schritt in diese Richtung.
“Offizieller Datenaustasuch mit validierbaren GeoPackages”: Hier sehe ich das Problem, dass es mehrere Abbildungsmöglichkeiten von OO nach relational gibt. Ergo verschieden “richtige” Geopackages des gleiches Datensatzes. Finde ich nicht so toll.
Hier sprichst du die Hauptproblematik aller XTF-Alternativen an. Im konkreten Fall von GPKG mit ilivalidator/ili2gpkg ist aber eine Konversion in ein valides XTF gewährleistet. Mit “validierbar” meine ich nicht nur den Dateninhalt, sondern auch die Abbildung des Modells und setze die daraus resultierende Konvertierungsmöglichkeit nach XTF voraus. Vielleicht werden in Zukunft auch noch weitere Abbilunden definiert und dann müsste wohl eine Auswahl an offiziellen unterstützten Mappings getroffen werden.
Mit GeoPackage haben wir heute ein bewährtes Format mit breiter Unterstützung und wir würden vielen Anwendern das Leben erleichtern, wenn wir die schwierigen Schritte wie Modell-Abbildungen den Spezialist:innen überlassen.
Dem Motto mehr Datenformate und weniger Arbeitsgruppen kann ich dafür teilweise zustimmen 
2 „Gefällt mir“
ich stelle auch fest, dass INTERLIS speziell in neu gedachten Dateninfrastrukturen kritischer betrachtet wird und dabei der Teil Modellbeschreibung gegenüber dem Transferformat das deutlich bessere Standing hat. XTF ist in den Downloadportalen ein seltener Gast.
Ich finde darum Pirmin’s Idee für die Zukunft absolut diskussionswürdig. Ein klares Bekenntnis zu etablierteren Datenformaten mit einer Konzentration auf die entsprechende(n) Schnittstelle(n) kann dabei für INTERLIS mittelfristig durchaus auch dienlich sein.
1 „Gefällt mir“
Mit GeoPackage haben wir heute ein bewährtes Format mit breiter Unterstützung und wir würden vielen Anwendern das Leben erleichtern, wenn wir die schwierigen Schritte wie Modell-Abbildungen den Spezialist:innen überlassen.
Ich glaube nicht, dass es das Problem löst: Je nach Modell wird das Resultat der Abbildung in einer relationen Datenbank sowieso herausfordernd und ist schlichtweg nicht anwenderfreundlich. Da kann man eventuell noch was rausholen (“smarter Mapping”). Aber andererseits müsstest du eine Abbildungsregel finden, die für alle Modelle und für alle Anwendungsfälle funktioniert. Und hier liegt vielleicht der Hund begraben: Man müsste die Sprache quasi auf INTERLIS 1 Niveau herunterbringen, damit man auch wieder einfach in relationen Datenbank erfassen kann. Alles andere überfordert sehr viele Anwender.
Die Spezialisten können heute bereits für jedes Modell verschiedene oder auch die passende Abbildung definieren und publizieren. Dies publizierte Abbildungsregeln kann dann von ili2gpkg automatisch verwendet werden und ein GPKG nach den Vorstellungen des Spezialisten hergestellt werden.
Modell-Abbildungen
Es kann auch vorkommen, dass verschiedene Abbildungen für Datenpflege, Visualisierung und Datenaustausch Sinn machen. D.h. auch bereits relationalen Interlis 1 - Modelle würden je nach Anwendung umgebaut werden.
Bei meinem Vorschlag geht es um den Datenaustausch mit Behörden, wo heute XTF vorgegeben wird. Ich könnte mir auch vorstellen, dass Behörden eine bestimmte Modellabbildung für GeoPackages vorgeben. Wenn sie ein GeoPackage als Vorlage publizieren, wäre das für viele Anwender eine Erleichterung.
Zusätzlich gibt es auch über die Norm hinausgehende GeoPackage-Funktionalität, wie das Einbetten eines QGIS-Projekts. Eine mitglieferte Kartendarstellung wäre ebenfalls eine grosse Erleichterung für Anwender und dürfte in einigen Fällen sogar helfen, die Datenqualität zu erhöhen.
Besten Dank für die interessante Diskussion. Beim Kanton Schwyz möchten wir unseren Anwenderinnen und Anwendern ebenfalls dabei helfen, die gesamte Kartendarstellung mitzugeben. Ebenfalls mit dem Ziel die Bearbeitung zu vereinfachen und Datenqualität insgesamt zu verbessern. Wir arbeiten im Moment an einer Lösung mit den UsabILIty Toppings des QGIS Model Bakers. Damit können wir die gesamte Symbolisierung und die ili2db-Einstellungen unseren Anwenderinnen und Anwendern zur Verfügung stellen.
1 „Gefällt mir“
Hoi zämen – Ich finde diese Diskussion im ganz allgemeinen Sinn sehr wichtig und ich erlaube mir, mich hier auch noch einzuklinken und ein paar (evtl. etwas kühne) Gedanken mitzugeben [Quelle: E-Mail von mir an Wiedmer, Gottsmann, Henrich, Ziegler vom 21.3.2024]
Allgemein kommt Bewegung in den „Daten-Markt“ mit dem EMBAG, NaDB, MODIS, I14Y usw. Auf Stufe eCH wird (Stand: März 2024) ein Themenantrag diskutiert, welcher im Wesentlichen will, dass anstelle der bislang in zahlreichen eCH-Standards enthaltenen, manuell geschriebenen XML-Schnittstellen- bzw. Format-Schemata eine „systemunabhängigere“, zukunftsfähigere Lösung entwickelt werden soll.
Nur: das gibt es längst, nämlich in der Form von eCH-0031: INTERLIS.
Dieses Beispiel zeigt, dass INTERLIS nach wie vor als allein innerhalb der Schweizer (Verwaltungs-)Geo-Gemeinschaft relevanter, hochspezialisierter Ansatz wahrgenommen wird. Dem Potenzial des modellbasierten Ansatzes kann man damit nicht gerecht werden.
In der Software-Entwicklung ist der modellbasierte Ansatz bzw. die modellbasierte Methode längst verbreitete, gängige Praxis. „Platform Independent Models“ (PIM) werden generisch in Programm-Code, „Platform Specific Models“ (PSM) umgesetzt.
Die modellbasierte Methode mit INTERLIS (und UML, XML-Schema) hat die Fähigkeit, dies unabhängig von „Geo“ ganz allgemein für Datenstrukturen zu leisten.
Ich glaube, die modellbasierte Methode mit UML und INTERLIS sollte neu gedacht werden. Dazu könnte die INTERLIS-Spezifikation (eCH-0031) modularisiert und als „The Data Language“ vermarktet werden (1):
Erster Teil, INTRODUCTION:
Beschreibung des modellbasierten Ansatzes, dessen Potenzial und Vorteile, insbesondere im Hinblick auf die syntaktische, formale und semantische Interoperabilität. Es darf auf die vollständige Durchgängigkeit bis hin zur Datenqualitätssicherung hingewiesen werden.
Zweiter Teil, CORE, PART 1:
Ein technisch-formal sauber definiertes Anwendungsprofil von UML-Klassendiagrammen, um die Kompatibilität zur internationalen Standardisierung aufzuzeigen und eine saubere Basis für die eigentliche Modellierung zu schaffen.
Klar definierte XMI-Kodierungsregeln, um die konzeptionellen UML-Modelle serialisieren zu können (soweit das im Rahmen des UML-Anwendungsprofil erforderlich ist).
Dritter Teil, CORE, PART 2:
Spezifikation der INTERLIS-CSL, also der formalen Sprache für konzeptionelle Datenmodelle — OHNE Raumbezugsaspekte/Geometrie!
Dafür inklusive OID (nur noch UUID?), Meta-Attribute, Einheiten.
Klar definierte Kodierungsregeln für XML-Transferdaten und allenfalls weiterer Formate. Anmerkung: eCH-0118 GML-Kodierung ist nicht relevant und soll aufgehoben werden.
Vierter Teil, EXTENSION GEOMETRY:
Erweiterung Geometrie. Evtl. inklusive 3D-Typen. Definition erforderlicher Funktionen. Sprach- und Kodierungsregeln.
Fünfter Teil, EXTENSION VIEWS + PORTRAYAL:
Sichten, evtl. Grafikdefinitionen <— hierfür sind die Resultate des Auftrags HEIG-VD zu berücksichtigen. Sprach- und Kodierungsregeln.
…, EXTENSION xyz…
Weitere zukünftige Teile/Module
…
(1) ob ein nachhaltiges Resultat ein wesentlich umfangreicheres eCH-0031 oder ein Paket mehrerer, abhängiger Standarddokumente sein soll, ist zunächst noch nicht relevant. Das OGC zeigt mit der API-Palette sehr schön, wie eine solche Standard-Gruppe funktionieren kann. eCH ist im Moment leider noch nicht so weit, Standards in der Form von Online-Ressourcen zu definieren, sondern als statische Dokumente.
Im Optimalfall würde eine strategische Partnerschaft mit dem BFS, eCH, DVS eingegangen werden können, um diese „INTERLIS-Verallgemeinerung“ zu realisieren.
Es müsste angestrebt werden, dass diese „Data Language“ auf Stufe eCH quasi als „Meta-Standard“ gilt für alle Daten- und Schnittstellenstandards: ohne Modell kein Standard. Dies ist, wohl bewusst, vielleicht illusorisch.
Im Rahmen der INTERLIS-Roadmap müsste die Neu-Standardisierung, die Entwicklung der dokumentatorischen Hilfsmittel (Anleitungen, Empfehlungen etc.), der Basis-Modelle und insbesondere die begleitende Weiterentwicklung der quelloffenen Software-Palette parallel geplant und ganz gezielt proaktiv vorangetrieben werden.
Das neue „INTERLIS 3.0“ muss vollständig rückwärtskompatibel sein zu INTERLIS 2.4. Es geht um ein strategisches „Neu-Labelling“, nicht um substantielle, materielle Erweiterungen!
Für den Übergang sind vollständig generische Migrationswerkzeuge bereitzustellen (Modell-Revisionen, Import/Export, DB-Migration etc.).
Mit begleitenden Marketingmassnahmen und den geeigneten strategischen Partnern (s. oben) ist die Einführung der „Data Language“ auf breiter Front voranzutreiben.
1 „Gefällt mir“