GDAL ohne ILI - und jetzt?

GDAL, ein Open Source Tool, welches Geodatenformate umwandeln/umbauen kann, hat schon jede/r genutzt, welche/r mit QGIS arbeitet. Denn im Hintergrund von QGIS läuft GDAL, wenn Vektordaten geladen werden (und wahrscheinlich auch bei anderer Gelegenheit, aber da lehne ich mich nicht zu weit aus dem Fenster).

GDAL unterstützt auch das Lesen und Schreiben von INTERLIS Transferdateien. Das kann man zum Beispiel daran erkennen, dass man eine INTERLIS 1 (.itf) oder INTERLIS 2 (.xtf) Datei per drag’n drop in ein QGIS-Fenster ziehen kann und man danach gefragt wird, welche Layer (hier: Tabellen resp. Klassen) man anzeigen möchte*. Dies alles wird durch GDAL im Hintergrund ermöglicht.

Wie andernorts im Forum bereits erkannt wurde, ist die Weiterentwicklung des INTERLIS-Treibers für GDAL etwas eingeschlafen. Das hat nun dazu geführt, dass einer der Hauptentwickler von GDAL INTERLIS auf die rote Liste der unterstützten Formate gesetzt hat. Nach Bestätigung von @pka, dem Maintainer des INTERLIS-Treibers bei Sourcepole, wurde am 23.01.2025 die Unterstützung zum Schreiben von INTERLIS aus dem Sourcecode von GDAL entfernt, so dass diese Funktion ab GDAL Version 3.11.0 nicht mehr zur Verfügung stehen wird.

Es stellt sich die Frage, was mit der Lesefunktion in GDAL in Zukunft geschehen soll. Wird sie überhaupt noch genutzt? In QGIS, wie oben beschrieben? Oder als Standalone-Werkzeug in einer Geodateninfrastruktur, zum Beispiel für einen automatisierten Datenumbau?

Wie erwähnt, ist die Entwicklung des INTERLIS-Treibers für GDAL in den vergangenen Jahren nicht vorangetrieben worden. Über die Gründe lässt sich spekulieren. Aber die Vermutung liegt nahe, dass der Treiber zu wenig benutzt wurde und auch niemand die Weiterentwicklung finanzieren mochte.

Als Themenverantworlicher „Tools“ bei GeoStandards.ch wäre ich interessiert daran zu erfahren, ob und wie GDAL mit dem INTERLIS-Treiber heute bei euch im Einsatz steht. Und wie ihr zu einer kompletten Entfernung des Treibers aus GDAL stehen würdet.

Die Diskussion ist eröffnet!

* falls das Plugin „Model Baker“ installiert ist, so kann dieses ebenfalls auf das drag’n drop einer INTERLIS Transferdatei reagieren.

3 „Gefällt mir“

Ich bin der Meinung, dass man den INTERLIS-Support aus GDAL entfernen kann. Man sollte sich darauf fokussieren z.B. etwas einfaches mit ili2gpkg machen, damit drag n drop in QGIS funktioniert. Model Baker scheint mir für quick n dirty zu kompliziert.

Der GDAL-Treiber unterstützt ili2.4 nicht. D.h. man müsste zwingend diese Version auch noch unterstützen. Und anscheinend hat der Entwickler keine Lust. Viele Möglichkeiten, die man eigentlich unterstützen müsste, gehen wahrscheinlich gar nie.

Wenn sich aber jemand findet, der hier mit Freude programmieren will, feel free. Aber künstlich am Leben halten und Geld reinbuttern, fände ich falsch.

1 „Gefällt mir“

In Model Baker eine Funktion einbauen, die nach drag’n’drop ili2gpkg direkt und ohne Constraints und Validierung ansteuert, um die Daten gleich anzuschauen - wie hier vorgeschlagen Watch XTF even more quick and dirty · Issue #1011 · opengisch/QgisModelBaker · GitHub - wär sicher eine Möglichkeit.

Spannend wäre noch die urprüngliche Frage an die Benutzer von @beistehen inwiefern GDAL genutzt wurde. Ist die simple Ansicht der XTF Daten der einzige Use Case?

3 „Gefällt mir“

Die Möglichkeit, INTERLIS per Drag&Drop direkt zu visualisieren finde ich extrem wertvoll, und aus diesem Grund ist die Entfernung von INTERLIS aus GDAL bedauerlich. Gleichzeitig ist das der einzige mir bekannte Use Case dafür.

Es wäre auf jeden Fall wünschenswert ein Tool zu haben, für das man nicht gleich mit einer DB-Import-Konfiguration konfrontiert wird, oder mit dem der Import dem User sonstwie maximal „bequem“ gemacht würde. Vielleicht mit „Standard“-Settings per ili2gpkg in ein GeoPackage in einem TEMP-Verzeichnis importieren, dem Vorschlag von @signedav folgend?

1 „Gefällt mir“

Ich kann das nur unterstützen - wenn INTERLIS auch von Geo-Fernen Personen genutzt werden soll, dann braucht es einen einfachen gratis INTERLIS Viewer. QGIS ist meines Wissens nach das einzige solche Tool - die anderen gibt es nicht mehr (früher ein Tool von Geocom - INTERLIS Viewer oder so ähnlich).

Mit GDAL können auch INTERLIS Transfer Files in QGIS angeschaut werden, von denen das Datenmodell unbekannt bzw. nicht vorhanden ist. Das erweitert den genannten Use Case doch erheblich. (Mir ist bewusst, dass das in einer idealen INTERLIS-Welt natürlich nicht vorkommt).

Ich weiss nicht, ob und wie ili2db damit umgehen würde / soll, wenn das Datenmodell nicht vorliegt.

Es würde die Repos nach dem Modell durchsuchen.

Die Frage ist, wie sich ili2db verhalten würde, wenn das Datenmodell in keinem Repo auffindbar wäre (in dem Sinne „unbekannt“)?
GDAL liest in einem Transfer File „einfach“ Tabelle um Tabelle bzw. Klasse um Klasse und setzt diese als Layer um, egal ob Modell bekannt oder unbekannt.

Ja, wenn es das Modell auf keinem Repo findet, kann es die DB nicht generieren. Ili2db baut die DB nach Modell korrekt, selbst wenn man Datentypen und Constraints deaktivieren kann. Aus einem XTF ist die Struktur nicht ersichtlich (zBs. sind optionale Attribute nicht als NULL erfasst, sondern gar nicht. Und folglich u.U. gar nicht ermittelbar).

Ein Tool, das einfach das XML parst, nach Elementnamen Tabellen und Layer generiert und die Geometrie in QGIS anzeigt, wär schon auch möglich zu bauen. Wenn auch nicht ganz so out-of-the-box wie mit der Nutzung von Modell + ili2gpkg. Wobei sich dann die Frage stellt, ob man nicht doch nochmals GDAL anschauen möchte…

Mich dünkt, dass wir uns hier auf einem arg theoretischen Level befinden. Wie das praxisrelevant sein soll, dazu fehlt mir einfach die Phantasie.

Ich habe Verständnis, dass man zu Beginn vielleicht nicht versteht, dass zu jedem XTF auch ein ILI gehört, aber dass es XTF OHNE Modell gibt? Ja, vielleicht in dunklen Zeiten, wo die SIA/VSA-Modell hinter der Paywall versteckt waren aber auch hier waren die Modell ja bekannt und eigentlich vorhanden.

@signedav Wie wäre das Verhalten von Modelbaker bei #1011 und dem Modell? Eigentlich muss man ili2db ja den Modellnamen mitliefern?

← wohin zeigt der Link?

Nicht sicher, ob ili2db den Modellnamen braucht oder diesen aus der zweiten Zeile (oder so) des XTF unter dem Element „Models“ heraus liest. Aber wenn nicht, dann wär das mit Model Baker easy, denn das macht er bereits im normalen Workflow.

Und ja, mit ili2db (und einem verfügbaren Modell) löst man vermutlich schon den Grossteil der Situationen.

Ich schliesse mich @el-wiss und @sjib an: Wenn wir Otto Normalverbraucher dazu bringen wollen, sich mit INTERLIS-Dateien abzugeben, dann muss die Einstiegshürde um ein xtf-File anzuschauen so tief wie möglich sein - keine Plugin-Abhängigkeiten, keine Kenntnisse des Datenmodells, reines Drag-n-Drop.

Zudem ist einer der grossen Vorteile im Alltag, dass der GDAL-basierte Ansatz keine formelle Korrektheit des Datenmodells voraussetzt. So können z.B. auch fehlerhafte Daten ohne eindeutigen Primärschlüssel angesehen werden.

1 „Gefällt mir“