sogeo.services -- Blog

Let's Hop #6 - Pixel für Pixel

Mon, 30 Mar 2026 00:00:00 +0000

Was wäre ein Spatial-ETL ohne Rasterunterstützung? Wir haben die gdal-java-bindings und das hop-gdal-plugin, das bis jetzt «nur» einen OGR-Input- und -Output-Transform bereitstellt. Wenn wir Rasterprocessing in Apache Hop wollen, müssen wir uns überlegen, wie wir das strukturieren. Ich habe mich entschieden, mich an der Struktur der neuen GDAL-Tools zu orientieren. D.h. nicht mehr ein gdal_translate und gdalwarp, die fast alles können und vor Optionen nur so strotzen, sondern «do one thing and do it well».

Et voilà, neu gibt es im hop-gdal-plugin folgende Raster-Transforms:

Als Beispiel will ich für unser Bürogebäude die Höhe berechnen:

Als erstes lese ich mit einem OGR-Input-Transform die Gebäude eines bestimmten Ausschnittes aus einer GeoPackage-Datei. Gleichzeitig clippe ich mit dem Raster Clip Transform von einer extern gehosteten Cloud Optimized GeoTIFF-Datei (mit den Gebäudehöhen aus LiDAR-Daten) den gleichen Ausschnitt und speichere die Datei temporär:

Weil der Raster Clip Transform nur eine einzige Row zurückliefert, können wir mit dem Stream aus dem OGR-Input einfach das kartesische Produkt bilden, damit erhält jede Row des OGR-Inputs auch den Pfad der temporären, geclippten Rasterdatei. Anschliessend können wir diesen Stream mit dem Raster Zonal Stats Transform verbinden. Das GUI dieses Transforms (und auch anderer) ist noch verbesserungswürdig und irgendwie verwirrend (was ist hier was?). Erstes weil einfach schlecht strukturiert und zweites hat es wirklich viele Optionen und Möglichkeiten, weil vieles auch aus seinem Field eines Streams übernommen werden kann:

Es fehlt in SWT so etwas wie der <details>-Tag in HTML. Aber hey, es geht noch schlimmer und ich denke da an das Leuchturmprojekt (Zeit- und Leistungserfassung) der «digitalen Transformation» im Kanton:

Ich meine, wer um Herrgottswillen kommt auf eine solche Idee?! Aber egal, weiter mit Apache Hop.

In diesem Transform sind alle Statistiken gemäss dem GDAL-Rastertool möglich. Wir wählen Durchschnitt und Maximum (pro Gebäude):

Eine Berechnungsvariante in diesem Transform ist Row-By-Row (Geometrie für Geometrie im Stream). Anschliessend entfernen wir noch ein paar Attribute aus dem Stream und speichern die Daten in einer GeoPackage-Datei mit dem OGR-Output-Transform. Das Resultat:

Probiert es aus und meldet Fehler. Das Komplettpaket wurde mit dem verbesserten GDAL-Plugin upgedatet. Und das kostet euch gar nichts. Nicht mal ein Kafi/Gipfeli pro Tag. Wow.

HOP_JAVA_HOME=/Users/stefan/.sdkman/candidates/java/25.0.1-tem \
HOP_OPTIONS="--enable-native-access=ALL-UNNAMED -Xmx2048m" \
./hop-gui.sh

Let's Hop #5 - Geometrien bearbeiten, Layer vergleichen, Coverages prüfenº

Tue, 17 Mar 2026 00:00:00 +0000

In diesem fünften Teil meiner kleinen Serie zu Apache-Hop-Plugins geht es um das hop-geoprocessing-plugin. Das Plugin bündelt Geoverarbeitung für Apache Hop in fünf Transform-Familien: Geometry Operation, Spatial Predicate, Layer Overlay, Layer Aggregate und Coverage Operation.

Geometry Operation:

Die Familie Geometry Operation ist der grosse Werkzeugkasten für einzelne Geometrien. Sie arbeitet mit einem Input-Layer, umfasst 34 Operationen und verwendet das Ausführungsmodell Streaming. Das bedeutet: Es wird Zeile für Zeile gearbeitet, ohne den ganzen Layer zu puffern. Im RAM bleibt im Wesentlichen nur die aktuelle Zeile. Typische Beispiele sind Buffer, Centroid, Vereinfachung, Geometrie-Bereinigung oder ähnliche Bearbeitungsschritte auf Einzelfeatures.

Spatial Predicate:

Die Familie Spatial Predicate arbeitet mit einem Primary Input und einem Secondary Layer. Es gibt 9 Operationen. Technisch wichtig ist: Der Secondary Layer wird zuerst vollständig eingelesen, im RAM gehalten und anschliessend mit einem STRtree auf den Envelopes indiziert. Erst danach beginnt die Verarbeitung der Primary Rows. Entsprechend ist der Secondary Layer möglichst früh zu reduzieren.

Layer Overlay:

Die Familie Layer Overlay deckt klassische GIS-Fälle wie Intersection, Clip, Erase oder Identity ab, insgesamt umfasst sie 4 Operationen und arbeitet ebenfalls mit primary + secondary input, ist technisch aber blocking per layer. Im RAM liegen dabei der vollständige Secondary Layer, ein STRtree auf dem Secondary Layer und optional zusätzlich eine Union-Geometrie des Secondary Layers. Es gibt hier auch die Berechnungsvariante FIXED_PRECISION, welche uns in PostGIS einiges besser dünkt, als die bisherige Variante.

Layer Aggregate:

Die Familie Layer Aggregate arbeitet mit einem Input-Layer und optionaler Gruppierung. Es gibt 4 Operationen (Dissolve- oder Collect-artige Operationen). Sie ist blocking per layer/group, also gerade nicht streaming. Stattdessen werden alle Zeilen eines Layers oder einer Gruppe gepuffert, bevor das Resultat emittiert wird.

Coverage Operation:

Die Familie Coverage Operation ist für Polygon-Coverages (INTERLIS-Area lässt grüssen) gedacht, umfasst 5 Operationen und arbeitet mit einem Input-Layer und optionaler Gruppierung und ist ebenfalls blocking per layer/group. Im RAM liegt der gesamte Layer oder die aktive Gruppe, ergänzt um den Zustand, den Coverage-weite Validierung oder Simplifizierung benötigt.

Kleines Beispiel gefällig? Machen wir gleich Nägel mit Köpfen und prüfen das Coverage «Waldplan» und bereinigen allfällige Fehler. Der Waldplan besteht aus 61'971 Polygonen.

Die Bearbeitung hat einiges gesehen: GRASS GIS, PostGIS, FME, ArcGIS und einen Bezugsrahmenwechsel durchgemacht. Entsprechend gibt es auch kleinere Unschönheiten wie Überlappungen und Löcher:

Meine Apache Hop Pipeline sieht so aus:

Einerseits prüfe ich den Waldplan, ob es Überlappungen gibt und gleichzeitig bereinige ich allfällige Überlappungen. Beide Resultate speichere ich in einer GeoPackage-Datei. Der Validator schreibt Linien-Geometrien (die betroffenen Linien-Segmente) und nicht einen exakten Ort.

Die beiden Transformer sind mehr oder weniger selbsterklärend:

Das Resultat kann sich sehen lassen. Zuerst ein Beispiel eines gefundenen Fehlers (die blauen Linien) und anschliessend die bereinigten Geometrien:

Das Ganze dauerte für beide Prozesse insgesamt 30 Sekunden.

Probiert es aus und meldet Fehler. Das Komplettpaket wurde mit dem geoprocessing-Plugin upgedatet.

HOP_JAVA_HOME=/Users/stefan/.sdkman/candidates/java/25.0.1-tem \
HOP_OPTIONS="--enable-native-access=ALL-UNNAMED -Xmx2048m" \
./hop-gui.sh

So, ich habe fertig. خلاص.

Oder vielleicht doch nicht ganz? Einige Ideen habe ich noch (Geometrie-Feldrechner, Python 3 Skripte einbinden, gdal_translate etc. und Ideen für Hop Server), aber nun brauchts eine Pause und ich will die gröbsten Bugs ausmisten, wenn ich bei Gelegenheit Apache Hop verwende und dann will ich mir auch noch was bezüglich guter Dokumentation überlegen.

Let's Hop #4 - Ich möchte Teil einer Validierung sein

Mon, 16 Mar 2026 00:00:00 +0000

Nach ili2db ist vor ilivalidator: https://github.com/edigonzales/hop-ilivalidator-plugin. Wahrlich nichts Grossartiges aber ohne geht es natürlich nicht. Auch hier das Beispiel, das alle XTF aus einem Verzeichnis liest und diese einzeln prüft:

Mit dem «Get file names« Transformer lesen wir alle INTERLIS-Transferdateien aus einem Verzeichnis:

Und dann kommt bereits das ilivalidator-Plugin:

Der erste Tab scheint mir noch harmlos zu sein. Natürlich kann man den Dateinamen entweder als statischen Text eingeben oder aus einem Field. Im zweiten Tab wird es interessanter:

Mit den beiden Optionen --config und --metaConfig kann man entweder statisch oder dynamisch oder via ilidata:xxx ein «Prüfprofil« angeben und muss sich nicht um die vielen Optionen und Validierungsmodellen etc. kümmern.

Der dritte Tab beinhaltet alle möglichen Optionen, um notfalls manuell eingreifen zu können:

Im letzten Tab kann man noch das Logfile und die optionalen Output-Felder bestimmen:

Ein erfolgreicher Run sieht so aus:

Was noch nicht implementiert ist, ist die Plugin-Unterstützung. Mich beschleicht ein Gefühl, dass es hier wieder zu Classloader-Issues kommt und nicht einfach mit dem Exponieren der Option gemacht ist. Irgendwie wird es schon gehen und muss es auch, das DMAV wartet…

Probiert es aus und meldet Fehler. Das Komplettpaket wurde mit dem ilivalidator-Plugin upgedatet.

HOP_JAVA_HOME=/Users/stefan/.sdkman/candidates/java/25.0.1-tem \
HOP_OPTIONS="--enable-native-access=ALL-UNNAMED -Xmx2048m" \
./hop-gui.sh

Let's Hop #3 - A native ili2db Integration for Apache Hop

Fri, 13 Mar 2026 00:00:00 +0000

Es musste ja soweit kommen. Here it is, ein ili2db-Plugin für Apache Hop. Es gibt das Plugin als Action wie auch als Transform. Korrekterweise müsste es wahrscheinlich «ili2db Input» heissen, da es sich momentan nur um den Import kümmert.

Die Idee ist, dass es nicht für jeden Flavor ein Plugin gibt, sondern ein ili2db-Plugin, welches die unterschiedlichen Flavor beinhaltet. Wie immer scheint mir eine der Herausforderung die schiere Fülle an möglichen Usecases und die sehr hohe Anzahl an Optionen zu sein. Wie man das sinnvoll dem Benutzer bereitstellt? Schwierig. Notfalls argumentiert man (aka Ausrede) einfach mit: «Profi-Software».

Was das Plugin (in Teilen kann) erkläre ich am Besten mit einem Transform-Beispiel: Ich möchte alle XTF-Dateien in einem Verzeichnis mit ili2gpkg in GeoPackages umwandeln. Die Pipeline sieht am Ende so aus («Text file output» ist nur noch fürs Debuggen):

Als erstes lesen wir alle Dateinamen mit der Endung .xtf aus einem Verzeichnis und bilden den Stream:

In unserem Fall aus dem Verzeichnis /Users/stefan/tmp/xtf/. Man darf ja nicht vergessen, nach der Auswahl des Verzeichnisses den «Add»-Button zu drücken. Sonst passiert nämlich nichts. Als nächstes fügen wir diesem Stream eine Spalte hinzu: Nämlich den Speicherort inkl. Dateinamen der GeoPackage-Datei, die aus jedem XTF erstellt werden soll:

Im Feld Formula schreibt man die Expression, die es braucht, um aus dem XTF-Dateinamen den Speicherort inkl. GPKG-Dateinamen pro Row zu erzeugen. Es ist halt so ein klassischer Feldrechner (interessanterweise basierend auf Apache POI. Leider fehlt sowas wie ein Extension Point, um eigene Funktionen registrieren zu können):

Nun kommt das Spannende. Der Import der Daten in eine GeoPackage-Datei:

Die ersten beiden Optionen dürften klar sein. Es stehen alle Funktionen zur Verfügung ausser - wie bereits erwähnt - Export. Connection kann nur ausgewählt werden, falls man den ili2pg-Flavor wählt. Bei GeoPackage oder anderen (zukünftigen) dateibasierten Datenbanken muss man den Namen der zu erstellenden Datei angeben. Das kann entweder statisch sein oder eben aus einem Feld aus dem Stream stammen. Wir wählen das im vorangegangenen Schritt erzeugte Feld gpkgPath. Ähnlich verhält es sich beim zu importierenden XTF. Auch hier kann man entweder statisch was hinschreiben oder wieder ein Feldname aus dem Stream wählen. Die XTF-Dateien müssen nicht lokal vorliegen, sondern sie können auch in einem INTERLIS-Datenrepository publiziert sein. In diesem Fall muss es einfach die ID des Datensatzes sein (ilidata:xxxx). Die anderen Optionen dürften wieder klar sein. Ich habe im Haupt-Tab noch die für mich wichtigsten (sehr subjektiv) Optionen exponiert. Man hat aber im zweiten Tab Zugriff auf alle Optionen:

Man kann auch mit Datasets arbeiten. Hier müsste ich noch schauen, ob das so implementiert ist, dass man es auch sinnvoll verwenden kann:

Zu guter Letzt hat der Transformer auch einige Output-Felder:

Das Resultat eines gelungenen Pipeline-Runs sieht so aus:

Probiert es aus und meldet Fehler. Das Komplettpaket wurde mit dem ili2db-Plugin upgedatet.

HOP_JAVA_HOME=/Users/stefan/.sdkman/candidates/java/25.0.1-tem \
HOP_OPTIONS="--enable-native-access=ALL-UNNAMED -Xmx2048m" \
./hop-gui.sh

Let's Hop #2 - Die Idee ist gut, die Vorschau ist besser

Mon, 9 Mar 2026 00:00:00 +0000

Nachdem wir Import und Export von Geodatenformaten erledigt haben, könnte man auf die Idee kommen, dass man die Geometrien innerhalb einer Pipeline auch anschauen möchte. In Apache Hop nennt sich das Preview:

Dank des nativen Geometriedatentypes erscheinen die Geometrien in tabellarischer Form in EWKT. Das ist zwar schön und gut aber Geometrien will ich in der Regel nicht als blossen Text anschauen müssen, sondern tatsächlich auch sehen: Hallo Geometry-Inspector-Plugin.

Das Geometry-Inspector-Plugin bettet sich neben den bereits bestehenden Preview-Funktionen ein:

Wählt man die Inspect Geometries Aktion, erscheint ein zweites Fenster mit verschiedenen Optionen:

Geometry source: Auto | Output | Input. Das ist notwendig, weil nicht jeder Transformer Output-Geometrien hat. Entsprechend müssen auch Input-Geometrien verwendet werden können.
Geometry field: Falls es mehrere Geometrieattribute hat, kann man das gewünschte wählen.
Sample size: Die Anzahl der Features, die gerendert werden sollen.
Sampling mode: FIRST | LAST | RANDOM. Welche Features sollen verwendet werden.

Zusätzlich kann man einen Hintergrundkarten-WMS verwenden:

Klickt man den Start-Button, sollte die Preview-Karte inkl. Featureinfo-Abfrage erscheinen:

Die Karte wurde mit GeoTools umgesetzt. GeoTools kennt zwar einige High Level Komponenten, wie z.B. JMapFrame, diese sind aber unsupported und passen nicht wirklich zu einem SWT-basiertem GUI wie Apache Hop. Aus diesem Grund habe ich nur das eigentliche Rendering und die Kommunikation mit dem WMS von GeoTools übernommen.

Die Kartenkomponente ist noch nicht allzu umfrangreich. So kann man das Aussehen der Geometrien oder das Koordinatensystem nicht ändern. Vom WMS wird jeweils das Koordinatensystem der Geometrien requestet. Ein Transformation findet aber nie statt. Ein komplettes Desktop-GIS nachbauen, will man zwar nicht, aber das eine oder andere Feature hat sicher noch Platz.

Am Schwierigsten war interessanterweise der Umgang mit dem nativen Geometrietyp. Dieser existiert zwar, aber er existiert nur als Plugin. Und soweit ich es verstanden haben, führt das zu Problemen, weil mehrere Plugins diesen Geometrietyp als Bibliothek mitliefern: Das ogr-Plugin streamt Records mit diesem Geometrietypen. Das Geometry-Inspector-Plugin erwartet einen solchen Geometrietypen zum Rendern. Weil aber die beiden Plugins in einem unterschiedlichen Classloader geladen werden, sind es eben nicht die identischen Java-Klassen. D.h. instanceof funktioniert nicht so wie man sich das vorstellen würde. Würde sich aber in Wohlwollen auflösen, wenn der Geometrietyp in den Hop-Kern wandern würde.

Probiert es aus und meldet Fehler. Das Komplettpaket wurde mit dem Geometry-Inspector upgedatet.

HOP_JAVA_HOME=/Users/stefan/.sdkman/candidates/java/25.0.1-tem \
HOP_OPTIONS="--enable-native-access=ALL-UNNAMED -Xmx2048m" \
./hop-gui.sh

Let's Hop #1 - Laying the Foundation

Fri, 6 Mar 2026 00:00:00 +0000

Apache Hop hat vielleicht ein halbes Momentum. Obwohl wir lieber ohne GUI unterwegs sind, fand ich bereits (Geo-)Kettle eine gute Sache. Es war schon immer eine gute Basis, um nicht mehr von FME abhängig zu sein. Hätte man vor 10 Jahren angefangen, wäre man nun 10 Jahre weiter. Lieber vergibt man aber als öffentliche Hand einen 44 Millionen Auftrag. Freihändig… weil alternativlos… Ich hoffe, dass das aber ein Generationenproblem ist und/oder ein geopolitisches, das sich dann so oder so von fast alleine löst.

Ausser bei GeoKettle war es immer das Problem wie man «Geo» nach Kettle resp. Apache Hop bringt. Bei GeoKettle war das Problem, dass es ein Fork war und nicht mittels einem Plugin-Ansatz funktionierte. Klar gibt es Workarounds wie alles in PostgreSQL/PostGIS oder DuckDB machen. Aber dann kann man sich fragen, warum man überhaupt noch Apache Hop verwenden will.

Es gibt vielleicht drei grössere Themenfelder damit man «Geo» in Apache Hop machen kann:

Es gibt keinen nativen Geometrie-Datentyp.
Es gibt keine Import- und Exportfunktionen von GIS-Datenformaten.
Es gibt keine Geoprocessing-Funktionen.

Atol CD hat ein GIS-Plugin für Apache Hop geschrieben, dass im Prinzip die drei Dinge löst: https://github.com/atolcd/hop-gis-plugins. Ich dachte mir dann, warum muss man eigentlich die ganzen Import- und Exportfunktionen nochmals programmieren, wenn es GDAL/OGR gibt? Und es gibt ein ogr2ogr-Plugin von OST: https://gitlab.ost.ch/apache-hop-plugin-sa/apache-hop-plugin-ogr2ogr. Wenn ich es aber richtig verstehe, ist das bloss ein Wrapper um das ogr2ogr CLI. Und da muss ich passen. Was bringt mir eine Java-Anwendung und damit verbunden die Einfachheit der Installation, wenn ich anschliessend noch eher non-trivial GDAL/OGR installieren muss? Und wie soll das gemeinsam verpackt und bereitgestellt werden? Für mich ein No-Go.

Ja, Apache Hop ist Java und GDAL/OGR ist in C++/C geschrieben. Ist das ein Problem? Jein. Es gibt schon seit geraumer Zeit Java-Bindings für GDAL/OGR. Das ist aber ein Mega-Geknorze und so richtig unterhalten sind sie meines Erachtens auch nicht mehr. Ich habe das paar Mal probiert und es war immer kein gutes Erlebnis. Das so ein Verheiraten aber auch gut funktionieren kann, zeigt z.B. der SQlite-JDBC-Treiber. Der verwendet ebenfalls native libraries.

Was nun? Java kennt seit Version 22 die Foreign Function & Memory API. Die Java Foreign Function & Memory API ist eine moderne Schnittstelle, mit der Java-Programme direkt auf nativen Code ausserhalb der Java Virtual Machine zugreifen können. Sie ermöglicht es, Funktionen aus in C oder C++ geschriebenen Bibliotheken aufzurufen, ohne auf ältere, komplexere Technologien wie JNI zurückgreifen zu müssen. Ein minimales Beispiel (für macOS):

mylib.c:

int add(int a, int b) {
    return a + b;
}

C-Bibliothek kompilieren:

clang -shared -o libmylib.dylib mylib.c

Main.java:

import java.lang.foreign.*;
import java.lang.invoke.MethodHandle;
import static java.lang.foreign.ValueLayout.*;

public class Main {
    public static void main(String[] args) throws Throwable {
        Linker linker = Linker.nativeLinker();

        // Bibliothek laden
        SymbolLookup lib = SymbolLookup.libraryLookup("libmylib.dylib", Arena.global());

        // Funktionssignatur: int add(int, int)
        MethodHandle add = linker.downcallHandle(
                lib.find("add").orElseThrow(),
                FunctionDescriptor.of(JAVA_INT, JAVA_INT, JAVA_INT)
        );

        int result = (int) add.invokeExact(3, 4);
        System.out.println("Result: " + result);
    }
}

Java kompilieren:

javac Main.java

Java ausführen:

java -Djava.library.path=. Main

Das Resultat ist:

Result: 7

Für GDAL/OGR ist das natürlich weitaus umfangreicher. Aber heute geht das - zumindest als PoC - eigentlich ganz mühelos: https://github.com/edigonzales/gdal-java-bindings/. Als erstes habe ich Bindings für ein paar CLI Tools gemacht (gdal_translate, ogro2ogr). Später musste ich natürlich die API aufbohren, da ich genau nicht nur z.B. einen Formatumbau machen will, sondern direkt auf einzelne Records zugreifen will, damit Apache Hop auch streamen kann.

Neben dem eigentlichen Herstellen der Bindings gibt es weitere Herausforderungen, die man irgendwie lösen muss. Spannend ist die Frage des Packaging. Die GDAL/OGR Binaries sind relativ gross (circa 1 GB) und natürlich OS-abhängig. D.h. wenn wir die Java-Bindings (inkl. GDAL/OGR) für die wahrscheinlich drei verbreitesten Betriebssysteme anbieten wollen, kommt das was zusammen. Momentan habe ich das so gelöst, dass es ein Core-Paket gibt und je ein Paket pro OS mit den Binaries. Die schiere Grösse kommt weniger vom Programm selber, sondern von den Ressourcen, die GDAL/OGR mitliefert (insb. Transformationsdateien). Ich habe noch eine «swiss»-Variante gemacht, die viel kleiner ist und für uns im Regelfall reichen sollte. Wenn ich die Bindings so paketiere, sind nachfolgende Arbeiten aber auch immer OS-abhängig. Für’s Erste lass ich es aber so. Ganz so schlimm finde ich es nicht, da ich immer noch in der Lage bin einfach self-contained Distributionen anbieten zu können.

Als nächstes muss man das eigentliche Apache Hop Plugin programmieren. Auch das geht heute halt schneller als früher: https://github.com/edigonzales/hop-gdal-plugin. Den nativen Geometrietyp habe ich aus dem AtolCD-Plugin extrahiert und als eigenes Plugin publiziert: https://github.com/edigonzales/hop-geometry-type-plugin/. Das kann aber nur eine temporäre Lösung sein. Ich erachte die Integration eines solchen Geometrietyps als einen ersten wichtigen Schritt. Wenn das nicht passiert, muss wieder jeder was basteln und es führt zu Inkompatibilitäten.

Wenn ich Apache Hop mit dem Plugin starte, habe ich neu einen ogr-reader und ogr-exporter:

Der ogr-reader Transformer sollte mehr oder weniger intuitiv sein:

Man könnte selbstverständlich noch andere ogr2ogr-Optionen bereits beim Import exponieren.

Die Pipelinevorschau zeigt die Records innerhalb der Tabelle der ausgewählten Geopackage-Datei:

Mit dem ogr-exporter-Transformer können wir die Geodaten in anderen (allen von ogr unterstützten) Formaten speichern:

So ganz alleine ergibt das hop-gdal-Plugin noch wenig Sinn. Spannend wird es später in Verbindung mit Geoprocessing-Operationen. Und was natürlich cool ist, man muss nicht mehr das Rad neu erfinden, um viele Geodatenformate in Apache Hop zu unterstützen.

Weil das Plugin aufgrund der Paketierung der Java-GDAL-Bindungs noch OS-abhängig ist, habe ich hier für macOS, Linux und Windows aktuelle Apache Hop Distributionen gemacht inkl. GDAL-Plugin: https://github.com/edigonzales/hop-distributions/releases

Weil wir die Java FFM-API verwenden, brauchen wird mindestens Java 22. In den Build-Pipelines verwende ich Java 23. Das wäre also die Mindestversion, um Apache Hop zu starten. Bei mir mache ich das so:

HOP_JAVA_HOME=/Users/stefan/.sdkman/candidates/java/25.0.1-tem \
HOP_OPTIONS="--enable-native-access=ALL-UNNAMED -Xmx2048m" \
./hop-gui.sh

Probiert es aus und meldet Fehler.

INTERLIS leicht gemacht #61 - INTERLIS goes AI

Mon, 12 Jan 2026 00:00:00 +0000

Während man noch darüber diskutiert, ob der Jurist in einem UML-Klassendiagramm selber Hand an ein INTERLIS-Datenmodell anlegen würde und so die Monate ins Land ziehen lässt, bin ich einen Schritt weiter: Warum überhaupt in einem GUI rumklicken oder INTERLIS-«Code» schreiben? Warum das nicht gleich der KI überlassen? Ich habe bereits im Oktober mit meinem INTERLIS-MCP-Server angefangen und wollte ihn nun weiterentwicklen Richtung brauchbar. Brauchbar heisst für mich, dass er ein korrektes Datenmodell zurückliefern kann resp. das LLM fähig ist aus Snippets ein korrektes Datenmodell zu erstellen und dass er selbstverständlich die meist genutzten Anwendungsfälle abdecken kann. Letzteres bleibt noch die Achillesferse, weil die Sprache halt schon sehr umfangreich ist. Genauso wichtig für brauchbar ist das Tooling drum herum. Da habe ich im Oktober eigentlich nicht viel gemacht, ausser hingekriegt, dass die Tools des MCP-Servers aufgerufen werden.

Den INTERLIS-MCP-Server gibt es als Docker Image hier. Der Quellcode zum Selberbauen hier.

Meine Idee wie man damit arbeiten kann, ist immer noch folgende: Ich habe in VS Code oder Eclipse Theia ein INTERLS-Modell geöffnet und ein Chatfenster. Im Chatfenster kann ich mit Prosaeingaben das Modell ergänzen oder verändern wie es mir beliebt. Aber beginnen wir beim Tooling noch einen Schritt vorher. Ich habe mich immer ein wenig gefragt, was bei einem MCP-Server eigentlich rauskommt? Die Spezifikation erklärt das zwar aber man will es sehen. Dazu gibt es den MCP Inspector. In meinem Fall rufe ich den Inspector mit diesem Befehl auf:

npx @modelcontextprotocol/inspector java -jar interlis-mcp.jar

Der Inspector bietet z.B. die Möglichkeit sämtliche Tools des Servers aufzulisten und die dazugehörigen Input-Parameter:

So bleibt das nicht irgendeine schwarze Magie, sondern man sieht wie Client und Server miteinander kommunizieren können. Der nächste Schritt ist das Erfassen des Servers in VS Code. Das geht mit dem Kommando MCP: Add Server …. Da klickt man sich durch, gibt das Startkommando des MCP-Servers an (siehe Inspector) und gibt dem Server einen eindeutigen Namen. Es öffnet sich die Datei mcp.json:

Man sieht im grauen Kleingedruckten, dass der Server bereits gestartet ist und 27 Tools anbietet. Als nächstes will ich via OpenAI-API Zugriff auf verschiedene LLM haben. Das geht mit dem Befehl Chat: Manage Language Models. Und hier dünkt mit das ganze VS Code Copilot Zeugs eher einschränkend. Man kann nur bestimmte Anbieter konfigurieren:

Die Konfiguration ist denkbar einfach, man muss den Provider aussuchen und den API-Key eintöggelen. Aber einen Drittanbieter (z.B. Infomaniak) mit einer OpenAI-kompatiblen API geht nicht. Modelle kann man einzeln freischalten (im Screenshot nur GPT-5-mini).

Der letzte Schritt ist das Erzeugen eines Custom Agents (Befehl: Chat: New Custom Agent …). Es öffnet sich eine Markdown-Datei mit <Namen>.agent.md>:

Im Header beschreibt man den Agenten und definiert auf welche Tools er Zugriff haben soll:

In der restlichen Datei macht man nun dem Agenten Vorgaben was er tun soll und was nicht. Bei mir sind das circa 330 Zeilen geworden, wobei ich sicher noch ein wenig ausmisten kann:

Endlich ist VS Code ready mir richtig beim Modellieren zu helfen. Dazu muss ich den INTERLIS-Agenten auswählen und das passende Modell:

Testen wir den Agenten und wollen alle INTERLIS-Text-Funktionen sehen. Er fragt zuerst nach, ob er überhaupt den MCP-Server verwendet darf. Das kann man relativ feingranular einstellen. Ich erlaube es ihm ohne ständig nachzufragen für diese Session:

Als nächstes lasse ich mir ein leeres Datenmodell erstellen:

Das Praktische an VS Code ist, dass ich einen Code-Block in eine neue, zu erstellende Datei kopieren lassen kann. Noch praktischer wird es wenn ich in einem Folgebefehl eine Klasse erstellen lasse und die neue ili-Datei als Kontext mitliefere (siehe kleiner Badge «MyModelA.ili» unter meinem Prompt):

Der Agent liefert mir ein Diff zurück, dass ich auf die bestehende ili-Datei anwenden kann:

Und wenn man im Chatfenster genau hinschaut, sieht man oberhalb den MCP Tool Call Ran validateIliModel - interlis-mcp (MCP-Server). Hier prüft der Agent das vollständige Modell auf syntaktische Korrektheit mit ili2c (das ebenfalls als Tool exponiert ist, dito Pretty Print).

Viel, wenn nicht fast alles, vom Verhalten des Agenten stecken in meinen circa 330 Zeilen. Unsicher bin ich, ob es sinnvoll ist, z.B. mehrere Modi anzubieten: immer ganzes Modell, nur Snippets oder Diff-Code-Blöcke. Da fehlt mir die Erfahrung wie gut man das dem Agenten beibringen kann.

Wie erwähnt, ist es schade, dass man nicht die LLM von Infomaniak in Copilot nutzen kann. Es gibt aber einen Haufen an VS Code Extensions, die man ausprobieren kann. Eines davon ist z.B. Continue. Der Aufbau und Konfiguration ist leicht anders und womöglich muss das Agenten-File jeweils auf das Tooling (und ggf. an die LLM-Familie) angepasst werden.

Was gibt es noch zu tun? Einiges:

Ich müsste mit einem Realweltbeispiel die wichtigsten Funktionen ergänzen (und vor allem prüfen).
Wie funktionieren Agenten in Eclipse Theia?
Den MCP-Server kann man auch gut in den besten INTERLIS-Editor dazupacken.
Reizen würde mich noch sowas wie ein «fractional compiler» der einzelne INTERLIS-Snippets auf syntaktische Korrektheit prüft (ili2c kann nur ganze Datenmodelle).

INTERLIS leicht gemacht #60 - INTERLIS IDE noch besser gemacht

Tue, 6 Jan 2026 00:00:00 +0000

Auch im neuen Jahr heisst das Motto wieder «INTERLIS macht Spass» und es gibt auch zukünftig viel Neues und Tolles über das man berichten kann und selber ausprobieren darf.

Ich habe die Tage an meiner INTERLIS IDE gearbeitet. Dabei rausgekommen ist die Version 0.0.6 und als VS Code Plugin die Version 0.0.25.

Als erstes musste ich einen Bug fixen. Das Problem war nicht nur beim graphml-Export vorhanden, sondern bereits auch beim Mermaid- und PlantUML-Diagramm, verursacht durch Referenzen auf Objekte in anderen Datenmodellen. Das sollte nun behoben sein.

Spannender ist aber ein neu eingebautes Feature: Ist es nicht so, dass man häufig das Modell auch abgebildet in einer Datenbank sehen möchte? Das beantwortet Fragen wie z.B. «Wie wird die Vererbung abgebildet?» oder «Hat die JSON-Abbildung das gemacht, was ich erwarte?» etc. pp. Meine Idee war nun, dass ich in der Extension einfach ili2gpkg mitliefern kann (Java ist ja bereits an Bord) und so in der Extension integriere, dass der Benutzer mit möglichst wenig Klicks eine GPKG-Datei erstellen kann.

Das Mitliefern ist das kleinste Problem. Mühseliger wird es bei der guten Umsetzung für die Ausführung des ili2gpkg-Kommandos. Wenn ich es richtig verstanden habe, kann man in VS Code nicht einfach hübsche GUIs in die Extension packen. Sondern man ist beim Ausführen von Kommandos sehr eingeschränkt, d.h. man wählt das Kommando aus und wizard-mässig kann man immer weitere Angaben zum Kommando machen und mit Enter bestätigen. Das ist bei der Anzahl an möglichen ili2gpkg-Optionen suboptimal:

Fair enough: Nicht alle sind relevant für die Erstellung des Schemas und der Tabellen. Aber es bleibt ein grosse Anzahl und kein Benutzer will 30 Mal Enter drücken. Abhilfe schafft die Meta-Config-ini-Datei. In dieser ini-Datei lassen sich die ili2gpkg-Optionen speichern und nur noch die Allerwichtigsten müssen vom Benutzer gewählt resp. bestätigt werden.

[ch.ehi.ili2db]
defaultSrsCode=2056
createEnumTabs=true
nameByTopic=true
createFk=true
createGeomIdx=true
createUnique=true

Dieser Ansatz führt zur berechtigten Frage was passiert, wenn ich andere Werte für diese Optionen verwenden will? Meine Lösung dafür: der Benutzer wählt einfach ein anderes ini-File aus. Die VS Code Extension bringt bereits eine ini-Datei mit, die der Benutzer nur zu bestätigen braucht oder aber er kann eine eigene ini-Datei auswählen.

Bilder sagen mehr als 1000 Worte.

Ausgangslage (ein hoffentliches kompilierendes INTERLIS-Datenmodell):

Auswahl des ili2gpkg-Kommandos:

Auswahl der ini-Datei. Entweder die eingebaute Default-Datei oder eine eigene:

Name und Speicherort der resultierenden GPKG-Datei:

Wahl des Datenmodelles. Es wird der Namen des aktuellen Datenmodelles vorgeschlagen:

Auswahl der Modelrepositories. Es werden die Standardrepositories und der Speicherort des aktuellen Modelles vorgeschlagen:

Fenster mit dem auszuführenden ili2gpkg-Kommando zwecks Review/Debugging:

Log-Messages in einem neuen Channel (siehe oben rechts im Output-Fenster «ILI2DB»):

Und jetzt? Entweder kann man sich die GeoPackage-Datei in dbeaver anschauen:

Oder es gibt auch SQLite-Extensions für VS Code resp. Theia. Leider habe ich da keine brauchbare gefunden, die ER-Diagramme darstellen kann. Und ausserdem könnte man das ER-Diagramm ebenfalls wieder mit Mermaid oder PlantUML direkt im Language-Server machen (analog dem UML-Klassendiagramm).

INTERLIS leicht gemacht #59 - INTERLIS IDE

Sun, 19 Oct 2025 00:00:00 +0000

Ich denke, dass man jetzt aufhören sollte mit dem Projekt «neuer UML/INTERLIS Editor». Warum noch viel Geld und Stunden verlochen, wenn es - tadaaa - meine INTERLIS IDE gibt.

Ich habe bereits für jEdit ein INTERLIS-Plugin geschrieben und dann feststellen müssen, dass (a) die Akzeptanz eher ein Kampf wäre und (b) Visual Studio Code schon auch Vorteile hat. Es gibt jedoch ein sehr grosses Aber! Die ganze Entwicklung von Visual Studio Code ist stark von Microsoft abhängig. Auch wenn das die meisten Digitalisierungs-«Profis» etc., die in die kantonale Verwaltungen strömen, nicht stört, mich tut es! Und darum war ich positiv überrascht, dass es mit Eclipse Theia einen kompatiblen Editor gibt. Er verwendet im Frontend sogar den gleichen Kern wie Visual Studio Code aber Theia selber ist mehr Framework als fertiges Produkt. Die Theia IDE ist also ein Produkt, das auf dem Theia Framework aufsetzt. Die Extensions von Visual Studio Code sind kompatibel. Nichts sprach also gegen die Portierung des jEdit-Plugins in eine VSCode-Extension.

Um das als VSCode-Extension anständig zu machen, muss man einen Language Server implementieren und drumherum eine kleine VSCode-Extension bauen. Den Language Server kann man eigentlich in irgendeiner Sprache programmieren. Er muss am Ende des Tages einfach auf der Zielplattform, wo auch VSCode läuft, ausführbar sein. Weil ich unbedingt wollte, dass sich die INTERLIS-Datenmodelle mit dem offiziellen INTERLIS-Compiler ili2c prüfen lassen können, musste es Java sein (umgesetzt mit lsp4j). Damit der Anwender sich nicht um eine Java Runtime auf seinem PC kümmern muss, liefere ich neben dem Language Server auch gleich eine möglichst kleine JRE mit. Und zwar für hoffentlich alle gängigen Betriebssysteme. Die Extension kümmert sich um das Starten und Beenden des Language Servers. Davon merkt der Anwender nichts. Die Kommunikation zwischen Editor und Language Server läuft via STDIO und JSON. Theoretisch funktioniert der Language Server auch mit anderen Editoren / IDE wie z.B. Eclipse IDE und Netbeans. Es gibt gewisse Standardfunktionen, die funktionieren werden. Implementiert der Language Server zusätzliche Befehle, müsste ein Client diese auch implementieren, sonst bringen sie nichts. Soweit die Theorie.

Was kann mein Language Server in Kombination mit der VSCode-Extension?

Datenmodell kompilieren:

Werden Fehler gefunden, sind diese strukturiert und können mittels Klick angesprungen werden:

Modell und Objekt Suggestions:

Pretty Print:

Rename-Funktion:

(Könnte noch bisschen wackeling sein…)

UML-Klassendiagramm:

Es kann auch ein PlantUML-Klassendiagramm erstellt werden. Zudem ist der jeweilige Code kopierbar, um das Diagramm nach eigenen Wünschen anzupassen.

Objektkatalog (HTML und .docx):

Verlinkte Modelle:

Importierte Modelle und deren Objekte können geöffnet und angesprungen werden.

Hierarchie-Baum:

Und ja, das ist jetzt alles noch nicht battle proven. Aber ein guter Start. Und wie man richtig erkennen kann, sind alle Screenshots mit VSCode gemacht. Was ist nun mit Eclipse Theia IDE? Funktioniert genau gleich. Man lädt die Software herunter und installiert die Extension:

Und was ist die «INTERLIS IDE»? Momentan noch nichts anderes als eine geforkte und leicht angepasste Theia-IDE und eingebauter VSCode-Extension:

Ob das langfristig wirklich notwendig ist, weiss ich noch nicht. Immerhin könnte so eine getailorete Variante den Einstieg vereinfachen? Nur sollten die bereitgestellten Installationspakete aber auch problemlos funktionieren… Unter macOS laufe ich natürlich prompt in ein Problem und man muss den Klassiker machen:

xattr -dr com.apple.quarantine InterlisIDE.app

Sonst kommt die Fehlermeldung, dass die Anwendung kaputt ist. Endziel hier wären natürlich signierte Pakete oder aber mindestens eine bessere Fehlermeldung.

Ein zweiter Grund für den speziellen Theia-Build wäre, falls eine VSCode-Extension nicht mehr reicht, um alle Anforderungen zu erfüllen. Und Anforderungen führt mich gleich noch zum Thema, dass sowohl UML-Diagramm wie auch Objektkatalog read-only sind. Auch wenn ich es technisch interessant finde, wenn man in jeder der drei Ansichten editieren könnte, so frage ich mich doch wie wichtig das wirklich ist (UML möchte ich mir zwar noch anschauen, aber eher aus Neugier und eventuell der Möglichkeit, dass man notfalls bezüglich Platzierung selber eingreifen kann). In einem Workshop habe ich das Argument gehört, dass ein Jurist seinen Input in der Objektkatalog-Ansicht machen kann. Da frage ich mich dann schon (noch sehr neutral), in welchem Universum wir leben. Definitiv nicht im gleichen und nicht weil wir schlechte Juristinnen und Juristen haben, sondern «Hallo Usecase?!?».

Neben den mächtigeren Erweiterungsmöglichkeiten (als Visual Studio Code) bietet das Theia-Framework auch noch Microsoft-freie Kollaboration. Man kann den Server - falls man möchte - sogar selber hosten. Und man kann die IDE auch als Browser-Anwendung laufen lassen, entweder lokal und in Kubernetes.

Die Pakete konnte ich unter den verschiedenen Betriebssystemen nicht ausprobieren. Mir steht nur macOS zur Verfügung. Die VSCode-Extension wurde unter Windows ausprobiert und sollte funktionieren.

Also, machen wir doch weniger Papiere und Workshops und arbeiten an etwas Konkretem.

Links:

INTERLIS leicht gemacht #58 - Jetzt aber wirklich einfach gemacht

Sat, 18 Oct 2025 00:00:00 +0000

Ich glaube ja immer noch, dass die einfachen Dinge in INTERLIS nicht schwierig zu modellieren sind. Die Syntax scheint mir sehr überschaubar. Schwieriger wird es bei komplizierteren Constraints. Das liegt mir nicht. Die grösste Herausforderung ist sowieso ein gutes Modell zu schreiben, das der Fragestellung gerecht wird und wirklich weniger die einfache Syntax.

«Aber» wäre es im momentanen KI-Hype nicht doch schön, man könnte ein LLM beauftragen, es solle eine Klasse soundso mit den und den Attributen eines bestimmten Typs erstellen? Ich habe die Erfahrung gemacht, dass z.B. ChatGPT zwischenzeitlich recht gut «INTERLIS kann». Interessanterweise kennt es auch den INTERLIS-Compiler recht gut, um damit zu programmieren. Aber wie kann man sicher sein, dass da nicht kompletter Mist rauskommt, wenn man Modellierungsfragen stellt? Man kann dazu z.B. einen MCP-Server verwenden. Was ist das?

MCP (Model Context Protocol) ist ein offenes Protokoll, mit dem KI-Clients (z. B. Chat- oder Agent-Apps) sicher und standardisiert auf externe MCP-Server zugreifen. Ein MCP-Server stellt dem Modell Tools, Ressourcen/Daten und Prompts bereit. Der Client entdeckt die Fähigkeiten des Servers, ruft Tools auf, liest Ressourcen und erhält Ergebnisse – transportagnostisch (z. B. stdio oder WebSocket).

Den MCP-Server habe ich mit Spring Boot und Spring AI umgesetzt. Beim Austausch via STDIO ist wirklich darauf zu achten, dass nichts nach STDIO geloggt wird, vor allem auch beim Hochfahren der Anwendung nicht. Austausch via STDIO bedeutet, dass das Teil lokal laufen muss. Es gibt noch die Möglichkeit den Austausch via WebSocket stattfinden zu lassen. Im letzteren Fall poppen oft Fragen hinsichtlich Authentifizierung und Autorisierung auf.

Ich verzichte hier auf das Auflisten sämtlicher Tools, die der MCP-Server unterstützt. Ein vollständige Liste findet sich im User Guide des Github-Repos.

Wie kann man den Server nun benutzen? Als wichtigster Reminder: Es braucht schon noch eine KI, also ein LLM. Als erstes hat meines Wissens Claude Desktop MCP unterstützt. Hier muss man die Datei claude_desktop_config.json konfigurieren. Diese liegt unter macOS im Ordner ~/Library/Application Support/Claude und sieht z.B. so aus:

{
    "mcpServers" : {
        "sogis-mcp" : {
            "command" : "/Users/stefan/.sdkman/candidates/java/21.0.4-graal/bin/java",
            "args" : [
                "-jar",
                "/Users/stefan/sources/sogis-mcp-poc/build/libs/sogis-mcp-poc-0.0.1-SNAPSHOT.jar"
            ]
        },
        "interlis-mcp": {
            "command" : "/Users/stefan/.sdkman/candidates/java/21.0.4-graal/bin/java",
            "args": ["-jar", "/Users/stefan/sources/interlis-mcp/build/libs/interlis-mcp.jar"],
            "env": {
                "JAVA_TOOL_OPTIONS": "-Xms512m -Xmx512m"
            }
        }
    }
}

Hier ein Beispiel mit Claude Desktop:

Man erkennt gut den strukturierten Request, den der Client an den MCP-Server macht:

{
  `name`: `Gebaeude`,
  `oidDecl`: `OID AS UUIDOID`,
  `attrLines`: [],
  `extendsFqn`: ``,
  `isAbstract`: false
}

Was genau übermittelt werden kann und in welcher Struktur, weiss der Client, weil der MCP-Server seine Tools beschreibt und diese Beschreibung auch ausliefert (ähnlich GetCapabilities von WMS o.ä.).

Auch Visual Studio Code unterstützt MCP-Server. Hinzufügen kann man sie über den MCP: Add Server Befehl. Das Hinzufügen geschieht anschliessend interaktiv. Am Ende landet die Konfig doch wieder in einer JSON-Datei, die man auch selber bearbeiten kann. Out-of-the-box ist in VSCode Copilot der Client. Hier habe ich noch nicht ganz den Durchblick. Ich glaube, man hat ein paar ChatGPT-Requests geschenkt, anschliessend muss der Rubel rollen. Erwähnenswert ist vielleicht folgendes (mit viel Halbwissen): Man kann sich einen eigenen Chatmodus erstellen (siehe Screenhot ganz unten rechts «SuperAgent»). Ich habe dies machen müssen, um Copilot dazu zu bringen, dass er bei INTERLIS-Fragen immer meinen MCP-Server fragt und nicht selber etwas wurstelt.

---
description: 'Description of the custom chat mode.'
tools: ['interlis-mcp']
---
Bitte verwende für alle INTERLIS-Modellbausteine immer den MCP-Server.

Neben der grundsätzlichen Sinnhaftigkeit, gibt es auch ein paar Nachteile: (1) Ich denke, dass es relativ aufwändig wird, wenn man praktisch die ganze INTERLIS-Sprache so umsetzen will. Aber vielleicht ist es auch bloss Fleissarbeit und gute Prompts. Und (2): Weil der MCP-Server nicht immer komplette Modelle zurückliefert resp. erstellt, kann man diese Konstrukte nicht mit ili2c prüfen. Entweder baut man sich einen «Snippet-Compiler» oder man macht z.B. um eine vom Server erstellt Klasse noch ein generisches «Mantel-Modell» drum und prüft dann mit ili2c.

Links:

https://github.com/edigonzales/interlis-mcp

INTERLIS leicht gemacht #57 - Python, Python und nochmals Python

Fri, 17 Oct 2025 00:00:00 +0000

Ich habe bereits mehrere Male über INTERLIS und Python geschrieben und gezeigt, dass man durchaus was damit machen kann:

Das funktioniert soweit tadellos. Der funktionale Nachteil dieses Approaches mit GraalVM ist, dass man quasi nur immer einen Befehl ausführen kann und immer nur genau eine simple Antwort zurück bekommt. Z.B. kann man sehr gut eine INTERLIS-Transferdatei validieren, aber die Antwort kann faktisch nur sein: valide oder nicht valide. Klar gibt es die Logdatei, die man auslesen kann. Ähnlich bei ili2db: Hier muss und will man als Anwender der Software viele Optionen mitgeben und entsprechend muss man hier Lösungen finden, weil im Prinzip nur einfache Datentypen übergeben werden können (z.B. JSON als String und wieder als JSON interpretieren). Das alles mag für einige Fragestellungen gar nicht so problematisch sein, für eine ist sie denkbar ungünstig: Was mache ich, wenn ich mehr über das INTERLIS-Datenmodell wissen will? Ganz einfache und dumme Fragestellung: Wie viele Klassen gibt es in meinem Modell und wie heissen sie? Den INTERLIS-Compiler ili2c habe ich ebenfalls als Versuch in eine native shared library kompiliert und als Python Package angeboten. Diese library liefert aber eben nur zurück, ob das Modell syntaktisch korrekt ist oder nicht. Jetzt könnte man natürlich in Java das Modell mit der entsprechenden Java-API auslesen und ebenfalls wieder strukturiert als String (z.B. JSON) an den Python Code zurückliefern. Dieser Python Code müsste den String wiederum interpretieren können. Machbar aber auch aufwändig und man hat immer noch die shared native library an der Backe. Diese Variante wird m.E. sehr ähnlich aber ohne den ersten Schritt momentan auf Wunsch verschiedener Kantone umgesetzt. Man wählt den Weg über die ilismeta-Datei. Das ist das Datenmodell abgebildet in einem INTERLIS-Metamodell als Transferdatei. Dabei muss die Python-Logik «nur» XML interpretieren können. Mein Problem mit dieser Lösung: Woher kriege ich diese ilismeta-Datei? Der Deal müsste doch sein: «Python only».

Zugegebenermassen leicht angefixt, dachte ich mir: Mmmmh, mit ChatGPT Codex könnte man doch Teile des ili2c-Codes nach Python umschreiben lassen. Interessant an diesem Experiment ist meines Erachtens fast weniger das Resultat, sondern der Weg dahin und was es für zukünftige Programmierarbeiten bedeutet. Und auf beides habe ich natürlich nicht die perfekte und definitive Antwort.

Was ich am Ende haben wollte, war sowas wie die TransferDescription damit ich sämtliche Informationen aus einem INTERLIS-Datenmodell direkt mit Python auslesen kann. Ili2c basiert auf antlr2, mit dem man nicht Python-Klassen herstellen kann. Ich wusste, dass es für INTERLIS 2.4 bereits eine antlr4-Grammatik gibt. Ebenfalls war (und ist) mir diese ganze Parser/Lexer-Welt noch eine ziemliche Unbekannte. Ich habe also ChatGPT Codex beauftragt das Java metamodel-Package (wo auch die TransferDescription drin ist) nach Python umzuschreiben und ihm die antlr4-Grammatik mitgeliefert. Das hat mit verschiedenen weiteren Schritten halbwegs funktioniert, bis ich merkte, dass ich nur die vereinfachte antlr4-Grammatik aus dem Repository verwendet habe. Unterwegs habe ich festgestellt, dass natürlich (weil auch beauftragt) Tests geschrieben werden, nur halt teilseise mit syntaktisch falschen Datenmodellen (weil von ChatGPT selber hergestellt). Das ist sicher eine Lektion, die man lernen kann: Die Testmodelle müssen stimmen. Ich habe mich dazu entschlossen nochmals von Null zu starten und eben die Testmodelle mitzuliefern. Bei diesem Startprompt habe ich Wahrscheinlich den Fehler gemacht, dass ich nicht genug erwähnt habe, dass ich explizit dieses Metamodell als Abstraktionslayer haben will. Inkl. sämtlicher Typen (z.B. EnumerationType, TextType etc.). Sondern als Ziel habe ich ihm gesetzt, dass ich UML-Klassendiagramme mit Mermaid herstellen will. Was auch schon relativ gut gelang ohne all dieses Type-Klassen. Aber trotzdem kam ich beim zweiten Mal schneller an mein Resultat.

Neben dem eigentlichen Parser wollte ich noch die ilirepository-Logik in Python haben. D.h. Python sucht nun - gleich wie ili2c - ein Modell in den INTERLIS-Modellablagen und speichert es in einem lokalen Cache. Dieses Feature habe ich zuerst losgelöst vom Parser entwickeln lassen und erst als es mehr oder weniger korrekt funktionierte mit einem weiteren Auftrag an ChatGPT im Parser implementiert.

Ich glaube nicht, dass es funktionieren würde, wenn man gar nichts von INTERLIS versteht und/oder gar nichts vom Resultat versteht, was man erreichen will (das Java-Metamodell in Python). Hellsehen kann ChatGPT immer noch nicht.

Die andere Frage ist: würde man mit sowas früher oder später in Produktion gehen? Jein. Wahrscheinlich falls es eher Wegwerf-Code ist (aber was heisst dann schon Produktion), kann man es riskieren. Oder falls man es nur in einem engeren Kreis braucht und immer noch das Wissen hat, richtig zu reagieren und notfalls Bugs zu fixen (oder fixen zu lassen). Auch wenn Tests geschrieben werden, sind manche Tests schlicht nutzlos, da sie nicht das Testen, was eigentlich sinnvollerweise getestet werden sollte. Im konkreten Fall könnte ich mir gut vorstellen, dass die Basis, die gelegt wurde, gar nicht mal so schlecht ist und dass man mit ein wenig reingesteckter Liebe noch weit kommt. Man müsste sich sicher die Grundarchitektur zu Gemüte führen und z.B. die Tests genauer anschauen etc. pp.

Einige einfache Beispiele:

Modell in Modellablage suchen:

import logging

from ili2c.ilirepository import IliRepositoryManager

logging.basicConfig(level=logging.INFO)

manager = IliRepositoryManager(["https://models.interlis.ch/"])
for metadata in manager.list_models():
    logging.info("%s %s -> %s", metadata.name, metadata.version, metadata.full_url)

metadata = manager.find_model("DMAV_Grundstuecke_V1_0")
if metadata:
    local_path = manager.get_model_file(metadata.name)
    logging.info("Cached copy stored at %s", local_path)

Modell parsen:

import logging
from pathlib import Path

from ili2c.pyili2c import parser
from ili2c.pyili2c.metamodel import Table

logging.basicConfig(level=logging.INFO)

settings = parser.ParserSettings(
    ilidirs=["examples/models"],
    repositories=["http://models.interlis.ch/"],
)

transfer_description = parser.parse(
    Path("examples/models/DMAV_Grundstuecke_V1_0.ili"),
    settings=settings,
)

for model in transfer_description.getModels():
    logging.info("Loaded model %%s (schema %%s)", model.getName(), model.getSchemaLanguage())

UML-Klassendiagramm herstellen:

import logging

from ili2c.pyili2c import parser
from ili2c.pyili2c.mermaid import render

logging.basicConfig(level=logging.INFO)

transfer_description = parser.parse("path/to/model.ili")
mermaid_source = render(transfer_description)
logging.info("Generated diagram:\n%s", mermaid_source)

Das funktioniert jedenfalls mit meinem neuen Lieblings-Test-Modell und mit seinem Vorgänger.

Was kann man nun mit dem Python Package anstellen? Man erstellt einen Mermaid-Renderer, der lokal im Browser läuft. Der Python-Code läuft in einer Python-WebAssembly-Variante:

Damit die Modellablagen verwendet werden können, müssen sie CORS unterstützen, was bei den meisten nicht der Fall ist. Auch aus diesem Grund habe ich die wichtigsten Repos bei uns gecached und kann sie für solche Fälle verwenden.

Die Tage unter die Augen gekommen: Spec Driven Development. Unter Umständen würde das hier gut funktionieren.

Links:

INTERLIS leicht gemacht #56 - Einfacher modellieren mit jEdit

Tue, 16 Sep 2025 00:00:00 +0000

Wir modellieren INTERLIS-Modelle mit dem UML/INTERLIS-Editor. Warum wir das so machen, weiss ich nicht mehr recht. Wahrscheinlich weil wir damals glaubten, dass man das halt so macht, obwohl das Teil bereits 2016 eher unmodern wirkte. Aber gegen unser neues Zeit- und Leistungserfassungstool scheint der UML/INTERLIS-Editor als hätte ihn Jony Ive persönlich designed. Aber das ist eine ganz andere Geschichte. Zurück zu den wichtigen Dingen des Lebens:

Nach all den Jahren können wir sagen, was uns wichtig ist: Die Datenmodelle sollen immer gleich formatiert sein und es muss eine visuelle Repräsentation in Form eines UML-Klassendiagramms vorhanden sein resp. einfach ableitbar sein. Nicht zwingend notwendig ist die Erstellung des Datenmodelles mit einem «Klick»-Editor. Die wirklichen Ur-Beweggründe für die Programmierung des UML/INTERLIS-Editors kenne ich nicht, aber mich dünkt der Mehrwert / die Unterstützung bei der Modellierung marginal bis nicht vorhanden bis kontraproduktiv. Die Syntax von INTERLIS für die einfachen Fälle (also Modell, Topic, Klasse und Attribute) ist ja wirklich trivial. Mit einem Text-Editor, der mich noch ein wenig unterstützt, bin ich garantiert schneller als jemand, der gefühlte 1000 Mausklicks machen muss. Wird es komplizierter (beginnt bei mir bereits bei Assoziationen: Mmmh, wohin gehört welche Rolle?), muss ich sowieso in die Modelldatei nachschauen gehen. Und wenn es wirklich grausam wird (komplexe Constraints), müsste ein guter UML/INTERLIS-Editor wirklich gut sein, damit ich einen Mehrwert habe.

Zusammengefasst: Mir reicht ein Text-Editor mit Syntax-Highlighting, der die Syntax meines INTERLIS-Modelles überprüft (kompiliert) und mir eine read-only UML-Darstellung erstellt. In einem älteren Beitrag habe ich gezeigt, wie ich eine VSCode-Extension für den INTERLIS-Compiler ili2c programmiert habe. Technisch ist es nicht gerade straight forward mit der native shared library, aber machbar. Stärker wiegt aber der Umstand, dass VSCode mehr oder weniger komplett von Microsoft kontrolliert wird. Und das fand ich dann weniger gut. Schon nur, weil wir bereits mit Github zu Microsoft-Jünger geworden sind. Mit jEdit steht ein Veteran bereit, der bereits seit Jahren Syntax-Highlighting für INTERLIS bietet und zudem in Java geschrieben ist. Damit dürfte die Entwicklung eines Plugins für INTERLIS (hauptsächlich für ili2c) sehr gut machbar sein. Der Nachteil von jEdit ist sicher seine kleine Community und dass er nicht das Language Server Protocol unterstützt. Weil ich das doch ziemlich gut finde, habe ich mich schlau gemacht und mit Eclipse Theia eine Alternative für VSCode gefunden. Aber wieder zurück zu jEdit. Ich habe ein recht umfangreiches INTERLIS-Plugin für jEdit geschrieben. Ob ich später etwas für Eclipse Theia mache, weiss ich noch nicht.

JEdit ist einfach erweiterbar und es gibt viele Plugins, die als Beispiele dienen. Was ich gut finde bei jEdit, ist die Einfachheit:

plugin.ch.so.agi.jedit.InterlisPlugin.menu=compileCurrentFile \
    toggleCompileOnSave \
    prettyPrintCurrentFile \
    interlis-collect-keywords \
    interlis-uml-show \
    interlis-uml-show-static \
    interlis.create-object-catalog

compileCurrentFile.label=Compile current file
toggleCompileOnSave.label=Toggle compile on save
prettyPrintCurrentFile.label=Pretty print current file
interlis-uml-show.label=Show UML diagram (interactive)
interlis-uml-show-static.label=Show UML diagram (static)
interlis-collect-keywords.label=Collect model tags
interlis.create-object-catalog.label=Export object catalog (.docx)

Dieser Eintrag in einer Properties-Datei erzeugt mir folgenden Menueintrag:

So einfach geht es eigentlich weiter. Es gibt auch eine Art Dependency Injection, wenn man sich auf andere Plugins abstützt und eine Implementierung einer Konsolenshell speziell für INTERLIS machen will. JEdit hat auch eine praktische Funktion wie eigene Fenster an das Hauptfenster gedockt werden kann. Die meisten dieser Dinge lassen sich einfach in einer zentralen Properties-Datei oder in verschiedenen XML-Dateien steuern.

Was habe ich alles für INTERLIS implementiert? Als allererstes habe ich das Syntax-Highlightung für INTERLIS 2.4 upgedatet. Dabei habe ich eine kleine funktionale Änderung bei den Kommentare vorgenommen. Neu werden Metaattribute separat behandelt. Die Farben wiederum sind nicht Bestandteil der Konfiguration, sondern können individuell in jEdit vorgenommen werden.

Als zweites wollte ich die Syntax des Modells kontrollieren indem ich das Modell mit ili2c kompiliere. Das geht natürlich sehr einfach aber ich wollte das Resultat (also der eigentlich Kommandozeilenoutput von ili2c) auch irgendwie in jEdit sichbar machen. Für solche Fälle ist das Console-Plugin zweckdienlich. Man kann damit beliebige Shells implementieren. In meinem Fall wollte ich die Logmeldungen von ili2c reinschreiben:

Es gibt die Möglichkeit, das Kompilieren an eine Tastenkombination zu binden, oder das Plugin bietet die Einstellung, dass die Datei nach jedem Speichern automatisch kompiliert wird («Toggle compile on save»).

Was passiert wenn Fehler gefunden werden? Die Fehler werden natürlich in der Konsole geloggt. Es wird zusätzlich ein Fenster mit den Fehlern geöffnet. Mittels Klick auf eine dieser Fehlerzeilen, landet man am korrekten Ort in der Datei. Diese Fehlerliste hat leider noch einen Fehler: Wenn ili2c mehrere Fehler pro Zeile meldet, stimmt irgendwas nicht (auch die Sortierung der Zeilennummern funktioniert nicht).

Ein Grund für die Verwendung vom UML/INTERLIS-Editor war, dass er die Modelle beim Export immer gleich formattiert. Für diesen Anwendungsfall gibt es im Plugin die «Pretty Print»-Funktion. Die Umsetzung war sehr einfach: ili2c liest die Modelldatei und schreibt sie wieder.

Ein weiteres wichtiges Feature für mich war die Unterstützung beim Schreiben von Klassen, Topics etc. Ich möchte, wenn ich beginne eine Klasse zu schreiben (CLASS Fubar =) nicht auch das Ende schreiben müssen (END Fubar;). Hier unterstützt mich das Plugin stark: Der Footer wird automatisch in den Editor geschrieben nachdem ich = getippt habe und der Cursor wird zwischen Header und Footer platziert, so dass ich Attribute hinzufügen kann. Dies funktioniert für die Elemente MODEL, TOPIC, CLASS, STRUCTURE und VIEW mit den jeweiligen Modifiern (falls die so heissen). Also auch z.B. CLASS Foo (ABSTRACT) EXTENDS ModelA.Bar =. Beim Element MODEL schreibt es mir einen kompletten Kommentar-Header rein:

Weiter geht es mit Vorschlägen bei IMPORTS. Da schlägt mir das Plugin die Modelle der Standardrepositories (und ihren verknüpften Repositories) vor:

Die Vorschläge funktionieren auch bei Attributen, die z.B. eine Struktur oder ähnliches aus einem anderen Modell referenzieren.

Ebenfalls umgesetzt ist das Anzeigen von importieren Modellen. Das funktioniert natürlich nur, wenn es mindestens eine erfolgreiche Kompilierung gab. Sonst kennt das Plugin das Modell ja gar noch nicht (gilt natürlich auch für andere Feature). Ein Klick auf das importierte Modell öffnet dieses in einem neuen Tab:

Zusätzlich gibt es so etwas wie eine Baumstruktur. Bei jEdit heisst es Sidekick oder Outline:

Last but not least und für mich zwingend, ist die visuelle Repräsentation als UML-Klassendiagramm. Ich habe zwei Varianten implementiert: eine interaktive und eine statische. Die interaktive Variante habe ich mit jhotdraw umgesetzt. Das ist die gleiche Bibliothek wie sich auch UML/INTERLIS-Editor einsetzt. Das Problem bei dieser Bibliothek ist, dass sie nicht mehr wirklich unterhalten wird oder sehr spärlich. Die Bibliothek bietet sehr viel, um sehr schnell das gewünschte Resultat zu erhalten. Ich habe mich entschieden, dass ich pro Topic einen Tab in einem separaten (dockable) Fenster generiere und einen zusätzlichen Tab für die Topic-Übersicht (und andere Elemente auf der Modellebene):

Die Objekte können umhergeschoben und eingefärbt werden. Das Ganze funktioniert nicht mal so schlecht für kleine und mittelgrosse Modelle. Bei grösseren Modellen bräuchte es einen sehr guten Platzierungsalgorithmus. Die UML-Diagramme können als PNG exportiert werden.

Bei der zweiten Variante wird ein Mermaid-UML-Diagramm hergestellt. Man kann zwar rein- und rauszoomen und rumpannen aber ansonsten ist es eine statische Angelegenheit. Das Diagramm wird im OS-Standardbrowser dargestellt. Java (Swing) bringt zwar auch eine Browserkomponente mit, die ist jedoch veraltet und da ist nix mit Javascript, SVG und CSS. Es gäbe in JavaFX eine aktuelle Browserkomponente aber ich wollte nicht noch weitere Abhängigkeiten im Plugin haben. Wenn das Datenmodell erfolgreich kompiliert wird, wird das Klassendiagramm im Browser automatisch nachgeführt.

Eigentlich wollte ich hier ja aufhören, aber habe trotzdem noch zwei Funktionen hinzugefügt. Die erste ermittelt mittels KI aus den Topic- und Klassennamen sowie dem Metaattribut shortDescription 10 bis 15 Synonyme, die man als Tags für die ilimodels.xml-Datei verwenden kann. Ich lasse die Tags auch gleich in verschiedene Sprachen übersetzen. Damit wäre es für eine Suchmaschine endlich möglich auch das MGDM Hazard Mapping (= Naturgefahren) zu finden. Leider ist hier die User Experience noch ungenügend. Da es relativ lange geht (warum ist mir nicht klar), fehlt ein Feedback in der Anwendung, dass was passiert. Gewisse Zeit später erscheint folgendes:

Die Tags erfassen wir bei uns als Metaattribut zum Modell. Unser automatisierter INTERLIS-Modellrepository-Herstellungsprozess liest diese aus und füllt sie in der ilimodels.xml-Datei ab.

Die letzte Funktion ist ein Export eines Objektkataloges in eine Wordatei. Das ist mir persönlich nicht wichtig, da wir eigentlich so einen Objektkatalog nicht verwenden. Es wird sich zeigen, ob er überlebt oder aus dem Plugin rausfliegt (ist halt nur LibreOffice, aber trotzdem .docx):

Sämtliche Funktionen des Plugins sind sicher noch buggy und teilweise ist es auch inkonsistent in der Bedienung. Nach ersten Tests wird sich zeigen, was uns wirklich wichtig ist und weiterverfolgt wird.

Ein (hoffentlich) Sorglospaket kann man hier herunterladen. Die Zipdatei auspacken und ins Verzeichnis wechseln. Anschliessend kann jEdit mit dem INTERLIS-Plugin wie folgt gestartet werden:

java -jar jedit.jar -settings=./portable-settings -log=2

Es läuft ab Java 11. Unter macOS ist Java 17 oder höher empfohlen, ansonsten macht das Arbeiten mit dem interaktiven UML-Klassendiagramm nicht Spass. Es ist viel zu käsig. Reingepackt habe ich zudem eine modernere Theme und ein Font, den ich persönlich sehr gut zum Entwicklen finde (JetBrains Mono).

Und als nächstes möchte ich einen INTERLIS-MCP-Server integrieren. Dafür muss aber zuerst überhaupt der MCP-Server her.

Links:

INTERLIS leicht gemacht #55 - Des ili2pgs neue Kleider

Mon, 15 Sep 2025 00:00:00 +0000

Ili2pg hat bekanntlich ein Wahnsinns-GUI:

Und wenn das neue GUI nicht zu ili2pg kommt, muss ili2pg zum neuen GUI kommen. Und das «neue» GUI ist dbeaver. Ich denke, bei mir gab es wie zwei Auslöser ein ili2pg-dbeaver-Plugin zu schreiben: Ich hatte bereits vor längerer Zeit die Idee, dass es eigentlich ganz praktisch wäre, wenn man auf Knopfdruck Daten in einer PostgreSQL-Datenbank mit ilivalidator resp. ili2pg prüfen könnte. Und als ein Mitarbeiter vor kurzem meinte, dass er Daten mit ili2pg via Kommandozeile nicht aus der Datenbank exportieren kann, war der Zeitpunkt für mich gekommen, das anzupacken. Natürlich mit der arroganten Meinung, dass ich dafür sicher nicht mehr Zeit brauche, als der Mitarbeiter für den Export (was sich natürlich als eine totale Fehleinschätzung erwies).

«Im Prinzip» und «eigentlich» müsste das doch ganz schnell gehen. Beide Anwendungen sind in Java geschrieben. Wie schwer kann das noch sein? Die Antwort ist: ziemlich schwer. Und zwar nicht wegen der eigentlichen Business-Logik. Das habe ich schon ein paar Mal gemacht (also Schema anlegen, Daten importieren und exportieren und solches Zeugs). Sondern das ganze Drumherum, also das eigentliche Plugin. Es ist ein schönes Beispiel dafür, dass man nicht nur die Programmiersprache kennen muss, sondern das ganze Ökosystem, um erfolgreich und effizient entwickeln zu können.

Der Stolperstein hier ist wie ein Plugin für Eclipse (dbeaver ist nichts Anderes als eine Eclipse-Anwendung) gepackt, bereitgestellt und installiert werden muss. Eclipse-Plugins sind OSGi-Bundles (plus noch ein paar spezifische Eclipse-Sachen). OSGi-Bundles sind Module für die Java-Welt: jedes Bundle ist ein JAR mit Metadaten (Manifest), das genau beschreibt, welche Pakete es bereitstellt und welche es benötigt. Dadurch können Module dynamisch geladen, gestartet, gestoppt und aktualisiert werden, ohne die gesamte Anwendung neu zu starten. Das Ganze stammt aber aus einer andere Epoche, ist zwar mächtig, aber nicht sonderlich etwicklerfreundlich (dünkt mich). Es war für mich eine ziemliche Herausforderung eine Entwicklungsumgebung so hinzukriegen, damit ich relativ effizient programmieren konnte. Hot- resp. Livereload ist da nicht, resp. habe ich nicht hingekriegt. Das Zückerchen gab es dann am Schluss: wie stellt man nun so ein Plugin bereit? Es sind sogenannte Update-Sites (oder Repositories). Leider ist das wiederum auch nicht so trivial wie ein Maven Repository. Fazit hier: Mein Projekt ist momentan ein Eclipse-Projekt (kein Maven- oder Gradleprojekt) und ich muss es noch manuell deployen.

Interessanter als mein Gejammer sind sicherlich die Features des Plugins. Wobei wir bei der Installation anfangen müssen. Wie soeben erwähnt, müssen die Plugins über eine Update-Site installiert werden. Ich habe für mein Plugin eine solche Update-Seite unter der URL https://dbeaver.sogeo.services/updates erstellt. In dbeaver muss man unter Help - Install New Software die Update-Site angeben und kann anschliessend das ili2pg-Plugin installieren:

Man muss verschiedenen Dingen «trusten», so auch meiner Update-Seite. Nach einem Restart von dbeaver steht das Plugin zur Verfügung. Das Plugin macht sich zum ersten Mal bemerkbar, wenn ich mit der rechten Maustaste auf ein Datenbank-Icon klicke:

Aus Bequemlichkeit habe ich im GUI nicht jede Option nachgebildet, sondern nur die absolut Notwendigsten. Nämlich eine Option für den Schemanamen und eine Option für eine INI-Datei. Die INI-Datei beinhaltet alle Infos, die ili2pg benötigt, um eine Schema anzulegen:

[ch.ehi.ili2db]
models=SO_Hoheitsgrenzen_Publikation_20170626
nameByTopic=true
defaultSrsCode=2056
createFk=true
createFkIdx=true
createMetaInfo=true
createUnique=true
createNumChecks=true
createTextChecks=true
createDateTimeChecks=true
createEnumTabs=true
strokeArcs=true

Die Logmeldungen erscheinen in einem speziellen «ili2pg»-Tab in der Konsole:

Will man Daten importieren, muss ich das soeben erstellte Schema anwählen und wiederum die rechte Maustaste klicken. Jetzt erscheinen mehrere Befehle:

Für den Datenimport werden mehr Optionen benötigt, um sinnvolle Imports machen zu können. Wahrscheinlich fehlt aber noch die eine oder andere (z.B. --replace) Option, um wirklich production-ready zu sein. Erwähnenswert ist die Option Model. Man muss ili2pg immer mitteilen, welches Modell man importieren resp. exportieren will. Aus den Metatabellen wird auch nicht ersichtlich, um welches Modell es sich handelte, als man Daten importierte. Es werden gleichberechtigt sämtliche benötigten Modelle in der Tabelle t_ili2db_model vorgehalten. Aus diesem Grund muss der Benutzer auch immer das Modell auswählen. Ich habe es nun so gelöst, dass ich vier Modellarten ignoriere (TYPE, CONTRACTED, REFSYSTEM und SYMBOLOGY). Diese wird man nicht importieren oder exportieren wollen. Sind nach Abzug dieser Modelle noch mehrere Modelle übrig, muss der Benutzer entscheiden. Ist nur noch eines übrig, wird automatisch dieses einzige Modell für den ili2pg-Befehl verwendet.

Das geht nun so weiter für die restlichen Befehle des Plugins: Export schema…, Export schema with options… und Validate schema…. Die Einstellungen zu den Modellrepositories kann man unter Settings - ili2pg vornehmen.

Die Dokumentation des Plugin-Repos ist noch ungenügend. Aber vielleicht kann jemand das Plugin bereits gewinnbringend einsetzen.

Links:

INTERLIS leicht gemacht #54 - INTERLIS meets Vibe Coding

Mon, 8 Sep 2025 00:00:00 +0000

«Vibe Coding» ist wahrscheinlich eher ein Gaga-Begriff und vor allem eine nicht sonderlich schlaue Arbeitsweise aber ich brauchte einen catchy Blogtitel. Ich habe im Juli unseren Modelfinder ein wenig aufgefrischt. Ich konnte das Frontend technisch massiv vereinfachen: simples Templating mit HTMX im Gegensatz zu GWT und und ich habe die Anwendung auch funktional erweitert. Neu gibt es eine Detailansicht für das INTERLIS-Datenmodell. Diese zeigt neben verschiedenen Metainformationen auch das Modell mit Syntax Highlighting und ein UML-Klassendiagramm:

Die Klassendiagramme werden mit Mermaid erstellt. Ganz glücklich war ich jedoch mit meiner Umsetzung noch nicht: Gewisse Modelle konnten nicht gerendert werden (looking at you «Kataloge») und umfangreichere Modelle wurden zu klein gerendert und entsprechend hat man nichts mehr erkannt. Der Code zur Herstellung des Mermaid-UML-Klassendiagramms habe ich selber geschrieben. Weil mir wegen eines anderen Projektes auffiel, dass ChatGPT 5 ein relativ gutes Wissen über das INTERLIS-Java-Metamodell verfügt, versuchte ich mit einem möglichst akkuraten Prompt mir Code für die UML-Herstellung generieren zu lassen:

I want to create a mermaidjs class diagram with Java. The input is a INTERLIS TransferDescription which you know kinda well. It is defined in the official INTERLIS compiler: https://github.com/claeis/ili2c and https://github.com/claeis/ili2c/blob/master/ili2c-core/src/main/java/ch/interlis/ili2c/metamodel/TransferDescription.java

What should be supported:

- For rendering: consider only models from last file (method TransferDescription.getModelsFromLastFile())
- Classes with attributes and cardinality. Please render attributes like "Geometrie[1] : MultiSurface". Classes can be "Abstract". Use a stereotype for this.
- Structures are like Classes. But with a stereotype "Structure".
- Topics: Use namespaces for this and put the viewables in it.
- Classes can also be outside of a topic. Then place it on the root level (like the topic).
- Enumeration: Use "Enumeration" stereotype for this. Do not list the enumeration values.
- Show inheritance. If the base class is not in a model from the last file, render the base class on the root of the diagram and add a "External" stereotype to it.
- Show associations with cardinality on both sides.

Think before you start coding. Especially about a clean architecture and use a pattern if there is one the fits this task.

Vielleicht hat es die eine oder andere Peinlichkeit drin aber ich war positiv vom Resultat überrascht. Nach etwas mehr als 1.5 Minuten kam eine recht brauchbare Variante heraus. Interessanterweise erfindet ChatGPT nicht zum ersten Mal eine Methode getElements() für die Klasse ch.interlis.ili2c.metamodel.Container. Und im vorliegenden Fall verwechselte ChatGPT die Klasse ModelElement mit Element. Wahrscheinlich könnte man beides noch in den Prompt einbauen und gut ist. Ebenso hat ChatGPT sich bei der einfachen Mermaid-Syntax leicht vertan. Aber all das war schnell gefixed. Ich benötigte noch zwei bis drei Iterationen weil ich im Ausgangsprompt einige Features vergessen hatte.

Der erste Härtetest kam beim Testen mit dem ISOS-MDM, das zu einer Exception führte. Und hier zeigt sich eine schöne Herausforderung, wenn die KI dir den Code schreibt: Habe ich genügend Wissen, um der KI überhaupt wieder genug Informationen zu füttern, damit sie den Bug fixen kann? Glücklich schätzen kann man sich, wenn das vor dem Go-live passiert. Im vorliegenden Fall wusste ich, wo es passiert und was am Modell speziell sein könnte (Hallo «Kataloge»!?). Mit diesen Inputs konnte ChatGPT den Fehler finden und beheben und das ISOS-MDM wird nun korrekt gerendert.

Das Problem der unleserlichen Darstellung habe ich so gelöst, dass es neu eine zusätzliche Seite nur mit dem Klassendiagramm gibt. In der Seite kann man zoomen und pannen. Somit wird auch unser aller liebstes INTERLIS-Datenmodell erlebbar:

Links:

INTERLIS leicht gemacht #53 - INTERLIS-Compiler-Bindings für Python und Node.js

Tue, 22 Jul 2025 00:00:00 +0000

Im 50. INTERLIS-Beitrag habe ich etwas über Verbesserungen der Developer Experience von INTERLIS geschrieben. Dafür habe ich eine Visual Studio Code Extension geschrieben, die drei Dinge macht:

Prüft mit dem INTERLIS-Compiler die syntaktische Korrektheit eines Modelles.
Formatiert die Modelldatei (wie es auch der INTERLIS-Compiler macht).
Erstellt ein UML-Diagram (PlantUML oder Mermaid) aus einer Modelldatei.

Die Businesslogik dazu steckt nicht in der VS Code Extension, sondern die Modelldatei wird an einen Webserver geschickt, der diese drei Aufgaben übernimmt und das entsprechende Resultat zurückschickt. Kann man so machen, aber schöner wäre natürlich, wenn das alles lokal (direkt mit der Extension) möglich wäre. Ggf. will man seine Daten nicht irgendwem auf einen Server laden oder man will nicht selber einen solchen Server betreiben. Das erklärte Ziel ist also den INTERLIS-Compiler irgendwie in die VS Code Extension zu packen, aber selbstverständlich ohne von Java abhängig zu sein. In meiner WebAssembly-Euphorie dachte ich, dass es damit geht. Aber das stellte sich als nicht machbar heraus. Die Backup-Variante ist nun folgende: Wir kompilieren ili2c resp. einige Methoden davon mit GraalVM in eine Native Shared Library. Anschliessend erstellen wir eine Node-Modul «ili2c», welches auf diese Library (je nach OS ist das eine .dll-, .so- oder .dylib-Datei) zugreift und gegen aussen ein API definiert. D.h. als Benutzer möchte ich sowas machen können:

npm install ili2c

const ili2c = require('ili2c');
const result = ili2c.compileModel("test/Test1.ili", "ili2c.log");

Damit wäre der Grundstein gelegt, um das ili2c-Modul auch in der VS Code Extension zu verwenden. Der Weg dahin war aber nicht ganz so einfach und trivial und straight forward wie erwünscht. Es gab einige Hürden überwinden:

Der erste Schritt ist der einfachste. Das Herstellen der Native Shared Library. Ich habe das bereits ausführlich mit ilivalidator und Python durchgespielt. Es gibt für die Java-Methoden, die in der Shared Library landen sollen, verschiedene Rahmenbedingungen. Eine davon ist, dass sie statisch sein muss und man kann nur beschränkt Objekte als Parameter übergeben und zurückliefern. Im vorliegenden Fall ist das alles nicht tragisch kompliziert, ich möchte z.B. die Modelldatei und eine Logdatei (resp. der jeweilige Pfad als String) übergeben:

@CEntryPoint(name = "compileModel")
public static int compileModel(IsolateThread thread, CCharPointer iliFile, CCharPointer logFile) {
    String iliFileStr = CTypeConversion.toJavaString(iliFile);
    String logFileStr = CTypeConversion.toJavaString(logFile);
    return compileModelImpl(iliFileStr, logFileStr);
}

public static int compileModelImpl(String iliFile, String logFile) {
    try {
        Files.deleteIfExists(new File(logFile).toPath());
    } catch (IOException e) {
        e.printStackTrace();
    }
    FileLogger fileLogger = new FileLogger(new File(logFile), false);
    EhiLogger.getInstance().addListener(fileLogger);

    EhiLogger.logState("ili2c-"+TransferDescription.getVersion());
    EhiLogger.logState("ilifile <" + iliFile + ">");

    IliManager manager = new IliManager();
    manager.setRepositories(Ili2cSettings.DEFAULT_ILIDIRS.split(";"));
    ArrayList<String> iliFiles = new ArrayList<String>();
    iliFiles.add(iliFile);
    Configuration config;
    try {
        config = manager.getConfigWithFiles(iliFiles);
    } catch (Ili2cException e) {
        EhiLogger.getInstance().removeListener(fileLogger);
        fileLogger.close();
        return 1;
    }

    DateFormat dateFormatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
    Date today = new Date();
    String dateOut = dateFormatter.format(today);

    TransferDescription td = null;
    try {
        td = ch.interlis.ili2c.Ili2c.runCompiler(config);
    } catch (Ili2cFailure e) {
        EhiLogger.logError("...compiler run failed " + dateOut);
        EhiLogger.getInstance().removeListener(fileLogger);
        fileLogger.close();
        return 1;
    }

    EhiLogger.logState("...compiler run done " + dateOut);
    EhiLogger.getInstance().removeListener(fileLogger);
    fileLogger.close();
    return 0;
}

Die Methode mit der Annotation @CEntryPoint ist die Methode, die exponiert wird. Die Aufsplittung in zwei Methoden habe ich gemacht, damit ich in Java den Grossteil der Businesslogik testen kann. Das Resultat sind Header-Dateien (.h-Files) und die betriebssystemabhängigen Libraries. Mit den Github Actions kann man für Linux (amd64), Windows (amd64) und macOS (amd64 und arm64) Binaries herstellen. Das bedeutet, dass das zukünftige ili2c-Node-Modul auf anderen Betriebssystemen und anderen Architekturen nicht funktionieren wird (was aber eher Exoten wären). Die Libraries sind keine statisch gelinkten Libraries, sondern benötigen z.B. unter Linux und macOS libc und zlib. Das ist aber in der Regel vorhanden und die Libraries funktionieren somit out-of-the-box. Auch unter Windows sollten sie soweit ohne weiteres Zutun funktionieren. Unter Linux kann man wirkliche statisch gelinkte Libraries herstellen, indem man sie gegen die musl-libc-Implementierung linkt. Dann könnte man die Bibliotheken z.B. auch in FROM scratch Dockerimages verwenden.

Das Ansprechen der Shared Native Libraries im Node-Module war sehr mühsam. Es gibt verschiedene Varianten wie das gemacht werden kann und als bequemer Mensch möchte man natürlich die vermeintlich einfachste Variante verwenden. Daraus wurde aber nichts. Die m.E. einfachere Variante ist das Laden der Library mit purem JavaScript. Dazu wird z.B. das node-ffi-napi-Modul benötigt. Und hier beginnt der Spiessrutenlauf. Das funktioniert nicht auf einem Apple Silicon Gerät. Dann gibt es Forks und Forks von Forks und neue Ansätze, die aber allesamt bei mir überhaupt nicht funktionierten oder zu einem Segfault führten. Somit musste ich die Kröte schlucken und die zweite Variante angehen. Bei dieser muss man ein natives Nodes.js Addon in C/C++ schreiben und gegen meine Shared Library linken. Da und bei der richtigen Konfiguration der Befehle etc. half mir mein neuer 23-Franken-Mitarbeiter (ChatGPT) sehr. Ich weiss nicht, ob ich das ohne ihn hingekriegt hätte. Gut, man hätte wahrscheinlich in einem Forum oder in einer Mailingliste nachgefragt. Ein Auszug aus diesem Addon:

Napi::Value CompileModel(const Napi::CallbackInfo& info) {
    Napi::Env env = info.Env();

    if (thread == nullptr) {
        Napi::Error::New(env, "Isolate not initialized. Call initIsolate first.").ThrowAsJavaScriptException();
        return env.Null();
    }

    if (info.Length() < 2 || !info[0].IsString() || !info[1].IsString()) {
        Napi::TypeError::New(env, "Expected (string iliFile, string logFile)").ThrowAsJavaScriptException();
        return env.Null();
    }

    std::string iliFile = info[0].As<Napi::String>();
    std::string logFile = info[1].As<Napi::String>();

    int res = compileModel(thread, const_cast<char*>(iliFile.c_str()), const_cast<char*>(logFile.c_str()));

    if (res < 0) {
        Napi::Error::New(env, "compileModel critical failure with code: " + std::to_string(res)).ThrowAsJavaScriptException();
        return env.Null();
    }

    // 0 means success, 1 means model compile failure
    return Napi::Boolean::New(env, res == 0);
}

Der JavaScript-Code, der mittels Node-API meine Libs anspricht und gegen aussen ein einfaches API definiert, ist eher trivial:

const path = require('path');

const platform = process.platform;
const arch = process.arch;

let runtime = "node";
if (process.versions.electron) {
  runtime = "electron";
}

if (process.platform === "win32") {
  const dllFolder = path.join(__dirname, 'prebuilds', `${platform}-${arch}`);
  process.env.PATH = `${dllFolder};${process.env.PATH}`;
}

const nativePath = path.join(__dirname, 'prebuilds', `${platform}-${arch}`, runtime, 'ili2c.node');
const native = require(nativePath);

let initialized = false;

// wrapper function that automatically handles isolate
function compileModel(iliFile, logFile) {
  if (!initialized) {
    native.initIsolate();
    initialized = true;
  }
  return native.compileModel(iliFile, logFile);
}

function prettyPrint(iliFile) {
  if (!initialized) {
    native.initIsolate();
    initialized = true;
  }
  return native.prettyPrint(iliFile);
}

// auto-teardown on exit
process.on('exit', () => {
  if (initialized) {
    native.tearDownIsolate();
  }
});

module.exports = {
  compileModel, prettyPrint
};

Das ist aber nicht das Ende des Leidenswegs. Das wird tiptop mit einer normalen Node.js-Anwendung funktionieren aber nicht mit Visual Studio Code. VS Code basiert auf Electron. Electron verwendet wie auch Node.js V8. Aber in einer anderen ABI-Version, d.h. die Binaries sind untereinander nicht kompatibel. Das betrifft aber nicht meine Native Shared Library, sondern bloss das Addon. Dieses muss für Node «pur» und für Electron separat kompiliert werden.

Hat man das alles zusammen, ist es gar nicht mehr so wild. Vor allem dünkt mich, dass man es schon verstehen kann, was abgeht. Unterstützung benötigt man vor allem bei der korrekten Konfiguration der Befehle beim Herstellen der Binaries. Das Ganze resultierte jedoch zu einer umfangreichen Pipeline / Github Action. In meinem Fall habe ich alles in den gleichen Workflow in unterschiedliche Jobs gepackt. Ich bin momentan aber eher der Meinung, dass man sogar das Github-Repository - also den Code - eher wieder auseinanderpfrimeln sollte. Oder aber mindestens die Workflows trennen: ein Workflow inkl. Deployment der Native Shared Libraries, ein Workflow für die Node.js-Bindings und ein Workflow für die Python-Bindings. Heute führt eine kleine Änderung z.B. im Node.js-Binding-Code zu neuen Native Shared Libraries und auch neuen Python-Bindings. Das finde ich nicht gut.

In meiner nicht sehr elaborierten und first-ever Visual Studio Code Extension (muss mindestens bissle aufgeräumt werden, das README.md ist doch eher peinlich) kann ich das ili2c-Node-Modul als Abhängigkeit definieren:

  "dependencies": {
    "ili2c": "^0.0.27",
  }

Man muss aufpassen, dass die Native Shared Libraries vor dem Paketieren der VS Code Extension an den richtigen Ort kopiert werden, sonst landen sie eben nicht in der Extension:

  "scripts": {
    "vscode:prepublish": "npm run package && mkdir -p dist/prebuilds && cp -r node_modules/ili2c/prebuilds/* dist/prebuilds/",
    ...
    "watch": "mkdir -p dist/prebuilds && cp -r node_modules/ili2c/prebuilds/* dist/prebuilds/ && npm-run-all -p watch:*",
    ...
  }

Mit Version 0.0.10 der Extension wird nun auf den Webservice komplett verzichtet und für das Pretty Printing und das Kompilieren des Modelles wird mein ili2c-Node-Modul mit den Native Shared Libraries verwendet. Das Herstellen des UML-Diagramms habe ich aus der Extension entfernt. Soweit funktioniert es bei mir unter macOS tadellos, ob es unter Linux und Windows gleich gut funktioniert, kann ich nicht prüfen:

Was ist mit Python? Das ist eher ein Abfallprodukt und man kriegt das praktisch geschenkt. Dort gibt es keine ähnlichen Schwierigkeiten wie bei Node.js. Keine ABI-Unverträglichkeit und man kann ein Python-Paket zum Ansprechen der Native Shared Libraries verwenden:

from ctypes import *
from importlib_resources import files
import platform

if platform.uname()[0] == "Windows":
    lib_name = "libili2c.dll"
elif platform.uname()[0] == "Linux":
    lib_name = "libili2c.so"
else:
    lib_name = "libili2c.dylib"

class Ili2c:
    @staticmethod
    def create_ilismeta16(iliFile: str, xtfFile: str) -> bool:
        lib_path = files('ili2c.lib_ext').joinpath(lib_name)
        # str() seems to be necessary on windows: https://github.com/TimDettmers/bitsandbytes/issues/30
        dll = CDLL(str(lib_path))
        isolate = c_void_p()
        isolatethread = c_void_p()
        dll.graal_create_isolate(None, byref(isolate), byref(isolatethread))

        try:
            result = dll.createIlisMeta16(isolatethread, c_char_p(bytes(iliFile, "utf8")), c_char_p(bytes(xtfFile, "utf8")))
            return result == 0
        finally:
            dll.graal_tear_down_isolate(isolatethread)

    @staticmethod
    def compile_model(iliFile: str, logFile: str) -> bool:
        lib_path = files('ili2c.lib_ext').joinpath(lib_name)
        dll = CDLL(str(lib_path))
        isolate = c_void_p()
        isolatethread = c_void_p()
        dll.graal_create_isolate(None, byref(isolate), byref(isolatethread))

        try:
            result = dll.compileModel(isolatethread, c_char_p(bytes(iliFile, "utf8")), c_char_p(bytes(logFile, "utf8")))
            return result == 0
        finally:
            dll.graal_tear_down_isolate(isolatethread)

    @staticmethod
    def pretty_print(iliFile: str) -> bool:
        lib_path = files('ili2c.lib_ext').joinpath(lib_name)
        dll = CDLL(str(lib_path))
        isolate = c_void_p()
        isolatethread = c_void_p()
        dll.graal_create_isolate(None, byref(isolate), byref(isolatethread))

        try:
            result = dll.prettyPrint(isolatethread, c_char_p(bytes(iliFile, "utf8")))
            return result == 0
        finally:
            dll.graal_tear_down_isolate(isolatethread)

Installieren kann man das Python-Paket ganz normal:

pip install ili2c

Ein Modell kompilieren:

from ili2c import Ili2c
result = Ili2c.compile_model("test/Test1.ili", "ili2c.log")
print(result)

In Python habe ich eine weitere Methode exponiert (create_ilismeta16). Diese erzeugt aus einem INTERLIS-Datenmodell die dazugehörige IlisMeta16-INTERLIS-Transferdatei. Nun kann man z.B. mit den XML-Fähigkeiten einer beliebigen Programmiersprache das INTERLIS-Datenmodell besser verstehen und daraus andere Dinge ableiten. Oder man spinnt - weil so spassig - mit XQuery 3.1 ein wenig rum und versucht aus dem XML Python Data Classes herzustellen:

xquery version "3.1";

declare namespace ili = "http://www.interlis.ch/xtf/2.4/INTERLIS";
declare namespace IlisMeta16 = "http://www.interlis.ch/xtf/2.4/IlisMeta16";

let $modelTid := "SO_ARP_SEin_Konfiguration_20250115"
let $classes :=
  //IlisMeta16:Class[
    starts-with(@ili:tid, concat($modelTid, ".")) and
    IlisMeta16:Kind = 'Class'
  ]

return
  string-join(
    for $cls in $classes
    let $clsName := $cls/IlisMeta16:Name/text()
    let $clsTid := string($cls/@ili:tid)
    let $attrs := //IlisMeta16:AttrOrParam[IlisMeta16:AttrParent/@ili:ref = $clsTid]
    return
      string-join((
        "from dataclasses import dataclass",
        "from typing import Optional",
        "",
        "@dataclass",
        "class " || $clsName || ":",
        if (empty($attrs)) then
          "    pass"
        else
          string-join(
            for $attr in $attrs
            let $attrName := $attr/IlisMeta16:Name/text()
            let $doc := normalize-space($attr//IlisMeta16:Text/text())
            let $typeRef := $attr/IlisMeta16:Type/@ili:ref
            let $typeEl := //*[namespace-uri() = 'http://www.interlis.ch/xtf/2.4/IlisMeta16' and @ili:tid = $typeRef]
            let $typeKind := name($typeEl)
            let $pyType :=
              if ($typeKind = 'IlisMeta16:TextType') then "str"
              else if ($typeKind = 'IlisMeta16:NumType') then "float"
              else if ($typeKind = 'IlisMeta16:DateType') then "str" (: or use date :)
              else "Optional[str]" (: default fallback :)
            return
              "    " || $attrName || ": " || $pyType || (
                if ($doc) then "  # " || $doc else ""
              )
          , codepoints-to-string(10))  (: newline :)
      ), codepoints-to-string(10))
  , codepoints-to-string(10) || codepoints-to-string(10))  (: double newline between classes :)

from dataclasses import dataclass
from typing import Optional

@dataclass
class Gemeinde:
    Name: str  # Name der Gemeinde (gemäss amtlichem Verzeichnis)
    BFSNr: float  # Offizielle Gemeindenummer
    Geometrie: Optional[str]  # Geometrie
    Bezirk: str  # Name des Bezirks
    Handlungsraum: Optional[str]

from dataclasses import dataclass
from typing import Optional

@dataclass
class Gemeinde:
    BoundingBox: str  # Ausdehnung / Bounding Box
    Gruppen: Optional[str]  # Liste sämtlicher Themen-Gruppen.

from dataclasses import dataclass
from typing import Optional

@dataclass
class Gemeinde:
    pass

from dataclasses import dataclass
from typing import Optional

@dataclass
class Gruppe:
    pass

from dataclasses import dataclass
from typing import Optional

@dataclass
class Objektinfo:
    pass

from dataclasses import dataclass
from typing import Optional

@dataclass
class Thema:
    pass

Ist jetzt nicht das Ende der Fahnenstange aber mit wenig schon einiges erreicht. Vieles fehlt natürlich: Aufzähltypen, abstrakte Klassen, Strukturen, qualifizierte Klassennamen, etc. pp. Meine Prompts waren sicher nicht allzu gut und zu detailliert. Dazu müsste ich sicher auch das Metamodell besser verstehen.

Nochmals: Unter macOS funktioniert das alles tadellos. Wie es mit anderen Betriebssystemen aussieht, weiss ich nicht. Es gibt ein paar Tests in der Github Action, die auf jedem Betriebssystem laufen. Ob jedoch das Endprodukt wirklich überall funktionstüchtig ist, ist noch eine Unbekannte.

INTERLIS leicht gemacht #52 - Neues vom Modelfinder

Mon, 21 Jul 2025 00:00:00 +0000

Vor Jahren habe ich eine Webanwendung geschrieben, die regelmässig (2x pro Tag) die INTERLIS-Modellablagen (genauer die ilimodels.xml-Dateien) durchforstet, diese mit Lucene indexiert und via GUI durchsuchbar macht. Die Anwendung ist in sich selber genügend, d.h. es gibt keine Abhängigkeiten zu einer Datenbank o.ä. Das soll auch so bleiben.

«Klammer-Rant»: Leider stellte sich heraus, dass eine solche Anwendung (genau wie auch https://ilimodels.ch) nur halb sinnvoll ist: Es fehlt das gemeinsame Verständnis wie die ilimodels.xml-Datei abgefüllt werden soll. Welche Informationen gehören da rein? Eventuell fehlt auch noch ein Attribut oder auch zwei im darunterliegenden Datenmodell. Die Krux ist eben die, dass man nun nach «Naturgefahren» suchen kann, aber das MGDM nicht findet. Der Grund dafür ist, dass das MGDM in Englisch modelliert ist und der Name des Modelles «Hazard_Mapping_LV95_V1_3» ist. Nun gibt es im ilimodels.xml das Tags-Attribut, das beliebige Schlagwörter aufnehmen kann. Leider füllt hier Swisstopo nur das GeoIV-Nümmerli (z.B. 166.1) ab. Somit bringt die Indexierung dieses Attributes für das konkrete Problem auch nichts. Lange Rede, kurzer Sinn: Man findet heute eigentlich die gesuchten Modelle eher schlecht. «Jemand» müsste das endlich angehen.

Von Zeit zu Zeit bin ich jedoch dankbar um unseren Modelfinder. Im Regelfall suche ich eigentlich eh nur unsere Modelle oder MGDM oder Kernmodelle. Via Modelfinder bin ich schneller als wenn ich einfach durchklicken würde. An unserer Lösung störte mich insbesondere die technische Umsetzung des Frontends. Dieses wurde mit GWT umgesetzt. Mit GWT schreibt man die JavaScript-Anwendung in Java und ein Transpiler wandelt den Java-Code in JavaScript um. Das funktioniert sehr gut und der Transpiler erzeugt effizientes JavaScript. Das ganze Drumherum ist aber für meine Usecases meistens ein Overkill. Oftmals habe ich bloss ein Suchfeld in dem der Benutzer z.B. nach Kartenlayer, nach Datensätzen oder ähnlichem suchen kann. Gefundene Objekte werden tabellarisch dargestellt. In diesem Fall sind es INTERLIS-Datenmodelle. Da ist nicht viel JavaScript drin. Man könnte natürlich JavaScript direkt schreiben, aber das will ich trotzdem lieber nicht, wenn ich es umgehen kann. Dabei kommt mir HTMX zu Hilfe. HTMX scheint mir ein wenig HTML auf Steroiden zu sein. Mit zusätzlichen Attributen kann z.B. jedes beliebige HTML-Element HTTP-Requests machen. Und es müssen nicht mehr zwingend click und submit Events sein, welche diese Requests triggern. Das offizielle Quickstart-Beispiel:

<script src="https://cdn.jsdelivr.net/npm/htmx.org@2.0.6/dist/htmx.min.js"></script>
<!-- have a button POST a click via AJAX -->
<button hx-post="/clicked" hx-swap="outerHTML">
  Click Me
</button>

Was passiert da? Wenn man auf den Button klickt, wird ein AJAX-Request ausgeführt und der Inhalt des Buttons wird mit der Antwort ersetzt. Die Definition meines input-Elementes (das eigentliche Suchfeld nach Datenmodellen) sieht mit HTMX wie folgt aus:

<input id="search-input" class="search-input"
    type="text"
    name="query"
    hx-get="models"
    hx-target="#results"
    hx-trigger="input keyup changed delay:300ms"
    hx-headers='{"Accept": "text/html"}'
    autocomplete="off"
    placeholder="Search for INTERLIS models..." />

Als Templating-Engine verwende ich neuerdings jte. Mit Thymeleaf wurde ich nie richtig warm. Entweder stimmt was mit mir nicht oder mit Thymeleaf.

Mit diesem Setup kann ich den ganzen GWT-«Ballast» über Bord werfen. Damit verschwindet auch ein weiteres Projekt, welches nicht Gradle, sondern Maven als Build-Tool verwendet. Nichts gegen Maven per se aber ich möchte mich bei uns auf ein Build-Tool beschränken und es fällt mir einfacher mit Gradle zu arbeiten.

Die Startseite mit den Suchresultaten sieht nicht viel anders aus:

Neben den technischen (weniger sichtbaren) Neuerungen gibt es ein paar funktionale Neuerungen: Neu gibt es eine Detailansicht eines Datenmodelles. Die Detailansicht beinhaltet die Attribute aus der ilimodels.xml-Datei. Das hilft v.a. auch für das Aufdecken von Flüchtigkeitsfehlern. Interessanter wird es bei der Darstellung des Modelles. Es gibt eine textuelle Vorschau des Modelles mit Syntax Highlighting. Das Modell wird nicht zur Laufzeit vom Repository gelesen, sondern liegt ebenfalls im Suchindex vor. Das Syntax Hightlighing mache ich mit Prism. Die dazugehörige Konfiguration habe ich der Konfiguration der Visual Studio Code INTERLIS Extension entnommen und mittels ChatGPT umgewandelt. Das hat auf Anhieb funktioniert. Neben der textuellen Vorschau gibt es eine visuelle Vorschau mittels UML-Diagramm. Das UML-Diagramm wird mit bereits vorhandenem Code zur Laufzeit hergestellt. Zur Laufzeit weil ich beim Indexieren nicht die Modelle kompilieren will. Einige Modelle können nicht dargesestellt werden. Das liegt meines Erachtens jedoch an Fehlern in meinem Code. Diesen möchte ich eh nochmals refactoren und schauen, ob er gänzlich ohne UML/INTERLIS-Editor-Code auskommt. Ich bin nicht ganz sicher wie resp. wo ich das Diagramm darstellen will. Unterhalb des Modelles ist nicht ganz glücklich. Eigentlich will man doch das Modell lesen können und das UML-Diagramm gleichzeitig sehen können? Mal schauen, ob mir da noch eine gute Idee kommt. Für grössere Modelle muss ich noch das Zoom-und-Pan-JavaScript-Plugin einbauen. Aber so ganz grundsätzlich bin ich eigentlich zufrieden:

Wie bereits die alte Version des Modelfinders wollte ich auch die neue Version mit GraalVM in ein Native Image runterkompilieren und damit Ressourcen sparen. Das stellte sich aber als Unmöglichkeit heraus, weil die UML-Diagramm-Abhängigkeit UML/INTERLIS-Editor-Code verwendet, der wiederum AWT-Klassen referenziert. Das ist mit GraalVM noch ein Gefummel. Mit der Liberica-Version von GraalVM sollte es funktionieren. Bei mir nur theoretisch. Ich habe dann einen anderen Weg beschritten, um die Startup-Zeit und den Ressourcenbedarf der Java-Anwendung zu reduzieren. Java versucht mit dem Projekt Leyden diese Fragestellungen anzugehen und auch ohne das Runterkompilieren der gesamten Anwendung in ein Native Image zu lösen. In einem Bell Software Blogbeitrag wird gezeigt, was heute mit Java 24 bereits möglich ist. Die Herstellung des Dockerimages wird zwar leicht komplizierter, die Startup-Zeit in unserem OpenShift-Cluster reduzierte sich aber von 2.5 Sekunden auf circa 0.8 Sekunden.

Links:

INTERLIS leicht gemacht #51 - INTERLIS im Browser

Sun, 20 Jul 2025 00:00:00 +0000

Ein Stück weit hat sich gedanklich eingebürgert, dass INTERLIS-Prüfungen nur via Webservice funktionieren. «Schuld» daran ist wohl die amtliche Vermessung mit dem dazugehörigen Checkservice. Damit wären wir auch gleich bei den positiven Aspekten eines Checkservices: Oftmals werden neben der eigentlichen Modellkonformität weitere Aspekte geprüft. Im Falle von ilivalidator sind diese in einem sogenannten Validierungsmodell (z.B. Nutzungsplanung) mit zusätzlichen INTERLIS-Constraints definiert. Manchmal benötigen diese Zusatzcontraints eigene INTERLIS-Funktionen. Also Funktionen, die nicht Bestandteil der INTERLIS-Spezifikation sind. Diese Funktionen (verpackt in einer Jar-Datei) müssen ilivalidator bekannt gemacht werden. Das alles ist machbar aber nicht sehr anwenderfreundlich. Man kann das als Auftraggeber (im Sinne von INTERLIS-Datenerfassung an Dritte beauftragen) vereinfachen, indem man im Datenrepository ein sogenanntes Prüfprofil anlegt (entspricht einer metaConfig-Datei, z.B. Nutzungsplanung). Damit ist für die Auftragnehmer der ilivalidator-Aufruf viel einfacher:

java -jar ilivalidator.jar --metaConfig ilidata:SO_Nutzungsplanung_20171118_20231101-meta npl.xtf

Und schon werden sämtliche vom Auftragnehmer zusätzlich definierten Constraints und andere Spezialkonfigurationen bei der Validierung angewendet. Ist die Prüfung jedoch abhängig von zusätzlichem Code (also den zusätzlichen Funktionen), funktioniert es trotzdem nicht und der Auftragnehmer müsste die Jar-Datei(en) irgendwo herunterladen. Also auch zu kompliziert, insbesondere wenn im Jahre 2025 bereits ein Konsolenaufruf eine Herausforderung ist. Das ilivalidator-GUI hilft hier halt auch nicht weiter («Was? Ilivalidator hat ein GUI?!»).

Aus diesem Grund ist ein zentral angebotener INTERLIS-Checkservice (inkl. sinnvoller maschineller Schnittstelle) nicht die dümmste Idee. Ein Grund warum ilivalidator überhaupt entstanden ist, war das Ziel, ihn frei verfügbar zu machen. Damit ist es auch möglich den (Prüf-)Algorithmus zu den Daten zu bringen und nicht die Daten zum Algorithmus. Der zentrale Checkservice hat entsprechend auch Nachteile: Die Daten verlassen die Organisation (oftmals zu einem Drittanbieter) und der Checkservice-Anbieter muss theoretisch beliebig viel Last verarbeiten können resp. er hat keine Ahnung, was ihn erwartet. Wir haben INTERLIS-Validierungen, die circa 8GB RAM benötigen. Dies aber nur ein paar Mal pro Jahr. Da wäre es eben einfacher, wenn der Auftragnehmer/Datenerfasser auf seinem Rechner (der wahrscheinlich mehr als das Doppelte an Arbeitsspeicher aufweist) die Validierung durchführen könnte und nicht wir mit unserem ilivalidator-web-service und diesem für drei Aufrufe pro Jahr 8GB RAM reservieren müssen. Ein weiteres Übel für den Diensteanbieter ist der Platzbedarf. Einerseits wenn die Transferdateien sehr gross werden (hier zudem noch die Firewall dazu kommt) und andererseits die temporären Dateien, die während der Validierung angelegt werden. Plattenplatz ist zwar relativ billig aber skaliert dann trotzdem nicht gegen unendlich.

Nun könnte man doch quasi «best of both worlds» anbieten: Einen INTERLIS-Checkservice, der die Transferdateien aber nicht auf einen fremden Server hochlädt, sondern lokal im Browser prüft. Wie das? Als erstes kommt einem WebAssembly in den Sinn. Die Frage ist also bloss, wie mache ich aus dem ilivalidator eine WASM-Datei? Es stellt sich natürlich heraus, dass das nicht wirklich simpel ist. GraalVM hat eine WebAssembly-Laufzeitumgebung aber ich will das Gegenteil. Und das Gegenteil steckt noch sehr in den Kinderschuhen. Ein zweites sehr interessantes Projekt ist TeaVM: Ein Ahead-of-Time Compiler, der aus Java-Bytecode JavaScript und WebAssembly erzeugt. Voller Vorfreude machte ich mich an einen Test aber schon bald stellte sich Ernüchterung ein. Man kann nicht einfach beliebige Java-Bibliotheken mir nichts, dir nichts nach WebAssembly kompilieren. Das hat damit zu tun, dass in WebAssembly nicht alles möglich ist, was mit Java geht und dass nicht alles was Java hergibt von TeaVM unterstützt wird. Zuerst musste ich SQLException-Klasse stubben nur um dann bei den antlr-Aufrufen von ili2c und den XML-Klassen zu scheitern. Also WebAssembly in dieser Form ad acta gelegt.

Ganz aufgeben kann/will man dann doch nicht. Es gibt noch CheerpJ: Das ist eine (vollständige) JVM für den Browser in WebAssembly und JavaScript. Ein Fokus liegt z.B. auf der Weiterverwendung von Legacy-Apps (z.B. Applets oder Swing-Anwendungen). Man kann aber auch headless beliebige Java-Bibliotheken ansprechen. Gesagt, getan. Der Einfachheit halber habe ich ilivalidator zu einer Fat Jar kompiliert. Somit muss ich mich nur um eine Jar-Datei kümmern. Die Lizenz sieht vor, dass man für Open Source Projekte CheerpJ gratis verwenden darf. Man kann aber die JavaScript-Datei (und zu guter Letzt die Browser-JVM) nicht lokal hosten. Aber zum Ausprobieren reicht es. Man muss einzig eine loader.js-Datei laden. Die ganze «Anwendung» sieht wie folgt aus (CSS-Teil weggelassen):

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>ilivalidator service</title>
  <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@picocss/pico@2/css/pico.min.css">
  <script src="https://cjrtnc.leaningtech.com/4.2/loader.js"></script>
  <style>
    ...
  </style>
</head>

<body>
  <script>
    (async function () {
      await cheerpjInit({ version: 17, status: "none" });
    })();
  </script>

  <div id="overlay">
    <div class="spinner"></div>
  </div>

  <main class="container">
    <h2>ilivalidator service</h2>

    <form onsubmit="handleFile(event)">
      <input
        type="file"
        id="fileInput"
        accept=".xml,.xtf,.itf"
        required
      />
      <button type="submit">Validate</button>
    </form>

    <p id="status"></p>

    <section id="logContainer">
      <h3>Validation Log</h3>
      <pre id="logOutput">Loading...</pre>
    </section>
  </main>

  <script>
    function handleFile(event) {
      event.preventDefault(); // prevent form from submitting

      const input = document.getElementById('fileInput');
      const file = input.files[0];
      const status = document.getElementById('status');
      const overlay = document.getElementById('overlay');
      const logContainer = document.getElementById('logContainer');
      const logOutput = document.getElementById('logOutput');

      if (!file) {
        status.textContent = "Please select a file first.";
        return;
      }

      const reader = new FileReader();
      reader.onload = async function(e) {
        const content = e.target.result;
        const filename = file.name;
        const path = "/str/" + filename;
        const logPath = "/files/" + filename + ".log";

        // Ensure cheerpOSAddStringFile exists
        if (typeof cheerpOSAddStringFile === 'function') {
          cheerpOSAddStringFile(path, content);
          status.textContent = `File "${filename}" loaded. Starting validation...`;
          overlay.style.display = "flex";

          try {
            const exitCode = await cheerpjRunJar("/app/ilivalidator-1.14.8-SNAPSHOT-all.jar", "--modeldir", "https://geo.so.ch/models;https://geo.so.ch/models/mirror/interlis.ch/;https://geo.so.ch/models/mirror/geoadmin/", "--log", logPath, path);
            status.textContent = `Validation finished with exit code ${exitCode}.`;

            const logBlob = await cjFileBlob(logPath);
            const logText = await logBlob.text();
            logOutput.textContent = logText;
            logContainer.style.display = "block";
          } catch (err) {
            status.textContent = `Error during validation: ${err.message || err}`;
          } finally {
            overlay.style.display = "none";
          }
        } else {
          status.textContent = "Error: cheerpOSAddStringFile is not defined.";
        }
      };
      reader.readAsText(file);
    }
  </script>

</body>
</html>

Es gibt zwei technische Herausforderungen damit man überhaupt die Anwendung zum Laufen kriegt: Da ist neu der Umstand, dass die INTERLIS-Modellablagen korrekt CORS konfiguriert haben müssen, weil ilivalidator nun ja in einem Browser läuft und die Modelle suchen muss. Verschiedene Modellablagen sind nicht korrekt konfiguriert. Aus diesem Grund setze ich bewusst beim ilivalidator-Aufruf in Zeile 76 die --modeldir-Option und verwende unsere Mirror-Repositories. Eine weitere Herausforderung ist der Umgang mit Dateien. Da ist einerseits die Konvention, dass die Jar-Dateien im Root-Verzeichnis liegen müssen und dann mit dem Pfad /app/… angesprochen werden müssen. Weitere Konventionen gelten für den Austausch von Dateien zwischen JavaScript und Java, z.B. muss ilivalidator die zu prüfende XTF-Datei bekannt gemacht werden. Und JavaScript muss am Ende auf den Inhalt der Logdatei, die ilivalidator erstellt hat, zugreifen können. Funktionieren tut es grundsätzlich tadellos:

Perfekte Welt? Mitnichten. Im Logfile sieht man den Memory, der der JVM zugewiesen wurde. Das sind 2GB. Ich weiss nicht, ob man das steuern kann. Lokal wird der JVM bei mir (mit 16GB) standardmässig 4GB zugewiesen. So wie ich es verstehe, stehen einer 32bit-WebAssembly-Anwendung anscheinend maximal 4GB zur Verfügung (gemäss Spezifikation) oder nur 2GB durch Browser-Limits. Will man ilivalidator im Browser wirklich verwenden, müsste sicher mehr drinliegen als bloss die 2GB. Das andere und vielleicht gewichtigere Problem ist die Performance. Diese scheint mir nicht auf Java-Niveau zu sein. Dauert die Prüfung im Browser 8 Sekunden, ist es lokal bloss eine… Upsi. Es erinnert mich an die Tests, die ich mit ilivalidator gemacht habe und versuchte nur den Bytecode auszuführen (ohne das - während der Laufzeit - Runterkompilieren nach Maschinencode).

INTERLIS im Browser scheint also nicht ganz so einfach zu sein und hat wohl auch einige Rahmenbedingungen, mit denen man leben muss. Dazu gehört sicher die Performance. Aber für den einen oder anderen (vielleicht exotischen) Usecase kann man mindestens mit CheerpJ ganz einfach die ilitools-Welt in den Browser bringen.

Links:

https://github.com/edigonzales/ilivalidator-local-web-service

INTERLIS leicht gemacht #50 - INTERLIS Developer Experience Improvements

Fri, 13 Jun 2025 00:00:00 +0000

Zum Geobeer-Jubiläum (50. Ausgabe coming soon) gehe ich in Vorleistung und schreibe den 50. INTERLIS-leicht-gemacht-Beitrag. Es gibt ein paar Dinge, die mich beim täglichen Arbeiten mit INTERLIS und den Werkzeugen stören. Und ein paar Dinge, die ich zwar nicht wirklich benötige aber trotzdem hilfreich fände.

Beginnen wir mit den störenden Dingen: Ich habe verschiedenste Versionen der verschiedenen INTERLIS-Tools installiert. Das kann zum Debuggen von Bugs manchmal ganz hilfreich sein («Das ging doch noch mit Version XY»). Das Herunterladen und in den korrekten Ordner kopieren, ist jetzt nicht so ein Ding. Was mich grundsätzlich eher stört, ist dass ich immer java -jar /Users/stefan/apps/ili2c-5.5.3/ili2c.jar fubar.ili tippen muss. Ja, jede Sekunde des Kantonsangestellten zählt. Ich bin grosser Fan von SDKMAN!. Damit lassen sich einfach verschiedenste JDK und andere Java-Software installieren. Etwas Ähnliches für die INTERLIS-Werkzeuge habe ich mir immer gewünscht. Gescheitert ist es an meinem Unvermögen brauchbare Bash-Skripte zu schreiben. Times have changed: Nein, ich kann immer noch keine Bash-Skripte schreiben, aber ChatGPT kann es. Welcome ilitools-manager (sehr origineller Name…).

Wie installiert man ilitools-manager? Als erstes muss gesagt werden, dass es nur in einer Shell unter Linux oder macOS funktioniert resp. unter Windows mit WSL2. Jedoch nicht in der Powershell. Zudem muss curl und unzip installiert sein. Unter macOS ist das bereits dabei, in meiner nackten Ubuntu-Installation musste ich glaube unzip installieren. Wenn diese Rahmenbedingungen erfüllt sind, reicht:

curl -s https://raw.githubusercontent.com/edigonzales/ilitools-manager/refs/heads/main/install-ilitools.sh | bash

Anschliessend entweder ein Terminal neu öffnen oder source ~/.bashrc. Dann sollte ilitools im Pfad verfügbar sein:

ilitools kennt drei Befehle: Man kann sich für ein bestimmtes Werkzeug die vorhandenen Versionen anzeigen lassen, z.B. alle verfügbaren INTERLIS-Compiler, die man sich installieren lassen kann:

Zurzeit werden die Werkzeuge ili2c, ilivalidator und «oldie but goldie» UML/INTERLIS-Editor unterstützt. Zum Installieren einer Version reicht folgender Befehl:

Das erstellt mir zusätzlich ein Wrapper-Skript ili2c mit dem ich den INTERLIS-Compiler starten kann:

Wenn ich nochmals ilitools l ili2c ausführe, zeigt es mir in der Liste an, welche Versionen ich installiert habe ((installed)) und welches die vom Wrapper-Skript aktuell verwendete ist (>):

Mit ilitools u ili2c 5.6.2 kann ich die zu verwendende Version ändern.

Woher die Liste mit den Versionen stammt? Ich verwende die maven-metadata.xml-Datei aus dem Maven-Repository.

Nächstes Thema: Visual Studio Code wird dank der INTERLIS-Extension von GeoWerkstatt gerne zum Schreiben von INTERLIS-Modellen verwendet. Wie cool wäre es, wenn ich das Modell auch gleich mit dem INTERLIS-Compiler prüfen könnte und zwar ohne den Compiler installieren zu müssen? Wie soll das gehen? Viele Möglichkeiten dazu gibt es ja nicht. Ich habe mich dazu entschieden einen Webservice zu schreiben, der eine Datei entgegen nimmt, mit ili2c die Datei kompiliert und das Logfile zurückschickt. Eingebettet in eine Visual Studio Code Extension. Es gibt einen global verfügbaren Webservice, der standardmässig in der Extension konfiguriert ist. Man kann den Service jedoch auch einfach in der eigenen Organisation betreiben, damit die Modelle nicht irgendwo in einem schwarzes Loch (auf einem Hetzner-Server in Deutschland) verschwinden.

Eine besondere Anforderung habe ich an den Webservice gestellt: Er soll zukünftig fähig sein mit verschiedenen Compiler-Versionen umgehen zu können. Wie kann ich das mit Spring Boot umsetzen? Frägt man unbedarft das Internet, kommt als erstes natürlich das Stichwort «Microservice» zurück. D.h. für jede Version des Compilers einen eigenen Webservice. Das ist mir aber irgendwie zu mühselig. Am anderen Ende der Fahnestange wäre die Variante mit einer Spring Boot Anwendung und dem dynamischen Laden der korrekten Version der ili2c-Abhängigkeiten. Das Stichwort hier ist «Class Loader Isolation». Das wiederum scheint mir zu heikel zu sein, da mein Verständnis dafür auch eher beschränkt ist. Den Mittelweg, den ich eingeschlagen habe, ist das WAR-Deployment. Dabei wird anstelle einer Fat-JAR-Datei (inkl. embedded Tomcat) eine WAR-Datei klassisch in einer Tomcat-Instanz deployed. D.h. ich kann für zukünftige Compiler-Versionen eine neue WAR-Datei erstellen und in der gleichen Tomcat-Instanz deployen (innerhalb eines Dockerfiles). Der Nachteil bei dieser Variante mit Spring Boot ist, dass jeweils das gesamte Spring Boot Framework ebenfalls in die WAR-Datei gepackt wird. Wenn man z.B. mit Jakarta EE unterwegs wäre, würde nur genau die Business-Logik (inkl. deren Abhängigkeiten) in die WAR-Datei gepackt. Es gäbe zwar verschiedene Workarounds für solche Thin-WAR-Dateien aber es sind halt Workarounds.

Zusätzlich zum Compiler möchte ich auch einen INTERLIS-Modell-Pretty-Print-Service anbieten und weil wir gerade dabei sind, möchte ich aus dem iliprettyprint mehr machen als bloss Modelle schön formatieren. Weil ich dazu die Bibliotheken vom UML/INTERLIS-Editor verwende, habe ich mir vorgestellt, dass man sicher relativ einfach auch UML-Diagramme erstellen kann. Das Modell ist nach dem Einlesen dahingehend interpretiert und strukturiert, dass das Herstellen von z.B. PlantUML- und Mermaid-Code relativ einfach sein sollte. D.h. ich erstelle auch aus dem erweiterten iliprettyprint-Code eine WAR-Datei und deploye sie in einer Tomcat-Instanz.

In der Tomcat-Instanz laufen also zwei Anwendungen mit ingesamt drei API-Endpunkten:

Zu guter Letzt müssen wir uns um die Visual Studio Code Extension kümmern. Dazu muss ich - wie beim ilitools manager - ChatGPT verwenden. Erstes kann ich überhaupt kein TypeScript programmieren und zweitens wüsste ich nicht wo beginnen mit der Extension und wie das gepackt und publiziert wird. Auch mit der Hilfe von ChatGPT war es bisschen hakelig. Aber am Ende hat es dann doch relativ wenig Aufwand benötigt. Die Extension hat den fantasievollen Namen «INTERLIS Tools»:

Wenn man eine INTERLIS-Modell-Datei im Editor lädt, fällt auf - jedenfalls ist es bei mir so -, dass die GeoWerkstatt-Extension automatisch ein UML-Diagramm (Mermaid) erstellt. Als zweites fällt auf, dass das Diagramm Fehler aufweist. Ich glaube, das hat damit zu tun, dass im Mermaid-Code für ein Objekt nicht ein eindeutiger Identifikator verwendet wird, sondern es wird nur der Name verwendet. So auch bei der Definition von Vererbungen. Aus diesem Grund zeigen alle Vererbungen irgendwie auf sich selber.

Für meine Extension kann man verschiedene Einstellungen vornehmen. Für jeden Service kann man den Endpunkt definieren und man kann zwischen zwei UML-Varianten wählen: PlantUML und Mermaid. Bei PlantUML schickt der Service die gerenderte PNG-Datei zurück, bei Mermaid den Sourcecode. Dieser wird in Visual Studio Code in einem eingebetteten Browser zu SVG gerendert.

Das Kompilieren des INTERLIS-Modelles muss erstmalig mit Ctrl+Shift+P ausgewählt werden:

Allfällige Fehler werden in einem separaten Fenster geloggt:

Die Modell-Datei wird anschliessend bei jedem Speichern geprüft:

Ähnlich verhalten sich die Dienste für das Pretty Printing und das Herstellen des UML-Diagramms:

So und jetzt das Ganze auch noch für jEdit?

Links:

AI - Model Context Protocol (MCP)

Wed, 16 Apr 2025 00:00:00 +0000

So, ich steig' jetzt ebenfalls auf den fahrenden MCP-Zug auf. Der neueste KI-Hype. Was ist das Model Context Protocol? Ich glaube, vereinfacht darf man sagen, dass es sich um eine standardisierte Variante von Function-Calling handelt. Der LLM erlaubt/ermöglicht man das Aufrufen bestimmer (zur Verfügung gestellter) Funktionen. Was die Funktionen machen und was sie zurückliefern, ist völlig offen. Erfunden hat das Protokoll Anthropic, die Firma hinter claude.ai.

Ich denke schon, dass eine öffentliche Verwaltung gewisse Mehrwerte mit LLM schaffen kann. Vor allem, wenn man auf eigene Daten zugreifen kann. Nun ist das so eine Sache. Bei uns ist halt in der Regel halb richtig, ganz falsch. Wem gehört ein Grundstück? Da gibt es eine richtige Antwort. Bei der Verwendung von LLM für die Beantwortung dieser und ähnlicher Fragen kann MCP sehr gut helfen. Das LLM entscheidet selbständig, dass es auf die Frage nicht mit seinem Basiswissen antworten kann und macht eine Anfrage via MCP. Die MCP-Funktion frägt dann z.B. beim Grundbuch (via GBDBS-Schnittstelle) nach und liefert den Namen des Eigentümers / der Eigentümerin. Das LLM macht anschliessend einen überzeugenden, toll klingenden Satz daraus.

Um bei Demos nicht gleich zu riskieren, dass die Leute wegen «LLM und Grundbuch» in Ohnmacht fallen, wähle ich andere Testfragen. Zum Aufwärmen soll mir das LLM alle Gemeindenamen des Kantons zurückliefern. Ich möchte auch fragen können, ob es in einer Gemeinde schützenswerte Ortsbilder (ISOS) gibt. Und zu guter Letzt soll es mir sagen, von welchen ÖREB-Themen ein Grundstück in einer Gemeinde betroffen ist.

Dazu braucht es einen MCP-Server und einen MCP-Client. Ich weiss nicht, ob es korrekt formuliert ist, aber ich würde sagen, dass der MCP-Client auch als LLM-Inferencer wirkt. Client und Server können gemäss Standard unterschiedlich miteinander kommunizieren: STDIO und Server-Sent Events. Für meine Tests reicht STDIO locker aus. Als Client wähle ich die Claude-Desktop-Anwendung. Für die Implementierung des Servers wähle ich natürlich Spring Boot, Spring AI und ein Video von His Masters Voice Dan Vega. Im Grunde genommen, muss man in Spring nur eine Service-Klasse mit einer Methode erstellen, welche die Businesslogik (im folgenden Beispiel eine Datenbankabfrage) enthält und diese korrekt annotieren, z.B.:

@Service
public class GemeindeService {
    private static final Logger log = LoggerFactory.getLogger(GemeindeService.class);

    private final JdbcClient jdbcClient;

    public GemeindeService(@Qualifier("pubJdbcClient") JdbcClient jdbcClient) {
        this.jdbcClient = jdbcClient;
    }

    @Tool(name = "sogis_get_area_of_municipalities", description = "Alle offiziellen Namen der Gemeinden des Kantons Solothurn mit ihrer Fläche / ihrem Flächenmass in Quadratmeter.")
    public List<Gemeinde> getGemeinden() {
        return jdbcClient.sql("SELECT gemeindename AS name,ST_Area(geometrie) AS flaeche FROM agi_hoheitsgrenzen_pub_v1.hoheitsgrenzen_gemeindegrenze")
                .query(Gemeinde.class)
                .list();
    }
}

Matchentscheidend ist die Beschreibung der Methode. Anhand dieser wird das LLM entscheiden für welche Frage es die Methode aufruft. Die Methoden müssen zusätzlich registriert werden:

@Bean
public List<ToolCallback> sogisTools(
        GemeindeService gemeindeService,
        IsosService isosService,
        GrundstueckService grundstueckService,
        OerebService oerebService) {
    return List.of(ToolCallbacks.from(gemeindeService, isosService, grundstueckService, oerebService));
}

Weil die Kommunikation über STDIO geschieht, darf die Anwendung nichts loggen und keinen Banner in die Konsole rendern:

spring.main.banner-mode=off
logging.pattern.console=

Das ist aber auch schon alles. Den vollständigen Quellcode gibt es im Github-Repo. Die Konfiguration des MCP-Clients / von Claude-Desktop geschieht über die JSON-Datei claude_desktop_config.json. Diese kommt im Claude-Applikations-Verzeichnis zu liegen:

{
    "mcpServers" : {
        "sogis-mcp" : {
            "command" : "/Users/stefan/.sdkman/candidates/java/21.0.4-graal/bin/java",
            "args" : [
                "-jar",
                "/Users/stefan/sources/sogis-mcp-poc/build/libs/sogis-mcp-poc-0.0.1-SNAPSHOT.jar"
            ]
        }
    }
}

Wenn alles so ist, wie es sein soll, sollte das GUI wie folgt aussen:

Wichtig ist das Hammer-Symbol mit der Zahl Vier. Das bedeutet, dass es vier verfügbare MCP Tools (Funktionen) gibt:

Wie man auf dem Screenshot erkennt, habe ich vier MCP-Funktionen implementiert. Bis auf die Letzte sind alles Datenbankabfragen. Die ÖREB-Funktion ruft natürlich den ÖREB-Webservice auf und wertet die zurückgelieferte XML-Datei aus.

Was liefert Claude bei der einfachsten Frage? Freude herrscht: Claude frägt, ob er den MCP-Server benutzen darf. Das kann so eingestellt werden, dass nicht bei jeder gestellten Frage wieder nachgefragt wird:

Die Antwort des MCP-Servers kann man sich anzeigen lassen:

Das Resultat überzeugt. Er listet alle 106 Gemeinden auf. Lustigerweise hat Claude auch schon 107 Gemeinden gelistet gehabt (Drei Höfe 2x). Der MCP-Server liefert natürlich immer das korrekte Resultat.

Jetzt möchte ich wissen, ob es in Grenchen ein schützenswertes Ortsbild gibt:

Die Antwort ist tiptop. Claude listet mir sogar die von der MCP-Funktion gelieferten Links zum PDF-Objektblatt und zum Web GIS Client auf. Ich will noch wissen, ob es in Messen schützenswerte Ortsbilder gibt (ja, zwei) und in Kyburg-Buchegg, wobei ich bewusst den Gemeindenamen falsch schreibe:

Claude erfüllt die Aufgabe auch hier. Nun zur Champions League: Ich möchte wissen, von welchen ÖREB-Themen das Grundstück 4497 in Grenchen betroffen ist. Dazu muss Claude zweimal eine MCP-Funktion aufrufen. Zuerst muss er aus Grundbuchnummer und Gemeindename den E-GRID ausfindig machen und anschliessend mit dem E-GRID eine andere MCP-Funktion aufrufen. Faszinierend ist für mich bereits, dass er Grundbuchnummer und Gemeindename korrekt der Funktion übergeben kann (und sie z.B. nicht vertauscht). Auch diese Aufgabe meistert Claude problemlos:

Wahrscheinlich lässt sich noch was rausholen, wenn man mit System-Prompts arbeiten würde/könnte und so ggf. die Themen selber besser beschreiben kann.

Löst MCP alle Probleme? Nein, insbesondere muss man aufpassen, dass man den Spagat hinkriegt zwischen sehr allgemeinen GIS-Fragestellungen und sehr spezifischen, die man mittels Funktionen beantworten will. Sind sie zu spezifisch, implementiert man sich wohl den Wolf. Sind sie zu allgemein, kann die LLM doch wieder keine schlüssige Antwort daraus formulieren.

INTERLIS leicht gemacht #49 - Der UML/INTERLIS-Editor ist tot, lang lebe der UML/INTERLIS-Editor

Sun, 13 Apr 2025 00:00:00 +0000

Der UML/INTERLIS-Editor wird völlig zu unrecht schlechtgeredet. Was gibt es daran auszusetzen? Spass beiseite. Aber so übel wie immer darüber gesprochen wird (von den Leuten, die eh nicht modellieren), ist er nicht. Es ist vielleicht nicht das sexieste Werkzeug ever aber interessanterweise kann ich auch seine positiven Seiten wertschätzen. Grundsätzlich denke ich, dass er logisch aufgebaut ist und entsprechend (halb-)intuitiv zu bedienen ist. Wenn man INTERLIS halt gar nicht versteht, kann man auch mit dem Editor keine Modelle erstellen. Mich dünkt, dass er mich das eine oder andere Mal definitiv was gelehrt hat aufgrund seines logischen Aufbaues. Was mich schaurig stört ist, dass Änderungen manchmal nicht übernommen werden.

Wo Licht ist, ist auch Schatten: Wie oft habe ich schon den Dateinamen der ILI-Datei geändert und auf «Apply» oder «OK» geklickt und nichts ist passiert resp. der alte Namen stand wieder drin. Herrje. Oder wenn die Änderungen tatsächlich übernommen werden, dafür aber der komplette Element-Tree links zusammengeklappt wird. Übel. Und die Diagramme funktionieren zwar, das automatische Anordnen bei grösseren Modellen ist aber schlecht.

Ich wurde innerhalb kurzer Zeit zweimal gefragt, warum wir überhaupt mit dem UML/INTERLIS-Editor die Modelle erstellen. In unserer INTERLIS-Anfangszeit wäre die Antwort wohl gewesen, weil es man so macht. Jahre später war die Antwort: vor allem damit die Modelldateien immer gleich und schön formatiert sind. Immerhin erstellen bei uns circa acht Personen Datenmodelle (und nicht nur der/die Lernende oder der Praktikant), was wahrscheinlich etwa der Hälfte aller UML/INTERLIS-Editor-Benutzern weltweit entspricht. Wenn es nur noch das ist, könnte man dann nicht einfach den Code aus dem UML/INTERLIS-Editor dazu nutzen, einen Pretty-Printer (als CLI-Tool) zu erstellen, der die ILI-Datei liest und schön formatiert wieder speichert?

Zuerst muss man den entsprechenden Code im Github-Repository finden. Dank der guten Suche wird man relativ schnell fündig. Es sind vor allem zwei resp. vier Klassen, die sich um den Import und Export von ILI-Dateien kümmern:

Die Schwerstarbeit übernehmen die «Transfer»-Klassen. Nomen est Omen: Beim Import wandeln sie das Ili2c-Metamodell in ein internes UML-Editor-Metamodell um und umgekehrt. Somit muss man für meinen Pretty-Printer nur diese Klassen verwenden. Ein paar kleine Hürden gab es natürlich trotzdem:

Die Jar-Datei des UML/INTERLIS-Editors sind im Maven-Repository https://jars.interlis.ch publiziert und man kann sie in seinem Projekt ganz normal als Abhängigkeit definieren. Leider erschien eine Fehlermeldung:

FAILURE: Build failed with an exception.

* What went wrong:
Configuration cache state could not be cached: field `classpath` of task `:compileJava` of type `org.gradle.api.tasks.compile.JavaCompile`: error writing value of type 'org.gradle.api.internal.artifacts.configurations.DefaultUnlockedConfiguration'
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not resolve ch.interlis:umleditor:3.10.3.
     Required by:
         root project :
      > Could not resolve ch.interlis:umleditor:3.10.3.
         > Could not parse POM https://jars.interlis.ch/ch/interlis/umleditor/3.10.3/umleditor-3.10.3.pom
            > Missing required attribute: dependency groupId

Ich gehe davon aus, dass es damit zusammenhängt, dass beim UML/INTERLIS-Editor nicht alle Abhängigkeiten aus einem Maven-Repository bezogen werden, sondern auch lokale verwendet werden (Mmmh, jhotdraw53 ist 23 Jahre alt gemäss SourceForge… und wo ist wohl der Quellcode dieser lokalen Libraries?). D.h. ich muss neben einigen der lokalen Libraries zusätzlich die UML/INTERLIS-Editor-Abhängigkeit in meinem Pretty-Printer lokal vorhalten.

Eine weitere Unschönheit ist, dass ich für den Export die Klasse TransferFromUmlMetamodel copy/pasten musste und ein paar wenige Veränderungen vornehmen musste. Die Klasse ruft das GUI auf, das es bei mir nicht gibt. Und ich möchte von aussen steuern können, wo die schön formatierte ILI-Datei gespeichert wird. Letzten Endes aber Kleinigkeiten. Der Aufruf ist wie folgt:

java -jar iliprettyprint-0.0.11-all.jar --ili ../sources/iliPrettyPrint/src/test/data/SO_ARP_SEin_Konfiguration_20250115.ili --out ../tmp

Es gibt zudem eine --modeldir-Option, um Modell-Repositories wählen zu können. Herunterladen kann man den Pretty-Printer auf der Github-Seite. Funktional ist er mit dem UML/INTERLIS-Editor-Prozess «Modell-Import mit anschliessendem Modell-Export» identisch. Wenn es in diesem Workflow Probleme gibt, gibt es sie auch beim IliPrettyPrinter. Den Praxistest mit ein paar Modellen hat er bestanden. Erwähnenswert ist:

Ein Funktionsmodell hat zu jeder Funktion einige Metaattribute und einen normalen Kommentar !!sample = "…". Dieser normale Kommentar verschwindet.
Beim Endgegner-Modell verschwinden die Metaattribute !!@ comment = "…" bei der Einheiten-Definition UNIT.
Constraints werden auf einer Zeile geschrieben. Bei langen Expressions ergibt das sehr lange Zeilen. Um diesen Umstand zu verbessern, bräuchte es zuerst Stilvorgaben.

IliPrettyPrinter ist als Tool eigentlich überflüssig. Diese Funktion sollte in den Compiler eingebaut werden (aber besser ohne Editor-Abhängigkeiten) im Sinne einer Entwicklung zu einem Linter o.ä. Was ich mir ebenfalls noch anschauen möchte ist, ob der Export in eine PlantUML- oder Mermaid-Datei einfach möglich ist. Dann entschärft sich eventuell auch die Diagramm-Situation. Ein andere Variante UML-Diagramme schöner (?) darzustellen, ist der Umweg über den XMI-Output des Compilers und einem Werkzeug, das diese XMI-Datei darstellen kann. So richtig erfolgreich bin ich damit noch nicht geworden. Mit Eclipse Papyrus ging was, scheint mir aber zu kompliziert zu sein. Jedenfalls schaffe ich es momentan nicht mehr.

Was ich mir definitiv auch noch anschauen möchte, ist eine neue Theme für den UML/INTERLIS-Editor. Mit FlatLaf gibt es eine ansprechende Java-Swing-Theme. Ein quick 'n' dirty Test zeigt, dass es funktioniert, jedoch die Icons ersetzt werden müssten. Diese sehen nun noch steinzeitlicher aus:

Und zu guter Letzt noch der pixelige Splashscreen ersetzen und die Hilfe mit einer funktionierenden und nachführten Online-Hilfe ersetzen und ich bin schon fast wieder richtig Fan vom UML/INTERLIS-Editor.

INTERLIS leicht gemacht #48 - Der INTERLIS-Super-GAU

Fri, 11 Apr 2025 00:00:00 +0000

Was ist passiert? Ich wollte ein nachgeführtes Modell in unsere INTERLIS-Modellablage (aka INTERLIS-Repository) publizieren. Wie es sich gehört, ist dieser Prozess automatisiert. Wir müssen bloss die Modelldatei in ein Github-Repository einchecken und dann beginnt die Pipeline / die Github-Action zu laufen. Ein Gradle-Plugin sucht alle Modelldateien im Repository und liest die notwendigen Informationen aus diesen aus und erstellt die ilimodels.xml-Datei und ein Dockerimage, das automatisch in unseren OpenShift-Cluster deployed wird. Das Dockerimage wird vor dem Pushen in die Registry in der Pipeline mit --check-repo-ilis geprüft.

Das Unheil fing am 27. April 2025 an: Die Pipeline lief nicht mehr durch. Das kann schon mal vorkommen, kleiner Schluckauf irgendwo. Im konkreten Fall war es auch nicht super tragisch, da ich das nachgeführte Modell einfach temporär dort speichern kann, wo es auch verwendet wird. Damit konnte ich immerhin weiterarbeiten. Am nächsten Morgen geschaut, ob die Pipeline nun durchläuft. Mmmh, immer noch nicht. Die Logdatei der Action meldet folgendes:

Mein Gradle-Plugin findet die Mutter aller INTERLIS-Modellablagen nicht. Das Plugin muss das IliRepository20-Modell kompilieren, um die ilimodels.xml-Datei herstellen zu können. Ich hatte den Compiler in meinem Code so konfiguriert, dass er nicht lokale Modelle verwendet, sondern das Modell in den externen Repositories sucht. Und genau das Repository mit dem gewünschten Modell war aus der Github Action nicht mehr erreichbar. Mit dem Repository schien jedoch alles in Ordnung zu sein. Mit dem Browser konnte ich darauf zugreifen.

Was machen? Eine E-Mail in die Runde ohne grosse Erkenntnisse und anschliessend im INTERLIS-Forum nachgeschaut: Immerhin hatten andere auch Probleme. Ok, uncool aber handlebar und sowieso: Ich kann das Modell zu meinem Code kopieren und bin nicht mehr auf ein externes Repository angewiesen.

Oops! Diese Idee hat leider nur ein Problem: Um diese Änderungen am Gradle-Plugin vornehmen zu können, benötige ich INTERLIS-Bibliotheken vom INTERLIS-Maven-Repository https://jars.interlis.ch. Dieses wird - wie auch das Modell-Repository - auf einem Infomaniak-Server gehostet. Und ja, auch mit diesem Server gab es in den Github Actions Probleme. Die Bibliotheken konnten nicht gefunden werden:

Es schien irgendwas mit der Kommunikation zwischen den Github-Actions-Servern und Infomaniak im Argen zu liegen. Es war Freitag und ich hätte natürlich warten können, dass sich das Problem bis Montag irgendwie selber löst. Aber wenn es Montag immer noch besteht, wird es mühsam, weil alle Mitarbeiter anders als gewohnt arbeiten müssten. D.h. als erstes musste ich irgendwie wieder an die INTERLIS-Bibliotheken kommen. Gott sei Dank hatte ich mich im letzten Sommer mit einem amtseigenen Maven-Repository-Caching-Proxy auseinandergesetzt. Die Idee dabei ist, dass wir eine Software betreiben, welche die verschiedenen Maven-Repositories zwischenspeichert. Ich müsste beim Builden der Java-Software nicht mehr die verschiedenen externen Maven-Repositories konfigurieren, sondern nur das eigene (z.B. https://jars.so.ch). Die Software lädt die benötigten Bibliotheken z.B. von https://jars.interlis.ch herunter und speichert sie bei sich. Damit ist sichergestellt, dass ich meine Java-Software auch builden kann, falls die externen Maven-Repositories down oder nicht erreichbar sind. Dieses Prinzip eines Caching-Proxies für die eigene Organisation ist keine Erfindung des Jahres 2025, sondern ist schon lange gute Praxis (auch aus anderen Gründen: lesenswert!). Also 5-Euro-Hetzner-Server hochgefahren und Anleitung zu Reposilite rausgesucht und fertig war unser Maven-Caching-Proxy. Die Github-Action mit dem veränderten Gradle-Plugin lief wieder durch.

Das war jedoch erst ein Teil der Lösung. Ich konnte zwar eine neue Plugin-Version in Betrieb nehmen aber das Herstellen der ilimodels.xml-Datei und das Prüfen des INTERLIS-Repositories gingen noch nicht, weil unsere Modelle wiederum Modelle vom nicht erreichbaren INTERLIS-Repository importieren und diese beim Kompilieren des eigenen Modelles benötigt werden. Da war schon einiges vorbereitet, das mir half: Nämlich konnte ich in einen Ordner einfach «fremde» Modelle reinkopieren, so als wären es eigene. Entsprechend findet der Compiler sie beim Kompilieren unserer Modelle. Ich musste also nur ein paar weitere Modelle in diesen Ordner kopieren und konnte beruhigt ins Wochenende.

Ich wusste aber, dass das auch nur ein Provisorium ist. Die Frage der Verfügbarkeit fremder Modelle (= ausserhalb des Kantonsnetzes) beschäftigt mich schon eine Weile. Bequemlichkeit hat mich davon abgehalten, dieses Problem halbwegs anständig zu lösen. Nun ist aber die Zeit gekommen. Ich habe mich entschieden, dass wir mittels --clone-repos die Repositories klone, die wir unbedingt benötigen und diese als «Mirror-Repo» publizieren. Die Modelle kommen zwar technisch auf dem gleichen Server (resp. im gleichen Docker-Container) zu liegen wie unser «Original-Repo», es sind aber zwei getrennte INTERLIS-Modellablagen. Ein Detail, das mich stört und ich ändern möchte: die URL ist momentan hardcodiert und sollte konfigurierbar gemacht werden. Eine eher witzige Frage war, wie jetzt die Repositories miteinander verknüpft werden sollen. Die Suche nach einem Modell läuft nach dem Breadth-First-Verfahren. Wir mussten ein wenig ausprobieren, damit wir - hoffentlich - die sinnvollste Variante fanden. Das «Original-Repo» kennt das «Mirror-Repo» nicht. Das «Mirror-Repo» wiederum kennt als «Kind-Repo» das «Original-Repo». Warum? Somit erreichen wir, dass --modeldir https://geo.so.ch/models/mirror genügt, um sämtliche unserer Prozesse am Laufen zu halten. D.h. zuerst werden die Modelle in den geklonten Repositories gesucht und anschliessend im «Original-Repository». Erst wenn das benötigte Modell in diesen Repos nicht gefunden wird, wird die Hierarchiestufe geändert, was nicht vorkommen darf.

Fazit: Durch den Vorfall viel gelernt und die Prozesse robuster gemacht. Und das Problem hat sich Montag/Dienstag von selbst (?) erledigt.

INTERLIS leicht gemacht #47 - INTERLIS, das bessere JSON-Schema?

Mon, 24 Mar 2025 00:00:00 +0000

Ich hätte ja gerne ein Ausrufezeichen im Titel verwendet. Nur so allgemeingültig ist die Aussage wohl nicht. Jedoch für uns könnte sie passen. Im letzten Blogbeitrag habe ich geschrieben, dass bei uns viel Konfiguration anfällt. Ein Teil wird (zukünftig) originär in JSON von Mitarbeitern erfasst. Die Konfiguration der vielen Microservices im Umfeld des Web GIS Clients ist ebenfalls JSON. Diese ist teilweise sehr umfangreich und wird in der Regel nicht mehr von Hand erstellt. Zu jeder dieser Microservice-Konfiguration gibt es ein JSON-Schema, das die Konfiguration definiert. Im Fall des «elevation»-Services ist die Konfiguration maximal simpel:

{
  "$schema": "https://github.com/qwc-services/qwc-elevation-service/raw/master/schemas/qwc-elevation-service.json",
  "service": "elevation",
  "config": {
    "elevation_dataset": "/data/geodata/ch.so.agi.lidar_2014.dtm/ch.so.agi.lidar_2014.dtm.tif"
  }
}

Der Service hat zwei Funktionen: eine liefert für eine Koordinate einen Höhenwert zurück, die zweite Funktion liefert Höhenwerte entlang eines Linestrings als Antwort.

Das dazugehörige Schema ist schon um einiges umfangreicher:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "https://raw.githubusercontent.com/qwc-services/qwc-elevation-service/master/schemas/qwc-elevation-service.json",
  "title": "QWC Elevation Service",
  "type": "object",
  "properties": {
    "$schema": {
      "title": "JSON Schema",
      "description": "Reference to JSON schema of this config",
      "type": "string",
      "format": "uri",
      "default": "https://raw.githubusercontent.com/qwc-services/qwc-elevation-service/master/schemas/qwc-elevation-service.json"
    },
    "service": {
      "title": "Service name",
      "type": "string",
      "const": "elevation"
    },
    "config": {
      "title": "Config options",
      "type": "object",
      "properties": {
        "elevation_dataset": {
          "description": "Elevation dataset (file or URL). Example: https://data.sourcepole.com/srtm_1km_3857.tif",
          "type": "string"
        }
      },
      "required": [
        "elevation_dataset"
      ]
    }
  },
  "required": [
    "service",
    "config"
  ]
}

Für JSON-Liebhaber mag das Kunst sein, für mich sieht es eher leicht chaotisch aus. Inhaltlich dürfte so ein Schema wohl viele Anforderungen abdecken. Man kann z.B. Konstanten oder Default-Werte definieren. Irgendwie noch schick. Oder auch URL verlangen. Wobei man anscheinend zwei Aussagen dazu braucht: Das URL-Attribut muss vom Typ «string» sein und gemäss einer «uri» formatiert sein. Scheint mir irgendwie umständlich. Was wäre aber, wenn wir das JSON-Schema als einfach lesbares INTERLIS-Modell definieren könnten?

INTERLIS 2.4;

MODEL Elevation (de) AT "mailto:edigonzales@localhost" VERSION "20250324" =

    TOPIC Elevation =

        STRUCTURE Config_ =
            elevation_dataset : TEXT*100;
        END Config_;

        CLASS Configuration =
            service : TEXT*100;
            config : Config_;
        END Configuration;

    END Elevation;

END Elevation.

Und ja, im Modell fehlen die Kommentare («description»), die im JSON-Schema vorhanden sind. Ebenfalls können keine Default-Werte und Konstanten gesetzt werden. Für beide Fragestellungen könnten z.B. Constraints verwenden werden. Und die Sache mit Modell → Topic → Class macht es auf den ersten Blick auch ziemlich verbose. Und trotzdem: Auch wenn wir Kommentare und Constraints noch einpflegen würden, dünkt es mich klarer, aussagekräftiger und sauberer strukturiert. Schlichtweg eleganter. Aber dazu gibt es wahrscheinlich auch gegenteilige Meinungen.

Die zum INTERLIS-Modell passende JSON-Datei sieht wie folgt aus / muss wie folgt aussehen:

[
    {
      "@type": "Elevation.Elevation.Configuration",
      "@id": "o1",
      "@bid": "bid1",
      "@topic": "Elevation.Elevation",
      "service": "elevation",
      "config": {
        "@type": "Elevation.Elevation.Config_",
        "elevation_dataset" : "/data/geodata/ch.so.agi.lidar_2014.dtm/ch.so.agi.lidar_2014.dtm.tif"
      }
    }
]

«Boah, wird ja immer komplizierter und hässlicher!» hört man sie sagen. Aber das hat alles schon seine Richtigkeit und Notwendigkeit. Aber der Reihe nach:

Bereits mit der ersten Version von GRETL wollten wir neben INTERLIS-Dateien auch CSV- und Shapedateien validieren können. GeoPackage ist im Laufe der Zeit noch hinzugekommen. Zur Validierung von Shapedateien habe ich vor Jahren was geschrieben. Im Prinzip geht das fast für jedes beliebige Format: man muss «nur» einen IoxReader implementieren. Anschliessend muss man einen Validator erweitern und schon hat man seinen Custom-Format-Validator mit der Mächtigkeit von INTERLIS und ilivalidator.

Vor einiger Zeit haben wir ebensolche JsonReader und GeoJsonReader programmieren lassen. Jetzt ist die Zeit gekommen diese in Wert zu setzen und sie als Basis für einen JsonValidator zu verwenden. Der JsonValidator wird als GRETL-Task umgesetzt. Ein Standalone-Werkzeug wäre aber mit minimalen Aufwand auch möglich.

Zurück zum hässlichen «INTERLIS-JSON»: Um möglichst viel von der Sprache INTERLIS verwenden zu können und Daten in JSON transportieren zu können, braucht es diese Metaattribute in der JSON-Datei. Man muss wissen welcher Basket geliefert wird, um welchen Klassentyp es sich beim konkreten Objekt handelt etc. pp. Für unseren momentanen Anwendungsfall/Spezialfall ist aber nur das Attribut @type notwendig. D.h. ich möchte die JSON-Datei nicht unnötig aufblasen. Das löse ich, indem ich fehlende Metaattribute vor der Validierung hinzufüge. Ebenso ein allfällig fehlendes Toplevel-Array. Den JsonReader lasse ich so sein, wie er ist. Unsere Konfigurationsdatei sieht abgespeckt so aus:

{
    "@type": "Elevation.Elevation.Configuration",
    "service": "elevation",
    "config": {
        "@type": "Elevation.Elevation.Config_",
        "elevation_dataset" : "/data/geodata/ch.so.agi.lidar_2014.dtm/ch.so.agi.lidar_2014.dtm.tif"
    }
}

Eine Unschönheit besteht/bestand noch: Ein JSON-Array mit z.B. Strings konnte nicht modelliert werden resp. nur über den Umweg mit INTERLIS-Strukturen. Das ist natürlich sehr umständlich. Weil mit INTERLIS 2.4 auch LIST und BAG mit einfachen Datentypen möglich ist, musste der JsonReader angepasst werden. Pullrequest ist gemacht.

Der JsonReader unterstützt auch Geometrien im Format von WKT. Ich kann z.B. folgendes Modell schreiben:

INTERLIS 2.4;

MODEL Test2 (de) AT "mailto:edigonzales@localhost" VERSION "20250324" =

    DOMAIN
        Coord2 = COORD
        2460000.000 .. 2870000.000,
        1045000.000 .. 1310000.000,
        ROTATION 2 -> 1;

    TOPIC Topic2 =

        CLASS ClassA =
            attrText : TEXT*60;
            attrArea : AREA WITH (STRAIGHTS, ARCS) VERTEX Coord2 WITHOUT OVERLAPS > 0.001;
        END ClassA;

    END Topic2;

END Test2.

Der JsonValidator überprüft problemlos die Area-Bedingung für folgende JSON-Datei (und findet die Überlappung):

[
    {
      "@type": "Test2.Topic2.ClassA",
      "attrText" : "line0",
      "attrArea" : "POLYGON ((2460000 1045000, 2460001 1045000, 2460001 1045001, 2460000 1045001, 2460000 1045000))"
    },
    {
      "@type": "Test2.Topic2.ClassA",
      "attrText" : "line1",
      "attrArea" : "POLYGON ((2460000.5 1045000, 2460002 1045000, 2460002 1045001, 2460001 1045001, 2460000.5 1045000))"
    }
]

Ist INTERLIS das bessere JSON-Schema? Für uns glaub schon. Wir müssen uns nicht in eine neue Spezifikation kämpfen und können auch weiterhin die gleichen Werkzeuge und die gleiche Sprache verwenden. Zudem die Werkzeuge und Sprache sehr mächtig sind. Ein weiterer interessanter Aspekt ist, dass die Formatfrage so mehr und mehr in den Hintergrund rückt, weil das Format abstrahiert wird.

INTERLIS leicht gemacht #46 - INTERLIS, GRETL und DuckDB: A match made in heaven

Sun, 9 Feb 2025 00:00:00 +0000

In einer Geodateninfrastruktur fällt eine Unmenge an Konfiguration an. Unter Konfiguration verstehe ich in diesem Kontext nicht die direkte, technische Steuerung einer Software (z.B. wie viel RAM wird der Software zugewiesen), sondern z.B. die Darstellung eines WMS-Layers. Im Falle von QGIS wäre das eine QML-Datei. Oder auch das INTERLIS-Datenmodell kann man als Konfigurationsartefakt ansehen. Ebenso unsere GRETL-Jobs, die aus einer Gradle Build-Datei und in der Regel aus SQL-Dateien bestehen.

Unsere Konfigurationen sind an unterschiedlichen Orten gespeichert und werden mit unterschiedlichen Ansätzen bearbeitet. Die Dienste (WMS, WFS, Dataservice) und die Datenabgabe werden über eine Webanwendung bearbeitet. Z.B. wählt man eine Datenbanktabelle aus, lädt die QML-Datei hoch und definiert unter Umständen noch ein paar Aliase für die Attributnamen. Diese Informationen werden anschliessend in einer Datenbank gespeichert und daraus die QGS-Datei für QGIS-Server hergestellt. Ein weiterer Teil unserer Konfigruation wird in Git-Repositories gespeichert. Dazu gehören die GRETL-Jobs und die Schema-Jobs (dienen zum Anlegen von Datenbankschemen mit GRETL). Das «GUI» ist der Texteditor nach Wahl. Zu guter Letzt liegt der Master sämtlicher Datenmodelle im Datenmodell-Repository.

Obwohl sich einiges über eine längere Zeit entwickelt hat, ist das Grundkonzept circa sechs bis sieben Jahre alt und in dieser Zeit konnten wir viele Erfahrungen sammeln. Obwohl wir nicht direkt unzufrieden mit der Webanwendung sind, bin ich der Meinung, dass wir erfolgreicher mit dem Git-Ansatz arbeiten. Das hängt vor allem damit zusammen, dass die Webanwendung sehr umfangreich geworden ist und immer mehr verknüpfte Informationen verwalten muss. Dadurch ist sie leider auch nicht intuitiver geworden. Funktional bietet sie viel: so kann ich z.B. auf Knopfdruck herausfinden, welche Datenbanktabelle in welchem WMS-Layer steckt. Dieses Wissen ist insbesondere bei Modelländerungen (und daraus folgend Datenbankschemaänderungen) wichtig.

Die Grundidee ist, dass wir sämtliche Konfiguration in Zukunft in einem Themen-Git-Repository speichern und — falls immer sinnvoll möglich — nur noch mit dem Texteditor arbeiten. Am liebsten hätten wir pro Datenthema ein eigenes Git-Repository aber wahrscheinlich machen wir ein Mono-Repo mit den Themen als Unterordner. Bei der Menge an Themen scheint uns das übersichtlicher zu sein. Nehmen wir als Beispiel das Thema Bauzonengrenzen. Heute gibt es im GRETL-Jobs-Repository den Unterordner arp_bauzonengrenzen_pub. In diesem Unterordner steckt der GRETL-Job, der die Daten aus der Edit-DB herstellt und in der Pub-DB speichert. Ebenfalls gehört der Export nach XTF, GeoPackage und Shapefile dazu. Dieser GRETL-Job würde im Themen-Repo im Ordner arp_bauzonen zukünftig im Unterordner gretl zu liegen kommen. Der Schema-Job, mit dem wir das Schema in der Datenbank anlegen, im Unterordner schema. Das Datenmodell im Unterordner ili etc. pp. Notwendige Konfigurationen für die verschiedenen Softwares (Dienste, Datenabgabe, …) würden mit GRETL in einer Pipeline (Github-Action, Jenkins, …) hergestellt.

Zwei schnell identifizierte Herausforderungen sind die referentielle Integrität, die es mit dem neuen Ansatz nicht geschenkt gibt und die Frage nach dem passenden Format für die Datenerfassung im Texteditor. Anhand eines konkreten Beispieles (die Datenabgabe) können Lösungen für beide Herausforderungen gezeigt werden. Ich verwende hier Statistikdaten und nicht unsere Geodaten. Grund dafür ist, dass wir womöglich zukünftig die eine oder andere Synergie nutzen wollen. Alles in allem ist der Prozess sehr ähnlich aber einfacher. Mein Themen-Git-Repo sieht für vier Themen so aus:

Man erkennt die vier Themen: zwei vom AGI, je eines vom AWA und der MFK. Diese sind immer gleich aufgebaut. Es gibt einen ili- und einen meta-Unterordner. Fehlen tut noch mindestens der gretl-Unterordner mit dem GRETL-Job, der die Daten entegennimmt, in eine Parquet-Datei umwandelt und auf eine Ablage kopiert. Das Datenmodell im ili-Ordner wird benötigt, um das «best practice Datenformat CSV» (Anonym, 2025) zu prüfen. Wenn die Daten bereitgestellt werden, braucht es noch Metadaten dazu. Das sind eine Beschreibung, Stichworte, Publikationsdatum etc. Die ersten beiden sind statisch und können einmalig definiert werden. Das Publikationsdatum ist dynamisch und ändert sich mit jeder Publikation der Daten. Die statischen Daten speichern wir in einer JSON-Datei thema.json im Unterordner meta. Der Inhalt der Datei ist circa folgender:

{
    "ID" : "ch.so.mfk.fahrzeugbestand",
    "Titel" : "Fahrzeugbestand",
    "Beschreibung" : "Fahrzeugbestand seit 1991 im Kanton Solothurn gruppiert in verschiedene Kategorien. Wird jährlich aktualisiert.",
    "Datenherr" : "ch.so.mfk",
    "Modell" : "SO_MFK_Fahrzeugbestand_20250201",
    "Tags" : [
        "Fahrzeug",
        "Bestand",
        "PKW",
        "Auto",
        "Lastwagen",
        "Anzahl"
    ]
}

Zwei Attribute sind von besonderem Interesse: Die ID darf natürlich in der gesamten Dateninfrastruktur nur einmal vorkommen. Heute nimmt mir die Datenbank diese Aufgabe ab. Ohne Datenbank muss ich das anders lösen. Das zweite interessante Attribut ist der Datenherr. Natürlich wird später für den Benutzer bei den Metadaten nicht einfach ch.so.mfk stehen, sondern die normale Adresse mit Kontaktdaten. Hier in der JSON-Datei steht nur der Fremdschlüssel. Und ja, er ist sprechend und folgt einer Logik. Aber dünkt mich handlebar. Die Adresse und Kontaktdaten der Ämter stecken in einer XTF-Datei amt.xtf im Order stammdaten.

Das Publikationsdatum wird während der Datenpublikation mit einem GRETL-Job ebenfalls in eine JSON-Datei geschrieben. Diese wird bei den publizierten Daten gespeichert (hier z.B. S3) und nicht im Themen-Repo. In der Datei steckt nur die ID und das Datum:

{
    "ID" : "ch.so.mfk.fahrzeugbestand",
    "publiziertAm" : "2025-02-01"
}

Wie kann man verhindern, dass die ID wirklich nur einmal vorkommt ist? Und wie kann ich eine Konfigurationsdatei mit allen Themen herstellen, die ich für meine Datenabgabe-Anwendung benötige und auch das Publikationsdatum beinhaltet und die korrekte Adresse des Datenherrn? Die Antwort ist natürlich INTERLIS, GRETL und DuckDB.

Als erstes braucht es ein Metamodell. Ein unvollständiges kann z.B. so aussehen:

INTERLIS 2.4;

MODEL SO_AGI_Metadaten_20250202 (de)
AT "https://agi.so.ch"
VERSION "2025-02-02" =
  DOMAIN

    SOOID = OID TEXT*255;

  STRUCTURE Amt_ =
    Name : MANDATORY TEXT;
    Abkuerzung : TEXT*10;
    Abteilung : TEXT;
    AmtImWeb : MANDATORY URI;
    Zeile1 : TEXT*50;
    Zeile2 : TEXT*50;
    Strasse : MANDATORY TEXT*50;
    Hausnr : MANDATORY TEXT*10;
    PLZ : MANDATORY TEXT*4;
    Ort : MANDATORY TEXT*100;
  END Amt_;

  TOPIC Amt =
    OID AS SO_AGI_Metadaten_20250202.SOOID;

    CLASS Amt EXTENDS SO_AGI_Metadaten_20250202.Amt_ =
      UNIQUE Abkuerzung, Abteilung;
    END Amt;
  END Amt;

  TOPIC ThemaPublikation =
    OID AS SO_AGI_Metadaten_20250202.SOOID;

    CLASS ThemaPublikation =
        ID : MANDATORY TEXT*100;
        Titel : MANDATORY TEXT*200;
        Beschreibung : TEXT*2000;
        Datenherr : MANDATORY SO_AGI_Metadaten_20250202.Amt_;
        Modell : TEXT*100;
        publiziertAm : INTERLIS.XMLDate;
        Tags : TEXT;
        UNIQUE ID;
    END ThemaPublikation;

  END ThemaPublikation;

END SO_AGI_Metadaten_20250202.

Die Klasse Amt im Topic Amt benötige ich zum Vorhalten der Ämterinformationen. Die Klasse ThemaPublikation im Topic ThemaPublikation brauche ich zum Herstellen der Konfigurationsdatei für meine Datenabgabe-Software. In dieser Klasse sieht man, dass ID eindeutig sein muss. Wie geht es weiter?

Es braucht einen GRETL-Job, der sowohl lokal beim Entwickeln resp. bei der Bearbeitung der Informationen ausgeführt werden kann wie auch in einer Pipeline. Es wird mehrere Jobs geben, da sie verschiedene Zwecke erfüllen müssen. Geht es nur darum zu prüfen, ob die ID eindeutig ist, muss ich die erwähnte Konfigurationsdatei für die Datenabgabe-Software nicht herstellen. Und es wird weitere Konfigurationsdateien geben, die ebenfals mittels GRETL-Jobs hergestellt werden (und weiteren Klassen im Metamodell). Der GRETL-Job für das Herstellen der Konfigurationsdatei sieht so aus:

import java.nio.file.Paths
import ch.so.agi.gretl.tasks.*
import ch.so.agi.gretl.api.*
import de.undercouch.gradle.tasks.download.Download

apply plugin: 'ch.so.agi.gretl'
apply plugin: 'de.undercouch.download'

defaultTasks 'uploadToExoscale'

def awsAccessKey = System.getenv("AWS_ACCESS_KEY_ID")
def awsSecretAccessKey = System.getenv("AWS_SECRET_ACCESS_KEY")
def awsRegion = System.getenv("AWS_DEFAULT_REGION")
def awsEndpoint = System.getenv("AWS_ENDPOINT_URL")

tasks.register("createStammdatenSchema", Ili2duckdbImportSchema) {
    dbfile = file("shubidu.duckdb")
    models = "SO_AGI_Metadaten_20250202"
    modeldir = rootProject.projectDir.toString() + "/../../_ili/" + ";http://models.interlis.ch"
    dbschema = "stammdaten"
    nameByTopic = true
    smart2Inheritance = true
    createEnumTabs = true
}

tasks.register("importStammdaten", Ili2duckdbImport) {
    dependsOn 'createStammdatenSchema'
    dbfile = file("shubidu.duckdb")
    models = "SO_AGI_Metadaten_20250202"
    modeldir = rootProject.projectDir.toString() + "/../../_ili/" + ";http://models.interlis.ch"
    dbschema = "stammdaten"
    dataFile = file("../../_stammdaten/amt.xtf")
}

tasks.register("createKonfigSchema", Ili2duckdbImportSchema) {
    dependsOn 'importStammdaten'
    dbfile = file("shubidu.duckdb")
    models = "SO_AGI_Metadaten_20250202"
    modeldir = rootProject.projectDir.toString() + "/../../_ili/" + ";http://models.interlis.ch"
    dbschema = "konfig"
    nameByTopic = true
    smart2Inheritance = true
    createEnumTabs = true
}

def pwd = rootProject.projectDir.toString()
def dbUri = "jdbc:duckdb:$pwd/shubidu.duckdb".toString()
def dbUser = ""
def dbPass = ""

tasks.register("createKonfigData", SqlExecutor) {
    dependsOn 'createKonfigSchema'
    database = [dbUri, dbUser, dbPass]
    sqlFiles = ['create_konfig_data.sql']
}

tasks.register("exportKonfigData", Ili2duckdbExport) {
    dependsOn 'createKonfigData'
    dbfile = file("shubidu.duckdb")
    models = "SO_AGI_Metadaten_20250202"
    modeldir = rootProject.projectDir.toString() + "/../../_ili/" + ";http://models.interlis.ch"
    dbschema = "konfig"
    dataFile = file("themen_publikation.xtf")
}

tasks.register('uploadToExoscale', S3Upload) {
    dependsOn 'exportKonfigData'
    accessKey = awsAccessKey
    secretKey = awsSecretAccessKey
    sourceFile = file('themen_publikation.xtf')
    endPoint = awsEndpoint
    region = awsRegion
    bucketName = 'XXXXX.YYYYY.ZZZZZ'
    acl = "public-read"
}

Als erstes importiere ich die Stammdaten (mit den Ämterinfos) in eine DuckDB. Anschliessend erstelle ich ein weiteres Schema konfig in der gleichen DuckDB. In diesem Schema muss ich aus den vorliegenden JSON-Dateien (lokal und S3) und den Ämterinfos die Klasse ThemaPublikation abfüllen. Ist das gemacht, exportiere ich die Klasse in eine XTF-Datei / in die Konfigurationsdatei. Das Wichtigste passiert im Task createKonfigData. Hier wird einzig mit SQL und DuckDB-Magie die Klasse ThemaPublikation befüllt:

CREATE OR REPLACE SECRET asecret (
    TYPE S3,
    PROVIDER CREDENTIAL_CHAIN,
    CHAIN 'env',
    ENDPOINT 'sos-xx-yy-z.exo.io'
);

DROP TABLE IF EXISTS
    themapublikation_tmp
;
CREATE TEMP TABLE themapublikation_tmp AS
SELECT
    nextval('konfig.t_ili2db_seq') AS T_Id,
    '_' || nextval('konfig.t_ili2db_seq') AS T_Ili_Tid,
    m.ID AS id,
    m.Titel AS titel,
    m.Beschreibung AS beschreibung,
    m.Modell AS modell,
    m.tags,
    m.datenherr,
    p.publiziertAm AS publiziertAm
FROM
    read_json('*/meta/thema.json') AS m
    LEFT JOIN read_json('s3://XXXXX.YYYYY.ZZZZZ/*/publishedat.json') AS p
    ON m.ID = p.ID
;

DELETE FROM
    konfig.themapublikation_themapublikation
;
INSERT INTO
    konfig.themapublikation_themapublikation
    (
        T_Id,
        T_Ili_Tid,
        id,
        titel,
        beschreibung,
        modell,
        tags,
        publiziertam
    )
SELECT
    T_Id,
    T_Ili_Tid,
    id,
    titel,
    beschreibung,
    modell,
    list_aggregate(tags, 'string_agg', ',') AS tags,
    publiziertam
FROM
    themapublikation_tmp
;

DELETE FROM
    konfig.amt_
;
INSERT INTO
    konfig.amt_
    (
        T_Id,
        aname,
        abkuerzung,
        abteilung,
        amtimweb,
        zeile1,
        zeile2,
        strasse,
        hausnr,
        plz,
        ort,
        thempblktn_thmpblktion_datenherr
    )
SELECT
    nextval('konfig.t_ili2db_seq') AS T_Id,
    aname,
    abkuerzung,
    abteilung,
    amtimweb,
    zeile1,
    zeile2,
    strasse,
    hausnr,
    plz,
    ort,
    themapublikation_tmp.T_Id AS thempblktn_thmpblktion_datenherr
FROM
    themapublikation_tmp
    LEFT JOIN stammdaten.amt_amt AS amt
    ON themapublikation_tmp.datenherr = amt.T_Ili_Tid
;

DuckDB stellt die read_json()-Funktion bereit. Mit dieser kann ich JSON-Dateien lesen und sie wie Tabellen ansprechen (ohne sie importieren zu müssen) und die Funktion unterstützt die glob-Syntax. Vereinfacht gesagt, kann ich sämtliche thema.json-Dateien an der gleichen Stelle in den Unterordnern ansprechen (siehe Zeile 23). Gleiches gilt auch für die JSON-Dateien, die im S3-Bucket bei den publizierten Daten liegen und das Publikationsdatum beinhalten. Die Ämterinfos hole ich einfachst aus dem anderen Schema.

Falls nun eine ID doppelt vorkommt oder man auf ein Amt verweist, das es nicht gibt, wird spätestens beim Export ilivalidator einen Fehler melden. Gewisse Constraints werden bereits auf der Datenbank angelegt. So auch der UNIQUE-Constraint. In diesem Fall wird schon der Datenumbau einen Fehler melden. Der gesamte Prozess dauert lokal circa 20 Sekunden. Dünkt mich vertretbar. Wahrscheinlich wird es zusätzlich eine read-only Metadatenbank als Webanwendung geben. Sowohl für uns zum Nachschlagen wie auch für die Kunden/Benutzer.

Man kann das Ganze noch ein wenig weitertreiben, indem man z.B. nicht mehr direkt in den main-Branch pushen darf, sondern via separatem Branch, der die Github Action durchlaufen muss. Die Github Action ist mit GRETL auch sehr einfach. Man kann der Action sagen, dass sie auf einem bestimmten Dockerimage laufen soll:

name: thema_publikation

on:
  push

jobs:

  build:

    env:
      AWS_ACCESS_KEY_ID: ${{secrets.AWS_ACCESS_KEY_ID}}
      AWS_SECRET_ACCESS_KEY: ${{secrets.AWS_SECRET_ACCESS_KEY}}
      AWS_DEFAULT_REGION: ${{secrets.AWS_DEFAULT_REGION}}
      AWS_ENDPOINT_URL: ${{secrets.AWS_ENDPOINT_URL}}

    runs-on: ubuntu-latest

    container:
      image: sogis/gretl:3.1

    steps:
      - uses: actions/checkout@v4

      - name: Run GRETL job
        run: |
          gradle -b _gretl/thema_publikation/build.gradle --init-script /home/gradle/init.gradle uploadToExoscale --no-daemon

Ein weiterer Anwendungsfall von INTERLIS-, GRETL- und DuckDB-Magie.

The house at the lake #3 - The dashboard diaries

Sun, 26 Jan 2025 00:00:00 +0000

Sie gehören halt einfach dazu: Dashboards. Ich habe mich mit der Visualisierung von (OGD-)Daten vor knapp 1.5 Jahren schon einmal auseinandergesetzt. Damals habe ich mir Grafana angeschaut und wie man damit nette Grafiken und Auswertungen in Dashboards herstellen kann. So richtig überzeugt hat es mich nachhaltig nicht. Am meisten störte mich, dass man keine Parquet-Dateien direkt verwenden konnte, sondern nur CSV (via Plugin) und somit das Wissen über die Datentypen verloren geht. Fairerweise muss man erwähnen, dass momentan meine selber gesetzte Rahmenbedingung ist, dass sämtliche Daten via z.B. Trino greifbar sind (siehe Teil 2). Parquet-Dateien direkt (ohne serverseitige Query-Engine o.ä.) anzapfen ist und bleibt natürlich ein Plus einer möglichen Lösung.

Nun wollte ich mir endlich Apache Superset genauer anschauen. Und habe es doch wieder sein lassen. Mir macht immer noch die schiere «Grösse» Angst. Ich weiss selber nicht so ganz genau, was ich damit meine. Aber wenn man sich die Anleitung zur Installation anschaut, dünkt es mich trotz Docker irgendwie overwhelming. Vor etwas mehr als einem Jahr stiess ich auf einen Blogbeitrag von MotherDuck. Sie haben drei BI-as-code Lösungen vorgestellt. Mir gefiel vor allem Evidence und die Möglichkeit das Endprodukt als statische Webseite zu deployen. Also, schaue ich mir anstelle von Apache Superset Evidence an:

Evidence funktioniert kurz zusammengefasst ganz einfach: Man schreibt SQL-Queries in einer Markdown-Datei und buildet die statische Webseite. That’s it. Klar gibt es auch hier eine gewisse Lernkurve. Aber dass der Master die Markdown-Dateien sind und ich diese in ein Git-Repository einchecken kann, ist schon ziemlich cool und kommt unserer Arbeitsweise sehr entgegen.

Es gibt zwar ein VSCode-Plugin, ich habe jedoch alles mit der Kommandozeile durchexerziert. Ein neues Projekt erstellt man mit folgenden Befehlen:

npx degit evidence-dev/template my-project
cd my-project
npm install
npm run sources
npm run dev

Interessant sind die beiden letzten Befehle. npm run dev startet die Entwicklungsumgebung. Der Entwicklungsserver buildet die Webseite während des Entwickelns und stellt diese bereit. Zudem stellt er eine Weboberfläche zur Verfügung, die unter anderem zur Konfiguration neuer Datenquellen dient. Und um Datenquellen geht es auch beim zweitletzten Befehl: npm run sources. Hat man nämlich Datenquellen definiert, müssen die Daten aus der Quelle exportiert werden, damit Evidence auf sie zugreifen kann. Das passiert mit diesem Befehl. Dieser Schritt ist quasi der Kern des Ganzen und soll mit einem Beispiel erklärt werden:

Ich möchte die Steuerfüsse der Gemeinden (der natürlichen Personen) visualisieren. Die Daten stecken in einem Data Lakehouse basierend auf Apache Iceberg (siehe Teil 1). Die Iceberg-Tabellen sind auf AWS S3 gespeichert und mittels Trino und SQL für Mensch und Maschine greifbar (siehe Teil 2). Daraus folgt, dass Evicence entweder sowas wie einen Connector für Iceberg-Tabellen benötigt (hat es nicht) oder aber für Trino (hat es):

Bestätigt man die Angaben, wird im Projektverzeichnis ein Ordner sources/mytrino erstellt. In diesem Ordner gibt es mindestens eine Datei connection.yaml mit den Connection-Parametern. Eine zweite Datei wird erstellt, falls die Connection ein Passwort benötigt. Diese Datei sollte man nicht in ein Repo einchecken. Der nächste Schritt ist der Export aus der Datenquelle, um mit den Daten in Evidence arbeiten zu können. Dabei handelt es sich um eine SQL-Query, die in einer Datei (z.B. steuerfuesse.sql) im soeben erstellen Ordner gespeichert wird. Die Query kann völlig beliebig sein und kann von ganz einfach bis ganz kompliziert reichen. Die SQL-Syntax muss der Syntax der Datenquelle entsprechen. In meinem Fall also Trino. Meine Query ist denkbar einfach:

SELECT
  *
FROM
  iceberg.agem_steuerfuesse.natuerliche_personen

Der Befehl npm run sources exportiert das Resultat dieser Query in eine Parquet-Datei. Falls beim Export was schief geht, sieht man das in der Konsole. Bei mir ist es bei einem anderen Beispiel vorgekommen, dass gewisse Datentypen von PostgreSQL (via Trino) Probleme bereiteten. Aber nicht exotische Datentypen, sondern varchar(256). Abhilfe hat dann das Casten nach varchar gebracht. Scheint mir ein Bug zu sein. Wo die Parquet-Datei liegt, muss mich nicht interessieren.

Als erstes will ich in meinem Dashboard einfach eine Tabelle mit den Steuerfüssen. Wie geht das? Ich erstelle im pages-Ordner eine neue Markdown-Datei fubar.md und schreibe folgendes rein:

```sql my_query
select * from mytrino.steuerfuesse
```
<DataTable data={my_query} />

Mit der SELECT-Query lese ich Daten aus der vorhin erstellten Parquet-Datei. Identifiziert wird die Parquet-Datei dabei über den Namen der Datenquelle (resp. des Ordners) und dem Namen der SQL-Datei (welche die Daten aus der Original-Datenquelle exportiert). Hier muss ich die DuckDB-SQL-Syntax verwenden. Warum? Weil mit DuckDB auf die Parquet-Datei zugegriffen wird. Die resultierenden Daten will ich in einem DataTable-Widget präsentiert bekommen. Im Widget greife ich über den Namen der Query auf die Daten zu. Das Resultat nach einem Page-Refresh:

Noch ziemlich unspektakulär. Geschenkt bekommt man einen CSV-Download und einen Fullscreen-Modus.

Einiges gefällt mir noch nicht: Ich möchte z.B. mindestens 150 Gemeinden anzeigen und bei den Jahreszahlen will ich keine Tausendertrennzeichen. Das ist alles einstellbar über Optionen des Widgets:

```sql my_query
select * from mytrino.steuerfuesse
```
<DataTable data={my_query} rows=150>
   <Column id=jahr title="Jahr" fmt='###0' />
   <Column id=gemeinde />
   <Column id=steuerfuss_in_prozent />
</DataTable>

Es wird die Excelsyntax für die Formatierung verwendet.

Es gibt sowas wie einen Debugmodus. Dieser nennt sich «Show Queries» und zeigt auf der Webseite die verwendete Query, sowie das Resultat der Query:

Eine typische Anforderung ist das Filtern von Daten. In meinem Fall will ich die Tabelle für ein bestimmtes Jahr filtern. Auch das dünkt mich logisch und straight forward. Ich brauche zusätzlich eine Query, um herauszufinden, welche Jahre überhaupt vorhanden sind und ein Dropdown-Widget, wo der Benutzer das zu filternde Jahr auswählen kann:

```sql unique_years
select
  jahr
from
  mytrino.steuerfuesse
group by
  1
order by
  jahr
```

<Dropdown
    name=selected_year
    data={unique_years}
    value=jahr
    title="Select a year"
    noDefault=true
/>

```sql my_query_filtered_by_year
select
  *
from
  mytrino.steuerfuesse
where
  jahr = '${inputs.selected_year.value}'
order by
  jahr,gemeinde
```

<DataTable data={my_query_filtered_by_year} rows=all>
   <Column id=jahr title="Jahr" fmt='###0' />
   <Column id=gemeinde />
   <Column id=steuerfuss_in_prozent />
</DataTable>

Ähnlich einfach umzusetzen sind Linecharts, z.B. die Entwicklung des Steuerfusses in einer Gemeinde:

```sql unique_gemeinden
select
  gemeinde
from
  mytrino.steuerfuesse
group by
  1
order by
  gemeinde
```

<Dropdown
    name=selected_gemeinde
    data={unique_gemeinden}
    value=gemeinde
    title="Wählen Sie eine Gemeinde"
    noDefault=true
/>

```sql query_steuerfuesse_filtered_by_gemeinden
select
  *
from
  mytrino.steuerfuesse
where
  gemeinde = '${inputs.selected_gemeinde.value}'
order by
  jahr,gemeinde
```

<LineChart
    data={query_steuerfuesse_filtered_by_gemeinden}
    x=jahr
    y=steuerfuss_in_prozent
    yAxisTitle="Steuerfuss pro Jahr"
    markers=true
    xFmt='###0'
    yMin=60
/>

Als letztes Beispiel möchte ich die Steuerfüsse in einer Karte darstellen. Dazu wird eine GeoJSON-Datei mit den Polygonen, die man anzeigen will, benötigt (EPSG:4326). In unserem Fall die Gemeindegrenzen des Kantons Solothurn. Die Datei speichert man im static-Ordner im Projektverzeichnis. Den static-Ordner muss man erstellen, falls er nicht existiert.

```sql my_query
SELECT
    *
FROM
    mytrino.steuerfuesse
WHERE
    jahr = 2022
```

<AreaMap
    data={my_query}
    areaCol=gemeinde
    geoJsonUrl='/kanton_solothurn.geojson'
    geoId=gemeindename
    value=steuerfuss_in_prozent
    title='Steuerfüsse (natürliche Personen)'
    attribution='Kanton Solothurn'
/>

Das Mapping der Gemeinde zur Geometrie wird über areaCol=gemeinde gesteuert. D.h. die GeoJSON-Datei hat ein Property gemeinde und das Query-Resultat hat ebenfalls ein Attribut gemeinde. Die Zuweisung des Wertes erfolgt über value=steuerfuss_in_prozent. Was ich mir noch nicht genau angeschaut habe, ist die Übersteuerung der Farbgebung. Sowohl hier bei der Karte wie auch bei den anderen Beispielen. Einiges scheint mir jedoch möglich zu sein.

Man erkennt, dass verschiedene Gemeinden fehlen. Das liegt entweder daran, dass ich Zeitstände versuche zu matchen, die nicht passen (wegen Gemeindefusionen) oder das Mapping der Gemeindenamen funktioniert nicht, weil eventuell die Namen unterschiedlich geschrieben sind.

Als letztes muss ich mein Projekt builden: npm run build. Das erstellt einen build-Ordner, dessen Inhalt ich als statische Homepage irgendwo hin deployen kann. Evidence hat auch ein Hostingangebot, das für öffentliche Dashboards gratis ist.

Links:

Sämtliche verfügbaren Widgets/Komponenten: https://docs.evidence.dev/components/all-components/
Beispiele mit Evidence: https://evidence.dev/examples

The house at the lake #2 - Start your engines

Sun, 12 Jan 2025 00:00:00 +0000

Nachdem wir uns im ersten Teil um das Speichern der Daten in unserem Data Lakehouse gekümmert haben, möchten wir jetzt mit den Daten arbeiten, d.h. wir brauchen eine Compute oder Query Engine. Es gibt verschiedene Engines, die auf Iceberg Tables zugreifen können. Anschliessend drei Beispiele dazu. Es sei nochmals darauf hingewiesen, dass man es nicht mit drei verschiedenen Datenbankklienten vergleichen kann. In DB-Fall verursachen die Klienten die (gleiche) Last auf dem Datenbankserver. Aufgrund der Trennung von Speichern und Compute in einem Data Lakehouse, liegt die Rechenlast bei der Query Engine selber.

Die erste Möglichkeit haben wir bereits im vorangegangenen Blogbeitrag kennengelernt: Spark. Spark diente mir hauptsächlich zum Anlegen der Iceberg-Tabellen. Man kann damit aber auch beliebige Analysen machen. Es gibt drei Benutzerinterfaces: SQL, Scala und Python. Die beiden letzten würde man wohl verwenden, wenn man für seine Analyse weitere Bibliotheken verwende möchte oder muss. Ich setze mir als Ziel die Tabelle der Steuerfüsse der natürlichen Personen, die ich in mein Data Lakehouse importiert habe, in eine Excel-Datei zu exportieren. Ich verwende für dieses Beispiel pyspark und muss zuerst noch weitere Bibliotheken herunterladen:

python -m venv .venv
source .venv/bin/activate
pip install setuptools pandas openpyxl

Das Python-Skript sieht wie folgt aus:

from pyspark.sql import SparkSession
import pandas as pd

spark = SparkSession.builder \
    .appName("IcebergLocal") \
    .config("spark.sql.extensions", "org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions") \
    .config("spark.sql.catalog.local", "org.apache.iceberg.spark.SparkCatalog") \
    .config("spark.sql.catalog.local.type", "hadoop") \
    .config("spark.sql.catalog.local.warehouse", "/Users/stefan/tmp/warehouse/") \
    .getOrCreate()

spark.sql("USE local.agem_steuerfuesse")

result_df = spark.sql("""
    SELECT
        *
    FROM
        natuerliche_personen
"""
)

result_df.show()

pandas_df = result_df.select("*").toPandas()
pandas_df.to_excel("/Users/stefan/tmp/myresult.xlsx", index=False)

Der Aufruf muss nicht in der Shell passieren, sondern kann als pyspark-Befehl auf der Konsole ausgeführt werden:

pyspark --packages org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.7.1 < to_excel.py

Man benötigt für den Export in eine Excel-Datei Pandas. Dazu muss der Spark Dataframe in einen Pandas Dataframe umgewandelt werden.

So weit, so unspektakulär. Spannender wird es mit der zweiten Möglichkeit: DuckDB:

Mit DuckDB erweitere ich meinen Anwendungsfall ein wenig. Ich möchte die Steuerfüsse in eine Excel-Datei exportieren. Zusätzlich soll die Fläche jeder Gemeinde als Spalte mitexportiert werden (bisschen Geo muss ja sein…). DuckDB hat eine Iceberg Extension, die man installieren muss. Die Anwendung ist relativ simpel. Man kann auf die Live-Daten, Metadaten und Snapshots zugreifen:

SELECT count(*)
FROM iceberg_scan('/Users/stefan/tmp/warehouse/agem_steuerfuesse/natuerliche_personen', allow_moved_paths = true) AS f;

SELECT *
FROM iceberg_metadata('/Users/stefan/tmp/warehouse/agem_steuerfuesse/natuerliche_personen', allow_moved_paths = true);

SELECT *
FROM iceberg_snapshots('/Users/stefan/tmp/warehouse/agem_steuerfuesse/natuerliche_personen');

Nach Iceberg schreiben geht noch nicht. Was - soweit ich es verstanden habe - auch noch nicht (gut) unterstützt wird, sind die Kataloge. DuckDB benötigt eine version-hint.text-Datei. Diese verweist auf die aktuelle Version der Daten. Fehlt diese, kann man versuchen direkt die Metadaten-JSON-Datei anzugeben. Aber von nativer Katalogunterstützung ist man noch ein Stück weit entfernt.

Meinen Anwendungsfall kann ich mit purem SQL umsetzen:

CREATE TEMP TABLE myresult AS
WITH steuern AS (
  SELECT
    *
  FROM
    iceberg_scan('/Users/stefan/tmp/warehouse/agem_steuerfuesse/natuerliche_personen', allow_moved_paths = true)
)
SELECT
  gemndname,
  ST_Area(geom),
  steuerfuss_in_prozent
FROM
  ST_Read('/vsizip//vsicurl/https://files.geo.so.ch/ch.so.agi.av.hoheitsgrenzen/aktuell/ch.so.agi.av.hoheitsgrenzen.shp.zip', layer='gemeindegrenze') AS g
  LEFT JOIN steuern
  ON g.gemndname = steuern.gemeinde
;
COPY (SELECT * FROM myresult) TO '/Users/stefan/tmp/myresult.xlsx' WITH (FORMAT GDAL, DRIVER 'xlsx');

Immer wieder schön zu sehen, dass man dank gdal/ogr die Daten nicht einmal vorgängig herunterladen muss.

Die dritte Variante ist die aufwändigste und wohl auch die «most enterprisey»: Trino. Trino ist eine clusterfähige SQL Query Engine. Die Clusterfähigkeit interessiert uns beim Rumspielen nicht. Spark ist ebenfalls clusterfähig, im Gegensatz zu DuckDB, wo zudem die Last nicht auf einem Server anfällt, sondern auf meinem Rechner. Trino hat mit Presto noch etwas ähnliches wie einen Klon (oder wie man das nennen mag). Presto scheint mir eher das Community-Projekt zu sein. Weil ich aber zuerst ein Trino-Dockerimage gefunden habe, mache ich es jetzt damit.

Weil Trino in einem Dockercontainer läuft, muss ich mir Gedanken bezüglich des Zugriffs auf die Iceberg-Tabellen und den Katalog machen. Entweder mounte ich meine lokalen Tabellen einfach in den Container rein oder ich mache es gleich «richtig» (kompliziert) und speichere die Tabellen auf S3 und den Katalog in einer PostgreSQL-Datenbank. Letzteres ist keine Herausforderung, da wir es bereits mit SQLite im ersten Teil gemacht haben.

Weil ich für meinen Anwendungsfall Geodaten benötige, starte ich eine weitere Datenbank, welche die Rolle des (Geo-)Datawarehouses übernimmt. Meine docker-compose-Datei:

services:
  pub-db:
    image: sogis/postgis:16-3.4-bookworm
    environment:
      POSTGRES_DB: pub
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: secret
    ports:
      - "54322:5432"
    volumes:
      - type: volume
        source: pgdata_pub
        target: /var/lib/postgresql/data
  iceberg-db:
    image: sogis/postgis:16-3.4-bookworm
    environment:
      POSTGRES_DB: iceberg
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: secret
    ports:
      - "54324:5432"
    volumes:
      - type: volume
        source: pgdata_iceberg
        target: /var/lib/postgresql/data
  trino:
    image: trinodb/trino
    ports:
      - "8080:8080"
volumes:
  pgdata_pub:
  pgdata_iceberg:

Für das Anlegen des Icebgerg-Kataloges und für den Datenimport verwende ich wieder Spark. Leider gibt es keine Möglichkeit einen Schemanamen zu definieren. So landen sämtliche Tabellen des Katalogs im public-Schema. Das Anlegen der Steuerfuss-Tabelle und Importieren der Daten war soweit auch kein Problem. Man muss einzig die korrekten Spark-Konfig-Parameter herausfinden. Das kann ein wenig hakelig sein. Was ich nicht geschafft habe, sind die AWS-S3-Credentials als Parameter zu definieren. Es funktioniert aber problemlos, wenn ich sie als Env-Variable definiere.

Mein pyspark-Skript sieht wie folgt aus:

from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .appName("IcebergS3") \
    .config("spark.sql.catalog.iceberg", "org.apache.iceberg.spark.SparkCatalog") \
    .config("spark.sql.catalog.iceberg.type", "jdbc") \
    .config("spark.sql.catalog.iceberg.uri", "jdbc:postgresql://localhost:54324/iceberg") \
    .config("spark.sql.catalog.iceberg.jdbc.user", "postgres") \
    .config("spark.sql.catalog.iceberg.jdbc.password", "secret") \
    .config("spark.sql.catalog.iceberg.warehouse", "s3://XXXXXXXXXXXXXXX") \
    .config("spark.sql.catalog.iceberg.io-impl", "org.apache.iceberg.aws.s3.S3FileIO") \
    .config("spark.hadoop.fs.s3a.impl", "org.apache.hadoop.fs.s3a.S3AFileSystem") \
    .config("spark.hadoop.fs.s3a.connection.ssl.enabled", "true") \
    .config("spark.hadoop.fs.s3a.path.style.access", "true") \
    .config("spark.sql.catalog.iceberg.s3.endpoint","https://s3-eu-central-1.amazonaws.com/") \
    .getOrCreate()

parquet_df = spark.read.parquet("/Users/stefan/Downloads/ch.so.agem.steuerfuesse.natuerliche_personen.parquet")
print(parquet_df)

parquet_df.writeTo("iceberg.agem_steuerfuesse.natuerliche_personen").using("iceberg").createOrReplace()

Erscheinen keine Fehlermeldungen, sollte der Import funktioniert haben:

Wenn man mit docker compose up die Container startet, passiert schon einiges aber noch nicht genau das, was man eigentlich will. Trino hat noch keinen Zugriff auf die Geodatenbank und auf die Iceberg-Tabellen. Dazu müssen mittels Connectoren Kataloge definiert werden. Es sind Properties-Dateien, die in einen bestimmten Ordner (/etc/trino/catalog/) kopiert werden müssen. Ich habe es so gelöst, dass ich diese in den Container reinmounte. D.h. die docker-compose-Datei muss beim Trino-Service um ein Volume erweitert werden:

    volumes:
      - type: bind
        source: /Users/stefan/tmp/trino
        target: /etc/trino

Die Konfig-Datei pgpub.properties für PostgreSQL:

connector.name=postgresql
connection-url=jdbc:postgresql://pub-db:5432/pub
connection-user=postgres
connection-password=secret

Die Konfig-Datei iceberg.properties für die Iceberg-Tabellen auf S3:

connector.name=iceberg
fs.native-s3.enabled=true
iceberg.catalog.type=jdbc
iceberg.jdbc-catalog.catalog-name=iceberg
iceberg.jdbc-catalog.driver-class=org.postgresql.Driver
iceberg.jdbc-catalog.connection-url=jdbc:postgresql://iceberg-db:5432/iceberg
iceberg.jdbc-catalog.connection-user=postgres
iceberg.jdbc-catalog.connection-password=secret
iceberg.jdbc-catalog.default-warehouse-dir=s3://XXXXXXXXXXXXXXX
s3.endpoint=https://s3-eu-central-1.amazonaws.com/
s3.region=eu-central-1
s3.aws-access-key=YYYYYYYYYYYY
s3.aws-secret-key=ZZZZZZZZZZZZ

Falls der Container immer noch startet, sollte alles korrekt konfiguriert sein. Für Trino existiert ein JDBC-Treiber. Somit kann ich z.B. mit DBeaver elegant auf alle konfigurierten Trino-Kataloge zugreifen. Trino unterstützt eine Vielzahl von Geo-Funktionen und ich kann, wie bei DuckDB, eine SQL-Query absetzen, die Daten aus verschiedenen Quellen holt:

SELECT
  np.gemeinde,
  ST_Area(hg.geometrie),
  np.steuerfuss_in_prozent
FROM
  pgpub.agi_hoheitsgrenzen_pub_v1.hoheitsgrenzen_gemeindegrenze AS hg
  LEFT JOIN iceberg.agem_steuerfuesse.natuerliche_personen AS np
  ON np.gemeinde = hg.gemeindename
WHERE
  jahr = 2000
;

Im Gegensatz zu DuckDB kann ich nicht direkt nach Excel exportieren. Als Workaround kann ich das CLI-Tool verwenden und ein good old CSV erstellen:

java -jar trino-cli-468-executable.jar http://localhost:8080 --file=query.sql --output-format=CSV > myresult.csv

Auf den ersten Blick erscheint DuckDB eleganter und leichtgewichtiger. Ist es auch, nur vergleicht man Äpfel mit Birnen. Bei Trino läuft die Query auf einem Server resp. kann die Last in einem Cluster auf verschiedene Server verteilt werden. DuckDB läuft im Regelfall bei mir lokal auf dem PC. Ein anderer gewichtiger Unterschied ist die ganze Authentifizierung und Autorisierung. Trino ist hier enorm mächtig. Man kann out-of-the-box bis auf Stufe Tabelle berechtigen. Mit weiteren Komponenten sogar bis auf Stufe Attribut. Mit DuckDB kann ich zwar auch Iceberg-Tabellen auf S3 benutzen. Wenn ich die S3-Credentials habe, sehe ich jedoch sämtliche Tabellen dieses Kataloges. Somit müsste also in einer Organisation der Zugang auf Iceberg-Tabellen einzig mittels einer Query Engine geschehen, die sich auch um die Autorisierung kümmert. Mehr Freiheiten hätte man, wenn sich der Iceberg-Katalog darum kümmert. Dann wäre es egal mit welcher Iceberg-Query-Engine ich auf die Tabellen zugreife. Mit Apache Polaris will man das so umsetzen. Polaris implementiert die REST-Variante eines Iceberg-Kataloges. Hier bannt sich - nach dem table format war - der nächste Krieg an: «The War of the Catalogs» (Apache Polaris vs Databricks Unity).

The house at the lake #1 - Iceberg ahead

Sun, 5 Jan 2025 00:00:00 +0000

Data Lake, Data Swamp, Data Lakehouse… Man kommt fast nicht hinterher. Kaum meint man minimal etwas verstanden zu haben, kommt schon was neues. Weil auch im Kanton nun ab und an das Stichwort «Dateninfrastruktur» fällt, wollte ich mich ein wenig in die Data Lake Thematik einlesen. Nur eben um zu merken, dass man jetzt keinen Data Lake mehr macht, sondern eben ein Data Lakehouse. Ich habe nie wirklich verstanden, was so genial am Data Lake sein soll. Da werden lustig unstrukturiert irgendwo Daten abgelegt. Wie man nun darauf zugreift, resp. überhaupt was finden soll - haha im Data Swamp - entzieht sich meiner Kenntnis. Und da kommt nun das Data Lakehouse ins Spiel: Vielleicht lässt sich sagen, dass ein Data Lakehouse aus einem Data Lake besteht, der mit Metadaten und Data Governance angereichert wird (und so wieder mehr einem Data Warehouse ähnelt).

Statt eines Haufens von Dateien in beliebigen Formaten gibt es im Lakehouse z.B. ein einziges Tabellenformat und die Daten werden dort gespeichert. Der Datenzugriff erfolgt dann mit diversen Clients via Metadaten auf dieses Tabellenformat und nicht mehr direkt auf die Dateien. Es wird auch häufig von Katalogen gesprochen. Hier hat es bei mir noch nicht klick gemacht. Wahrscheinlich - déformation professionnelle - verstehe ich was anderes darunter. Vielleicht wird es auch verschiedene Kataloge geben müssen: eher was technisches für die Maschinen und etwas für den Menschen, der nach einem bestimmten Thema sucht und nicht weiss, wie eine bestimmte Tabelle genau heisst.

Das Tabellenformat ist das Tabellenformat. D.h. es darf nicht mit einem Dateiformat verwechselt werden, welches wiederum vom Tabellenformat verwendet werden kann, um die Daten tatsächlich zu speichern und es ist eben auch «nur» das Tabellenformat: Es stellt nicht eine Berechnungsengine zur Verfügung, so wie man das vom klassischen Data Warehouse kann, wo die relationale Datenbank sich um das Speichern der Daten kümmert und auch die Bearbeitungsmöglichkeit derselben mittels SQL zur Verfügung stellt. Wenn man mit den Daten in einem Data Lakehouse auch arbeiten will, braucht es noch mindestens eine weitere Kompenente.

Ein für ein Data Lakehouse sinnvolles Tabellenformat muss ACID-Transaktionen unterstützen, so wie man es auch von relationen Datenbanken kennt. Ein solches Tabellenformat ist z.B. Apache Iceberg. Es gibt noch weitere aber von Iceberg liest man momentan relativ viel und anscheined hat Iceberg den «table format war» gewonnen. Und mit Iceberg wollte ich nun mal arbeiten, um ein Gespür zu bekommen, was das genau heisst und was für Komponenten im Spiel sind.

Apache Iceberg ist nicht etwas, was man einfach mittels «setup.exe» installiert. Es ist vor allem eine Spezifikation, bietet aber auch noch ein paar Libraries an, damit bestehende Werkzeuge damit arbeiten können. Starten müssen wir aber mit Apache Spark. Das wird unser Client, um Daten in Iceberg speichern zu können. Ich wähle die Version 3.5.4 und den Package-Typ «Pre-built for Apache Hadoop 3.3 and later». Grundvoraussetzung ist, dass Java installiert ist. Mit Version 11 und 17 liegt man nicht falsch. Mit Version 21 geht es noch nicht. Spark bietet drei Benutzerinterfaces an: SQL, Scala-Shell und Python-Shell. Falls man Scala (Version 2.12) und Python verwenden will, muss man diese ebenfalls installieren. Scala habe ich mit SDKMAN installiert und Python hatte ich bereits installiert gehabt. Apache Spark entzippt man und ergänzt die PATH-Variable, z.B. in der .zshrc-Datei:

export SPARK_HOME=/Users/stefan/apps/spark-3.5.4-bin-hadoop3
export PATH=$SPARK_HOME/bin:$SPARK_HOME/sbin:$PATH

Der Aufruf spark-shell --version sollte circa folgenden Output liefern:

25/01/04 18:24:26 WARN Utils: Your hostname, Monterrico.local resolves to a loopback address: 127.0.0.1; using 10.0.1.12 instead (on interface en0)
25/01/04 18:24:26 WARN Utils: Set SPARK_LOCAL_IP if you need to bind to another address
Welcome to
      ____              __
     / __/__  ___ _____/ /__
    _\ \/ _ \/ _ `/ __/  '_/
   /___/ .__/\_,_/_/ /_/\_\   version 3.5.4
      /_/

Using Scala version 2.12.18, OpenJDK 64-Bit Server VM, 17.0.10
Branch HEAD
Compiled by user yangjie01 on 2024-12-17T04:51:46Z
Revision a6f220d951742f4074b37772485ee0ec7a774e7d
Url https://github.com/apache/spark
Type --help for more information.

Und nun wirds kompliziert: die Kataloge ins Spiel. Wir müssen eine Spark-Session (egal bei welchem der drei Interfaces) so konfigurieren, dass man mit Iceberg zusammenarbeiten kann. Mit spark-sql sieht ein Start-Aufruf so aus:

spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.7.1 \
--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions \
--conf spark.sql.catalog.local=org.apache.iceberg.spark.SparkCatalog \
--conf spark.sql.catalog.local.type=hadoop \
--conf spark.sql.catalog.local.warehouse=/Users/stefan/tmp/warehouse

Es wird eine zusätzliche Library benötigt. Dabei ist auf die passende Version zu achten: 3.5 für Spark, 2.12 für Scala und 1.7.1 für Iceberg. Beim Start wird die Jar-Datei herunterladen. Man kann sie aber auch einmalig herunterladen und in den jars-Ordern der Spark-Installation kopieren.

Mit der zweiten Zeile teilen wir Spark mit, dass wir Iceberg-Extensions verwenden wollen. Und dann kommen drei Zeilen mit den Katalogen und ich kann immer noch nicht genau abgrenzen, ob es ein Spark-Katalog, ein Iceberg-Katalog oder was auch immer ist. Jedenfalls verstehe ich es so, dass es darum geht den Typ des Iceberg-Kataloges auszuwählen. Mit hadoop wählen wir die einfachste file-basierte Variante eines Katalogs aus (eignet sich nicht für Produktion). Die Daten selber werden unter warehouse gespeichert. Hier wird in Produktion häufig ein S3-Bucket stehen. Der Namen des Katalogs ist local und darf auch anders heissen und trotzdem ein lokaler Katalog sein. Den Befehl setzt man in der Konsole ab und falls alles gut geht, erscheint: spark-sql (default)>.

Zeit, um Tabellen und Daten zu erzeugen:

CREATE TABLE local.foo.steuerfuss (jahr int, gemeinde string, steuerfuss int) USING iceberg;

Die Tabellen werden qualifiziert angesprochen, wobei local der Katalog ist, foo der Namespace (entspricht plusminus einem DB-Schema) und steuerfuss der Tabellenname ist.

Auf dem Dateisystem werden erste Verzeichnisse und Dateien erstellt:

INSERT INTO local.foo.steuerfuss (jahr, gemeinde, steuerfuss) VALUES (2000, 'Aedermannsdorf', 150);

INSERT INTO local.foo.steuerfuss (jahr, gemeinde, steuerfuss) VALUES (2000, 'Aeschi (SO)', 135);

INSERT INTO local.foo.steuerfuss (jahr, gemeinde, steuerfuss) VALUES (2000, 'Balm bei Günsberg', 110);

Mit SELECT kann ich mir die drei Records anzeigen lassen:

spark-sql (default)> SELECT * FROM local.foo.steuerfuss;
2000	Aeschi (SO)	135
2000	Aedermannsdorf	150
2000	Balm bei Günsberg	110
Time taken: 0.067 seconds, Fetched 3 row(s)
spark-sql (default)>

Viel interessanter ist jedoch, was auf dem Dateisystem abging:

Es gibt mehr Metadaten und einen data-Ordner. In diesem data-Ordner sind drei Parquet-Dateien. Die Daten speichert Iceberg in Parquet-Dateien (andere Formate stehen zur Auswahl). Was besonders auffällt, ist natürlich, dass es drei Stück gibt und wir haben drei INSERT-Befehle gemacht. Häufig führt wahrscheinlich schon jeder INSERT-Befehl zu einer zusätzlichen Datei, wobei ein INSERT-Befehl natürlich mehrere Records beinhalten kann. In unserem Fall ist in jeder Parquet-Datei auch jeweils nur genau ein Record. Man kann die maximale Grösse von Parquet-Dateien konfigurieren und man will bei ganz vielen vorliegenden Dateien aus Performancegründen diese zu einer grösseren zusammenführen können (auch das ist möglich mit sogenannten «compaction jobs»).

Apache Iceberg unterstützt Snapshots und Time Travel. Jede Transaktion (in unserem Fall die drei INSERT-Befehle) führt zu einem Snapshot:

spark-sql (default)> SELECT * FROM local.foo.steuerfuss.snapshots;
2025-01-04 19:01:55.286	4283993947365810884	NULL	append	/Users/stefan/tmp/warehouse/foo/steuerfuss/metadata/snap-4283993947365810884-1-c6c6b8bd-a8de-4a6e-88a5-fa59e263e328.avro	{"added-data-files":"1","added-files-size":"940","added-records":"1","app-id":"local-1736012466059","changed-partition-count":"1","engine-name":"spark","engine-version":"3.5.4","iceberg-version":"Apache Iceberg 1.7.1 (commit 4a432839233f2343a9eae8255532f911f06358ef)","spark.app.id":"local-1736012466059","total-data-files":"1","total-delete-files":"0","total-equality-deletes":"0","total-files-size":"940","total-position-deletes":"0","total-records":"1"}
2025-01-04 19:02:01.306	4180574121117132588	4283993947365810884	append	/Users/stefan/tmp/warehouse/foo/steuerfuss/metadata/snap-4180574121117132588-1-364edb50-a639-4665-8e01-5e4a0797c75b.avro	{"added-data-files":"1","added-files-size":"919","added-records":"1","app-id":"local-1736012466059","changed-partition-count":"1","engine-name":"spark","engine-version":"3.5.4","iceberg-version":"Apache Iceberg 1.7.1 (commit 4a432839233f2343a9eae8255532f911f06358ef)","spark.app.id":"local-1736012466059","total-data-files":"2","total-delete-files":"0","total-equality-deletes":"0","total-files-size":"1859","total-position-deletes":"0","total-records":"2"}
2025-01-04 19:02:05.316	2935673125777738477	4180574121117132588	append	/Users/stefan/tmp/warehouse/foo/steuerfuss/metadata/snap-2935673125777738477-1-790f349b-3cf5-4eba-b95b-738d16c2292d.avro	{"added-data-files":"1","added-files-size":"968","added-records":"1","app-id":"local-1736012466059","changed-partition-count":"1","engine-name":"spark","engine-version":"3.5.4","iceberg-version":"Apache Iceberg 1.7.1 (commit 4a432839233f2343a9eae8255532f911f06358ef)","spark.app.id":"local-1736012466059","total-data-files":"3","total-delete-files":"0","total-equality-deletes":"0","total-files-size":"2827","total-position-deletes":"0","total-records":"3"}
Time taken: 0.055 seconds, Fetched 3 row(s)
spark-sql (default)>

Die erste Spalte ist der Zeitstempel und die zweite Spalte die Snapshot-ID. Mit dieser ID kann ich einfach einen bestimmten Datenstand aufrufen:

spark-sql (default)> SELECT * FROM local.foo.steuerfuss VERSION AS OF 4180574121117132588;
2000	Aedermannsdorf	150
2000	Aeschi (SO)	135
Time taken: 0.065 seconds, Fetched 2 row(s)
spark-sql (default)>

Und schon sind es nur noch zwei Records. Ähnlich funktioniert es mit dem Timestamp:

spark-sql (default)> SELECT * FROM local.foo.steuerfuss TIMESTAMP AS OF '2025-01-04 19:01:55.286';
2000	Aedermannsdorf	150
Time taken: 0.066 seconds, Fetched 1 row(s)
spark-sql (default)>

Snapshots kann und soll man wohl von Zeit zu Zeit löschen, da sonst auch wieder die Performance massiv leidet. Es beschleicht mich das Gefühl, dass die «korrekte» Konfiguration von Iceberg auch nicht ganz ohne ist.

Ein weiteres interessantes Feature von Apache Iceberg ist das Partitioning. Nehmen wir an, wir haben einen sehr grossen Datensatz. Es gibt pro Jahr (das als Attribut im Tabellenschema vorhanden ist) sehr viele Records. Abfragen werden häufig für ein bestimmtes Jahr gemacht. Dann können die Daten in der Tabelle auch gruppiert nach Jahr gespeichert werden. So werden die Queries viel schneller. Als Beispiel importieren wir mit der Python-Shell eine Parquet-Datei mit den Steuerfüssen sämtlicher Gemeinden für die Jahre 2000 - 2022. Das Starten ist gleich wie bei der SQL-Shell, nur mit pyspark:

pyspark --packages org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.7.1 \
--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions \
--conf spark.sql.catalog.local=org.apache.iceberg.spark.SparkCatalog \
--conf spark.sql.catalog.local.type=hadoop \
--conf spark.sql.catalog.local.warehouse=/Users/stefan/tmp/warehouse

Mit Python ist es möglich auf Basis einer Parquet-Datei eine Tabelle zu erstellen und sämtliche Daten innerhalb einer Transaktion zu importieren:

from pyspark.sql import SparkSession

parquet_df = spark.read.parquet("/Users/stefan/Downloads/ch.so.agem.steuerfuesse.natuerliche_personen.parquet")
print(parquet_df)

parquet_df.writeTo("local.bar.steuerfuss_partitioned").partitionedBy("jahr").using("iceberg").createOrReplace()

Die Befehle dünken mich selbsterklärend. Die Struktur auf dem Dateisystem sieht entsprechend gegliedert aus:

Zu guter Letzt nochmal was zu meiner Nemesis, den Katalogen: Wie erwähnt gibt es verschiedene Typen von Iceberg-Katalogen. Ein weiterer Typ ist «jdbc». In diesem Fall werden bestimmte Metainformationen in einer relationalen Datenbank gespeichert. Die Konfiguration (mit Scala) ist folgendermassen:

import org.apache.spark.sql.SparkSession

val spark = SparkSession.builder()
  .appName("IcebergExample")
  .config("spark.sql.catalog.local", "org.apache.iceberg.spark.SparkCatalog")
  .config("spark.sql.catalog.local.type", "jdbc")
  .config("spark.sql.catalog.local.jdbc.url", "jdbc:sqlite:/Users/stefan/tmp/iceberg_metadata.db")
  .config("spark.sql.catalog.local.jdbc.driver", "org.sqlite.JDBC")
  .config("spark.sql.catalog.local.warehouse", "file:/Users/stefan/tmp/warehouse")
  .getOrCreate()

import spark.implicits._

spark.sql("CREATE TABLE local.default.sample_table (id INT, name STRING) USING iceberg")

Dabei darf man sich nicht irritieren lassen, dass die SQLite-Datenbank erst nach dem Erstellen einer ersten Iceberg-Tabelle erzeugt wird (Hallo Zukunfts-Stefan).

Mein Lakehouse-Zwischenfazit: Abklären, was man eigentlich will und was die Anforderungen sind, sollte man schon noch vor der Realisierung eines Data Lakehouses. Vielleicht reicht auch wie fast immer eine PostgreSQL-Datenbank und bisschen Parquet-Dateien und DuckDB. Wir werden wohl nicht so schnell hunderte von Petabytes an Daten vorliegen haben.

Links:

INTERLIS leicht gemacht #45 - INTERLIS goes OLAP

Fri, 27 Dec 2024 00:00:00 +0000

So, ich habe nochmals ein paar Stunden in den ili2duckdb-Flavor investiert und schlussendlich einen Pull-Request gemacht. Wenn/falls er gemerget wird, gibt es ili2db nun auch für eine OLAP-Datenbank. Interessanterweise ist mein erster Einsatzzweck nicht mal per se eine Analyse, sondern eher klassisches Geoprocessing (wobei: wo genau hört das eine auf und beginnt das andere?). Zuerst aber ein paar Worte zur Umsetzung von ili2duckdb:

Wie im ersten Beitrag zu ili2duckdb erwähnt, ist die Umsetzung relativ straight forward nach dem Motto: Wo ein JDBC-Treiber, da auch ein ili2xy. Notfalls muss/kann man sich sogar einen eigenen JDBC-Treiber (oder Wrapper) schreiben (siehe ili2fgdb). Im Regelfall reicht es, wenn man fünf abstrakte Klassen erweitert resp. Interfaces implementiert und schon hat man seinen ili2db-Flavor. Ili2db ist eben nicht bloss ein Werkzeug, sondern auch ein Framework, um weitere Flavors umzusetzen. Die Arbeiten mit diesem Framework gestalten sich meiner Meinung nach als angenehm und man durchschaut relativ schnell, wo man was anpassen muss. So gibt es z.B. eine zu implementierende Methode, die sich darum kümmert wie aus einem IOM-Koordinaten-Objekt ein Java-Objekt gemacht wird, welches anschliessend mit einer Geofunktion der Datenbank in die Datenbank geschrieben wird.

@Override
public Object fromIomCoord(IomObject value, int srid, boolean is3D)
  throws SQLException, ConverterException {
  if (value!=null) {
      Iox2wkb conv=new Iox2wkb(2, ByteOrder.BIG_ENDIAN, false);
      try {
        return conv.coord2wkb(value);
      } catch (Iox2wkbException ex) {
        throw new ConverterException(ex);
      }
    }
  return null;
}

Die dazugehörige Geofunktion muss ebenfalls definiert werden, indem man folgende Methode implementiert (resp. überschreibt):

@Override
public String getInsertValueWrapperCoord(String wkfValue, int srid) {
  return "ST_GeomFromWKB("+wkfValue+"::blob)";
}

Das explizite Casten nach blob ist meines Erachtens eine/ein Unschönheit/Bug von DuckDB Spatial. Btw: Das Variable-Naming als wkfValue finde ich unlogisch und ungünstig (oder ich steh' auf dem Schlauch… es wird nicht der WKF-Wert geliefert und es ist ein Prepared-Statement, d.h. der String ist nichts anderes als ein Fragezeichen).

Die fromIomCoord-Methode kann für jeden Flavor völlig anders funktionieren. Für ili2gpkg muss eine andere Methode für die Umwandlung nach WKB verwendet werden, weil GeoPackage ein leicht anderes WKB-Format verwendet. Das sieht so aus:

@Override
public java.lang.Object fromIomCoord(IomObject value, int srsid, boolean is3D)
  throws SQLException, ConverterException {
  if (value!=null) {
      Iox2gpkg conv=new Iox2gpkg(is3D?3:2);
    try {
      return conv.coord2wkb(value,srsid);
    } catch (Iox2wkbException ex) {
      throw new ConverterException(ex);
    }
  }
  return null;
}

So geht das nun weiter für mehr oder weniger sämtliche möglichen Datentypen (nicht nur Geometrien), wie z.B. Date, UUID etc. pp. Auch muss ein ID-Generator implementiert werden, weil nicht zwingend jede Datenbank Sequenzen gleich unterstützt.

Und das Coole ist, dass ich mich um alles andere nicht zu kümmern brauche. Jede der gefühlt 1000 ili2db-Optionen funktioniert mit jedem neuen Flavor. Ein super Fundament wurde hier geschaffen.

Es wäre natürlich zu einfach und gelogen, wenn es nicht doch noch einen kleinen Stolperstein (oder auch zwei) gegeben hätte. Als ich als erstes die DuckDB-Version von 0.9.2 auf die aktuelle Version 1.1.3 upgedatet habe und einen Testrun machte, hing sich ili2duckdb auf. Während des Testruns ging plötzlich nichts mehr. Es stellte sich heraus, dass es einen Bug (?) gibt. In meinem Fall war nicht die zweite Connection das Problem, sondern ein zweites Statement, ohne das erste zu schliessen. Es dürfte sich aber wohl um den gleichen Bug handeln. Das gleiche Problem tauchte beim Erstellen des Schemas auf. Hier wird die ehisqlgen-Bibliothek verwendet und muss deshalb gefixed werden. Der zweite kleine Stolperstein, der es nötig machte den Kern-Testcode an der einen oder anderen Stelle anzupassen, ist die Besonderheit, dass DuckDB nur eine schreibende Connection erlaubt oder mehrere nur-lesende. Das war es aber auch schon.

Erwähnenswert sind ebenfalls Dinge, die wegen DuckDB nicht gehen:

3D-Geometrien werden nicht unterstützt und werden nach 2D-Geometrien umgewandelt.
Kreisbögen werden nicht unterstützt.
SRID wird bei Geometrien nicht unterstützt.
Die ADD CONSTRAINT-Syntax wird noch nicht unterstützt. Das führt zu fast keinen Constraints auf der Datenbank.
Der Geometrie-Index ist zwar vorhanden, jedoch - soweit ich es verstehe - nicht wirklich brauchbar, da z.B. bei ST_Intersects() ein Wert zur Planning Time bekannt sein muss.

Was ist nun mein Einsatzzweck? Exemplarisch ein Projekt des Amtes für Raumplanung (ARP). Sie möchten für jede Gemeinde auf Knopfdruck wissen, von welchen raumplanerisch relevanten Themen die Gemeinde betroffen ist. Ihre Idee war es diese Information pro Gemeinde händisch nachzuführen. Obwohl ich mich mit der Grundidee (also sicher nicht mit der händischen Nachführung) anfreunden kann, hadere ich mit dem Glauben, dass das in Realität wirklich gut kommt. Sie haben jetzt schon eine Liste mit über 70 Themen und da es nicht für einen ganz konkreten Anwendungfall gelten soll, sondern für Raumplanung als solches, ist die Antwort dann vielleicht zu allgemein. Naja… Viele der benötigten Daten liegen natürlich in unserer zentralen Datenbank vor. Unter den 70 Themen sind aber auch viele Bundesinventare. Diese Daten importieren wir nicht, sondern zeigen nur den WMS des Bundes im Web GIS Client an. Wie finde ich nun heraus, ob die Gemeinde Solothurn vom Bundesinventar Amphibienlaichgebiete betroffen ist?

Eine erste Idee war den REST-Service anzuzapfen und die JSON-Antwort als Datei zu speichern. Diese in die PostgreSQL-Datenbank zu importieren und dann mit den JSON-Funktionen von PostgreSQL bisschen Geo-Magic zu machen. Das alles ginge heute bereits mit GRETL problemlos. Wenn ich den REST-Service aber richtig verstehe, werden nur 200 Objekte zurückgeliefert (dokumentiert sind 50, was falsch zu sein scheint). Weil ich ja nicht sicher sein kann, dass ich nie mehr als 200 habe, müsste ich mehrere Requests (Offsets werden unterstützt) machen. Das fand ich dann bisschen zu workaroundig/handgestrickt. Eine andere Möglichkeit, die wir im Angebot haben, ist das Hochfahren einer temporären PostgreSQL-Datenbank. In diese wird dann mit GRETL die angebotene Shapedatei der Amphibienlaichgebiete importiert. Das Setup ist aber so, dass wir zur Shapedatei ein «Dummy-INTERLIS-Modell» schreiben müssen, um die Tabellen in der DB zu erstellen. Finde ich immer bisschen aufwändig für etwas, was eigentlich nicht von dauerndem Interesse ist. Und genau hier kommt eben ili2duckdb ins Spiel.

DuckDB Spatial hat eine ST_Read()-Funktion im Angebot, die ein Wrapper um OGR ist. D.h. ich kann mit dieser Funktion jedes von OGR unterstützte Format via SQL in DuckDB ansprechen und verwenden:

SELECT
  *
FROM
  ST_Read('amphibLaichgebiet.shp', spatial_filter_box={min_x: 2590925, min_y: 1212325, max_x: 2645288, max_y: 1263441}::BOX_2D)

Das Tüpfelchen auf dem I wäre, wenn die von Swisstopo angebotenen Zip-Dateien so gepackt wären, dass man GDALs Virtual File System verwenden könnte. Dann müsste man die Dateien nicht mal mehr herunterladen:

ogrinfo -ro -al -so /vsizip/vsicurl/https://data.geo.admin.ch/ch.bafu.bundesinventare-amphibien/data.zip

Als Beweis, dass das gehen würde:

ogrinfo -ro -al -so /vsizip/vsicurl/https://files.geo.so.ch/ch.so.afu.abbaustellen/aktuell/ch.so.afu.abbaustellen.shp.zip

Das Ultra-Tüpfelchen wären natürlich Cloud Native Formate…

Zusammengefasst heisst das: Ich habe mit DuckDB eine dateibasierte Datenbank, die Geoprocessing und INTERLIS unterstützt. Es gibt mit dieser Variante viel weniger Overhead und Komplexität: kein Datenmodell für Wegwerf-Daten, kein Dockercontainer, der gestartet werden muss.

Ein kleines INTERLIS-Datenmodell wird benötigt, um das Wissen zu speichern, welche Gemeinde von welchem Thema betroffen ist. Ad hoc sieht das etwa so aus:

INTERLIS 2.3;

/** !!------------------------------------------------------------------------------
 *  !! Version    | wer | Änderung
 *  !!------------------------------------------------------------------------------
 *  !! 2024-12-27 | sz  | Initialerstellung
 *  !!==============================================================================
 */
!!@ technicalContact=mailto:agi@bd.so.ch
!!@ furtherInformation=https://geo.so.ch/models/ARP/SO_ARP_SEin_Konfiguration_20241227.uml
!!@ shortDescription="Datenmodell für die (Teil-)Konfiguration der SEin-App"
!!@ title="SEin-App Konfiguration"
MODEL SO_ARP_SEin_Konfiguration_20241217 (de)
AT "https://arp.so.ch"
VERSION "2024-12-27"  =

  TOPIC SEin =

    CLASS Gruppe =
      Name : MANDATORY TEXT*500;
    END Gruppe;

    CLASS Thema =
      Name : MANDATORY TEXT*500;
      Karte : TEXT*500; !! Eigentlich Layer-ID
      !! TODO: Transparenz
    END Thema;

    CLASS Gemeinde =
      Name : MANDATORY TEXT*200;
      BFSNr : MANDATORY 2000 .. 3000;
      UNIQUE BFSNr;
    END Gemeinde;

    ASSOCIATION Gruppe_Thema =
      Gruppe_R -- {1} Gruppe;
      Thema_R -- {0..*} Thema;
    END Gruppe_Thema;

    ASSOCIATION Thema_Gemeinde =
      Thema_R -- {0..*} Thema;
      Gemeinde_R -- {0..*} Gemeinde;
      ist_betroffen : BOOLEAN;
    END Thema_Gemeinde;

  END SEin;

END SO_ARP_SEin_Konfiguration_20241217.

Der Prozess (aka GRETL-Job) sieht circa so aus:

DuckDB-Datei mit Konfigurations-INTERLIS-Datenmodell erstellen.
Hoheitsgrenzen importieren (z.B. von hier)
Pro Gemeinde einen Eintrag in der Klasse Gemeinde erstellen.
Loop über alle Gemeinden und prüfen, ob ein Amphibienlaichgebiet innerhalb der Gemeinde liegt und Eintrag in die Beziehungstabelle (Thema_Gemeinde) erstellen.

Der relevante Teil des GRETL-Jobs sieht wie folgt aus:

tasks.register('downloadAmphibien', Download) {
    src "https://data.geo.admin.ch/ch.bafu.bundesinventare-amphibien/data.zip"
    dest pathToTempFolder
    overwrite true
}

tasks.register('unzipAmphibien', Copy) {
    dependsOn 'downloadAmphibien'
    from zipTree(Paths.get(pathToTempFolder, "data.zip"))
    into file("$rootDir")
    include "*LV95*/*.shp"
    include "*LV95*/*.dbf"
    include "*LV95*/*.shx"
}

tasks.register('processInit', SqlExecutor) {
    database = [dbUri, dbUser, dbPwd]
    sqlFiles = ["delete.sql"]
}

def gemeinden = [2401,2402,2403,2404,2405,2406,2407,2408,2421,2422,2424,2425,2426,2427,2428,2430,2445,2455,2457,2461,2463,2464,2465,2471,2472,2473,2474,2475,2476,2477,2478,2479,2480,2481,2491,2492,2493,2495,2497,2499,2500,2501,2502,2503,2511,2513,2514,2516,2517,2518,2519,2520,2523,2524,2525,2526,2527,2528,2529,2530,2532,2534,2535,2541,2542,2543,2544,2545,2546,2547,2548,2549,2550,2551,2553,2554,2555,2556,2571,2572,2573,2574,2575,2576,2578,2579,2580,2581,2582,2583,2584,2585,2586,2601,2611,2612,2613,2614,2615,2616,2617,2618,2619,2620,2621,2622]

gemeinden.each { gemeinde ->
    tasks.register("processGemeinde_$gemeinde", SqlExecutor) {
        dependsOn 'processInit'
        database = [dbUri, dbUser, dbPwd]
        sqlFiles = ["gemeinde.sql", "amphibien.sql"]
        sqlParameters = [bfsnr: gemeinde as String]
    }
}

task processAll() {
    description = "Sql aggregation task."
    dependsOn {
        tasks.findAll { task -> task.name.startsWith('processGemeinde_') }
    }
}

Die eigentliche Businesslogik (Ist die Gemeinde betroffen? Abfüllen der Konfig-Tabellen.) passiert in SQL:

LOAD spatial;

CREATE TEMP TABLE t_betroffen AS
WITH gemeinde AS
(
    SELECT
        g2.t_id AS gemeinde_t_id,
        gemeindename,
        bfs_gemeindenummer,
        geometrie
    FROM
        agi_hoheitsgrenzen_pub.hoheitsgrenzen_gemeindegrenze AS g1
        INNER JOIN sein_konfig.sein_gemeinde AS g2
        ON g1.bfs_gemeindenummer = g2.bfsnr
    WHERE
        bfs_gemeindenummer = ${bfsnr}
)
,
themadaten AS
(
    SELECT
        ST_Multi(geom) AS geom
    FROM
    ST_Read('Amphibien_LV95/amphibLaichgebiet.shp', spatial_filter_box={min_x: 2590925, min_y: 1212325, max_x: 2645288, max_y: 1263441}::BOX_2D)

)
,
thema AS
(
    SELECT
        t_id AS thema_t_id
    FROM
        sein_konfig.sein_thema
    WHERE
        karte = 'ch.bafu.bundesinventare-amphibien'
)
,
betroffen AS
(
    SELECT
        gemeinde.gemeinde_t_id,
        gemeinde.gemeindename,
        gemeinde.bfs_gemeindenummer,
        ist_betroffen,
        thema.thema_t_id
    FROM
    (
        SELECT
            count(*) > 0 AS ist_betroffen
        FROM
            gemeinde
            INNER JOIN themadaten
            ON ST_Overlaps(gemeinde.geometrie, themadaten.geom)
    ) AS foo
    LEFT JOIN gemeinde
    ON 1=1
    LEFT JOIN thema
    ON 1=1
)
SELECT
    *
FROM
    betroffen
;

INSERT INTO sein_konfig.sein_thema_gemeinde
(
    thema_r,
    gemeinde_r,
    ist_betroffen
)
SELECT
    thema_t_id,
    gemeinde_t_id,
    ist_betroffen
FROM
    t_betroffen
;

DROP TABLE
    t_betroffen
;

Die Idee ist, dass die Klassen «Gruppe» und «Thema» durch das Fachamt in der zentralen Datenbank nachgeführt werden. Der GRETL-Job exportiert die Daten aus der zentralen Datenbank und importiert sie in die DuckDB-Datei (siehe Punkt 1 oben). Natürlich muss das SQL angepasst werden oder der GRETL-Job, wenn z.B. ein neues Thema hinzukommmt. Übrigens: Eleganter wäre, wenn wir die Klassen in unterschiedliche Topics packen würden. Dann kann ich beim Re-Import nur das «Gemeinde»-Topic berücksichtigen.

Es gibt mit DuckDB vielleicht sogar noch eine weniger aufwändige Variante. Man kann aus DuckDB PostgreSQL direkt ansprechen und auch Daten zurückschreiben. Somit müsste ich nicht einmal das INTERLIS-Modell in DuckDB erstellen, sondern könnte direkt mit PostgreSQL kommunizieren.

DuckDB, the next big thing, das FME-Boomer alt aussehen lässt.

Links:

ili2duckdb-5.2.2-SNAPSHOT.zip

INTERLIS leicht gemacht #44 - ilishaper: shape your xtf

Mon, 18 Nov 2024 00:00:00 +0000

It’s finally here: ilishaper Version 1.0. Kurze Rekapitulation, wozu brauchen wir ilishaper? Die meisten unserer Daten sind öffentlich und frei verfügbar. Einige Themen beinhalten nicht-öffentliche Informationen. Das kann z.B. der Name einer Person sein oder ihre Telefonnummer. Diese Informationen sind nicht für die Öffentlichkeit bestimmt und nur für den internen Gebrauch resp. für berechtigte Personen gedacht. Im Kartendienst haben wird das applikatorisch gelöst: Wir veröffentlichen die Datenbanktabelle einfach zwei Mal. Einmal mit den geschützten Attributen für interne resp. angemeldete Benutzer und einmal ohne die geschützten Attribute für die Öffentlichkeit. Aber wir sind jedoch noch nicht in der Lage, den Datensatz als Datei zu veröffentlichen. Wir hatten zuerst einen Ansatz mit Vererbungen im INTERLIS-Modell verfolgt. Das erwies sich aber als zu kompliziert. Und hier kommt nun ilishaper ins Spiel. Die Idee ist folgende:

Wir erstellen zuerst nur ein flaches Publikationsdatenmodell mit allen Attributen (also auch den nicht-öffentlichen). Dieses Modell verwenden wir, um die Datenbanktabellen zu erstellen, welche z.B. der Kartendienst verwendet. Die Daten werden bei einer Publikation des Themas in eine XTF-Datei exportiert. Was wir jetzt benötigen ist eine Software, die aus dem Basismodell ein Derivatmodell ohne die nicht-öffentlichen Attribute erzeugt und aus der XTF-Daten entsprechend eine zusätzliche XTF-Datei ohne die nicht-öffentlichen Attribute erstellt (gemäss Derivatmodell). Das Derivatmodell muss natürlich nur einmalig erstellt werden und kann in ein INTERLIS-Repository eingecheckt werden.

Schauen wir uns ein Beispiel an. Gegeben das folgende Datenmodell:

INTERLIS 2.3;

MODEL SO_ALW_Bienenstandorte_restricted_20241113 (de)
AT "https://alw.so.ch"
VERSION "2024-11-13"  =
  IMPORTS GeometryCHLV95_V1;

  TOPIC Bienenstandorte =
    OID AS INTERLIS.UUIDOID;

    /** Bienenstandort
     */
    CLASS Bienenstandort =
      /** Nummer
       */
      Nummer : MANDATORY TEXT*16;
      /** Honigsorte
       */
      Honigsorte : (
        Bluetenhonig,
        Waldhonig
      );
      /** Standort
       */
      Standort : MANDATORY GeometryCHLV95_V1.Coord2;
      /** Bemerkung
       */
      Bemerkung : TEXT*200;
      /** Name des Imkers
       */
      Name : MANDATORY TEXT*255;
      /** Telefonnummer
       */
      Telefonnummer : TEXT*20;
    END Bienenstandort;

  END Bienenstandorte;

END SO_ALW_Bienenstandorte_restricted_20241113.

Die letzten beiden Attribute Name und Telefonnummer sind nicht-öffentlich und dürfen im Derivatmodell nicht mehr vorkommen. Für die Konfiguration von ilishaper wird eine ini-Datei benötigt, die ziemlich selbsterklärend sein sollte:

[SO_ALW_Bienenstandorte_restricted_20241113]
name=SO_ALW_Bienenstandorte_20241113
issuer=https://alw.so.ch
version=2024-11-13
doc=Datenmodell für die Bienenstandorte mit öffentlichen Daten

[SO_ALW_Bienenstandorte_restricted_20241113.Bienenstandorte.Bienenstandort.Name]
ignore=true

[SO_ALW_Bienenstandorte_restricted_20241113.Bienenstandorte.Bienenstandort.Telefonnummer]
ignore=true

Mit dem folgenden Befehl kann man das Derivatmodell erstellen lassen:

java -jar ilishaper-1.0.1.jar --createModel --config bienenstandorte.ini --modeldir ".;https://models.geo.admin.ch" --out SO_ALW_Bienenstandorte_20241113.ili SO_ALW_Bienenstandorte_restricted_20241113.ili

Das Derivatmodell sieht aus wie gewünscht:

INTERLIS 2.3;

/** Datenmodell für die Bienenstandorte mit öffentlichen Daten
 */
MODEL SO_ALW_Bienenstandorte_20241113 (de)
  AT "https://alw.so.ch"
  VERSION "2024-11-13"
  =
  IMPORTS GeometryCHLV95_V1;

  TOPIC Bienenstandorte =

    /** Bienenstandort
     */
    CLASS Bienenstandort =
      /** Nummer
       */
      Nummer : MANDATORY TEXT*16;
      /** Honigsorte
       */
      Honigsorte : (
        Bluetenhonig,
        Waldhonig
      );
      /** Standort
       */
      Standort : MANDATORY GeometryCHLV95_V1.Coord2;
      /** Bemerkung
       */
      Bemerkung : TEXT*200;
    END Bienenstandort;

  END Bienenstandorte;

END SO_ALW_Bienenstandorte_20241113.

Aber Achtung: Es sieht wahrscheinlich nur auf den ersten Blick so aus wie gewünscht. Es fehlt OID AS INTERLIS.UUIDOID. Warum das aber korrekt ist, steht hier.

Wenn wir das Derivatmodell haben, können wir in meinem Testdatensatz mit drei Bienenstandorten die nicht-öffentlichen Attribute gemäss Derivatmodell «abstreifen» und eine neue XTF-Datei erstellen lassen:

java -jar ilishaper-1.0.1.jar --deriveData --config bienenstandorte.ini --modeldir ".;https://models.geo.admin.ch" --out bienenstandorte.xtf bienenstandorte_restricted.xtf

Et voilà: Die resultierende XTF-Datei hat kein Name-Attribut und kein Telefonnummer-Attribut.

Aber ilishaper kann noch mehr. Wir haben zusätzlich die Anforderung, dass wir neben Spalten (Attribute) auch Zeilen filtern können. Nehmen wir an, dass die Öffentlichkeit nur die Bienenstandorte, die Blütenhonig produzieren, kennen darf. Dazu müssen wir die ini-Datei erweitern:

[SO_ALW_Bienenstandorte_restricted_20241113]
name=SO_ALW_Bienenstandorte_20241113
issuer=https://alw.so.ch
version=2024-11-13
doc=Datenmodell für die Bienenstandorte mit öffentlichen Daten

[SO_ALW_Bienenstandorte_restricted_20241113.Bienenstandorte.Bienenstandort.Name]
ignore=true

[SO_ALW_Bienenstandorte_restricted_20241113.Bienenstandorte.Bienenstandort.Telefonnummer]
ignore=true

[SO_ALW_Bienenstandorte_restricted_20241113.Bienenstandorte.Bienenstandort]
filter="Honigsorte==#Bluetenhonig"

Die beiden letzten Zeilen sind dazugekommen. Erlaubt sind Expressions wie z.B. bei einem Mandatory-Constraint. Der Ausdruck muss jedoch pro Objekt auswertbar sein und darf also keine Rollen oder Referenzattribute enthalten. Das Derivatmodell müssen wir nicht mehr erstellen, da sich an diesem nichts ändert. Ein nochmaliger Aufruf für das Erstellen der XTF-Datei:

java -jar ilishaper-1.0.1.jar --deriveData --config bienenstandorte.ini --modeldir ".;https://models.geo.admin.ch" --out bienenstandorte_filter.xtf bienenstandorte_restricted.xtf

Der Konsolenoutput verrät uns bereits, dass nur noch zwei Objekte in der neuen XTF-Datei vorhanden sind:

Info: bienenstandorte_restricted.xtf: SO_ALW_Bienenstandorte_restricted_20241113.Bienenstandorte BID=SO_ALW_Bienenstandorte_restricted_20241113.Bienenstandorte
Info:       3 objects in CLASS SO_ALW_Bienenstandorte_restricted_20241113.Bienenstandorte.Bienenstandort
Info: bienenstandorte_filter.xtf: SO_ALW_Bienenstandorte_20241113.Bienenstandorte BID=1
Info:       2 objects in CLASS SO_ALW_Bienenstandorte_20241113.Bienenstandorte.Bienenstandort
Info: ...conversion done

Ein Blick in die neue XTF-Datei bestätigt dies.

Sämtliche Dateien zum Rumspielen stehen hier zum Download bereit.

INTERLIS leicht gemacht #43 - ilivalidator JVM-Benchmarking (revisited)

Sun, 20 Oct 2024 00:00:00 +0000

Angespornt durch mein GeoServer-Benchmarking wollte ich ein weiteres Mal das Verhalten von ilivalidator mit verschiedenen JVM-Varianten unter die Lupe nehmen. Gibt es irgendwelche Kombinationen von JVM-Version, RAM-Zuteilung, Garbage-Collector, die besonders schnell oder langsam sind?

Für das Benchmarking habe ich die Nutzungsplanung des Kantons Thurgau verwendet. Diese ist als einzelne XTF-Datei auf geodienste.ch bereitgestellt und hat darum eine entsprechende Grösse und ilivalidator hat einiges zu rechnen. Letztes Mal habe ich noch INTERLIS-1-Datensätze geprüft. Das lasse ich sein, das sollte langsam Geschichte sein.

Als Hardware dient mir der Dedicated-vCPU-Server aus dem GeoServer-Benchmarking mit 32 GB RAM und 16 Kernen, wobei die Anzahl Kerne für dieses Benchmarking nebensächlich ist.

Mit einem JBang-«Java-Skript» prüfe ich 100 Mal die Transferdatei inkl. Katalog und schreibe die benötigte Zeit in Sekunden in die Konsole:

///usr/bin/env jbang "$0" "$@" ; exit $?
//REPOS mavenCentral,ehi=https://jars.interlis.ch/
//DEPS ch.interlis:ilivalidator:1.14.3

import org.interlis2.validator.Validator;
import ch.ehi.basics.settings.Settings;

import static java.lang.System.*;

import java.text.SimpleDateFormat;
import java.util.Date;

public class run_ilivalidator {

    public static void main(String... args) {
        SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS");

        long startTime = System.currentTimeMillis();
        Date startDate = new Date(startTime);
        out.println("Start Time: " + dateFormat.format(startDate));

        Settings settings = new Settings();
        settings.setValue(Validator.SETTING_ALL_OBJECTS_ACCESSIBLE, Validator.TRUE);
        settings.setValue(Validator.SETTING_ILIDIRS, ".");

        for (int i=0; i<100; i++) {
            boolean valid = Validator.runValidation(new String[] {"Nutzungsplanung_Catalogue_CH_V1_2_20210901.xml", "Nutzungsplanung_LV95_V1_2.xtf"}, settings);
        }

        long endTime = System.currentTimeMillis();
        Date endDate = new Date(endTime);
        System.out.println("End Time: " + dateFormat.format(endDate));

        long timeTaken = endTime - startTime;
        out.println("Time taken: " + timeTaken / 1000 + " seconds");
    }
}

Die INTERLIS-Datenmodelle lagen alle lokal vor und es mussten keine Requests zu anderen Repos gemacht werden. Die 100-fache Ausführung (= 100 x ~40s) der Validierung innerhalb der gleichen JVM sollte vorhandene Performanceunterschiede hervorheben. Für jede verwendete JVM habe ich den Benchmark 4 Mal durchgeführt. Verwendet wurden folgende JVM:

GraalVM 23
GraalVM 21
GraalVM 17
OpenJDK 21
OpenJDK 17
OpenJDK 11
OpenJDK 8

Das Resultat habe ich in einem Matplotlib-Chart zusammengestellt. Eigentlich wollte ich bloss Punkte zeichnen, das habe ich jedoch nicht hingekriegt. Darum gibts jetzt pseudo-wissenschaftliche Boxplots:

Es scheint als gäbe es einen klaren Gewinner in meinem Testszenario: GraalVM mit ParallelGC. Wobei man davon ausgehen kann, dass ab OpenJDK 21 und GraalVM 17 alle gleich aufliegen (auch mit ParallelGC). Interessant ist die Verschlechterung von OpenJDK bis zur Version 17.

Die JVM verwendete die Hälfte des vorhandenen RAM: 16 GB. Ich habe die Variante GraalVM 21 (ParallelGC) mit 4 GB Heap laufen lassen und komme auf ein minimal schlechteres Resultat. Der Versuch mit 2 GB war nicht erfolgreich und führte zu Out of Memory Fehlern. Der RAM-Verbrauch ist relativ gering, steigt jedoch rapide an bei AREA-Validierungen (soweit meine Beobachtung).

Eine allgemein gültige Empfehlung ist schwierig anhand dieses Testes. Letztes Mal hat INTERLIS 1 eine leicht andere Resultatcharakteristik gezeigt als INTERLIS 2. Eventuell führen stark unterschiedliche Datensätze (viele oder wenig Geometrien, AREA- oder keine AREA-Prüfung, viele oder wenig Constraints) zu unterschiedlichen Resultaten. Aber bis auf weiteres würde ich (für institutionaliserte Betreiber) eine aktuelle JVM empfehlen (ab 21) und ParallelGC.

Links:

https://github.com/edigonzales/ilivalidator-benchmark

Documentation as Code

Thu, 17 Oct 2024 00:00:00 +0000

Documentation as Code: Und zwar in zweifacher Hinsicht. Einerseits will ich Dokumentation wie Code behandeln und andererseits steckt ein Grossteil der Informationen, die ich in der Dokumentation haben will, direkt beim Quellcode (also eher from Code). Konkret geht es um die GRETL-Dokumentation. Zu Beginn gab es «nur» die Referenzdokumentation als einzelne Markdown-Datei im GRETL-Git-Repository. Diese wird manuell nachgeführt. Es gibt eine Beschreibung des Tasks, die erklären soll für was der Task verwendet werden kann, gefolgt von Beispielen und der Auflistung sämtlicher für den Benutzer relevanten Properties (also z.B. der Name der Datei, die man mit ilivalidator geprüft haben will) in einer Tabelle. Die Tabelle besteht aus Propertyname und Beschreibung (ggf. noch mit Defaultwert). Letztes Jahr folgte die Webseite gretl.app, die neben weiteren Informationen auch die Referenzdokumentation beinhaltet. Die Webseite ist mit Quarto gemacht und wird in einem von GRETL separaten Github-Repository vorgehalten. Das führt jetzt natürlich zum Problem, dass die Referenzdokumentation an zwei Orten vorgehalten wird und erst noch händisch nachgeführt werden muss. Aus dem Code-Repository möchte ich die Referenzdokumentation nicht entfernen, aber den Webseiten-Code auch nicht ins Code-Repository migrieren. Ein weiteres Problem ist das händische Nachführen der Referenzdokumentation. Die Prosabeschreibung des Tasks und die Beispiele tuen mir nicht weh, jedoch schmerzt mich die Tabelle mit den Properties, da diese Information bereits (fast vollständig) im GRETL-Quellcode bei den Custom Tasks vorhanden ist. Ausserdem stört mich, dass der Datentyp in der Tabelle nicht ersichtlich ist, ebenso fehlt die Information, ob ein Property optional ist oder nicht.

Für letzteres (technisches) Problem hatte ich relativ schnell eine Idee: Mit Javadoc gibt es ein Werkzeug, dass aus den Java-Quelltexten automatisch HTML-Output generiert. Dazu gibt es ein Doclet API mit dem man eigene sogenannte Doclets schreiben kann und so Informationen aus den Java-Quelltexten in beliebige Formate schreiben kann. Die Idee war nun, dass ich mir ein Doclet schreibe, dass die Task-Properties in eine Markdown-Tabelle schreibt. Diese Markdown-Tabelle (pro Task) referenziere ich als externe Quelle im «Rahmen-Referenzdokumentations-Markdown» (mit der Prosa-Beschreibung und den Beispielen) und generiere so die fertige Referenzdokumentation resp. Webseite.

Das Doclet zu implementieren war nicht allzu schwierig. Trotzdem gab es eine Herausforderung zu meistern: Eigentlich ist sonnenklar, was von der Java-Klasse (welche den Task implementiert) in der Tabelle landen soll. Nämlich die Properties, die für den Anwender später relevant sind (wieder das Beispiel mit dem Namen der Datei, die geprüft werden soll). Die Java-Klasse (weil vererbt) hat noch viele andere Properties resp. Fields und Methoden, die für meinen Anwendungsfall nicht relevant sind. Im einfachsten Fall sieht der Quellcode eines Custum-Gradle-Tasks so aus:

public class S3Download extends DefaultTask {
    /**
    * AWS Access Key
    */
    @Input
    public String accessKey;

    @Input
    public String secretKey;

    @Input
    public String bucketName;

    @Input
    public String key;

    @OutputDirectory
    public File downloadDir;

    @Input
    @Optional
    public String endPoint = "https://s3.eu-central-1.amazonaws.com";

    @Input
    public String region = "eu-central-1";

    @TaskAction
    public void upload() {
        // do something
    }
}

Man sieht, dass die Properties annotiert sind. Man findet dank den Annotationen genau die Properties, die man will. Hat das Property einen Kommentar, kann man auch diesen mit der Doclet-API auslesen. Leicht komplizierter wird es, weil es auch noch weitere Arten gibt einen Task zu schreiben:

public class S3Upload extends DefaultTask {
    private String accessKey;
    private String secretKey;
    private Object sourceDir;
    private Object sourceFile;
    private Object sourceFiles;
    private String bucketName;
    private String endPoint = "https://s3.eu-central-1.amazonaws.com";
    private String region = "eu-central-1";
    private String acl = null;
    private String contentType = null;
    private Map<String,String> metaData = null;

    /**
    * AWS Access Key
    */
    @Input
    public String getAccessKey() {
        return accessKey;
    }

    @Input
    public String getSecretKey() {
        return secretKey;
    }

    public void setAccessKey(String accessKey) {
        this.accessKey = accessKey;
    }

    public void setSecretKey(String secretKey) {
        this.secretKey = secretKey;
    }
    ...

Die Annotationen stehen bei dieser Variante nicht mehr bei den Properties, sondern bei der Getter-Methode. Eine dritte Variante kennt gar keine Properties (im Quellcode) mehr, sondern es wird nur noch ein abstrakter Getter geschrieben:

public abstract class S3Upload extends DefaultTask {
    /**
    * AWS Access Key
    */
    @Input
    public abstract Property<String> getAccessKey();

    @Input
    public abstract Property<String> getSecretKey();
    ...

Das Doclet muss mit diesen Varianten umgehen können und als Produkt sowas ausspucken:

Parameter | Datentyp | Beschreibung | Optional
----------|----------|-------------|-------------
accessKey | `Property<String>` | AWS Access Key | nein
secretKey | `Property<String>` |  | nein

Das Doclet-Proof-of-Concept liefert und ich kann die Markdown-Tabellen in Quarto einbinden. Das löst das technische Problem.

Das organisatorische Problem (wo liegt welcher Code?) ist mit dem Doclet noch nicht gelöst. Für die Lösungfindung kommt erschwerend hinzu, dass ich auch die Dokumentation verschiedener GRETL-Versionen greifbar haben will. Wir verwenden bei uns häufig zwei Versionen parallel und für diese möchte ich die korrekte Dokumentation bereitstellen. Nach ein paar schlechten Lösungen bin ich glaub auf die bisher beste Variante gestossen:

Die Referenzdokumentation verbleibt originär im GRETL-Repository. Das Release-Management von GRETL sieht vor, dass jeder Commit (in bestimmen Branches) zu einem Release führt. Die vollständige Version (major.minor.patch) von GRETL ist nur innerhalb der Pipeline (Github Action) bekannt, da die Patch-Nummer der Job-Run-Nummer entspricht (was aber auch nicht super genial ist, da diese nicht ewig stabil ist). D.h. dass während eines GRETL-Builds die Referenzdokumentation hergestellt wird, zuerst mit Javadoc die Markdown-Tabellen, anschliessend wird mit Quarto eine einzelne HTML-Seite hergestellt. Jede Version dieser HTML-Seite wird irgendwohin deployed (z.B. S3). So in etwa wie docs.interlis.ch (leicht anderes CSS, verprochen):

Die Webseite gretl.app zeigt weiterhin nur eine Version und wird auch weiterhin in einem separaten Repo verwaltet. Die Pipeline, welche die Webseite herstellt, wird nur bei Bedarf (manuell) ausgelöst (oder z.B. aus dem main-Branch von GRETL getriggert). Die Pipeline muss auch den GRETL-Quellcode auschecken und die Referenzdokumentation als Teil der Webseite herstellen.

Soweit meine Idee zur Organisation. Gibt es weitere Vorschläge?

GeoServer on steroids

Tue, 15 Oct 2024 00:00:00 +0000

Ich mag GraalVM. Sei es um Java-Anwendungen zu einem Native Image runterzukompilieren oder Python mit Java zu verheiraten. Ein weiterer spannender Punkt ist der eigene Graal JIT Compiler. Dieser kann zu einer Performancesteigerung der Java-Anwendung führen und zwar ohne, dass man an dieser überhaupt was ändern muss. Nur die Runtime («Java-Variante») austauschen und gut ist. So hat der Wechsel zum Graal JIT Compiler z.B. bei der 1BRC eine Performancesteigerung von acht Prozent gebracht. Bei mir selber habe ich solche Unterschiede noch keine festgestellt. Vor ein paar Jahren habe ich mit ilivalidator und ili2pg ein paar Benchmarks gemacht, die aber nicht sonderlich aussagekräftig waren und nicht gezeigt hätten, dass GraalVM bedeutend schneller ist. Weil wir uns zur Zeit überlegen von QGIS Server auf GeoServer zu wechseln, wäre das jedenfalls ein Anwendungfall, den man untersuchen könnte, da der Server zu Bürozeiten relativ stark beansprucht wird und somit eine genügend hohe Dauerlast besteht. Obwohl wir bereits heute viele Java-Anwendungen in Betrieb haben, hat keine davon eine ähnliche Last zu tragen wie ein möglicher, zukünftiger Java-Kartendienst.

Nun benötige ich ein Testszenario, das aus mehr als bloss vier Flächen und zwei Punkten besteht. Ich habe mich dazu entschieden die Nutzungsplanung und ein Orthofoto (swissimage 2021) zu verwenden. Die Nutzungsplanung steht als Vektordatensatz in einzelnen INTERLIS-Transferdateien zur Verfügung, die ich ruckzuck mit GRETL in eine gedockerte PostgreSQL/PostGIS-Datenbank importieren kann. Die SLD-Datei hatte ich noch von früheren Spielereien rumliegen:

Das Orthofoto liegt als 30 GB grosses cloud optimized GeoTIFF lokal vor:

Für das eigentliche Benchmarking verwendete ich JMeter. Man definiert in JMeter sowas wie eine Basis-URL (also in unserem Fall einen WMS-GetMap-Request) mit Platzhaltern für die Parameter (WIDTH, HEIGHT, BBOX und LAYERS), die bei jedem von JMeter gemachten Request dynamisch befüttert werden. Die Werte für die Platzhalter können in einer CSV-Datei gespeichert werden:

width;height;bbox;layer
2102;2119;2605738.274269104,1236815.4005975279,2605773.134554806,1236850.5428170345;ch.swisstopo.swissimage_2021.rgb
3308;1924;2619968.8471599706,1256153.9242204945,2632686.446437572,1263550.7383106109;ch.swisstopo.swissimage_2021.rgb
3320;1896;2610788.4627983514,1256404.5859801334,2617948.8869838137,1260493.7920812287;ch.swisstopo.swissimage_2021.rgb
3470;1797;2634212.7299694223,1248533.8556387443,2641987.561823341,1252560.1878697216;ch.swisstopo.swissimage_2021.rgb
1972;2126;2592921.414637569,1242392.7718350205,2601610.971095325,1251760.9244867398;nutzungsplanung_grundnutzung
3391;1803;2597536.2772151744,1211156.517151424,2632904.225935421,1229961.7107646957;ch.swisstopo.swissimage_2021.rgb
3551;1134;2604904.606863846,1237243.4070413096,2623471.839928261,1243172.7909599373;nutzungsplanung_grundnutzung
...

Wie habe ich die CSV-Datei mit Random-Werten hergestellt? Als Grundlage diente mir ein Python-Skript von den legendären FOSS4G Performance Shoot-outs. Das Skript hat verschiedene Parameter mit dem man den Output steuern kann: So ist es möglich einen Range für WIDTH und HEIGHT anzugeben und die übergeordnete Region, in der die BBOX der einzelne GetMap-Requests liegen sollen. Zusätzlich lässt sich ein Auflösungsrange angeben, was nichts anderes ist als Massstabsbereiche. Als letztes Zückerchen kann man eine Shapedatei angeben, um sicherzustellen, dass die berechnete Bounding Box entweder komplett innerhalb der Shapefilegeometrien liegt oder diese mindestes schneidet (intersects), was in unserem Fall sinnvoll ist, da ich keine Requests will, die ins Leere zeigen. Für diese Geometrieoperationen verwendet das Python-Skript Bindings für OGR/GDAL. Das war mir ein (Installations-)Graus. Ich habe das Skript ChatGPT geschickt mit der Bitte um eine Umwandlung nach GeoScript Groovy. Das hat sogar halbwegs gut funktioniert und weil es für GeoScript eine Uber Jar gibt, ist die Installation nur ein Download dieser Jar-Datei. Der Aufruf des Skriptes ist simpel: java -jar geoscript-groovy-app-1.22.0.jar script wms_requests.groovy. Maximal so kompliziert sollte «geo-scripting» sein. Dünkt mich angenehmer als Python-Bindings installieren und auf Teufel komm raus die passenden OGR/GDAL-Libs (mit Conda oder dergleichen).

Ich habe mich dazu entschieden, dass ich für WIDTH und HEIGHT einen Range von 3840x2160 Pixel und 1920x1080 Pixel und einen Massstab von circa 1:350'000 bis 1:350 zulasse. Da ich nur zwei Layer zur Auswahl habe, wählt das Skript wahlweise einen der beiden aus und schreibt ihn in die CSV-Datei.

Bei der Hardware habe ich mich für Hetzner-Server entschieden. Ich habe die Benchmarks auf zwei unterschiedlichen Servern durchgeführt. Einmal auf einem Server mit shared vCPU und einmal mit dedicated vCPU. Shared bedeutet, dass die vCPU mit anderen VM geteilt wird. Mit wie vielen ist nicht klar. Bei den VM mit dedicated vCPU muss sich die VM die vCPU nicht mit anderen teilen. Die Preise sind entsprechend sehr unterschiedlich. Ich habe mich jeweils für 16 Kerne und 32 GB RAM entschieden. Die Shared-Variante (ARM-Prozessoren) kostet 26.70 Euro, die Dedicated-Variante 103.77 Euro (pro Monat). Also viermal so viel.

Die Datenbank läuft gedockert auf der gleichen VM. GeoServer (2.26.0) läuft ungedockert in Tomcat. Bezüglich CPU-Zuweisung habe ich weder bei der Datenbank noch bei GeoServer etwas gemacht. Tomcats Heap Memory habe ich beim Start resp. als Maximum auf 4GB beschränkt.

Den Benchmark habe ich mit 2, 4, 8, 12 und 16 Threads laufen lassen. Er sollte unbedingt nicht im GUI gestartet werden, sondern in der Konsole, z.B.:

./bin/jmeter -n -t benchmark.jmx  -l graal-17-g1gc-v1.jtl -e -o graal-17-g1gc-v1

Der Befehl erzeugt einen HTML-Report mit allerlei Grafiken. Leider ist mir zu spät in den Sinn gekommen, dass ich v.a. the Throughput auch gerne als Daten hätte, damit ich sie gemeinsam in einem Diagramm darstellen kann. So bleiben mir nur die automatisch generierten Grafiken pro Run, die man halt visuell vergleichen muss.

Getestet habe ich folgende Java-/GraalVM-Versionen:

GraalVM 17
GraalVM 21
OpenJDK 11
OpenJDK 17

Auf der Dedicated-vCPU-VM habe ich den Benchmark für jede Version vier Mal laufen lassen. Zusätzlich kommen noch Varianten mit unterschiedlichen Garbage Collector (G1GC vs ParallelGC) hinzu. Auf der Shared-vCPU-VM habe ich nicht im gleichen Umfang getestet.

Und finally habe ich einen Anwendungsfall, bei dem GraalVM signifikant schneller ist und mehr Throughput schafft. Wobei GraalVM 17 und 21 praktisch identisch sind mit leichten Vorteilen für GraalVM 21 (visuell verglichen).

GraalVM 21 (dedicated, G1GC):

GraalVM 17 (dedicated, G1GC):

Die Sprünge zwischen der Anzahl Threads ist klar ersichtlich. Einzig beim Sprung von 12 auf 16 Threads ist mit nicht viel mehr Throughput zu rechnen.

GraalVM 17 (dedicated, ParallelGC):

Die Verwendung vom ParallelGC bringt hier (im Gegensatz zur INTERLIS-Validierung mit ilivalidator) nichts.

OpenJDK 17 (dedicated, G1GC):

Wenn GraalVM bei 16 Threads immer um die 20 requests/second pendelt, so sind es bei OpenJDK klar weniger (circa 17.5 requests/second).

OpenJDK 11 (dedicated, G1GC):

OpenJDK 11 ist praktisch identisch zu OpenJDK 17.

Interessant sind ebenfalls die Resultate der Shared-vCPU-VM.

GraalVM 17 (shared, G1GC):

OpenJDK 17 (shared, G1GC):

Einerseits zeigt sich das gleiche Bild: GraalVM vs OpenJDK. Spannend ist aber der Throughput bei 12 und 16 Threads. Da kommt GraalVM beinahe an die Resultate von OpenJDK auf der Dedicated-vCPU-VM heran. Und sowieso sind die Resultate nicht übel, wenn man bedenkt, dass man nur einen Viertel bezahlt.

Fazit: Use GraalVM! Grob geschätzt sind es 15% mehr Durchsatz. Aber Achtung: Den RAM-Verbrauch habe ich z.B. nicht angeschaut. Dazu kann ich gar keine Aussage machen.

Links:

https://github.com/edigonzales/geoserver-benchmarks/tree/main/results

AI - Behördensprache ade

Mon, 24 Jun 2024 00:00:00 +0000

«Talent borrows, Genius steals»: Das Statistische Amt des Kantons Zürich hat einen sehr interessanten Prototypen zur Vereinfachung von Texten in einfache und leichte Sprache entwickelt. (Meine Eselsbrücke: Die leichte Sprache ist noch einfacher, als die einfache Sprache.) Für mich war klar, das will ich auch ausprobieren. Was mich jedoch besonders interessiert, ist, wie gut ein frei verfügbares LLM (Llama3) die Aufgabe meistert. Das Ganze hat sich natürlich aufwändiger als geplant herausgestellt. Aber der Reihe nach:

Der ZH-Prototyp ist mit Python und Streamlit umgesetzt. Ich habe mit beidem wenig bis keine Erfahrung und darum dachte ich, dass ich den GUI-Teil schnell mit Vaadin umsetzen kann. Das eigentlich GUI ging tatsächlich schnell, es stellte sich jedoch heraus, dass die Anwendung auch noch einen beträchtlichen Teil an Businesslogik beinhaltet: Nämlich die Analyse resp. Bewertung der Texte. Letzten Endes läuft es auf die Einstufung der Texte (vorher/nachher) in ein CEFR-Level hinaus. Die Anwendung verwendet spaCy, eine NLP-Bibliothek, um bestimmte Parameter zu berechnen. Mit diesen Parametern wird anschliessend die Verständlichkeit eines Textes berechnet. Die Formel haben sie mittels eines Logistic Regression Modelles hergeleitet. Dieses spaCy-Teil gibt es natürlich nicht 1:1 in Java. Ich habe mit languagetool eine Java-Bibliothek gefunden, die ähnliche Funktionen aufweist. Verschiedene Parameter weisen beim Ausprobieren die exakt gleichen Werte aus, andere - z.B. der common word score - nicht. Soweit ich es nachvollziehen kann, liegt es daran, dass unterschiedlich «lemmatized» wird. Das führt natürlich zur Frage, ob die erwähnte Formel auch in meinem Stack stimmt. Wahrscheinlich weniger gut, als im Original. Trotzdem führt es meines Erachtens zu plausiblen und sinnvollen (leicht unterschiedlichen) Punktzahlen.

Neben dieser Analyse-Logik hat der Kanton Zürich sicher auch einiges an Zeit in die Prompts investiert, die für die guten Resultat unabdingbar sind. Auch hier: Ehre, wem Ehre gebührt.

Mein Prototyp mit Vaadin und einem Resultat mit GPT-4o:

Die Resultate dünken mich ziemlich gut. Mit GPT-4o scheint mir schneller als GPT-4 zu sein und häufiger mit Aufzählungn zu arbeiten als GPT-4.

Wie sieht es mit Llama3 aus? Die Herausforderung war eine brauchbare Testumgebung zu finden. Lokal mit meinem M1-Prozessor macht es wirklich gar keinen Spass. Ein Mitarbeiter hat auf seinem Gamer-PC mit einer RTX 4080 Super Grafikkarte gezeigt, dass die (gefühlte) Geschwindigkeit nahe an ChatGPT 4 ist. Machte ich mich also auf die Suche nach einem Cloud-Anbieter, der GPU-Rechner im Programm hat. Die wirklich grossen Hyperscaler waren mir entweder zu kompliziert (Azure, weil noch nie was gemacht mit) oder dermassen undurchschaubar im Angebot (AWS), dass ich nicht wusste, welche Instanz nun geeignet ist für meine Tests. Hetzner hat zwar einen GPU-Rechner im Angebot, jedoch mit hohen Setup-Gebühren. OVHCloud hätte zwar viele unterschiedliche GPU-Rechner im Angebot. Als Neukunde kann man diese jedoch, trotz hinterlegter Kreditkarte, nicht verwenden. Eine Anfrage wurde abgelehnt. Keine Ahnung warum. Als halber Freund von DigitalOcean bin ich über Paperspace gestolpert. Die wurden vor kurzem von DigitalOcean aufgekauft und haben GPU-Rechner im Angebot. Auch hier muss man sich mittels Ticket die Rechner freischalten lassen aber danach kann man frisch fröhlich verschiedenste GPU-Rechner auswählen.

Ich habe mich für einen Rechner mit einer Ampere A4000 Nvidia Karte für $0.76/h entschieden. Die richtige Coolen würden A100-80Gx8 für $25.44/h wählen…

Ollama installieren geht eigentlich ganz passabel, es installiert jedoch einen neuen Kernel (soweit ich es verstanden habe) und dauert darum ein Weilchen und die VM muss gerebootet werden. Anschliessend reicht:

ollama run llama3

Das startet Ollama mit Llama3 als LLM. Man muss Ollama beibringen, dass er nicht bloss auf 127.0.0.1 hören soll, sondern auf allen lokalen Interfaces. Dazu muss die Env-Variable OLLAMA_HOST=0.0.0.0 in der Datei /etc/systemd/system/ollama.service gesetzt werden. Ollama ist nun auch von extern ansprechbar (so natürlich nie in Produktion gehen). Prüfen kann man es mit curl:

curl http://74.82.28.177:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "Why is the sky blue?"
}'

Die Geschwindigkeit kann sich wirklich sehen lassen.

Wie gut funktioniert es aber mit unserem Behördensprache-ade-Tool? Die Geschwindigkeit ist trotz umfangreicherer Prompts auf GPT-4o-Niveau. Die Qualität der vereinfachten Texte ist jedoch weniger gut resp. sie erreichen nur Punktzahlen zwischen 10 und 15 (der Ausgangstext hat eine Punktzahl von 1). Das ist zwar ein wenig ernüchternd aber soweit ich es nachvollziehen konnte, ist Llama3 nicht wirklich auf die deutsche Sprache trainiert. Es gibt auf HuggingFace Llama3-basierte Modelle, die mit deutschen Token feingetuned wurden. Ob mit einem solchen Modell bessere Ergebnisse erzielt werden können, müsste man noch ausprobieren.

Nichtsdestotrotz finde ich es wichtig, dass es frei verfügbare LLM gibt. Für Organisationen werden sie spannend, wenn man «KI machen» will und keine Kompromisse beim Datenschutz und der digitalen Souveränität eingehen will/kann.

Ausprobieren:

docker run -p8080:8080 -e OPENAI_API_KEY=123456789 edigonzales/simply-simplify-language

Für Llama3 müssen die zwei Env-Variablen gesetzt werden.

Links:

Original: https://github.com/machinelearningZH/simply-simplify-language/
Shameless plug: https://github.com/edigonzales/simply-simplify-language-java/

AI - Let the journey begin

Mon, 3 Jun 2024 00:00:00 +0000

Als NVIDA-Aktionär muss ich das Thema jetzt pushen; die Investition soll sich ja lohnen. Wie jeder andere auch verwende ich hin- und wieder ChatGPT und freue mich über sinnvolle Antworten vor allem als Hilfe zum Programmieren. Der Zugang zum Thema fällt mir aber schwer: LLM, Tokens, RAG, Prompt Engineering, Fine Tuning… WTF? Um das Thema nicht nur den Luftikussen und Verkäufern zu überlassen, muss ich mich hier auch minimal schlau machen. Und wie gelingt mir das am besten? Ich brauche eine (halb-)konkrete Fragestellung und Werkzeuge, mit denen ich was anstellen kann. Welcome Spring AI und LangChain4j. Beides sind Java-Frameworks, die das Arbeiten mit den unterschiedlichsten LLM und AI-Diensten vereinfachen, in dem sie als Abstraktionsschicht dienen. Das hilft ungemein in Zeiten, in denen gefühlt jeden Tag das neue, beste LLM entsteht. Man will also das LLM austauschen können, ohne den Code ändern zu müssen. Spring AI - nomen est omen - dient vor allem im Spring-Umfeld und LangChain4j ganz allgemein im Java-Umfeld. Die konkrete Fragestellung ist jetzt nicht so originell: Ich will mit eigenen Daten arbeiten und Antworten bekommen auf Fragen wie:

Wer ist Amtschef im Amt für Raumplanung im Kanton Solothurn?
Müssen Obstkulturen in der amtlichen Vermessung aufgenommen werden?
Was sind die Rechtsgrundlagen für eine Gemeindegrenzregulierung?
Welche Eigentumsbeschränkungen gibt es auf dem Grundstück 114 in der Gemeinde Zuchwil?

Die LLM können aus verschiedenen Gründen diese Fragen meistens nicht beantworten. Entweder weil sie nicht mit diesen Daten trainiert wurden. Denke kaum, dass sie das «Das Handbuch der amtlichen Vermessung Kanton Solothurn» irgendwann zu Gesicht bekommen haben oder aber sie wurden anhand nicht mehr aktueller Daten trainiert (knowledge cut off date).

Folgende Beispiele sind mit dem gpt4-Modell durchgespielt. D.h. Informationen landen immer auf einem fremden Server. Aus diesem Grund verwende ich nur frei verfügbare Daten und mein Lieblingsbeispiel «Wem gehört das Grundstück XY in der Gemeinde YZ?» lasse ich vorderhand im Giftschrank. Möchte ja meinen Job behalten. Interessant wären in diesem Zusammenhang natürlich lokal / inhouse laufende Modelle wie z.B. llama3. Auf meinem Notebook macht das keinen Spass und die 200 Euro pro Monat für einen Hetzner-Server waren mir dann doch zu viel.

Eine einfache Variante mit eigenen Daten zu arbeiten, ist prompt stuffing. Dabei werden die Information einfach mit der Frage mitgeschickt. Ein paar Amtschefs habe ich in beispielhaft in einer Markdown-Datei erfasst:

## Bau- und Justizdepartement (BJD)

- Amt für Umwelt (AfU): Gabriel Zenklusen
- Amt für Raumplaung (ARP): Sacha Peter
- Amt für Denkmalpflege und Archäologie (ADA): Stefan Blank
- Amt für Verkehr und Tiefbau (AVT): Roger Schibler
- Hochbauamt (HBA): Guido Keune
- Motorfahrzeugkontrolle (MFK): Kenneth Lützelschwab
- Amt für Geoinformation (AGI): Stefan Ziegler

## Volkwirtschaftsdepartement (VWD)

- Amt für Landwirtschaft (ALW): Felix Schibli
- Amt für Wald, Jagd und Fischerei (AWJF): Rolf Manser
- Amt für Gemeinden (AGEM): Grolimund André
- Amt für Militär und Bevölkerungsschutz (AMB): Diego Ochsner
- Amt für Wirtschaft und Arbeit (AWA): R. Frei

## Departement des Innern (DDI)

- Amt für Gesellschaft und Soziales (AGS): Sandro Müller
- Gesundheitsamt (GESA): Peter Eberhard
- Migrationsamt: Johanna Schwegler
- Amt für Justizvollzug (AJUV): Michael Leutwyler

Diese Daten müssen irgendwie zum LLM gelangen. Dazu wird ein Prompt-Template mit Einleitung und Platzhaltern für den Kontext (aka unseren eigenen Daten) und der eigentliche Frage benötigt:

Verwende den folgenden Inhalt, um die Frage am Ende zu beantworten.
Wnn du die Antwort nicht kennst, antworte mit
"Ich kenne die Antwort leider nicht".

{context}

Frage: {question}

Mit Spring AI kann ich einen Restcontroller schreiben und aus dem Prompt-Template einen Prompt machen:

@Value("classpath:/docs/organisation-kanton-solothurn.md")
private Resource docsToStuffResource;

....

@GetMapping("/api/output/stuff/organisation")
public String getOrganisationInfo(
        @RequestParam(value = "message", defaultValue = "Wer ist Amtschef oder Amtschefin im Amt für Umwelt des Kantons Solothurn") String message
        ) {

    PromptTemplate promptTemplate = new PromptTemplate(organisationKantonSolothurnResource);
    Map<String,Object> map = new HashMap<>();
    map.put("question", message);
    map.put("context", docsToStuffResource);

    Prompt prompt = promptTemplate.create(map);
    ChatResponse response = chatClient.call(prompt);

    return response.getResult().getOutput().getContent();
}

Die Platzhalter werden mit der Frage (message-Parameter) und dem Inhalt der Markdown-Datei (docsToStuffResource) ersetzt und anschliessend wird das Ganze zu OpenAI hochgeladen und GPT-4 liefert mir die korrekte Antwort. Auch die Frage der Anzahl Departemente wird richtig beantwortet.

Was kann man machen, wenn wir nicht nur eine einzelne Markdown-Datei vorliegen haben, sondern 100 oder 1000 PDF, E-Mails, Word-Dateien etc.? Das Prinzip bleibt das gleiche, nur dass wir nicht alle Dokumente hochladen, sondern nur den (hoffentlich) relevanten Teil. Wir können/sollten aus zwei Gründen nicht alle Dokumente hochladen: Einerseits sind die sogenannten Tokens die Währung in diesem AI-Zirkus. D.h. es wird pro Input- und Output-Token abgerechnet. Es ist massiv teurer 100 PDF-Seiten hochzuladen als bloss einen Paragraphen daraus. Tokens entsprechend Wortteilen und man rechnet mit circa 1.25 Token pro Wort. Andererseits können die LLM nicht mit unendlich vielen Tokens umgehen. Hier gibt es grosse Unterschiede zwischen den LLM und die maximale Anzahl wächst ständig mit neuen Generationen der LLM.

Die Lösung für dieses Problem heisst RAG (Retrieval Augmented Generation) und Embeddings. Kann ich nicht richtig erklären, ergoogelt sich man besser. Kurzum: Unsere 1000 Dateien werden in einen Vektorstore importiert und bei einer Anfrage wird zuerst nach den zur Frage möglichst passendsten Inhalten gesucht und nur diese werden zum LLM geschickt. Vektorstores gibt es wie Sand am Meer. Spring AI hat zum rumpröbeln einen filebasierten Store, ich verwende PostgreSQL mit der pgvector-Extension. Für viele Anwendungsfälle reicht PostgreSQL wohl. Bei meinen Beispielen war die Dokumentensuche in der Datenbank jedenfalls nicht der zeitlimitierende Faktor. Spring AI bietet für den Import von Dateien verschieden Reader an. Ich habe für drei Dokumente der amtlichen Vermessung den PDF-Reader verwendet. Es handelt sich um das circa 190-seitige Handbuch der amtlichen Vermessung Kanton Solothurn, sowie um die Vermarkungsweisung und die Weisung betreffend Gemeindegrenzregulierungen. Es kann auch mal vorkommen, dass die PDF-Datei nicht gelesen werden kann oder dass komische Meldungen wegen Fonts im Log erscheinen. Warum ist mir nicht ganz klar. Entweder ist die PDF-Datei korrupt oder es liegt am PDF-Reader. Spring AI verwendet zum Lesen der PDF-Dateien Apache PDFBox und es gibt ergänzend einen Tika-Reader mit dem man alles mögliche lesen kann.

Nach dem Import, der bei mir circa zwei Minuten gedauert (dauert die Vektorberechnung so lange?) hat, sieht es in der Datenbank so aus:

Stelle ich eine Frage werden zuerst die n ähnlichsten Dokumente(-nteile) in der Datenbank gesucht. Das n darf man selber wählen. Anschliessend wird diese Information wieder in ein Prompt-Template gestopft:

Sie sind ein hilfreicher und freundlicher KI-Assistent,
der Fragen zur amtlichen Vermessung des Kantons Solothurn
beantworten kann. Verwenden Sie die Informationen aus dem
Abschnitt DOKUMENTE, um genaue Antworten zu geben.
Wenn sie unsicher sind oder die Antwort nicht im Abschnitt
DOKUMENTE zu finden ist, geben sie einfach an, dass sie
die Antwort nicht kennen.

Bitte verwenden sie in der Antwort keine "ß", sondern "ss".

FRAGE:
{input}

DOKUMENTE:
{documents}

Anhand der Metadaten (siehe Spalte metadata in der DB-Tabelle) weiss die Anwendung aus welchen Original-Dokumenten die Information für die Antwort stammen und kann diese dem Benutzer auch mitteilen.

Zu korrekten Antworten haben folgende Fragen geführt:

Müssen Obstkulturen aufgenommen werden?
Müssen Apfelbäume aufgenommen werden?
Dürfen Kunststoffzeichen für die Vermarkung verwendet werden?
Was sind die Rechtsgrundlagen für eine Gemeindegrenzregulierung?

Bei anderen Fragen wurde halluziniert:

Wie ist die Gebäudedefinition?
Was gehört bei einer Gemeindegrenzregulierung auf den Regulierungsplan?
Wann kommt es zu einer Gemeindegrenzregulierung?

Eingangs habe ich die Frage «Welche Eigentumsbeschränkungen gibt es auf dem Grundstück 114 in der Gemeinde Zuchwil?» beispielhaft aufgeführt. Ist sowas möglich? Ja. Verschiedene LLM kennen das Prinzip des Function Callings. Dabei können vom Entwickler beliebige Funktionen eingehängt werden. Die Funktion führt beliebigen Code aus und liefert eine Antwort zurück, die das LLM verwenden kann. In meinem Fall sind es sogar zwei Funktionen. Eine liefert den E-GRID eines Grundstückes anhand des Gemeindenamens und der Grundstücksnummer. Die zweite Funktion ruft mit dem E-GRID als Identifier den ÖREB-Webservice auf, liest aus dem XML die betroffenen Themen aus und liefert diese als Liste zurück. Die LLM sind dahingehend trainiert, dass sie möglichst gut wissen, wann sie die Funktion(en) aufrufen müssen. Das Ganze ist aber schon bisschen magisch. Mir ist noch nicht ganz klar, was und wie genau hier rein spielt. Die Funktionen werden annotiert und es hilft sicher hier was sinnvolles reinzuschreiben (rede ich mir jedenfalls ein).

Die Frage nach den Eigentumsbeschränkungen konnte beantwortet werden:

Anscheinend wird wirklich zuerst anhand des Gemeindenamens und der GB-Nummer die Grundstuecks-Funktion aufgerufen und anschliessend mit dem jetzt bekannten E-GRID die ÖREB-Funktion, die nur eine Java-Liste zurückliefert. Der schön formatierte Text stammt vom LLM. Faszinierend.

Links:

Viel Code stammt aus den Beispielen von Dan Vega.
https://github.com/edigonzales/spring-ai-demo
https://github.com/edigonzales/spring-ai-avdocs

INTERLIS leicht gemacht #42 - INTERLIS over the wire

Fri, 31 May 2024 00:00:00 +0000

Seit über 20 Jahren landen Informationen über Baugesuche ausserhalb der Bauzone in unserer GDI. Die erste Generation einer Geschäftskontrolle wurde noch selber programmiert. Interessant war dabei, dass die Lokalisierung quasi im Zentrum stand: Das Geschäft musste mit einem Klick in die Karte eröffnet werden. Heute mit einer externen Lösung ist das nicht mehr so gelöst. Nichtsdestotrotz landen die Koordinaten des Baugesuches und weitere Informationen in unserer Datenbank und werden als geschützter WMS-Layer publiziert. Die Daten werden von der externen Anwendung via unserem Dataservice (einfache Rest-API und JSON) in die Datenbank gespeichert. Ganz geglückt ist die Integration nicht, da das Fehlerhandling - warum auch immer - eher medioker ist: Falls es beim Zurückschreiben (PUT oder POST) einen Fehler gibt, war es das. Der Benutzer bemerkt diesen Fehler nicht und die Anwendung macht auch nichts. So weit, so gut. Ist jetzt noch nicht per se ein Negativpunkt für ein Rest-API.

Der Kanton realisiert zur Zeit das Projekt «Elektronisches Baubewilligungsverfahren (eBauSO)» und auch hier ist das Zurückschreiben der Geoinformationen zum Baugesuch ein Thema, das behandelt werden muss. Entweder machen wir es in verbesserter Form mit dem Rest-API, dessen Signatur wir aber abgekündigt haben (und in Zukunft OGC API - Features verwenden wollen). Oder wir ziehen andere Lösungsvarianten in Betracht. Dazu muss man die Anforderungen kennen: Die externe Anwendung kennt immer die Lokalisierung des vom Benutzer (Baugesuchssteller oder Leitbehörde etc.) bearbeitenden Baugesuchs (ohne GDI, ohne WMS) und kann sie auf einer eigenen Karte darstellen. Für die Behörden ist ebenso wichtig zu wissen, ob es andere aktuelle oder ältere Baugesuche gibt, die sich auf dem Grundstücke oder in der Nähe befinden. Diese Information muss aber nicht zwingend real-time sein. Das heisst, wenn ein Baugesuchssteller ein neues Baugesuch eröffnet, müssen die Behörden nicht zum gleichen Zeitpunkt die Koordinaten im geschützten WMS-Layer sehen. Wenn wir wählen können, ist uns ein filebasierter Austausch mit INTERLIS lieber. Eine Variante wäre z.B. eine tägliche Gesamtlieferung aller Baugesuchsinformationen. Da jedoch pro Jahr circa 6'000 Baugesuche erstellt werden, skaliert das dann doch nicht so gut. Eine andere Variante eines dateibasierten Austausches ist, dass man pro Geschäft eine Datei erstellt und nur jeweils bei Veränderungen im Geschäft die Datei exportiert und irgendwo hinkopiert, wo wir sie herunterladen können. Mit ili2pg resp. GRETL können wir die Daten einfach in die Datenbank importeren. Ein Geschäft = eine Datei = ein Dataset. Ganz fire and forget ist dieser Ansatz aber nicht: Man kann mit diesem Ansatz keine Geschäfte direkt löschen, sondern es wird ein Status-Attribut benötigt, das diese Information speichert und ein nachgelagerter Prozess müsste, so gewollt, den Punkt in der Datenbank löschen (oder in der Karte einfach nicht darstellen). Zudem spielt die Reihenfolge eine wichtige Rolle: Z.B. darf die Löschmeldung nicht vor einer anderen Änderung in die Datenbank importiert werden. Dieses Problem löst sich auf, falls die externe Anwendung immer den gleichen Dateinamen für das Geschäft verwendet und die Dateien am Zielort einfach überschrieben werden. Die Geschichte des Geschäfts wird in unserer Datenbank nicht abgebildet, so dürfen einzelne Zwischenzustände also fehlen. Umsetzen würden wir es ganz simpel: Externe Anwendung speichert die Daten auf einem FTP-Server und wir machen bissle GRETL und Jenkins und gut ist.

Mit diesem Ansatz sind wir im Bereich von Messaging angekommen. Man könnte die letzte Variante auch mit einem Message Broker umsetzen, ohne Umweg über Dateien exportieren und rumschieben. Gesagt, getan: Spasseshalber Apache ActiveMQ heruntergeladen und gestartet. Apache ActiveMQ ist ein Open Source Message Broker, der das Jakarta Messaging API (JMS) implementiert. Damit er auch ausserhalb der Java-Welt einsetzbar ist, unterstützt ActiveMQ auch andere Protokolle, z.B. REST, STOMP oder WebSocket. ActiveMQ kennt zwei Modi: Queue und Topic. Bei der Queue gibt es einen Producer und einen Verbraucher. Wurde die Nachricht vom Verbraucher empfangen, wird sie aus der Queue gelöscht. Topic entspricht einem Publisher/Subscriber-Modell. Hier können mehrere Subscriber die Nachricht empfangen.

Faken wir also unseren Usecase mit einem Python-Producer und einem Java-Consumer. Der Python-Producer verschickt die Nachricht mittels STOMP:

import stomp

# Create a connection to ActiveMQ
conn = stomp.Connection12([('localhost', 61613)], auto_content_length=False) #https://github.com/jasonrbriggs/stomp.py/issues/216
conn.connect(login='admin', passcode='admin', wait=True)

# Send a message to a specific destination (queue)
destination = 'ch/so/dsbjd/ebau'
message = '''<?xml version="1.0" encoding="UTF-8"?>
<ili:transfer xmlns:ili="http://www.interlis.ch/xtf/2.4/INTERLIS" xmlns:geom="http://www.interlis.ch/geometry/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SO_ARP_Baugis_20190612="http://www.interlis.ch/xtf/2.4/SO_ARP_Baugis_20190612">
  <ili:headersection>
    <ili:models>
      <ili:model>SO_ARP_Baugis_20190612</ili:model>
    </ili:models>
    <ili:sender>ili2gpkg-5.1.0-58fc980cc6639b2c16a3cff8a0fa19ef1484b11c</ili:sender>
  </ili:headersection>
  <ili:datasection>
    <SO_ARP_Baugis_20190612:Baugis ili:bid="SO_ARP_Baugis_20190612.Baugis">
      <SO_ARP_Baugis_20190612:Geschaeft ili:tid="E888E057-B203-4488-866F-0EA1D365AFEF">
        <SO_ARP_Baugis_20190612:SobauID_sprechend>Neubau Zürihaus</SO_ARP_Baugis_20190612:SobauID_sprechend>
        <SO_ARP_Baugis_20190612:SobauID_system>08DE6290-A2EF-4044-9C49-3B9A1F280610</SO_ARP_Baugis_20190612:SobauID_system>
        <SO_ARP_Baugis_20190612:Art_Text>foo</SO_ARP_Baugis_20190612:Art_Text>
        <SO_ARP_Baugis_20190612:Art_Code>1</SO_ARP_Baugis_20190612:Art_Code>
        <SO_ARP_Baugis_20190612:Vorhaben>Gaga</SO_ARP_Baugis_20190612:Vorhaben>
        <SO_ARP_Baugis_20190612:Entscheid_Text>Ja</SO_ARP_Baugis_20190612:Entscheid_Text>
        <SO_ARP_Baugis_20190612:Entscheid_Code>1</SO_ARP_Baugis_20190612:Entscheid_Code>
        <SO_ARP_Baugis_20190612:Sistiert_Text>nein</SO_ARP_Baugis_20190612:Sistiert_Text>
        <SO_ARP_Baugis_20190612:Sistiert_Code>2</SO_ARP_Baugis_20190612:Sistiert_Code>
        <SO_ARP_Baugis_20190612:Sobau_Link>https://agi.so.ch</SO_ARP_Baugis_20190612:Sobau_Link>
        <SO_ARP_Baugis_20190612:Projektleiter_Name>Lisa Liegenschaft</SO_ARP_Baugis_20190612:Projektleiter_Name>
        <SO_ARP_Baugis_20190612:Geometrie>
          <geom:coord>
            <geom:c1>2607892.464</geom:c1>
            <geom:c2>1228257.773</geom:c2>
          </geom:coord>
        </SO_ARP_Baugis_20190612:Geometrie>
      </SO_ARP_Baugis_20190612:Geschaeft>
    </SO_ARP_Baugis_20190612:Baugis>
  </ili:datasection>
</ili:transfer>
'''

conn.send(body=message, destination=destination, headers={'persistent' :'true'})

# Disconnect from ActiveMQ
conn.disconnect()

Zum Herstellen des INTERLIS-XML in Python würde für unseren Anwendungfalls reines Templating reichen. Man muss nur die Attribut- resp. Elementwerte austauschen.

Wird die Nachricht verschickt und es gibt noch keinen Consumer, kann man die Nachricht in der Enterprise-90er-Jahre-Vibes-Oberfläche von ActiveMQ betrachten:

Interessanterweise überlebten die Nachrichten im Broker einen Restart zuerst nicht. Anscheinend ist es eine Eigenschaft der Nachricht selber, ob sie persistent ist oder eben nicht. Mit STOMP muss das via Header gelöst werden (siehe Zeile 43).

Den Konsumenten bauen wir mit Apache Camel. Apache Camel ist ein in Java geschriebenes Open Source Integration Framework. Mit JBang-Zuckerguss drüber, kann man mit einer einzigen Datei Java-Code sehr viel erreichen. Die sogenannte Route (siehe Zeile 27 … extends RouteBuilder) lädt vom Message Broker die Nachricht herunter (Zeile 38-40), speichert sie in einer Datei (Zeile 41-42) und validiert diese mit ilivalidator (Zeile 46-51). Falls die Nachricht valide ist, wird sie mit ili2pg importiert (nicht implementiert, Zeile 54-55), ansonsten wird eine entsprechende Meldung geloggt.

//REPOS mavencentral,ehi=https://jars.interlis.ch/
//DEPS ch.interlis:ilivalidator:1.14.1
//DEPS ch.ehi:ehibasics:1.4.1
//DEPS org.apache.camel:camel-bom:4.5.0@pom
//DEPS org.apache.camel:camel-main
//DEPS org.apache.camel:camel-activemq
//DEPS org.apache.camel:camel-debug
//DEPS org.apache.camel:camel-file
//DEPS org.apache.camel:camel-health
//DEPS org.apache.camel:camel-jms

import ch.ehi.basics.settings.Settings;
import org.interlis2.validator.Validator;

import org.apache.camel.main.Main;
import org.apache.activemq.ActiveMQConnectionFactory;
import org.apache.camel.Exchange;
import org.apache.camel.Predicate;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.component.activemq.ActiveMQComponent;

import static org.apache.activemq.ActiveMQConnection.DEFAULT_BROKER_URL;

import java.nio.file.Paths;
import java.util.UUID;

public class consume_messages extends RouteBuilder {
    private static final String TMP_DIR = "/Users/stefan/tmp/";

    Main main = new Main();

    @Override
    public void configure() throws Exception {
        // Kann man sich sparen, falls Default-Url verwendet wird.
        main.bind("activemq", ActiveMQComponent.activeMQComponent(DEFAULT_BROKER_URL));
        main.bind("activemqConnectionFactory", ActiveMQConnectionFactory.class);

        from("activemq:queue:ch/so/dsbjd/ebau" +
            "?username=user" +
            "&password=1234")
        .setHeader("CamelFileName", method(consume_messages.class, "generateFileName"))
        .to("file:"+TMP_DIR)
        .choice()
            .when(new Predicate() {
                @Override
                public boolean matches(Exchange exchange) {
                    Settings settings = new Settings();
                    settings.setValue(Validator.SETTING_ILIDIRS, ".;"+Validator.SETTING_DEFAULT_ILIDIRS);
                    String fileName = (String) exchange.getIn().getHeader("CamelFileName");
                    boolean valid = Validator.runValidation(Paths.get(TMP_DIR, fileName).toString(), settings);
                    return valid;
                }
            }).process(exchange -> {
                System.out.println("File is valid and will be imported: " + exchange.getIn().getHeader("CamelFileName"));
                // ili2pg...
            })
            .otherwise().log("File is NOT valid.")
        .end();
    }

    public static String generateFileName() {
        UUID uuid = UUID.randomUUID();
        return uuid.toString() + ".xtf";
    }
}

Der Dateinamen (Zeile 139) ist im Codebeispiel einfach eine random UUID. Damit könnte ich für den ili2pg-Import nicht auf den Dateinamen als Dataset zurückgreifen, sondern müsste z.B. zuerst die TID aus der XML-Nachricht rauslesen (siehe Anforderungen oben).

Bringt INTERLIS in solchen Fällen etwas? Mich dünkt ja. Ich kann die Nachricht vor der Weiterverarbeitung mit dem vollen INTERLIS-Arsenal prüfen. Die Prüfung bekomme ich mit ilivalidator geschenkt. Anschliessend kann ich die Daten mit ili2db in die Datenbank importieren. Diesen Schritt bekomme ich ebenfalls geschenkt. Es fallen praktisch keine Zeilen Businesslogik an. Ich muss keine Zeile Code ändern, wenn das Datenmodell ändert oder wenn ich den Messaging-Ansatz für ein komplett anderes Thema wähle. Zudem interessieren mich hier beim Empfangen der Nachricht die Information über das Geschäft nicht (also der einzelne Record / das einzelne Objekt). D.h. ich muss gar nicht auf diese Stufe runter. Ansonsten könnte die Validierung mit Beans Validiation erfolgen und der Import mit einem ORM gemacht werden. Aber da würde massiv mehr Code anfallen und man müsste es für jedes Thema / jedes Modell separat lösen. Und falls das Modell umfangreicher wird (mit Assoziationen etc.) wird das schnell hässlich. Wenn wir bei XML bleiben aber nicht INTERLIS machen wollen, könnte man die Validierung mit XSD machen. Das ist definitiv einige Stufen weniger praktikabel und elegant als mit INTERLIS. Zudem fehlt mir etwas für den generischen Import in die Datenbank. Das ähnliche Problem hatten wir bei der Realisierung des neuen Meldewesens für die amtlichen Vermessung. Wir bekommen die Nachrichten im Standard eCH-0132. Ist im Prinzip dead on arrival, weil wir als erstes die XML-Datei in eine INTERLIS-Datei gemäss einem eigenen Modell umtransformieren (müssen), damit wir möglichst viel Aufwand und Code sparen. Das als einer der verschiedenen Kritikpunkte an den eCH-Objektwesen-Standards.

https://github.com/edigonzales/message-broker-playground

INTERLIS leicht gemacht #41 - Hello Datahub

Wed, 29 May 2024 00:00:00 +0000

Seit knapp acht Jahren bieten wir einen INTERLIS-Webservice in einfacher Form an: Datei hochladen und gut ist. In seiner letzten Iteration wurden sogenannte Prüfprofile eingeführt. Der Benutzer soll/muss das entsprechende Prüfprofil in einer Comobox oder via Query-Parameter auswählen.

Ein Prüfprofil ist letzten Endes nur eine metaConfig-Konfiguration, die für ein bestimmtes Thema die Konfigurationen der Software und der Prüfung steuert. Die metaConfig-Datei muss in diesem Fall nicht auf dem Server vorliegen, sondern es wird automatisch und selbständig in den INTERLIS-Data-Repositories (aka ilidata.xml) nach ihr gesucht (analog der Modelle). Diese Laufzeitabhängigkeit von anderen Repositories ist zwar nicht das Gelbe vom Ei aber weil wir die Konfigurationen an verschiedenen Stellen benötigen, gehen wir diesen Deal ein. Letzten Endes war es ein bewusster Entscheid. Vorteilhaft bei dieser Lösung dünkt mich, dass ein Anwender so die genau gleiche Validierung bei sich lokal durchführen kann, ohne die Daten zuerst hochladen zu müssen.

Das Bedürfnis, dass nach einer erfolgreichen Prüfung eine automatische Anlieferung der Daten erfolgt, hatten wir bis jetzt nicht. Einzig die Daten der amtlichen Vermessung werden mindestens wöchentlich an den Kanton geliefert. Hier setzen wir immer noch auf das Infogrips-Universum. Das Einpflegen neuer Daten in die Nutzungsplanung machen wir selber (ausser bei kompletten Ortsplanungsrevisionen) und Leitungskataster machen wir noch nicht. Andere Themen fallen nicht ins Gewicht. Mit der Einführung des neuen Datenmodelles in der amtlichen Vermessung ist jedoch der richtige Zeitpunkt gekommen, den Anlieferungsprozess der amtlichen Vermessung zu überdenken und wir sind zum Schluss gekommen, dass wir hier ebenfalls die «ilivalidator-Schiene» fahren wollen.

Die Anforderungen an den Prozess sind grob:

«ftp put»- oder «curl -X POST»-Niveau für einfache Automatisierung auf Seiten Datenlieferant.
Passwort muss durch Datenlieferant veränderbar sein.
Beliebige Datenmodelle: Auch wenn wir zuerst nur den DMAV-Anlieferungsprozess implementieren werden, muss es für beliebige andere Modell funktionieren.
Daten werden geprüft und in einem Verzeichnis abgelegt. Weitere Prozessierungsschritte sind (momentan) nicht Aufgabe des Datahubs.
Übersicht Lieferstatus für Datenlieferanten und AGI (GUI und Rest-API)

Nach reiflicher Überlegung und einigen Diskussionen haben wir uns bei der Authentifizierung auf einen API-Key geeinigt. Dieser wird als Header mitgeschickt und wir können dadurch die Anlieferung mit einem simplen curl-Befehl umsetzen. Der API-Key kann durch die Anwender selbständig widerrufen werden, ebenso können neue oder zusätzliche API-Keys angefordert werden. Das führt - auch zwecks besserem Verständnis - zum Datenmodell, welches die Konfiguration des Datahubs beschreibt. Selbstverständlich wurde es mit INTERLIS gemacht:

Es ist bewusst sehr einfach gehalten: Es gibt ein Thema, z.B. die Grundstücke der amtlichen Vermessung. Der Name ist der Identifikatior, z.B. DMAV_Grundstuecke. Auf Anhieb nicht ganz einfach zu verstehen, ist der Fakt, dass ilivalidator eine config- als auch eine metaConfig-Option kennt. Die config-Option steuert die Prüfung, die metaConfig-Option steuert die Software. In der metaConfig-Konfiguration wiederum kann man auf eine config-Konfiguration verweisen… Klingt alles sau-kompliziert, ist es aber eigentlich gar nicht so. Vielleicht hilft ein Blick in eine Beispiel-metaConfig-Datei und eine Beispiel-config-Datei. D.h. auch, dass die Theme-Klasse sogar noch abgespeckt werden könnte, da der Verweis auf eine metaConfig-Konfiguration reichen würde.

Als zweite Klasse gibt es das Operat. Das Operat entspricht einem ili2db-Dataset, in der amtlichen Vermessung ist das die Gemeinde. Wahrscheinlich kommt früher oder später das Bedürfnis, dass Operate eines gleichen Themas unterschiedliche Validierungskonfigurationen haben dürfen. Dann müsste auch die Klasse Operat ein metaConfig-Attribut aufweisen. Jedes Operat ist einem Thema zugeordnet.

Die dritte Klasse ist die Organisation. Hier geht es um die Autorisierung: Wer darf welches Operat zu welchem Thema liefern. Als letztes Puzzleteil gibt es die ApiKey-Klasse. Jeder API-Key ist einer Organisation zugewiesen ist.

Langer Rede, kurzer Sinn. Hier ein curl-Aufruf einer Anlieferung der Grundstücke der amtlichen Vermessung der Gemeinde Solothurn:

curl -v -X POST --header "X-API-KEY:c0bb04eb-789b-4063-95ad-bd86a06c6aff" \
-F 'file=@Grundstuecke_Solothurn.xtf' -F 'theme=DMAV_Grundstuecke' -F 'operat=2601' \
http://localhost:8080/api/deliveries

Als Antwort liefert der Datahub sofort (nachdem die Datei hochgeladen wurde) einen Statuscode 202 (= Accepted) zurück und einen Link, um den Status des Jobs einsehen zu können:

http://localhost:8080/api/jobs/B0820978-B325-4C66-87F1-7F21C8DA4819

Im Gegensatz zu unserer heutigen Lösung spielen die Dateinamen keine Rolle. Die Dateien werden nach erfolgreicher Prüfung automatisch entsprechend dem Operatsnamen umbenannt und in das Themenverzeichnis kopiert. Dort stehen sie für nachgelagerte Prozesse, in diesem Fall für den Import in die Datenbank, zur Verfügung. Ili2db resp. GRETL kann so automatisch die Datei dem richtigen Dataset zuweisen (nämlich dem Dateinamen ohne Extension). Hier ein Beispiel mit den Themen IPW_2020 und LKMAP_2015 und einigen Operaten:

Es wird - auch bewusst - nicht geprüft, ob der Inhalt der Daten dem angegebenen Operat/Dataset entspricht. Wir hatten in fast 20 Jahren ein oder zwei Mal ein solches Malheur in der amtlichen Vermessung. Ein Fehler, der anscheinend nicht häufig vorkommt. Die Auswirkungen wären heute (noch) nicht schlimm und schnell zu beheben. Zudem eine robuste und generische Umsetzung mich herausfordernd dünkt.

Den Anwendern steht, zusätzlich zur Abfrage via Jobs-API, eine einfache filterbare Job-Übersichtstabelle zur Verfügung. Ebenfalls werden die Resultate der Validierung per E-Mail verschickt.

Zukünftig werden API-Keys nach einer gewissen Zeit automatisch ungültig. Die Organisation wird frühzeitig informiert werden, dass sie einen neuen Key lösen muss. Zudem wird ein API-Key sofort von der Anwendung selber widerrufen, wenn anstelle «https» nur «http» in der Datahub-URL verwendet wurde. Ein neuer resp. zusätzlicher Key kann mit der Key-API erzeugt werden:

curl -i -X POST --header "X-API-KEY:c0bb04eb-789b-4063-95ad-bd86a06c6aff" \
http://localhost:8080/api/keys

Die Anwendung kennt aufgrund des mitgelieferten API-Keys die Organisation und kann den neuen Key dieser zuordnen. Der neue Key wird nicht in der Antwort mitgeschickt, sondern an die hinterlegte E-Mail-Adresse geschickt. Damit wird verhindert, dass ein kompromittierter Key für zuviel Schabernack verwendet werden kann. Die Nachführung der E-Mail-Adressen übernehmen wir selber und kann von Benutzern nicht selber verändert werden. Erstens gibt das einen zusätzlichen Schutz und zweitens kommt das sehr selten vor.

Keys können auch gelöscht/widerrufen werden:

curl -i -X DELETE --header "X-API-KEY:c0bb04eb-789b-4063-95ad-bd86a06c6aff" \
http://localhost:8080/api/keys/e2b76dce-5160-429b-96ec-0c64ed7c5027

Umgesetzt wurde der Datahub mit Spring Boot. Wir verwenden, wie bereits beim ilivalidator-web-service, die JobRunr-Bibliothek für das interne Jobmanagement. Die Anwendung nimmt eine Lieferung entgegen, speichert die Daten in einem temporären Verzeichnis ab und macht einen Eintrag in die JobRunr-Queue. Die Queue kann im Memory sein oder in einer Datenbank (wie in unserem Fall). Es können beliebig viele Worker registriert werden, um die Queue abzuarbeiten. Der Worker muss nicht einmal im gleichen Netzwerk liegen, sondern muss einzig Zugriff auf die Queue haben und in unserem Fall auf die XTF-Datei zugreifen können (was z.B. mit Objectstorage leicht möglich wäre). Die Anwendung ist so konzipiert, dass sie sowohl Frontend wie auch Worker sein kann (steuerbar über Env-Variablen). Der Overhead des Frontends scheint mir zu gering, um die Trennung in zwei separate Anwendungen (Frontend inkl. Rest-API und Worker) zu rechtfertigen. Dafür gewinne ich einfacheres Entwickeln und für minimale Anforderungen reicht das Deployment einer einzelnen Anwendung.

Die Authentifizierung und Authorisierung ist mit Spring Security gemacht, das «Frontend» (also die einzelne, filterbare Tabelle) mit Jakarta Faces (der Screenshot zeigt noch einen Mockup).

Das Datenmodell wurde mit ili2pg in der PostgreSQL-Datenbank implementiert, um mit Apache Cayenne mit dem Database First Approach die Java-Klassen erzeugen zu können.

As simple as it gets: Einfache Gesamtarchitektur, eine Programmiersprache, eine Modellierungsprache.

https://github.com/sogis/datahub

HTTP-Statuscode 206 - Cloud Optimized GeoTIFF Benchmark

Mon, 13 May 2024 00:00:00 +0000

«Mach' Cloud Optimized GeoTIFF!» sagen sie. «Dann brauchst du keinen WMS mehr!» behaubten sie. Gesagt, getan. «Das macht alles viel einfacher!» beteuern sie. Zumindest letzteres ist leider nur die halbe Wahrheit, wenn man das Ganze auch in einer kantonalen Infrastruktur aufbauen will. Aber natürlich bleibe ich trotzdem grosser Freund von diesem cloud native / cloud optimizeten Geozeugs.

Wo hakt es nun?

Zum Testen habe ich auf einem Hetzner-Cloud-Server unsere Rasterdaten als Cloud Optimized GeoTIFF deployed und mittels Caddy öffentlich verfügbar gemacht. In QGIS bisschen rumgespielt und mit der Performance absolut zufrieden gewesen. Ok, dann lass' es uns in der kantonalen Infrastruktur umsetzen. Wir haben einen einen «dummen» Webserver, der die Vektor- und Rasterdaten ähnlich wie bei meinem Hetzner-Test öffentlich zugänglich macht. Ich freute mich schon die E-Mail mit den Neuigkeiten rauszuhauen und mit bestem Digitaliserungsboomer-Marketingsprech über unsere Cloud-Errungschaften und so zu schreiben. Gott sei Dank noch vorher mit dem Orthofoto (swissimage 2021 kantonale Abdeckung, circa 30GB) getestet und mich gefragt warum das interessanterweise vor allem beim schnellen Zoomen sehr käsig ist. Es ist signifikant langsamer als die Hetzner-Variante, die erst noch weiter entfernt ist. Der Super-GAU ist jedoch, dass QGIS manchmal die Rasterdatei gar nicht als solche erkennt und mit einer Fehlermeldung quittiert. Ob beide Probleme irgendwie zusammenhängen wissen wir, wie so vieles, noch nicht.

Letzeres scheint einen Zusammenhang zu haben mit den GDAL-Umgebungsvariablen, die verhindern, dass unnötige HTTP-Requests gemacht werden. Und/oder mit dem Umstand, dass unser Webserver keinen HEAD-Request unterstützt. Who knows.

Ziemlich nervig ist ebenfalls die schlechtere Performance gegenüber der Hetzner-Variante. Das kann doch fast nicht sein, müsste man meinen. Um es aber der zentralen IT, die ausnahmweise diesen File-Webserver für uns betreibt, schwarz auf weiss darlegen zu können, muss ein sauberes Benchmarking her. Grundsätzlich natürlich sofort an jMeter gedacht. Wie simuliert man nun aber solche Range Requests? Ein Range Request ist bloss ein normaler HTTP-GET-Request mit einem Range-Header, der - nomen est omen - den gewünschten Byterange angibt:

curl -v -X GET -H "Range: bytes=26201587777-26202626445" https://files.geo.so.ch/ch.swisstopo.swissimage_2021.rgb/aktuell/ch.swisstopo.swissimage_2021.rgb.tif

Ich habe mir mit Java und jBang ein Java-Skript geschrieben, dass mir innerhalb der Grösse der Zieldatei einen Byterange zwischen 200KB und 2MB ausrechnet. Man müsste im Webserver-Logfile schauen, ob das circa der Realität entspricht. Diese Range Requests sind nicht mehr ganz so einfach zum Faken wie WMS-Requests mit Boundingbox und Pixel-Anzahl. Gehen wir aber davon aus, dass meine Ranges mehr oder weniger mit der Realität vergleichbar sind. Diese Byteranges werden in einer CSV-Datei gespeichert und können von jMeter als dynamischen Header-Wert verwendet werden.

Erster Versuch war von zu Hause aus, also mit langsamerer Internetverbindung. Ich habe hier nur mit einem Thread getestet. Mit dem Hetzner-Server erreiche ich durchschnittlich einen Throughput von 3.6 Requests pro Sekunde:

Mit der Inhouse-Variante erreiche ich nur lausige 1.9 Requests pro Sekunde:

Als Gegenprobe habe ich das Gleiche mit Objectstorage von Exoscale probiert. Dort erreiche ich sehr ähnliche Werte wie mit dem Hetzner-Rechner.

Und nun noch im Büro mit schnellerer Internetverbindung und mit mehreren Threads (1, 2, 4 und 8). Mit Hetzner erreiche ich durchschnittlich 18.8 Requests pro Sekunde mit einem Maximum von fast 40 Requests pro Sekunde bei 8 Threads:

Mit der Inhouse-Variante sieht es düster aus. Im Durchschnitt 3.1 Requests pro Sekunde und ein Maximum von knapp 5 Requests pro Sekunde. Mit einem Thread erreiche ich ziemlich exakt den gleichen Throughput wie von zu Hause aus:

Auch hier die Gegenprobe mit S3 von Exoscale mit sehr ähnlichen (leicht besseren) Resultaten als mit Hetzner.

Wo ist das Problem mit der Inhouse-Variante? Man weiss es nicht. Irgendwo im Netzwerk? WAF? Zu wenig Ressourcen dem Webserver zugewiesen? Zu langsames Filesystem? Frustrierend sind die vielen Meetings ohne Outcome. Es liegt ja auf dem Tisch, dass etwas faul ist im Staate Dänemark oder mindestens Solothurn und dass es offensichtlich mit dem 5 Euro-Rechner von Hetzner massiv schneller geht. Obwohl die Cloud Optimized GeoTIFF Sache sehr simpel erscheint und «eigentlich» auch ist, gibt es ein paar Stolpersteine auf dem Weg zur Glückseligkeit.

Oops! I accidentally made a report server

Tue, 2 Apr 2024 00:00:00 +0000

Für das Erstellen von sogenannten Objektblättern verwenden wir JasperReports. Unter Objektblatt verstehen wir vor allem ein PDF mit Informationen zu einem einzelnen Objekt oder zu einem Standort. Standardmässig werden die Feature-ID, die Koordinaten und das Koordinatensystem dem Report-Server übermittelt. Es können aber beliebige Parameter dem Jasper-Report übermittelt werden. Diese dienen meistens der Filterung via SQL-Query. Immer häufiger kommt vor, dass neben Objektblättern (Excel-)Listen gewünscht werden.

Warum gefällt uns die jetzige Situation nicht?

Der eigentliche Server, den wir einsetzen, ist nicht JasperReports-Server, sondern wurde im Rahmen des «neuen» Web GIS Clients auf Basis der JasperReports-Bibliothek und Spring Boot durch den Lieferanten 2017/2018 selber entwickelt. Ein Update hat der Server nie erfahren. Sowohl bei der JasperReports-Bibliothek als auch bei Spring Boot (Version 1.5…) nicht. Funktional gibt es ebenfalls einige Unschönheiten. So sind maximal Verbindungen zu fünf verschiedenen Datenbanken möglich und dann war da noch was mit Jasper-Subreports, was nicht funktionierte. Richtig Spass macht die Arbeit mit JasperReports auch nicht. Das Studio ist so ein GUI-Moloch und nicht intuitiv. Zwar beherrscht JasperReports viele Ausgabeformate (PDF, DOCX, XLSX, HTML) aber richtig brauchbar dünkt mich nur die PDF-Augabe. Bereits die XLSX-Ausgabe ist ein Gefrickel.

So richtig zufrieden waren wir also nie. Ab und wann schaut man über den Gartenzaun und entdeckt, dass die kantonale Informatik auch einen Report-Server im Angebot haben: dox42. Für ein Thema setzen wir nun auf dieses Pferd: Der Klick in die Karte löst eine SQL-Query aus und die Resultate werden mittels GET-Request an den dox42-Server geschickt. Das Gute daran ist, dass wir es nicht selber betreiben müssen und dass man die Report-Templates direkt in Word oder Excel machen kann. Ein heikler Punkt sind halt die Organisationsgrenzen. Für uns ist es sehr wichtig, dass wir durcharbeiten können. Wir können es uns nicht leisten, dass der Sachbearbeiter, der das Thema / das Projekt umsetzt, ein Ticket machen muss, um irgendein Detail am Report zu ändern und/oder um diesen in die Produktion zu deployen. Ein No-Go.

Mit diesen Rahmenbedingungen haben wir uns entschlossen ein Projekt zur Ablösung oder Weiterentwicklung unseres Report-Servers zu machen. An einer Brainstorming-Sitzung kam plötzlich die Frage auf, wie der ÖREB-Katasterauszug gemacht wird und warum man das nicht für alle Reports so machen will/kann. Unser ÖREB-Katasterauszug wird mit XSL-FO aus dem ÖREB-XML-Auszug hergestellt. Und das macht er tatsächlich gut und stabil. Rein funktional betrachtet, dürfte damit wohl fast jede Anforderung an ein Objektblatt abgedeckt sein (nicht die Excelliste). Als Input benötigt man jedoch eine XML-Datei, deren Schema beim ÖREB-Kataster spezifiert ist. Diesen Weg (ein XML-Schema definieren), möchte man kaum für jedes Thema beschreiten, weil aufwändig und schlichtweg nicht nötig. Die XML-Datei wäre ja nur dazu da, die PDF-Datei herzustellen und es bliebe alles in der gleichen Organisation und niemand anderes muss sich auf die Struktur der XML-Datei verlassen können. Es reduziert sich nun auf die Frage: Kann man eine XML-Datei praktikabel herstellen? Ja. Weil die Informationen zum Objektblatt sowieso alle in einer Datenbank vorliegen, kann mir die Datenbank auch das XML herstellen und ich brauche dazu keine Middleware.

Der Deal ist der folgende: Es gibt pro Objektblatt eine ini-Datei. In dieser steht momentan nur die Datenbank-ID, damit die Anwendung weiss, an welche Datenbank sie die SQL-Query aus der zweiten Datei schicken muss. Die Query kann von aussen mit beliebigen Parametern (aus GET- und/oder POST-Request) alimentiert werden. Die Query liefert einen String zurück, der gültiges XML ist. Wichtig dabei ist, dass nur genau ein einziger Record mit einer Spalte zurückgeliefert wird. Diese temporäre XML-Datei wird dann mittels der XSL-Transformation aus der dritten Datei zu einem XSL-FO-Dokument und dieses zu einem PDF gemacht. Fertig. Zum vielleicht besseren Verständnis das Ablaufschema visualisiert:

Der Aufruf bleibt im Prinzip gleich wie bei der bestehenden Lösung: http://localhost:8080/reports/grundstuecksbeschrieb?feature=22460&x=2639079&y=1256177&format=pdf.

Das Tolle an dieser Lösung dünkt mich, dass man die Schritte sehr bequem einzeln entwickeln kann. So kann ich mir zuerst ein Dummy-XML händisch machen und damit die XSL-Transformation entwickeln. Oder ich sehe es als Zielstruktur meiner SQL-Query und kümmere mich zuerst um diese. GUI braucht es dazu auch keines. Ebenfalls habe ich das Gefühl, dass die Lösung transparenter ist. Bei den JasperReports passiert das SQL irgendwo unübersichtlich in den Reports (=Debugging-Hölle). Bei meiner Lösung sammle ich die Daten zuerst und übergebe sie dem Arbeitsschritt, der die Daten rendern soll.

Die Resultate können sich sehen lassen. Als Beispiel habe ich das Erdwärmesondestandortblatt umgesetzt. Die XML-Datei, die ich mittels SQL-Query herstellen muss, ist simpel:

<?xml version="1.0" standalone="yes"?>
<ewsstandort>
  <gbnr>3317</gbnr>
  <grundbuch>Solothurn</grundbuch>
  <gemeinde>Solothurn</gemeinde>
  <easting>2605775</easting>
  <northing>1228417</northing>
  <tiefe>100</tiefe>
  <tiefe_grund>Instabiler_UG</tiefe_grund>
  <grundwasser>true</grundwasser>
  <getmap>https://geo.so.ch/ows/somap?SERVICE=WMS&amp;VERSION=1.3.0&amp;REQUEST=GetMap&amp;FORMAT=image%2Fpng&amp;TRANSPARENT=false&amp;LAYERS=ch.so.agi.hintergrundkarte_ortho,ch.so.agi.av.grundstuecke&amp;STYLES=&amp;SRS=EPSG%3A2056&amp;CRS=EPSG%3A2056&amp;TILED=false&amp;OPACITIES=255&amp;DPI=96&amp;WIDTH=600&amp;HEIGHT=480&amp;BBOX=2607821.625%2C1228212.5%2C2607980.375%2C1228339.5&amp;MARKER=X-%3E2607901%7CY-%3E1228276</getmap>
</ewsstandort>

Apache FOP macht übrigens aus dem GetMap-Request tatsächlich ein Bild im PDF:

Also: PDF ist gegessen. Was ist jedoch mit unseren Excellisten? Da verfolge ich in Teilen den gleichen Ansatz. Mit dem Unterschied, dass ich hier mit einer Excel-Template-Datei arbeiten muss. Mit Jxls gibt es eine gute Excel-Templating-Engine. D.h. man schreibt in der Excel-Datei, die später als Template dienen soll, gewisse Anweisungen in die Zellen und als Notiz zu Zellen. Vom Wesen her nicht ganz unterschiedlich zu z.B. Jinja2-Templates. Im Gegensatz zum Objektblatt interessiert mich beim Listenreport in der Regel mehr als bloss ein Objekt. Entsprechend darf die SQL-Query auch mehr als einen Record und eine Spalte zurückliefern. Es werden mehrere SQL-Queries (eine pro Datei) für ein Listenreport unterstützt, damit z.B. mehrere Sheets abgefüllt werden können:

Ob man mit Jxls elaborierte Exellisten (Grafiken o.ä.) erstellen kann, weiss ich anhand meines ersten Gehversuches noch nicht. Unser Projekt wird zeigen müssen, ob unsere Anforderungen mit diesen beiden Ansätzen plusminus erfüllt werden können.

DuckDB - Lizenzgebühren zu hoch? Try DuckDB!

Sun, 28 Jan 2024 00:00:00 +0000

Aus aktuellem Anlass zwei anschauliche Beispiele warum DuckDB eine tolle Sache ist. Im Grundsatz geht es um sogenannte «federated queries», also die Fähigkeit, Daten von mehreren, verteilten oder heterogenen Datenquellen abzufragen / zu analysieren / umzubauen und so zu tun, als wäre es eine einzige einheitliche Quelle.

Beispiel 1

Ich möchte an einer bestimmten Koordinate den Zonentyp kennen, die Gemeindenummer und den Steuerfuss der Gemeinde. Gut, das Beispiel ist brutal gefaked, aber egal. Gehen wir davon aus, dass die Nutzungsplanung in der DuckDB vorliegt:

java -jar ili2duckdb-5.1.1-SNAPSHOT.jar --dbfile arp_npl_2549.duckdb \
--disableValidation --defaultSrsCode 2056 --nameByTopic \
--models SO_ARP_Nutzungsplanung_Publikation_20201005 \
--preScript init.sql --doSchemaImport \
--import ilidata:2549.ch.so.arp.nutzungsplanung.kommunal

Gentle Reminder, dass die ilidata-Unterstützung in allen ili2db-Varianten ein geniales Feature ist.

Die Gemeindegrenzen sind in einer PostgreSQL-Datenbank gespeichert. Die Steuerfüsse liegen in einer Parquet-Datei auf S3 vor.

Die PostgreSQL-Datenbank müssen wir in der DuckDB registrieren:

ATTACH 'dbname=pub user=ddluser password=ddluser host=127.0.0.1 port=54322' AS pg (TYPE postgres);

Und dann geht es bereits los mit goold old SQL:

SELECT
    npl.typ_bezeichnung,
    npl.bfs_nr,
    gem.gemeindename,
    taxes.steuerfuss_in_prozent
FROM
    nutzungsplanung_grundnutzung AS npl
    LEFT JOIN pg.agi_hoheitsgrenzen.hoheitsgrenzen_gemeindegrenze AS gem
    ON npl.bfs_nr = gem.bfs_gemeindenummer
    LEFT JOIN 'https://s3.myregion.amazonaws.com/xxxxxxxxx/ch.so.agem.steuerfuesse.natuerliche_personen.parquet' AS taxes
    ON gem.gemeindename = taxes.gemeinde
WHERE
    ST_Intersects(ST_Point(2611477,1233990), npl.geometrie)
    AND
    taxes.jahr = 2022
;

Man kann das Resultat auch als DuckDB-Tabelle persistieren oder eine View erstellen: CREATE VIEW v1 AS …. Das Resultat als Excel-Datei exportieren, ist auch nur ein COPY-Befehl:

COPY (SELECT * FROM v1) TO 'output.xlsx' WITH (FORMAT GDAL, DRIVER 'xlsx');

Beispiel 2

Dieses Beispiel ist tatsächlich ein realer Usecase. Jedoch kann ich ihn in der Realität noch nicht bis zum bitteren Ende durchspielen. Das bittere Ende ist das Exportformat: Arc GENERATE. WTF!? Wahrscheinlich von Jack Dangermond persönlich in Assembler geschrieben. Ein Müsterchen gefällig:

OBJECTID	FLAECHE	DK_HABS	DK_GEBTYP	DK_GEBNUTZDK_EMPFST	DK_OBERFL	BESCHAEFT	OIDDS	HOEHE
478362209		1	1		501			7.10
2611228.895	1227828.112	7.10
2611230.401	1227836.795	7.10
2611242.775	1227834.644	7.10
2611240.585	1227822.074	7.10
2611240.642	1227822.064	7.10
2611240.619	1227821.936	7.10
2611232.357	1227823.369	7.10
2611233.055	1227827.390	7.10
2611228.895	1227828.112	7.10
END

Scheint mir aber sehr simpel zu sein. Mir fehlt nur der passende IoxWriter, den ich dann in GRETL ansteuern kann und Daten via SQL exportieren kann. Womit wir wieder bei SQL angekommen sind. PostGIS kann auch Raster und kann auch Raster mit cloud optimized geotiff. Das hat den Vorteil, dass die Datenbank nicht ins Unermessliche wächst. Für meinen vorliegenden Fall benötige ich das Geotiff mit den Gebäudehöhen (abgleitet aus LiDAR-Daten). Das GeoTIFF ist 2.1GB gross. Wenn ich die Daten aber nicht komplett in die DB importiere, ist die «Raster-»Tabelle bloss 67MB gross.

Was ich benötige ist der Grundriss eines Gebäude aus der amtlichen Vermessung und die durchschnittliche Gebäudehöhe. Also ein Verschnitt zwischen Vektor und Raster. In PostgreSQL sieht das z.B. so aus:

WITH buildings AS
(
    SELECT
        t_id,
        geometrie AS geometrie
    FROM
        agi_dm01avsoch24.bodenbedeckung_boflaeche
    WHERE
        art = 'Gebaeude'
    AND
        ST_Intersects(ST_SetSRID(ST_MakePoint(2611306, 1228084), 2056), geometrie)
)
,
clipped_tiles AS
(
  SELECT
    ST_Clip(elev.rast, buildings.geometrie) AS rast,
    elev.rid,
    buildings.t_id
  FROM
    agi_lidar_2019_ndsm.buildings AS elev
  JOIN
    buildings
    ON ST_Intersects(buildings.geometrie, ST_ConvexHull(elev.rast))
)
,
stats AS
(
    SELECT
        t_id,
        (ST_SummaryStatsAgg(rast, 1, true)).*
    FROM
        clipped_tiles
    GROUP BY
        t_id
)
SELECT
    buildings.t_id,
    buildings.geometrie,
    stats.mean AS hoehe
FROM
    buildings
    LEFT JOIN stats
    ON buildings.t_id = stats.t_id
;

Und mit DuckDB? DuckDB kann auch Queries direkt in der attachten PostgreSQL-Datenbank ausführen, z.B.

SELECT * FROM postgres_query('pg', 'SELECT postgis_full_version()');

Anstelle SELECT postgis_full_version() muss ich meine CTE von oben ausführen. Ich erstelle ein View und exportiere sie in eine Shapedatei:

CREATE VIEW v2 AS
SELECT
    *
FROM
    postgres_query('pg', '...')
;

COPY (SELECT * EXCLUDE geometrie, ST_GeomFromWkb(geometrie) FROM v2) TO 'gebaeudehoehen.shp' WITH (FORMAT GDAL, DRIVER 'ESRI Shapefile', SRS 'EPSG:2056');

Beweis in QGIS:

Und das Beste: DuckDB ist Open Source und man bezahlt keine Lizenzgebühren.

INTERLIS leicht gemacht #40 - Let there be ili2duckdb

Mon, 15 Jan 2024 00:00:00 +0000

Gleich ein zweifaches Jubiläum: 40. INTERLIS-Blogpost und 10 Jahre Blogging (Neudeutsch: Content Creation). Und ja, immer noch mit RSS-Feed.

Ich mag DuckDB. Und weil es wirklich eine coole Sache ist und die Möglichkeiten, was man damit anstellen kann, beinahe grenzenlos sind, muss natürlich ili2duckdb her. Ganz generell lässt sich behaupten: Wo ein JDBC-Treiber, da ein ili2db-Flavor. Ili2db ist so aufgebaut, dass man relativ einfach eine neue Datenbankvariante hinzufügen kann. Voraussetzung ist eben das Vorhandensein eines JDBC-Treibers und das Schreiben einiger Java-Klassen. In den Java-Klassen muss man vendor-spezifisches Zeugs regeln. Also z.B. wie die Datentypen der spezifischen Datenbank heissen: Ist es BIGINT oder INT8? Oder wie muss ein Datum formatiert sein, damit ich es mit einem Insert-Befehl importieren kann? Solche Geschichten halt. Da es bereits verschiedenste Flavor gibt, konnte ich viel spicken resp. vor allem verstehen, welche Klassen und Methoden welche Bedeutung haben.

Ein initialer Commit habe ich gemacht. Die Arbeit war soweit ziemlich straight forward aber trotzdem lehrreich: Man lernt ili2db, DuckDB und die Fähigkeiten des JDBC-Treibers besser kennen. Im Commit fehlen unter anderem noch Tests. Ich habe ili2duckdb nur manuell, also mit eigenen XTF, getestet. Was sind meine Erkenntnisse, was ist der Stand?

JDBC-Treiber: Es handelt sich um einen sogenannten Typ-2-Treiber. D.h. neben Java-Code braucht es eine zusätzliche Bibliothek, die jedoch «versteckt» in der Jar-Datei ist. Die Bibliothek ist in der Regel betriebssystem-spezifisch, was bedeutet, dass der JDBC-Treiber nur auf kompatiblen Betriebssytemen funktioniert. Sowohl als Programmierer wie auch als Anwendert merkt man das in den allermeisten Fällen gar nicht. Die DuckDB-Lib läuft auf Linux, macOS und Windows. Soweit alles kein Problem. Das gleiche gilt übrigens auch für ili2gpkg.

JDBC-Test-Code: Damit man überhaupt versteht, was der JDBC-Treiber kann, lohnte es sich für mich eine eigene Java-Klasse zum Rumspielen zu haben, die nur Inserts und Selects macht. Die ganze ili2db-Magie gibt es da nicht und ich gewann Klarheit warum ein Fehler auftritt.

Dateigrösse: Momentan dünken mich die resultierenden DuckDB-Dateien gross. Ein Testdatensatz als GeoPackage ist 220KB gross, die DuckDB-Variante 4.2MB. Ob ich noch was besser machen kann, oder das eher auf Seiten DuckDB zu suchen ist, weiss ich nicht. Sie schwärmen jedenfalls von ihrer Compression. Was verlinkter Beitrag nicht berücksichtigt, sind die Geometrien. Soweit für mich nachvollziehbar, sind die Geometrien in DuckDB nicht komprimiert. Vielleicht liegt es alleine daran.

init.sql: Die spatial skills von DuckDB sind in eine Extension ausgelagert. Diese Extension muss man installieren und laden. Das Installieren muss nur einmalig gemacht werden und ili2db bietet dazu Möglichkeiten. Beim Laden wirds komplizierter. Dies muss - soweit ich es verstehe - immer gemacht werden, wenn eine neue DB-Verbindung gemacht wird. Nun ist es so, dass ili2db nicht alles mit der gleichen Verbindung macht. D.h. nach dem Installieren der Extension wird die DB-Verbindung geschlossen, das Laden bringt hier nichts (mehr). Es muss also ein Weg gefunden werden, wie beim Anlegen der Tabellen oder beim Importieren der Daten die Extension mit der gleichen Verbindung, die auch für die nachfolgenden SQL-Befehle verwendet wird, vorgängig geladen werden kann. Mir ist nur die Variante mit der --preScript-Option eingefallen. Aber vielleicht hat ili2db noch irgendwo was anderes, wo man sich einhaken kann.

ST_GeomFromWKB: DuckDB kennt die Funktion ST_GeomFromWKB(BLOB) und so dachte ich, dass man das identisch wie bei PostGIS machen kann: Ili2db parst das XTF und wandelt die Geometrie nach WKB um und übergibt die WKB-Geometrie anschliessend dem SQL-Insert-Statement. Nur hat das - warum auch immer - nicht funktioniert. Abhilfe schafft die Verwendung von ST_GeomFromHEXWKB() und die vorgängige Umwandlung in einen HEX-String.

ADD CONSTRAINT: Ili2db erzeugt zuerst die Tabelle und fügt anschliessend mit ADD CONSTRAINT-Befehlen die Constraints hinzu. Da DuckDB diese Synax nicht kennt, sondern man Constraints nur beim Anlegen der Tabellen erzeugen kann, gibt es momentan keine Constraints.

Geometrie-Support: Ja, der Geometrie-Support in DuckDB ist schon nicht ganz auf PostGIS-Niveau. So gehen M- und Z-Werte nicht und SRID werden auch keine unterstützt. Compound Curves (Kreisbogen) habe ich schon gar nicht probiert.

Das Resultat kann sich sehen lassen:

More to come …

HTTP-Statuscode 206 - Parquet und DuckDB

Sat, 30 Dec 2023 00:00:00 +0000

Wie im vorangegangen Blogpost aufgezeigt, wird WFS dank Cloud Native Formate für gewisse Anwendungsfällte ziemlich überflüssig. Die Frage ist, ob z.B. GeoParquet auch für Realtime-Datenanalysen, im einfachsten Fall für Filterabfragen, geeignet ist. Unter Filterabfragen verstehe ich sowas wie ein WMS-GetFeatureInfo-Request und/oder ein klassischer GIS-Nadelstich für Fachanwendungen mittels WFS/Featureservice. Als Abfragesprache eignet sich SQL und als Engine dazu DuckDB. Gehen tut es natürlich schon, die Frage ist, ob es performant genug ist, ohne die GeoParquet-Datei lokal vorzuhalten. Weil (Geo)Parquet und DuckDB zusammen irgendwie Magie ist und momentan die Antwort auf fast jede Frage, erhoffte ich mir in brutaler Naivität natürlich eine ansprechende Performance. Dank guter Dokumentation hat man die Syntax für die spezifisichen Geokniffe schnell heraus:

SELECT
    typ_kt
FROM
    'https://stac.sogeo.services/files/test/nutzungsplanung_grundnutzung_v.parquet' AS grundnutzung
WHERE
    ST_Intersects(ST_Point(2596651,1226670), ST_GeomFromWkb(grundnutzung.geometry))
;

Die Abfrage dauert circa entäuschende 7 Sekunden. Das entspricht mehr oder weniger der Downloadzeit der gesamten Parquet-Datei, was tatsächlich - gemäss Logdatei des Webservers - auch gemacht wurde: Content-Range=[ "bytes 4-63990494/64006068" ]. Nach professioneller Recherche (also Ausprobieren bis die Ohren wackeln) glaube ich langsam ein gewisses Wissen davon zu haben, was hinter den Kulissen abgeht (vor allem auch Dank Chris Holmes Beitrag) und wo man dran schrauben kann resp. muss, damit das schneller geht. Ob es dann tatsächlich einmal gleich schnell wie eine GetFeatureInfo-Abfrage wird, wage ich heute zu bezweiflen. Die GetFeatureInfo-Abfrage dauert bei uns für Grundnutzung und Grundstücke jeweils circa 200ms. Gemeinsam in einem Request circa 300ms. Es sind einfach andere Prinzipien mit anderen Rahmenbedingungen. Aber der Reihe nach. Am einfachsten bekommt man vielleicht ein Verständnis wie folgt:

Was passiert, wenn ich einen einzelnen Record mit einer WHERE-Clause anfordere?

SELECT
    t_ili_tid
FROM
    'https://stac.sogeo.services/files/test/nutzungsplanung_grundnutzung_v.parquet' AS grundnutzung
WHERE
    t_ili_tid = 'e9732511-dbe5-4625-98e1-535c47793fb8'
;

Die Query dauert circa 0.5 Sekunden. Im Webserver-Log sehe ich vier Einträge. Der erste ist ein HEAD-Request. Die drei folgenden sind Range-Requests, wobei auf den ersten Blick nur der letzte ins Gewicht fällt. Sowohl bei der Antwortzeit wie auch bei der Datenmenge. Wie sieht es aus, wenn ich noch ein weiteres (Sach-)Attribut anfordere:

SELECT
    t_ili_tid,
    typ_kt
FROM
    'https://stac.sogeo.services/files/test/nutzungsplanung_grundnutzung_v.parquet' AS grundnutzung
WHERE
    t_ili_tid = 'e9732511-dbe5-4625-98e1-535c47793fb8'
;

Die Query wird nicht spürbar langsamer, im Logfile sieht man jedoch einen zusätzlichen Range-Request. Es ist also relevant, wie viele und welche Attribute man in der Query anfordert.

Wenn ich nun noch das Geometrieattribut anfordere, dauert die Query aber wieder knapp 7 Sekunden:

SELECT
    t_ili_tid,
    geometry
FROM
    'https://stac.sogeo.services/files/test/nutzungsplanung_grundnutzung_v.parquet' AS grundnutzung
WHERE
    t_ili_tid = 'e9732511-dbe5-4625-98e1-535c47793fb8'
;

Parquet-Dateien sind in row groups partitioniert. Gute Erklärung dazu in einem DuckDB-Blogbeitrag. Es müssen also mindestens alle row groups heruntergeladen werden, die meiner Query resp. den Filterkriterien entsprechen. Und so wie ich es mir nun zurecht gelegt habe, kann man innerhalb einer row groups die Attribute mittels Range-Request ansprechen. Darum gibt es bei der zweiten und dritten Query einen weiteren Range-Request (für das zweite Attribut). Die vorangegangen Range-Requests dienen dem Herunterladen der Metadaten (also v.a. Statistiken zu den row groups). Die Metadaten einer Parquet-Datei kann man in DuckDB anschauen:

SELECT
    *
FROM
    parquet_metadata('https://stac.sogeo.services/files/test/nutzungsplanung_grundnutzung_v.parquet')
;

In meiner Parquet-Datei gibt es genau eine row group (mit allen 37'731 Records drin). Interessant sind die beiden letzten Spalten, die den Speicherplatzbedarf der Attributwerte innerhalb der row group ausweist. Wenn ich mir die komprimierte Grösse des Attributes t_ili_tid anschaue (1'353'462), entspricht das exakt der Grösse einer Antwort eines Range-Requests (für t_ili_tid). Es müssen also zwingend bereits bei der einfachsten Query mit nur einem angeforderten Attribut 1.3MB Daten heruntergeladen werden. Wenn ich das Geometrieattribut anfordere, werden zusätzliche 61MB Daten runtergesaugt.

Nun gibt es die Möglichkeit die Daten innerhalb der Parquet-Datei in mehrere mehrere row groups aufzuteilen (resp. die Menge der Records einer row group zu definieren). Dann müsste nur noch die row group, die meine Geometrie enthält, heruntergeladen werden. Gesagt, getan (Achtung: siehe …_bbox_v3.parquet):

SELECT
    t_ili_tid,
    geometry
FROM
    'https://stac.sogeo.services/files/test/nutzungsplanung_grundnutzung_v_bbox_v3.parquet' AS grundnutzung
WHERE
    t_ili_tid = 'e9732511-dbe5-4625-98e1-535c47793fb8'
;

In dieser Datei-Variante gibt es 18 row groups mit jeweils 2048 Records. Die Query dauert nicht mehr 7 Sekunden, sondern nur noch circa 900ms. Es werden aber 23 Requests losgeschickt und nicht mehr bloss 5 Requests wie mit der Original-Datei. DuckDB muss nun anhand der Metadaten/Statistik die passenden row groups finden. Was passiert wenn ich die allererste Query (den Nadelstich) mit dieser Datei ausführe? Es dauert genau gleich lang oder sogar noch ein klein wenig länger. Es werden 27 Requests abgesetzt und weil die Geometriespalte keine Statistiken ausweist, muss DuckDB sämtliche Geometrie-row groups herunterladen und die Intersects-Bedingung prüfen. Das ist Stand heute mit GeoParquet Version 1.0.0 einfach so. Auf der Roadmap für Version 1.1.0 stehen glücklicherweise Dinge wie «spatial optimization, spatial indices and spatial partitioning to improve performance reading spatial subsets».

Man kann sich selber eine BBOX-Spalte basteln und diese in die WHERE-Clause miteinbeziehen. Das sind dann circa so aus:

SELECT
    t_ili_tid
FROM
    'https://stac.sogeo.services/files/test/nutzungsplanung_grundnutzung_v_bbox_v3.parquet' AS grundnutzung
WHERE
    bbox.minx < 2596651 AND bbox.maxx > 2596651 AND bbox.miny < 1226670 AND bbox.maxy > 1226670
;

Das performt solange man die Geometriespalte nicht anfordert. Ohne Geometriespalte circa 700ms, mit Geometriespalte 7.5 Sekunden. Das Intersects brauche ich schon gar nicht mehr zu versuchen anzuhängen. Mit Geometriespalte sind es zwar «bloss» 24 Requests, die gemacht werden müssen aber es sind teilweise auch grössere Antworten dabei, die DuckDB zuerst runterladen muss. Es wird somit auch ein Abwägen sein zwischen der Menge von row groups und der Grösse der row groups. Weniger row groups bedeuten weniger Requests aber grössere Downloads (und umgekehrt). Und es ist natürlich ein Unterschied zwischen 2'048 Punkten oder 2'048 Flächen (mit tausenden Vertexpunkten) in einer row group.

Aber genug des Jammerns: Wenn die Dateien lokal vorliegen, flutschen die Queries natürlich nur so und das Duo DuckDB und GeoParquet wird noch viel Freude bereiten. Zu guter Letzt noch ein Hinweis auf ein nettes Goodie: das hive partitioning. Das funktioniert lokal oder mit S3. Grundsätzlich erlaubt es DuckDB mehrere Parquet-Dateien als eine anzusprechen:

SELECT
    count(t_ili_tid)
FROM
    read_parquet('s3://xxxxxxxxxxxxx/ch.so.arp.nutzungsplanung.kommunal/*.parquet', hive_partitioning = 1)
;

Es gilt die Annahme, dass für jede Gemeinde eine Datei vorliegt und im Verzeichnis/Bucket ch.so.arp.nutzungsplanung.kommunal liegt. Hat man sehr viele (z.B ganze Schweiz oder so) Dateien, kann man das beschleunigen, indem man für jede Gemeinde einen Unterordner macht und diesen korrekt benennt: bfs_nr=<xxxx>. Wenn man in einer Query nur noch an Daten einer spezifischen Gemeinde interessiert ist, sucht DuckDB auch nur noch in diesem Unterordner (und muss nicht mehr sämtliche Dateien durchsuchen):

SELECT
    count(t_ili_tid)
FROM
    read_parquet('s3://xxxxxxxxxxxxx/ch.so.arp.nutzungsplanung.kommunal/*/grundnutzung.parquet', hive_partitioning = 1)
WHERE
    bfs_nr = 2503
;

HTTP-Statuscode 206 - Let's get started

Fri, 29 Dec 2023 00:00:00 +0000

Des GIS-Menschen liebster HTTP-Statuscode sollte 206 sein. Warum? 206 heisst Partial Content und bedeutet, dass der angeforderte Teil erfolgreich übertragen wurde. D.h. es wird nicht die komplette Ressource angefordert, sondern nur Teile davon. Der Client teilt dem Server den gewünschten Teil mittels Content-Range-Header mit. Im Geo-Bereich kann das interessant werden, um mit Daten zu arbeiten ohne sie vollständig (z.B. die 50GB grosse Rasterdatei) herunterladen zu müssen. Die Daten müssen jedoch gewisse Bedingungen erfüllen, damit die 206-Magie auch greifen kann. Sie müssen also «cloud native» oder «cloud optimized» sein.

Als erstes ist mir vor ein 1-2 Jahren das Cloud Optimized GeoTIFF begegnet. Damals ein wenig rumgespielt und wieder sein gelassen. Wie wahrscheinlich andere auch halten wir unsere Rasterdaten (Orthofotos, LiDAR-Derivate) in einzelnen Kacheln vor. Dazu eine VRT-Datei und für kleinere Massstäbe eine einzelne Übersichtsdatei. Das Handling ist immer ein wenig mühsam: Es sind teilweise mehrere tausend Dateien und man braucht zwingend die Übersichtsdatei für die kleineren Massstäbe. Ich denke, dass man bereits vor dem Cloud Optimized GeoTIFF einfach eine einzige grosse BigTIFF-Datei hätte herstellen können. Damit wäre zumindest unser Handling-Problem kleiner geworden. Andere Benefits hätten wir nicht gehabt. Insbesondere möchten unsere Kunden nicht wirklich 50GB runterladen, wenn sie bloss an einem Ausschnitt interessiert sind.

Weil das Cloud Optimized GeoTIFF aber wirklich ziemlich genial ist, habe ich nochmals einen Anlauf unternommen und aus unseren tausenden Rasterdaten mit GDAL jeweils ein einzelnes GeoTIFF erzeugt. Seit geraumer Zeit gibt es sogar ein spezielles COG-Profil. Damit ist die Herstellung kinderleicht. Es werden sogar die internen Overviews erstellt (falls gewünscht). Die resultierenden GeoTIFFs habe ich auf einen Hetzner-Server geschmissen: https://stac.sogeo.services/files/raster/ und zugleich als STAC-Katalog exponiert.

In QGIS kann man seit längerem GeoTIFFs auch mittels URL laden. Zum Ausprobieren lade ich so z.B das 13GB grosse Orthofoto ch.so.agi.orthofoto_2007.rgb.tif in QGIS. Die Performance ist genial und insbesondere in einem Bereich, in dem bereits relativ viele einzelne Kacheln geladen werden müssen, schneller als der WMS (der immer noch das VRT mit den vielen einzelnen TIFFs verwendet). Mit einer schnellen Internetverbindung beinahe so schnell als würde die Datei lokal vorliegen.

Was passiert im Hintergrund? Dazu schaue ich mir die Logdatei des Webservers an:

Man sieht sehr schön den Statuscode (= 206), den Content-Range-Header und die ausgelieferte Grösse der Antwort. Es ist natürlich auch relativ performant, weil die Orthofotos ordentlich komprimiert sind. Wenn man «richtige» Rasterdaten (z.B. ch.bl.agi.lidar_2018.dtm_slope.tif) verwendet, wird die Menge der herunterzuladenden Daten bei einer Teilanfrage grösser, weil man die Ausgangsdaten nicht gleich stark komprimieren kann wie das Orthofoto.

Ein wenig störend ist das erstmalige Laden der Datei. Das scheint lange zu dauern. In der Webserver-Logdatei sieht man viele 404er. QGIS (GDAL?) sucht nach verschiedenen Hilfs-/Metadateien (*.aux.xml etc.), die es nicht gibt. Bei mir sind das insgesamt 75 Requests ins Leere. Lokal spielt das weniger eine Rolle. Aber wenn 75 (ich kanns immer noch nicht ganz glauben) HTTP-GET-Requests gemacht werden müssen…

Wie sieht es mit Vektordaten aus? Eigentlich ziemlich ähnlich. Es gibt verschiedene Formate, die von sich behaupten (oder andere behaupten es) «cloude native» zu sein. Siehe Übersicht unter cloudnativegeo.org. Mit ogr2ogr habe ich unsere frei verfügbaren Vektordaten nach FlatGeobuf und GeoParquet umgewandelt und ebenfalls auf den Hetzner-Server kopiert und als STAC-Katalog exponiert. Bei einigen, wenigen Umwandlungen aus der GeoPackage-Datei kam es zu Fehlern. Stand heute ist mir der Grund noch nicht klar. Analog zu Rasterdaten können in QGIS auch Vektordaten mittels URL geladen werden. In der Webserver-Logdatei erscheinen wieder die 206-Statuscodes. FlatGeobuf funktioniert bei mir im Gegensatz zu GeoParquet wunderbar. GeoParquet wird in QGIS unter macOS noch nicht unterstützt, unter Windows ist mir damit QGIS abgestürzt.

Nun muss man aber auf den grundlegenden Unterschied zu den Rasterdaten aufmerksam machen, der bei kleinen Dateigrössen und schneller Internetverbindung zuerst gar nicht auffällt. Im Gegensatz zum Cloud Optimized GeoTIFF haben weder FlatGeobuf noch GeoParquet Overviews. Das bedeutet, dass ich je nach Zoomstufe relativ viele Daten - sprich irgendeinmal alle - herunterladen muss. Abhilfe schafft nur ein Format, dass auch Overviews unterstützt, z.B. PMTiles. Wobei mir nicht klar ist, ob das auch wieder zu verschnittenen Flächengeometrien (weil «Tile») führt und wie man damit gut umgehen soll. Ich meine, wer will verschnittene Grundstücke?

Bei «anständigen» Zoomlevels ist die Performance von FlatGeobuf sehr gut. Insbesondere im Vergleich zu einer GeoPackage-Datei, die man ebenfalls als HTTP-Ressource in QGIS anzapfen kann. Zum Ausprobieren habe ich im Test-Ordner sowohl die AV-Bodenbedeckung wie auch die Grundnutzung der Nutzungsplanung in verschiedenen Formaten abgelegt.

Was nun? Im Prinzip kann der WMS für Rasterdaten einpacken. Wobei es vielleicht doch nicht ganz so einfach ist. Es würde zwar zu einer Vereinfachung des technischen Systems führen (kein Server mehr, nur Webspace), aber vielleicht will man die Rasterdaten mit einem Defaultstyle anbieten, oder einen Layer (z.B. Landeskarte) aus verschiedenen einzelnen Layern? Und für den Endbenutzer ist es wohl einfacher (wenn es bloss um die Darstellung geht) alles an einem Ort (also dem WMS) abzuholen. Aber als Ergänzung muss man es allemal anbieten.

Der WFS als dumber Dateidownload hat ausgedient. Ich sehe hier keine Vorteile mehr zur Variante FlatGeobuf/GeoParquet mit STAC (und einfacher und brauchbarer Integration im QGIS Data Source Manager). Wenn ich die gesamte Bodenbedeckung via WFS herunterlade, klemmt es garantiert irgendwo. Sei es die Last beim WFS selber oder dann irgendwo in QGIS. Als Kunde weiss ich ja nicht einmal, ob der WFS-Server alle angeforderten Features ausgeliefert hat oder bloss die serverseitig eingestellte, maximale Anzahl. Bissle broken by design. Darum lieber FlatGeobuf o.ä. mit STAC.

Interessanter wird es bei gefilterten Requests, also z.B beim klassischen Nadelstich: Welche Grundnutzung gilt an der Koordinate X/Y? Wäre natürlich genial, wenn man auch hier auf einen Featureservice/WFS verzichten könnte und man bloss ein paar Parquet-Files bereitstellen müsste. Der Client könnte mit DuckDB und SQL die Abfragen machen. Ob und wie das gehen könnte, gibt es in einem weiteren Blogpost zu lesen.

INTERLIS leicht gemacht #39 - "Dear BFS, I fixed it for you."

Mon, 20 Nov 2023 00:00:00 +0000

Wie heisst es so schön: «Wer den Schaden hat, braucht für den Spott nicht zu sorgen». Man weiss zwar (noch) nicht genau, wie das Wahl-Statistik-Debakel passiert ist, aber ein wenig frotzeln lässt sich schon. Die meisten Informationen stehen meines Erachtens in einem NZZ-Artikel. Lassen wir mal die Microservices («Für jedes mögliche (kantonale) Datenformat existiert ein solches Programm.»: Ojeeeee…) beiseite und widmen uns den «Datenlieferungen» in Form einer Exceldatei. Ich weiss wirklich nicht, wie man auf eine solche Idee kommt. Aber Rohdaten (wenn man den Begriff verwenden darf) in einer Exceldatei als Transferformat? Ballsy! Ein weiterer Kritikpunkt ist die Datenstruktur: Nicht alles auf dieser Welt lässt sich als einfache Tabelle abbilden. Manchmal wäre ein normalisiertes Datenmodell definitiv die bessere Wahl. Dann zählt man die Gemeinden auch nicht dreifach.

Also: man nehme den Screenshot aus dem NZZ-Artikel und generiere daraus ein INTERLIS-Modell:

Das Modell hat keinen Anspruch auf Vollständigkeit und Genialität. Wahrscheinlich fehlen noch ein paar Attribute, insbesondere müsste es sowohl Majorz- und Proporzwahlen abbilden können. Zuerst wollte ich mich an den eCH-Standard anlehnen. Den verstehe ich aber nicht so wirklich. Ich fühle mich damit genauso unwohl wie mit den eCH-Objektwesen-Standards. Ich finde sie massiv schlechter lesbar als INTERLIS-Modelle.

Mein INTERLIS-Modell ist sehr einfach gehalten. Trotzdem ist es natürlich nicht ganz so einfach wie die flache Exceldatei. Es gibt zwei Klassen: Gemeinde und Kandidaten. Die Gemeinde-Klasse beinhaltet Informationen zu einer Gemeinde, die Kandidaten-Klasse Informationen zu einem Kandidaten. Kandidat und Gemeinde stehen in einer Beziehung zueinander. Jeder Kandidat kann in jeder Gemeinde gewählt werden. Aus diesem Grund hat die Beziehung ein Stimmen-Attribut. Es beschreibt die Anzahl Stimmen, die ein Kandidat in einer Gemeinde geholt hat.

Mit ili2gpkg habe ich eine leere GeoPackage-Datei erstellt und die Zahlen aus dem Screenshot mit dbeaver übertragen. Das ging interessanterweise trotz der Beziehungen noch ganz entspannt, da dbeaver bei Fremdschlüsseln die möglichen Beziehungs-Records auflistet. Man kann anschliessend den zu verknüpfenden Record bequem mit einem Mausklick auswählen:

Nicht viel anstrengender als eine Exceldatei auszufüllen.

Was gewinnt das BFS damit? Es kann sowohl seine Microservices wie auch seine Excel-Importskripts wegwerfen. Wenn es die Geowelt hinkriegt, sollte auch das BFS eine standardisierte Lieferung hinkriegen. Trotz oder genau wegen des Föderalismus.

Interessant sind nun die Prüfmöglichkeiten, die dank INTERLIS gratis mitkommen:

Die Einfachsten sind die UNIQUE-Constraints. So darf die Gemeindenummer und die Kandidatenummer nur einmal pro Lieferung vorkommen (Kandidatenummer müsste wohl in Kombination mit Kanton geprüft werden). Die UNIQUE-Constraints helfen auch dabei, dass man in der Hitze des Gefechts eine Gemeinde nicht x-fach importiert.

Spannender sind die Constraints, die prüfen, ob das mitgelieferte Total gleich der Summe einzelner Werte ist. So bei den Stimmberechtigten, die als Total wie auch aufgeteilt in Frauen- und Männerstimmen, geliefert werden. Und bei bei den Wahlzetteln: Hier wird das Total geliefert, wie auch ungültige, leere etc. Die Constraints sind straight forward:

!!@ name=korrekteAnzahlStimmen
!!@ ilivalid.msg="Eingelegte Wahlzettel ungleich Summe leere, ungültige und in Betracht gezogene Wahlzettel."
MANDATORY CONSTRAINT Math.add(Math.add(leere_Wahlzettel, ungueltige_Wahlzettel), in_Betracht_Wahlzettel) == eingelegte_Wahlzettel;

!!@ name=korrekteSummeMaennerFrauen
!!@ ilivalid.msg="Anzahl Stimmberechtigte ungleich Summe Maenner und Frauen."
MANDATORY CONSTRAINT Math.add(Maenner, Frauen) == wahlberechtigt;

Das Rechnen mit Math.add etc. ist ziemlich noisy und es wird schnell unübersichtlich. Mit INTERLIS 2.4 geht dann auch + usw.

Das sind alles Constraints, die für jede kantonale Lieferung in identischer Form gelten würden. Was macht man, wenn man spezifisch pro Kanton etwas prüfen will. Eine einfache Variante sind Validierungsmodelle. Besagter Kanton schickt einen Nationalrat nach Bern. D.h. das Attribut gewaehlt in der Klasse Kandidat darf nur ein einziges Mal den Wert true aufweisen. Der für die Prüfung notwendige Constraint sieht so aus:

!!@ name = korrekteAnzahlGewaehlter
!!@ ilivalid.msg = "Anzahl gewählter Personen ist nicht korrekt."
SET CONSTRAINT WHERE gewaehlt : INTERLIS.objectCount(ALL) == 1;

Eine andere, zukünftige Variante ist die Verwendung von Runtime-Parameter. Man könnte den Constraint im Hauptmodell belassen und beim Prüfaufruf den für den Kanton korrekten Wert als Paramter mitliefern:

java -jar ilivalidator.jar \
--runtimeParams "CH_BFS_Wahlresultate_20231109.anzahlGewaehlteKandidaten=1"

Der Constraint hat Zugriff auf den Runtime-Parameter:

!!@ name = korrekteAnzahlGewaehlter
!!@ ilivalid.msg = "Anzahl gewählter Personen ist nicht korrekt."
SET CONSTRAINT WHERE gewaehlt : INTERLIS.objectCount(ALL) == PARAMETER CH_BFS_Wahlresultate_20231109.anzahlGewaehlteKandidaten;

Wer hätte das gedacht! INTERLIS hilft sogar bei der Publikation korrekter Wahlresultate. Spass beiseite. Ich bin auf den Bericht gespannt, der die ganze Sache untersuchen soll. Jedenfalls dünkt mich viel Optimierungspotenzial vorhanden. Die Vorteile mit INTERLIS liegen auf der Hand. Ein nicht ganz offensichtlicher Vorteil ist die gute Testbarkeit des gesamten Systems. Alles kann mit Testdaten bequem getestet werden und die Businesslogik ist nicht irgendwie verpackt in Skripts und Microservices, sondern in einem bestehenden Kommandozeilen-Werkzeug. Brauche ich wirklich Hipster-Microservices, kann ich die INTERLIS-Programmbibliotheken verwenden.

Die XTF-Datei zum Rumspielen und Provozieren von Fehlern kann heruntergeladen werden.

INTERLIS: ein Angebot auch für das BFS.

GeoServer Magie #2 - More GetFeatureInfo witchcraft

Fri, 3 Nov 2023 00:00:00 +0000

GeoServer war schon immer der WMS-Server der Herzen, also meines Herzens. Ganz zu Beginn (muss 2001 oder früher gewesen sein) hatten wir MapServer erfolgreich im Einsatz. GeoServer haben wir ein paar Jahre später für das Herstellen von grossformatigen PDF verwendet. Zu guter Letzt sind wir dem Marketing von QGIS-Server erlegen und haben auch diesen WMS-Server in Betrieb genommen.

Ein wichtiges Ziel bei der Einführung des neuen Web GIS Clients (2016 - 2018) war die Reduktion der WMS-Server auf einen. Die Wahl fiel auf QGIS-Server. Weil wir früher oder später beim Web GIS Client und sämtlichen Services und Umsystemen über die Bücher müssen, darf man sich jetzt GeoServer wieder ins Gedächtnis rufen.

Ich fand bei GeoServer immer gut, dass bereits viel mitkommt, das wir bei unserer Lösung zusätzlich programmieren lassen mussten, z.B.

Identity and Access Management
GUI für die Administration
Layergruppen zu einem Einzellayer gruppiert
Mächtige Konfigurationsmöglichenkeiten bei der GetFeatureInfo-Funktion

Und um diese Konfigurationsmöglichenkeiten geht es hier und jetzt. Ich habe bereits vor fünf Jahren davon geschwärmt und bin immer noch begeistert. Ich habe unsere Anforderungen an die Objektabfrage (die plusminus der GetFeatureInfo-Abfrage entspricht) rausgekramt und will wissen, wie das mit GeoServer ginge?

Anforderungen:

Aliasnamen: Die Attributnamen aus der Datenbank sollen überschrieben werden können.
Attribute sollen ausgeblendet resp. nicht angezeigt werden können.
Reihenfolge der Attribute muss konfigurierbar sein
Attributewerte sollen formatiert werden können. Z.B. «true» soll zu «Ja» formatiert werden.
Neue Attribute sollen hinzugefügt werden können, z.B. ein Link auf eine Fachanwendung. Der Link ist nicht in der Datenquelle vorhanden.
Der hinzukonfigurierte Link soll zudem verwendet werden können, um einen Report-Service aufzurufen. Dem Report-Service muss die Objekt-ID und die geklickte Koordinate mitgeliefert werden können.
Fotos (Link auf URL) sollen automatisch dargestellt werden (nur HTML-Output).
Allfällige JSON-Inhalte als Attributwert sollen als Key-Value gerendert werden (nur HTML-Output).
Templating Engine für sehr spezifische Outputs.
Beliebige SQL-Query: Das Resultat einer beliebigen SQL-Query wird als Key-Value in der GetFeatureInfo-Antwort zurückgeliefert.
Beliebige Businesslogik: Es wird selbst programmierter Code ausgeführt und das Resultat wird als Key-Value in der GetFeatureInfo-Antwort zurückgeliefert. Haben wir wenig überraschend wirklich nicht so gerne und noch weniger gerne als die SQL-Query.

Templating Engine

Wahrscheinlich das Wichtigste gleich zu Beginn: GetFeatureInfo-Antworten werden in GeoServer für die Formate GeoJSON und HTML mittels Freemarker Templates konfiguriert. Somit ist die Basis für viel Einflussnahme gelegt. Die Templates können global, pro Workspace oder für einen spezifischen Layer definiert werden.

Das Ziel ist natürlich ein möglichst generisches, globales Template herstellen zu können und nur für die absoluten Spezialfälle ein zusätzliches.

Aliasnamen / Attribute ausblenden / Reihenfolge

Diese drei Anforderungen können seit Version 2.21.0 leicht umgesetzt werden:

Der Attributnamen «schoener_Stein» wird zu «Schöner Stein». Mit den Pfeilen kann man die Reihenfolge ändern und mit dem roten Button, kann man Attribute entfernen. Hat jetzt noch Luft nach oben, was die Benutzerfreundlichkeit betrifft: Ich würde lieber ein Attribut visuell «disablen» und nicht löschen. Und die Reihenfolge möchte ich mit Drag 'n' Drop verändern.

Wenn man die Attributnamen verändert, muss man unbedingt wissen, dass der XML/GML-Output nicht mehr zwingend funktioniert. GeoServer sendet eine WFS-FeatureCollection zurück. Attribute landen in XML-Tags. Was natürlich mit Umlauten und Leerzeichen nicht mehr funktioniert. Die erlaubten Antwortformate lassen sich aber in GeoServer konfigurieren.

Attributwerte formatieren

Inbesondere bei Boolean-Werten hat man das Bedürfnis diese anders als true/false zu rendern. Hier helfen uns die Filter-Funktionen. Mit diesen lassen sich die Attributwerte verändern. Im folgenden Beispiel wird zuerst geprüft, ob der Werte null ist und anschliessend findet die eigentliche Umwandlung in den «schönen» String statt:

Neue Attribute

Wozu braucht man das? Wir verlinken regelmässig in der Antwort einer Objektabfrage zu anderen Fachanwendungen. Ein gutes Beispiel sind die Grundstücke. Klickt man auf das Grundstück, wird zusätzlich ein Link auf die Grundbuch-Webanwenwendung (Intercapi) gerendert:

Dieser Link soll nicht Bestandteil der eigentlichen Daten sein und er muss dynamisch sein. D.h. der Query-Parameter des Links ändert sich bei jedem Grundstück (z.B. ?egrid=CH270670353285), damit man direkt beim angewählten Grundstück in der Fachanwendung landet. Stand heute machen wird das mit einem zusätzlichen, speziellen Jinja-Template. Mit GeoServer geht das einfacher: neue Attribute können mit «Add attribute» hinzugefügt werden. Mit den bereits erwähnten Filterfunktionen und dem Zugriff auf andere Attribute (hier «egrid») kann der Link einfach zusammengestöpselt werden:

Objekt-ID und geklickte Koordinate

Wir haben einen eigenen Report-Service, der Zusatzinformationen zu Objekten als PDF oder Excel zurückliefert (siehe Objektblatt-Link).

Dem Report-Service muss man die Objekt-ID (des geklickten Objekts) und/oder die geklickte Koordinate übergeben:

https://geo.so.ch/api/v1/document/afu_bodenprofilstandorte?feature=10632&x=2604491.665269116&y=1228356.537479993&crs=EPSG%3A2056

Was der Report-Service mit diesen Informationen macht, ist ihm überlassen. Heute können wir in unserer Administrationsanwendung die (Jasper-)Reports direkt einem WMS-Layer zuweisen. Mit GeoServer würde man den Link wie oben als zusätzliches Attribut erfassen. Was aber noch fehlt, ist die geklickte Koordinate. Diese muss als Platzhalter im Link erfasst werden und kann im Freemarker Template zur Laufzeit berechnet und der Platzhalter ersetzt werden. Im Freemarker Template stehen gewisse Informationen immer zur Verfügung. So z.B. die GetFeatureInfo-Request-URL. Aus dieser lässt sich die geklickte Koordinate berechnen und dem Link hinzufügen. Das kann im globalen Template gemacht werden.

Fotos rendern

Im globalen Template kann geprüft werden, ob ein Link auf ein Foto zeigt. Mehr oder weniger muss nur die Endung geprüft werden. Ist es kein Foto, wird nur der Link gerendert, sonst das Bild.

JSON-Inhalte rendern

Objekte weisen bei uns manchmal Attribute auf, deren Inhalt JSON ist. Das rührt daher, dass einem Objekt z.B. mehrere Dokumente (mit den Attributen Link, Titel, offizielle Nummer, …) zugewiesen sind. Das lösen wir so, dass wir diese unbekannte Anzahl an Dokumenten als JSON im Attribut kodieren. In der GetFeatureInfo-Antwort soll aber kein JSON-String stehen, sondern wie alle anderen Attribute im Key-Value-Stil gerendert werden. Auch diese Anforderung kann direkt in einem globalen Template gelöst werden. Herausfordernd ist, herauszufinden, ob es sich um JSON handelt oder um einen normalen String. Freemarker sieht in beiden Fällen nur einen String (weil GeoServer das bereits umwandelt).

Beliebige SQL-Query / Businesslogik

In ganz wenigen Ausnahmefällen müssen wir Informationen zurückliefern, die nicht direkt vom geklickten Layer stammen. Für diesen Use Case haben wir zwei Lösungsvarianten: Wir können beliebiges SQL ausführen oder beliebigen Python-Code. Bei beiden Varianten gibt es sowas wie ein Interface, das implementiert werden muss, damit es generisch funktioniert.

Für GeoServer prototypisch umgesetzt habe ich nur die SQL-Variante. Vom Prinzip her ist die Python-Variante (in unserem Fall natürlich Java) sehr ähnlich. Freemarker Templates erlauben das Ausführen von beliebigen statischen Java-Methoden. Diese müssen aber vorgängig explizit (aus Sicherheitsgründen) freigeschaltet werden. Wir schreiben einmalig eine Java-Klasse mit einer statischen Methode, die eine SQL-Query ausführt. Die SQL-Query steht in einer Datei, die z.B. in das GeoServer-Data-Directory kopiert wird. Die Java-Methode sucht anhand der Parameter die Datei und führt die SQL-Query aus und retourniert die Antwort als Liste von Maps.

Gratis bekommt man zudem das DB-Connection-Pooling, weil man die Datasource via JNDI definiert. Wir teilen uns somit mit GeoServer den Connection Pool.

Man könnte sogar soweit gehen, diese Logik in das generische, globale Freemarker Template zu integrieren. Ist meines Erachtens wahrscheinlich nicht sinnvoll, weil somit jeder GetFeatureInfo-Request zuerst prüft, ob eine solche SQL-Query ausführt werden muss.

Fazit

GeoServer bietet sehr mächtige Konfigurationsmöglichenkeiten im Bereich des GetFeatureInfo-Requests an. Einiges, das wir benötigen und speziell entwickeln liessen, gibt es hier out-of-the-box.

INTERLIS leicht gemacht #38 - ilishaper: shape your ili

Wed, 20 Sep 2023 00:00:00 +0000

Es gibt (bald) ein neues INTERLIS-Werkzeug und es heisst ilishaper (jaja, ich höre die Häme bereits: «shape…»). Ilishaper hat zwei Funktionen:

Die erste Funktion betrifft die INTERLIS-Modelldatei. Man kann aus einem Modell ein weiteres, reduziertes Modell ableiten. Dabei lassen sich Attribute, ganze Klassen und ganze Topics abstreifen. Dazu benötigt es eine Konfigurationsdatei:

[Basismodell]
name=Derivatmodell
issuer=mailto:test@host
version=2023-01-01
doc=Neu generiertes Modell

[Basismodell.TopicT1.ClassA.Attr1]
ignore=true

[Basismodell.TopicT1.ClassB]
ignore=true

[Basismodell.TopicT2]
ignore=true

[Basismodell.TopicT1.ClassA]
filter=Attr5==#rot

Die Syntax dünkt mich mehr oder weniger selbsterklärend. Die ersten paar Zeilen betreffen die Modellinformationen: Man kann den Namen des Modells bestimmen und weitere Meta-Attribute. Interessant sind die letzten beiden Zeilen: Mit diesen lassen sich auch Objekte filtern. Im vorliegenden Fall werden sämtliche Objekte gefiltert, die den Aufzähltypwert #rot aufweisen. Das führt zur zweiten Funktion von ilishaper. Das Filtern hat ja keine Auswirkung beim Herstellen des Derivatmodelles, sondern erst wenn auch die INTERLIS-Transferdatei vom Basismodell ins Derivatmodell von ilishaper «geshaped» wird. Somit wird es möglich sein sowohl Zeilen wie auch Spalten abzustreifen.

Warum brauchen wir so was?

Die meisten unserer Geodaten sind öffentlich und frei verfügbar. Einige der Themen weisen jedoch teilweise geschützte Daten auf. Der Klassiker: eine Telefonnummer. Diese Information darf die Öffentlichkeit nicht sehen und ist nur für den internen Gebrauch. Auf Service-Stufe (also WMS etc.) haben wir das applikatorisch gelöst (im QGIS-Server). Bei der Bereitstellung der Geodaten als Datei (XTF, GeoPackage etc.) hatten wir keine Lösung. Der erste Ansatz, den wir verfolgten, war Vererbung. Wir modellierten das Modell mit den öffentlichen Informationen und dazu ein erweitertes Modell mit den zusätzlichen Informationen, die nicht öffentlich sind. Man ist nun in der Lage mit ili2pg Daten gemäss beiden Modellen zu exportieren (was eigentlich recht abgefahren ist). Ein Beispiel aus dem Fundus:

INTERLIS 2.3;

MODEL SO_ALW_Bienenstandorte_20210529 (de)
AT "https://alw.so.ch"
VERSION "2021-05-26"  =
  IMPORTS GeometryCHLV95_V1;

  TOPIC Bienenstandorte =
    OID AS INTERLIS.UUIDOID;

    /** Bienenstandort (public)
     */
    CLASS Bienenstandort =
      /** Nummer
       */
      Nummer : MANDATORY TEXT*16;
      /** Standort
       */
      Standort : MANDATORY GeometryCHLV95_V1.Coord2;
      /** Bemerkung
       */
      Bemerkung : TEXT*200;
    END Bienenstandort;

  END Bienenstandorte;

END SO_ALW_Bienenstandorte_20210529.

MODEL SO_ALW_Bienenstandorte_protected_20210529 (de)
AT "mailto:stefan@localhost"
VERSION "2021-05-29"  =
  IMPORTS SO_ALW_Bienenstandorte_20210529;

  TOPIC Bienenstandorte
  EXTENDS SO_ALW_Bienenstandorte_20210529.Bienenstandorte =

    /** Bienenstandort mit allen (inkl. nicht-öffentlichen) Attributen.
     */
    CLASS Bienenstandort (EXTENDED) =
      /** Name des Imkers
       */
      Name : MANDATORY TEXT*255;
      /** Telefonnummer
       */
      Telefonnummer : TEXT*20;
    END Bienenstandort;

  END Bienenstandorte;

END SO_ALW_Bienenstandorte_protected_20210529.

Wenn wir das Modell mit ili2pg in der Datenbank abbilden, entsteht zwar trotz Vererbung mit passender Abbildungsregel nur eine Tabelle. Jedoch entstehen auch zwei zusätzliche Spalten t_basket und t_type:

Die t_type-Spalte schmerzt mich nicht sonderlich, das ist eine Konstante. Was mich mehr stört und nervt ist die t_basket-Spalte, um die ich mich kümmern muss. Es ist ein Fremdschlüssel zur t_ili2db_basket-Tabelle. Ich kann also nicht irgendwas reinschreiben. Und hier liegt der wirkliche Hund begraben: Zu den oben dargestellten Modellen (sogenannte flache Publikationsmodelle) gibt es bei uns in der Regel auch immer ein sauber normalisiertes Erfassungsmodell. Die Publikation vom Erfassungs- in das Publikationsmodell machen wir mit SQL. Und nun muss man sich plötzlich ziemlich mühsam (v.a. bei umfangreicheren Modellen) um diesen Fremdschlüssel kümmern. Und warum? Weil ich die Telefonnummer nicht publizieren will. Man muss also einen ziemlichen Handstand machen (Vererbung, zwei Modelle, komplizierter Datenumbau), um ein Attribut loszuwerden. Die Idee von ilishaper ist eben auch, diesen Prozess viel transparenter zu machen: man konfiguriert das Abstreifen eines Attributes in der Konfig-Datei und muss sich nicht um Baskets kümmern. Scheint mir so eine viel «expressivere» Lösung für das Problem zu sein. Zudem kann man mit dem Vererbungsmeccano nicht Zeilen filtern, was bei uns ebenfalls ab und wann verlangt wird.

Wir werden zukünftig ein Erfassungmodell machen, das nicht weiss, ob z.B. ein Attribut öffentlich oder nicht-öffentlich ist. Weiter werden wir ein Publikationsmodell mit öffentlichen und nicht-öffentlichen Daten erstellen. Dieses Publikationsmodell persistieren wir in der Datenbank und es dient ebenfalls für die Publikation der Daten als Service (siehe oben, Problem applikatorisch gelöst). Aus diesem Publikationsmodell erstellen wir einmalig das reduzierte Publikationsmodell mit den öffentlichen Daten. Das Modell verschwindet natürlich nicht wieder, sondern wird genauso, wie alle anderen Modellen in der INTERLIS-Modellablage publiziert. Nach dem Export der Daten in das Publikationsmodell kommt der ilishaper zum Zuge und wandelt die Transferdatei in das reduzierte Publikationsmodell um, das jedermann zur Verfügung stehen wird.

Klar, es entsteht auch wieder Konfiguration aber trotzdem scheint mir dieses Vorgehen transparenter, einfacher und auch skalierbarer (unterschiedliche Derivatmodelle) zu sein.

ÖREB-Kataster richtig gemacht #15 - ÖREB-Proxy-Service

Mon, 14 Aug 2023 00:00:00 +0000

Update 2023-08-17: Die Suche eines EGRID mittels Adresse funktioniert. Was nicht geht ist die Suche mittels NBIdent und GB-Nummer. Das scheint mir die Api nicht herzugeben.

Es gibt 27 ÖREB-Webservices. Jeder Webservice ist unter einer anderen URL erreichbar. Wenn ich als Kunde nicht nur in einem Kanton ÖREB-Katasterauszüge beziehen wollte, fände ich diesen Umstand bemühend. Ich muss 27 Endpunkte verwalten und vor allem muss ich bei jeder Koordinate oder jedem EGRID irgendwie herausfinden, welchen Service/Kanton ich nun verwenden muss. Es muss ein ÖREB-Proxy her, der die standardisierten Requests entgegennimmt und nachdem er herausgefunden hat, welcher Kanton betroffen ist, den Request ausführt und die Antwort an den Client zurückliefert. Ein erster Prototyp (oder im Solothurnischen Neusprech: Rocksolide Top-of-the-Pops-Application, also Champions League) steht: https://proxy.oereb.services.

Ein paar Testrequests:

https://proxy.oereb.services/getegrid/xml/?EN=2600595,1215629 (Solothurn)
https://proxy.oereb.services/getegrid/xml/?EN=2757735,1224129 (Liechtenstein)
https://proxy.oereb.services/getegrid/xml/?GNSS=7.44646,47.09171 (Solothurn)
https://proxy.oereb.services/extract/xml/?EGRID=CH807306583219 (Solothurn)
https://proxy.oereb.services/extract/xml/?EGRID=CH767982496078 (Basel-Landschaft)

Den Quellcode ist auf Github.

Was wird unterstützt?

Es wird nur XML und PDF als Format unterstützt. XML ist im Gegensatz zu JSON zwingend und es gibt mindestens zwei Kantone, die JSON nicht anbieten. Es werden die Requests «GetEgrid» und «Extract» angeboten. Die beiden anderen könnte man aber problemlos noch umsetzen. Es funktionieren auch nicht ganz alle Aufrufe. Der GetEgrid-Request mit einer Adresse geht nicht. Dazu später gleich mehr.

Es sollten alle Kantone freigeschaltet sein, die den Kataster in der Version 2 anbieten (und Fürstentum Liechtenstein). Falls der Request ein Kanton betrifft, der nicht gefunden wird, wird der Statuscode 204 zurückgeliefert.

Umgesetzt habe ich es mit Spring Boot. Das Ganze mit GraalVM in ein Native Binary runterkompiliert. So startet die Java-Anwendung in 0.06 Sekunden und braucht massiv weniger RAM.

Der Service selber ist bewusst dumm gehalten. Er soll nur Requests entgegennehmen und beim betroffenen Kanton den Auszug anfordern. Die Antwort wird nicht verändert. Es gibt zusätzlich einen «redirect»-Modus. In diesem Fall wird der betroffene Kanton eruiert und anschliessend wird zum kantonalen ÖREB-Webservice weitergeleitet. Das hat den Nachteil, dass Geschichten wie CORS wieder Probleme machen könnten.

Die Hauptschwierigkeit liegt eigentlich darin herauszufinden, welcher Kanton betroffen ist. Wenn man bei der GetEgrid-Anfrage beginnt, muss man den Kanton anhand einer Koordinate herausfinden. Ich habe das früher für meinen Viewer mit sequenzieller und auch paralleler Abfrage aller Kantonsservices probiert. Das geht viel zu lange. Wenn ich schon von 27 Services abhängig bin, kann ich mich auch noch von einem weiteren Service abhängig machen: Die GeoAdmin API. Man muss zwar im vielfälltigen Angebot suchen, bis man den passenden Dienst hat. Aber danach klappt es einwandfrei. Die Koordinate beim GetEgrid-Request kann auch als WGS84 geliefert werden. Dafür gibt es von Swisstopo ebenfalls einen Dienst. Warum dieser jedoch nicht unter der GeoAdmin API dokumentiert ist, weiss ich nicht. Für die Variante mit der Adresse (Ortschaft, Strasse, Hausnummer) habe ich keine Variante gefunden, die mir eindeutig den EGRID zurückliefert. Anyone?

Wenn man den EGRID hat und den eigentlichen Auszug bestellen will, muss man anhand des EGRID den betroffenen Kanton eruieren. Auch das geht mit der GeoAdmin API.

Und das wars eigentlich auch schon. Mit geodienste.ch[geodienste.ch] kann ich an einer Stelle die MGDM (Daten und Dienste) beziehen. Warum soll das nicht auch für den ÖREB-Kataster möglich sein?

OGD made easy #3 - Visualisierung und Data Crunching

Sun, 13 Aug 2023 00:00:00 +0000

Teil 1 und 2 behandeln die Integration und Bereitstellung von OGD-Daten. Viele Dienststellen möchten ihre Daten aber auch visualisiert haben. Insbesondere wenn es darum geht die Gemeindeflächen z.B. nach Steuerlast einzufärben (Choroplethenkarte), gelangen sie zu uns. Das ist bei uns jeweils immer bisschen Handarbeit und wir wünschten uns was Effizienteres. Wir hatten früher eine Lösung mit Excel, welche aber Maintenance-Hell war und wieder verschwunden ist. Eins vorneweg: Gefunden habe ich die perfekte Lösung noch nicht, sondern es ging mir ums Kennenlernen und Ausloten bestehender Lösungen für klassische (nicht-kartografische) Visualisierungen.

Ich bin Anfang des Jahres über Dashbuilder gestolpert. Jetzt im Rahmen dieser Rumspielerei war der passende Anlass es auszuprobieren. Das Ausprobieren gestaltete sich aber relativ schwierig. Ich hatte extrem Mühe den Einstieg zu finden. Anscheinend ist da sehr viel im Fluss und m.E. leidet darunter die Dokumentation, was es natürlich für Aussenstehende wiederum schwieriger macht (z.B. Ankündigugen von Neuerungen in Blogs, die schon wieder passé sind). Zuerst gab es sowas wie einen visuellen Dashboardbuilder. Dieser ist - soweit ich es eben verstanden habe - Geschichte. Es brauchte auch eine Runtime, auf die man die zusammengebastelten Visualisierungen deployen konnte (musste?). Auch diese ist nicht mehr nötig. Neu schreibt man sein Zeugs nur noch mit YAML. Diese Kröte könnte man ja noch Schlucken, wenn es top-notch dokumentiert wäre. Ist es aber nicht. Ich habe die Übung mit Dashbuilder abgebrochen und bin umgeschwenkt auf was Anderes.

Jeder Kubernetes- oder OpenShift-Leidgeplagte kennt es wohl: Grafana. Grafana sagt von sich: «Grafana is the leading open source visualization and dashboarding platform that allows you to query, visualize, alert on, and understand your data no matter where it’s stored.» Klingt schon mal nicht schlecht. Vorsicht ist immer geboten, wenn ein OSS-Produkt nur von einer Firma bewirtschaftet wird. Das kann auch böse enden oder zumindest zu Unsicherheiten führen (siehe HashiCorp). Da ist z.B. QGIS bezüglich OSS schon ein anderes Kaliber.

Unsere OGD-Daten haben wir von CSV nach Parquet und Excel umformatiert. Wie sieht es damit in Grafana aus? Eher mau. Es gibt zwar unzählige Datenquellen, die man anzapfen kann. Aber Parquet ist nicht darunter. Wenn man nicht gleich «all in» via PostgreSQL gehen will, bleibt fast nur noch CSV mit dem Infinity-Plugin. Hier natürlich sehr nervig, weil man entweder explizit den Datentyp casten muss oder aufpassen muss, dass Grafana resp. das Plugin den Datentyp aus dem CSV korrekt erkennt. Die Gestaltungsmöglichkeiten sind umfrangreich und die Dokumentation ist gut:

Als Vergleich dazu die Grafik aus der heute bereitgestellten Exceldatei.

Man kann Grafana-Dashboards der Öffentlichkeit ohne Login bereitstellen (Beta-Feature) oder es besteht die Möglichkeit, dass Teile davon als iFrame von anderen Anwendungen eingebunden werden können.

Ein ebenso spannender Aspekt ist das Data Crunching. Wir sind bei uns in der Geoinformation SQL-zentrisch unterwegs. GIS-Analysen etc. finden immer in der Datenbank statt (Dank Docker auch mal in einer Jenkins-Pipeline). Geht SQL-mässig auch was, ohne die Daten in PostgreSQL zu importieren?

Weil technisch faszinierend, habe ich zuerst Apache Drill ausprobiert. Man kann damit praktisch jede erdenkliche NoSQL-Datenbank mit richtigem SQL (nicht irgendein Pseudo-Dialekt) ansprechen und zudem die Quellen verwalten. Es ist also möglich z.B. Parquet-Dateien auf S3 mit SQL abzufragen, wenn sie in Apache Drill freigeschaltet (oder je nach Sichtweise registriert) sind. Kann man gut finden oder auch schlecht. Kommt wohl auf die Anforderungen darauf an. Als Einzelbenutzer wäre mir so eine Verwaltung egal. Wenn jemand Apache Drill als Software in einer Organisation zur Verfügung stellt, will man wahrscheinlich sowas. Damit nicht zu viel Schabernack gemacht wird. Drill lässt sich Standalone betreiben oder in einem mehr oder weniger aufwändigen Setup mit Zookeeper. Dann sind mehrere «Drillbits» möglich, um die Last besser zu verteilen. Interessant ist Drill auch, weil es einen JDBC- und ODBC-Treiber gibt. Ich kann somit sämtliche registrierten Datenquellen in beliebigen Anwendungen mit SQL abfragen (z.B. dbeaver oder klassische BI-Werkzeuge). Neben all diesem steht auch eine einfache Konsole zur Verfügung, in der ich die SQL-Statements absetzen kann:

SELECT * FROM s3.`ch.so.afu.abfallmengen_gemeinden.parquet`;

Wobei s3 hier nur für den Namen des Storages dient und es nicht zwingend s3 heissen muss für Daten auf S3. Man kann sich das vielleicht wie einen Schemanamen vorstellen.

Die Antwort wird in 0.8 Sekunden zurückgeliefert:

Man kann auch zwischen beliebigen Quellen joinen:

SELECT
    *
FROM
    s3.`ch.so.afu.abfallmengen_gemeinden.parquet` AS abfall
    LEFT JOIN s3.`ch.so.agi.amtliche_vermessung_statistik.umsatz.parquet` AS av_umsatz
    ON av_umsatz.jahr = abfall.jahr
;

(Und ja, die Query hier ist sinnfrei.)

Die Ausführung der Query dauert circa 1.5 Sekunden.

Exports von Datanalysen in verschiedene Formate sind möglich. Erwähnenswert ist, dass man neben der Vielzahl von NoSQL-Datenbanken eben auch normale relationale Datenbanken ansprechen kann (solange es einen JDBC-Treiber gibt). Damit liessen sich Abfragen zwischen Parquet-Daten in einem Data Swamp und einem klassischen Datawarehouse machen.

Ein klein wenig mulmiges Gefühl bekomme ich, wenn ich mir die Performance anschaue. Sollten die Queries komplexer werden, weiss ich nicht, ob die Antwortzeiten komplett durch die Decke gehen.

Was wäre Data Crunching mit SQL, wenn man nicht auch DuckDB anschauen würde? DuckDB ist quasi die Datenbank to go. Ein einziges Binary und fertig. Standardmässig werden erzeugte Tabellen nicht auf die Harddisk persistiert und man kann verschiedene Formate prozessieren, ohne sie importieren zu müssen. Es gibt auch einen JDBC-Treiber, um z.B. dbeaver als Client zu verwenden. Es ist aber kein reiner Java-Treiber, sondern es werden für verschiedene Betriebssystem Binaries in die Jar-Datei gepackt (wie beim SQLite-Treiber). Darum ist sie über 50MB gross. Aber es funktioniert tadellos.

Die letzten vier Dateien in der Auflistung sind die Binaries für Linux (amd und arm), Windows und macOS.

Um Parquet-Dateien auf S3 abzufragen, muss man zuerst einmalig die HTTPFS-Extension installieren und laden:

INSTALL httpfs;
LOAD httpfs;

Anschliessend kann man beliebige Dateien, die via HTTP greifbar sind, abfragen:

Die Abfrage dauert circa 0.2 Sekunden. Der unsinnige Join mit der Statistik der amtlichen Vermessung sieht nun so aus:

SELECT
    *
FROM
    read_parquet('https://s3.eu-central-1.amazonaws.com/ch.so.data-dev/ch.so.afu.abfallmengen_gemeinden.parquet') AS abfall
    LEFT JOIN read_parquet('https://s3.eu-central-1.amazonaws.com/ch.so.data-dev/ch.so.agi.amtliche_vermessung_statistik.umsatz.parquet') AS av_umsatz
    ON av_umsatz.jahr = abfall.jahr
;

Die Query dauert nur 0.3 Sekunden. Was fast Faktor 5 schneller ist als mit Apache Drill. Woran es liegt, weiss ich nicht. Ich würde darauf tippen, das bereits die Umgehung des S3-Protokolls einen gewissen Einfluss hat. Nomen est omen: OGD-Daten sind frei verfügbar. Das ganze S3-Berechtigungs-Gedöns ist in diesem Fall nicht notwendig und es sind schlicht Dateien, die via HTTP lesbar sind.

Daten (als erzeugte Tabellen) können exportiert (lokal in verschiedene Formate oder auch nach S3) werden. Es gibt eine Spatial-Extension, die GIS-Operationen implementiert. Und man kann sogar GDAL-Formate verwenden. Ziemlich abgefahren alles. Ganz frisch ist Motherduck, wo Kollaboration und Cloud eine Rolle spielen sollen.

R würde sich für Data Crunching auch noch eignen. Hier fehlt mir irgendwie immer noch der Zugang. Für coole Dashboards könnte/müsste man sich zudem Apache Superset anschauen.

OGD made easy #2 - Datenintegration und -publikation

Thu, 20 Jul 2023 00:00:00 +0000

Im ersten Teil ging es um die Umwandlung von CSV-Dateien in das Parquet-Format und um die Prüfung der CSV-Dateien mit einem CLI-Tool. Nun kann das CLI-Tool zwar zweckdienlich sein, aber für die automatisierte Integration in eine Dateninfrastruktur reicht es nicht und passt nicht in unseren Stack. Wir benötigten die Funktionalitäten als Gradle-Task in unserem ETL-Werkzeug GRETL. Gesagt, getan: es gibt nun drei neue GRETL-Tasks:

Die ersten Beiden wandeln eine CSV-Datei in eine Parquet- resp. Excel-Datei um. Dabei wird - falls vorhanden - ein INTERLIS-Modell zwecks Bestimmung der Datentypen berücksichtigt. Der dritte Task erstellt aus einer TOML-Datei mit minimalen Metainformationen (Titel, Beschreibung, Datumsangaben, Zuständigkeiten) und dem Datenmodell eine Datei mit sämtlichen Metainformationen im INTERLIS-Format. Das Datenmodell ist angelehnt an DCAT-AP CH.

Ein Intergrations-GRETL-Job sieht folgendermassen aus:

import ch.so.agi.gretl.tasks.*
import java.nio.file.Files
import java.nio.file.Paths
import de.undercouch.gradle.tasks.download.Download

apply plugin: 'ch.so.agi.gretl'

defaultTasks "runIntegrationJob"

def pathToTempFolder = System.getProperty("java.io.tmpdir")
def resultDir = file("./result")
resultDir.mkdirs()

def csvFileName = "ch.so.afu.abfallmengen_gemeinden.csv"
def baseName = "ch.so.afu.abfallmengen_gemeinden"
def csvFileObj = file(Paths.get(resultDir.toString(), csvFileName))
def parquetFileName = baseName + ".parquet"
def excelFileName = baseName + ".xlsx"
def tomlFileName = baseName + ".toml"
def bucket = "ch.so.data-dev"
def modelName = "SO_AFU_Abfallmengen_Gemeinden_20230629"
def defaultModelDir = projectDir.toString()+";https://geo.so.ch/models"

// Könnte auch Upload durch Benutzer sein.
tasks.register('downloadCsv', Download) {
    src "https://s3.eu-central-1.amazonaws.com/ch.so.data.ingress-demo/$baseName/$csvFileName"
    dest csvFileObj
    overwrite true

    doLast {
        println "File downloaded to: " + pathToTempFolder
    }
}

tasks.register('validateCsv', CsvValidator) {
    dependsOn 'downloadCsv'
    dataFiles = [csvFileObj.toString()]
    firstLineIsHeader = true
    valueDelimiter = null
    valueSeparator = ";"
    models = modelName
    modeldir = defaultModelDir
}

tasks.register('createParquet', Csv2Parquet) {
    dependsOn 'validateCsv'
    csvFile = csvFileObj
    firstLineIsHeader = true
    valueDelimiter = null
    valueSeparator = ";"
    models = modelName
    modeldir = defaultModelDir
    outputDir = file(resultDir)
}

tasks.register('createExcel', Csv2Excel) {
    dependsOn 'createParquet'
    csvFile = csvFileObj
    firstLineIsHeader = true
    valueDelimiter = null
    valueSeparator = ";"
    models = modelName
    modeldir = defaultModelDir
    outputDir = file(resultDir)
}

tasks.register('createMeta', OgdMetaPublisher) {
    dependsOn 'createExcel'
    configFile = file(tomlFileName)
    outputDir = resultDir
}

tasks.register('uploadFiles', S3Upload) {
    dependsOn 'createMeta'
    accessKey = awsAccessKeyAgi
    secretKey = awsSecretAccessKeyAgi
    sourceFiles = fileTree(resultDir) { include "*.parquet" include "*.xlsx" include "*.csv" include "*.xtf" }
    endPoint = "https://s3.eu-central-1.amazonaws.com"
    region = "eu-central-1"
    bucketName = bucket
    acl = "public-read"
}

tasks.register('runIntegrationJob') {
    dependsOn 'uploadFiles'
}

Die einzelnen Tasks führen überschaubare Aufgaben aus. Also z.B. Datei herunterladen oder CSV-Datei nach Excel umwandeln. Grundsätzlich gestalten wir unsere GRETL-Tasks immer so. Für die Geodatenpublikation haben wir jedoch einen sehr umfassenden «Publisher»-Task entwickeln lassen. Dieser exportiert die Daten aus der Datenbank, prüft diese, wandelt sie in unterschiedliche Format um und lädt die Dateien auf einen SFTP-Server. Dieser Task ist zwar sehr umfangreich aber er muss für unsere circa 150 Geodaten-Themen immer das Gleiche machen. Uns so kann es durchaus sinnvoll sein, einen sehr spezifischen und umfangreichen Task vorzuhalten. Auch im vorliegenden Fall könnte man früher oder später auf die Idee kommen, die Umwandlung der CSV-Datei, die Erstellung der Meta-Datei und das Hochladen zu kombinieren, da immer gleich.

Als Ausführungsplattform und Orchestrator von GRETL-Jobs verwenden wir bei uns Jenkins. Wir sind immer noch sehr zufrieden. Insbesondere mit der Flexibilität und den vielen Möglichkeiten, die man mit Jenkins hat. Andere verwenden z.B. GitLab. Das ist so einfach möglich, weil GRETL letzten Endes nichts anderes ist als ein Gradle-Build-Job. D.h. man benötigt Gradle und Java. Am besten packt man sämtliche Abhängigkeiten in ein Docker-Image und schon hat man eine eigene GRETL-Runtime, die nur Docker benötigt. Um den Integrationsprozess zu testen (gut, könnte man auch lokal) und weil Jenkins und GitLab durch sind, probiere ich es noch mit GitHub Actions. Dazu mache ich mir ein GitHub-Repo mit sämtlichen Integrationsjobs. Zusätzlich benötige ich die Konfiguration der Action (aka Pipeline). Die Action-Konfiguration ist einfach und besteht aus einem parametrisierten Gradle-Job-Aufruf (Zeile 25). Der Benutzer muss beim Start den Job-Namen eintippen und dieser wird zur Laufzeit in der Action verwendet und es wird der gewünschte Integrationsjob ausgeführt. Im Job muss ein Standardtask (defaultTask) definiert werden. Die Actionkonfiguration sieht so aus:

name: ogd-job
on:
  workflow_dispatch:
    inputs:
      version:
        description: 'identifier?'
        required: true

jobs:
  dataIntegration:
    env:
      ORG_GRADLE_PROJECT_awsAccessKeyAgi: ${{secrets.AWS_ACCESS_KEY_ID}}
      ORG_GRADLE_PROJECT_awsSecretAccessKeyAgi: ${{secrets.AWS_SECRET_ACCESS_KEY}}

    runs-on: ubuntu-latest

    container:
      image: sogis/gretl:latest

    steps:
      - uses: actions/checkout@v3

      - name: Run GRETL job
        run: |
          gradle -b ${{ github.event.inputs.version }}/build.gradle --init-script /home/gradle/init.gradle --no-daemon

Das Interessante sind die Zeilen 17 und 18. Hier wird definiert in welchem Container der Job laufen soll. Wir wählen unser GRETL-Image. Nachfolgende Action-Steps werden direkt in diesem Container ausgeführt. Wir könnten auch ohne Dockerimage auskommen. Dann müssen aber die Abhängigkeiten von GRETL (als Gradle-Plugin) aus verschiedenen Maven-Repositories herunterladen werden, d.h. die Repositories müssen online sein. Mit Docker-Container dünkt es mich eleganter und zuverlässiger.

Die Daten und die Meta-Dateien liegen nach der Integration auf einer öffentlich zugänglichen Ablage (hier S3). Um den Zugang niederschwelliger zu gestalten, ist ein kleines Frontend sicher nicht verkehrt. Dazu verwende ich als Grundlage einfach die Anwendung, die Rahmen unseres neuen Datenbezuges entstand. Et voilà: https://sogis-sodata-ogd-vli2k.ondigitalocean.app/.

Die Anwendung wurde mit GWT und Spring Boot umgesetzt. Die während der Integration hergestellten Meta-Dateien werden geparsed und die notwendigen Informationen landen in einem Lucene-Index (man geniesse und schätze das old school Webseiten-Layout!) für die Suche. Weil es sich bei den Meta-Dateien um INTERLIS-Transferdateien handelt, kann ich zum Parsen iox-ili verwenden. Damit habe ich Zugriff auf die einzelnen Transferobjekte. Die Kommunikation (also die Antwort auf eine Suchanfrage) zwischen Client und Server basiert auf JSON. Aus diesem Grund muss ich aus dem geparsten XTF JSON-Objekte resp. -Strings herstellen können. Kostet mich nicht mehr als:

IoxEvent event = xtfReader.read();
while (event instanceof IoxEvent) {
    if (event instanceof ObjectEvent) {
        ObjectEvent objectEvent = (ObjectEvent) event;
        IomObject iomObj = objectEvent.getIomObject();
        IomObject[] iomObjects = new IomObject[] {iomObj};
        Writer writer = new StringWriter();
        JsonGenerator jg = objectMapper.createGenerator(writer);
        Iox2jsonUtility.write(jg, iomObjects, td);
        jg.flush();
        jg.close();
        String jsonString = writer.toString();
        // do something with jsonString
    }
    event = xtfReader.read();
}

Für die Umwandlung eines Iom-Objektes in einen JSON-String gibt es die Klasse Iox2jsonUtility. Es wird immer ein zusätzliche Attribut @type erzeugt, welches der INTERLIS-Klasse (oder -Struktur) entspricht. Bei Objekten (im Gegensatz zu Strukturen) gibt es ein weiteres Zusatzattribut @id, welches der TID entspricht:

[
  {
    "@type": "SO_OGD_Metadata_20230629.Datasets.Dataset",
    "@id": "ch.so.agi.amtliche_vermessung_statistik",
    "Identifier": "ch.so.agi.amtliche_vermessung_statistik",
    "Title": "Statistische Kennzahlen der amtlichen Vermessung",
    "Description": "Statistische Kennzahlen der amtlichen Vermessung über Personal und Umsatz in den Jahren 1983 bis 2022.",
    "Publisher": {
      "@type": "SO_OGD_Metadata_20230629.Office_",
      "AgencyName": "Amt für Geoinformation",
      "Abbreviation": "AGI",
      "OfficeAtWeb": "https://agi.so.ch",
      "Email": "mailto:agi@bd.so.ch",
      "Phone": "032 627 75 92"
    },
    "Theme": "Statistik,Amtliche Vermessung",
    "Keywords": "Statistik,Amtliche Vermessung",
    "StartDate": "1983-01-01",
    "EndDate": "2022-12-31",
    "Resources": [
      {
        "@type": "SO_OGD_Metadata_20230629.Resource",
        "Identifier": "ch.so.agi.amtliche_vermessung_statistik.umsatz",
        "Title": "Umsatz pro Jahr",
        "Description": "Umsatz pro Jahr. Anzahl Gebäudemutationen und Grundstücksmutationen und Gesamtumsatz in Franken.",
        "Model": {
          "@type": "SO_OGD_Metadata_20230629.ModelLink",
          "Name": "SO_AGI_Amtliche_Vermessung_Statistik_Umsatz_20230625",
          "LocationHint": "https://geo.so.ch/models"
        },
     ....

Integration und Publikation geschafft. Als nächstes kommt Visualisierung und Data Crunching.

OGD made easy #1 - csv2parquet

Mon, 10 Jul 2023 00:00:00 +0000

Ob wir überhaupt mal OGD machen werden, steht noch in den Sternen. Es schadet aber wohl nichts, sich ein paar Gedanken zu den Abläufen und dem Einsatz und Zusammenspiel einzelner Komponenten zu machen. Synergien zu den Prozessen und den Werkzeugen unserer GDI gibt es mit genügend grosser Wahrscheinlichkeit.

CSV-Dateien spielen anscheinend eine grosse Rolle. Gehen wir also davon aus, dass Fachstellen ihre offenen Daten im CSV-Format anliefern. Ein paar Fragen, die sich stellen:

Wie beschreibt man CSV-Daten? (z.B. Was bedeutet das Attribut <xxx> genau?)
Wie kontrolliert man CSV-Daten?
Soll man neben CSV (und dem Klassiker XLSX) noch weitere, «bessere» Formate bereitstellen?

Die ersten beiden Fragestellungen lassen sich mit INTERLIS erledigen. Eine Antwort auf die letzte Frage könnte Parquet sein. Parquet ist ein spaltenorientiertes Dateiformat. Die Spezifikation ist quelloffen. Es eignet sich gut für die Abfrage und Verarbeitung von Daten. Und vielleicht am Profansten: Es gibt Datentypen, Rätselraten war gestern.

Was nun CSV mit INTERLIS zu tun hat und wie man eine CSV-Datei in eine Parquet-Datei umwandeln kann, zeige ich anhand meines kleinen Prototypes csv2parquet. Es handelt sich dabei um eine Java-Kommandozeilenanwendung und dient momentan vor allem Anschauungs- und Testzwecken. Früher oder später würde die Umwandlung bei uns wohl in unserem ETL-Werkzeug GRETL integriert werden. Heruntergeladen werden kann die aktuellste Version hier. Die Zip-Datei entpacken und das Shell-Skript resp. die Batch-Datei auführen:

./bin/csv2parquet --help

In der Konsole sollte der Hilfetext erscheinen. Die Anforderungen an die Anwendung sind moderat (Java 8 reicht). Leider muss man gefühlt das halbe Internet herunterladen. Die Zip-Datei ist circa 70MB gross. Der Grund dafür sind die - für mich und viele anderen - unnötigen Hadoop-Abhängigkeiten der Parquet-Bibliothek. Es gibt einen Issue dazu. Vergessen wir das aber wieder und konzentrieren uns auf die Funktionen und erstellen die erste Parquet-Datei aus einer CSV-Datei. Ausgewählt habe ich die bewilligten Erdwärmeanlagen. Das Amt für Umwelt stellt viele Daten bereits heute freundlicherweise online. Der einfachst mögliche Aufruf ist:

./bin/csv2parquet -i bewilligte_erdwaermeanlagen.csv

Damit das einfach so funktioniert, werden von der Software Annahmen bezüglich des Trennzeichens (Separator) und des Feldtrenners (Delimiter) getroffen. Standardwert für das Trennzeichen ist ein Semikolon und für den Feldtrenner ein leeres Zeichen (also kein Feldtrenner). Das entspricht dem Output von Excel:

jahr;anfragen;bewilligte_anlagen;durchschnittlicher_oelpreis_pro_1000_liter;bewilligte_erdsonden;bewilligte_erdkollektoren;sondenlaenge_km;heizleistung_kw;internet_clicks_durchschnitt_pro_monat
1991;28;28;;26;2;;;
1992;67;33;;26;7;;;
1993;99;26;;24;2;;;

Wenn kein Zielverzeichnis (--output) angegeben wird, wird versucht die Parquet-Datei in das Quellverzeichnis zu schreiben. Jetzt haben wir zwar eine Parquet-Datei aber wie kann man sie anschauen? Für ganz rasches Quick 'n' Dirty reicht mir (eher aus Entwicklersicht) ein Online-Viewer, z.B. https://www.parquet-viewer.com/. Der Viewer hat anscheinend gerade in den letzten paar Tagen ein Update erfahren und einige Features sind nicht mehr gratis. Es gibt aber auch noch andere Möglichkeiten relativ einfach eine Parquet-Datei anzuschauen: Und zwar mit dbeaver. Wenn man dbeaver sowieso in Betrieb hat, muss man einmalig einen zusätzlichen Treiber installieren (basierend auf DuckDB). Wurde der Treiber installiert, kann man mit einem simplen SELECT die Daten anzeigen lassen:

Mit DESCRIBE SELECT kann man Informationen über die Attribute anzeigen und es fällt auf, dass der Datentyp immer Text ist:

Wie man das ändern kann, zeige ich gleich. Vorher möchte ich erläutern, wie man mit unterschiedlichen Trennzeichen und Feldtrennern umgeht. Als Beispiel verwende ich den gleichen Datensatz aber mit einem Komma als Trennzeichen und Anführungszeichen als Feldtrenner.

"jahr","anfragen","bewilligte_anlagen","durchschnittlicher_oelpreis_pro_1000_liter","bewilligte_erdsonden","bewilligte_erdkollektoren","sondenlaenge_km","heizleistung_kw","internet_clicks_durchschnitt_pro_monat"
"1991","28","28","","26","2","","",""
"1992","67","33","","26","7","","",""
"1993","99","26","","24","2","","",""

Wenn ich csv2parquet gleich wie im ersten Aufruf verwende, wird das mit einem Fehler («org.apache.avro.SchemaParseException») quittiert. Das Problem ist eben, dass die Zeilen nicht geparsed werden können. Wir müssen csv2parquet mit dem richtigen Feld- und Trennzeichen konfigurieren. Das geschieht mit einer TOML-Datei:

["ch.so.afu.bewilligte_erdwaermeanlagen"]
firstLineIsHeader=true
valueSeparator=","
valueDelimiter="\""

Was zwischen den eckigen Klammern steht, spielt momentan noch keine Rolle. Wichtig ist jedoch, dass der Text dazwischen immer zwischen Anführungszeichen steht. Die drei Optionen sind selbsterklärend. Das Anführungszeichen als Feldtrenner muss escaped werden. Der Aufruf ändert sich zu:

./bin/csv2parquet -c config.toml -i bewilligte_erdwaermeanlagen_komma_anfuehrungszeichen.csv

Es resultiert wiederum eine Parquet-Datei, die aus reinen Text-Attributen besteht. Als weitere Option steht encoding zur Verfügung, um z.B. ISO-8859-1 encodierte CSV-Dateien korrekt lesen zu können (Standard ist UTF-8).

Was augenfällig sein sollte, ist die Tatsache, dass man immer den Feldtrenner verwenden muss. Man kann also keine CSV-Dateien verwenden, in der z.B. Texte mit Anführungszeichen begrenzt werden, numerische Werte aber nicht. Zuerst fand ich das nicht gut, dann sehr gut, nun bin ich eher hin- und hergerissen. Malesh, ist nun mal so und müsste in der darunterliegenden Bibliothek geändert werden und verliert vor allem den Schrecken, wenn wir endlich INTERLIS ins Spiel bringen.

Man will wahrscheinlich die Daten, die geliefert werden, für die Anwender relativ gut beschreiben. Beschreibe ich die Daten akkurat, kann ich diese entsprechend der Beschreibug auch prüfen. Dank der Beschreibung der Daten kann ich ebenfalls den Datentyp in der Parquet-Datei definieren und muss mich nicht mit «Text» zufrieden geben. Für das alles kann man INTERLIS und sein Tool-Ökosystem verwenden. Auf der Hand liegt, dass für die Beschreibung ein INTERLIS-Modell verwendet wird. In unserem Fall mit den bewilligten Erdwärmeanlagen kann das so aussehen:

INTERLIS 2.3;

MODEL SO_AFU_Bewilligte_Erdwaermeanlagen_20230616 (de)
AT "https://agi.so.ch"
VERSION "2023-06-16"  =

  TOPIC Bewilligte_Erdwaermeanlagen =

    CLASS Bewilligte_Erdwaermeanlagen =
      /** Erhebungsjahr
       */
      jahr : MANDATORY INTERLIS.GregorianYear;
      /** Anzahl Anfragen
       */
      anfragen : MANDATORY 0 .. 100000;
      /** Anzahl bewilligte Anlagen
       */
      bewilligte_anlagen : 0 .. 100000;
      /** Durchschnittlicher Erdölpries pro 1000 Liter
       */
      durchschnittlicher_oelpreis_pro_1000_liter : 0 .. 10000;
      /** Bewilligte Erdsonden
       */
      bewilligte_erdsonden : 0 .. 100000;
      /** Bewilligte Erdkollektoren
       */
      bewilligte_erdkollektoren: 0 .. 100000;
      /** Gesamte Bohrmeter / Sondenlänge in Kilometer
       */
      sondenlaenge_km : 0.000 .. 10000.000;
      /** Gesamte Heizleistung in Kilowatt
       */
      heizleistung_kw : 0.000 .. 10000.000;
      /** Anzahl Onlineanfragen via Web GIS Client
       */
      internet_clicks_durchschnitt_pro_monat : 0 .. 100000;
    END Bewilligte_Erdwaermeanlagen;

  END Bewilligte_Erdwaermeanlagen;

END SO_AFU_Bewilligte_Erdwaermeanlagen_20230616.

Ins Auge springen zwei Dinge: die Beschreibung der Attribute und natürlich die Definition der Datentypen. Im vorliegenden Fall nicht sonderlich spannend, aber immerhin gibt es «Jahr», «Integer» und sowas wie «Double».

Schön und gut aber wie hilft mir das weiter? Hier kommt die iox-ili- resp. iox-wkf-Bibliothek zum Zuge. Sie werden zwar vor allem in ili2db und ilivalidator eingesetzt, man kann damit eben auch z.B einen CSV-Reader oder Parquet-Writer implementieren. Ersteres haben wir vor Jahren bereits für GRETL gemacht. Hat man einen solchen IOX-Reader, ist es nicht mehr weit zum CSV-Validator, der sich ebenfalls leicht implementieren lässt und somit gleich/ähnlich wie ilivalidator funktioniert. Der Clou ist, dass das alles mit einem INTERLIS-Modell gesteuert wird.

Für mich hiess das, ich musste vor allem zuerst den Parquet-IOX-Writer programmieren. Den CSV-IOX-Reader und den CSV-Validator gab es in GRETL bereits (bissle copy/paste mit Anpassungen…). Der Parquet-IOX-Writer hat mich einiges an Nerven gekostet: Der ganze Umgang mit Datum und Zeit scheint mir für Normalsterbliche mühsam. Grundsätzlich kennt Parquet UTC-berichtigte und lokale Zeiten. Ich wollte lokale Zeiten verwenden. Leider gab es einen hässlichen Bug. Aber Open Source to the Rescue: Man fixe es halt.

Die TOML-Datei muss nun um eine Zeile erweitert werden. Es muss definiert werden, welches Modell verwendet werden soll. Die Modelldatei darf dabei in einem Modellrepository sein oder im gleichen Verzeichnis wie die CSV-Datei vorliegen:

["ch.so.afu.bewilligte_erdwaermeanlagen"]
firstLineIsHeader=true
valueSeparator=";"
models="SO_AFU_Bewilligte_Erdwaermeanlagen_20230616"

Ich verwende wieder die erste CSV-Datei (Export aus Excel). Aus diesem Grund habe ich «valueDelimiter» entfernt. Der Aufruf bleibt gleich wie vorhin:

./bin/csv2parquet -c config.toml -i bewilligte_erdwaermeanlagen.csv

In der Konsole erscheint der bekannte Output von ilivalidator. Die resultierende Parquet-Datei schauen wir uns in dbeaver nochmals an:

Und siehe da: plötzlich sind da unterschiedliche Datentypen. Die Konfig-Datei könnte zukünftig in einem Datenrepository bereitgestellt werden. Dann würde ein Aufruf à la -c ilidata:<identifier> reichen und sie müsste nicht lokal vorliegen.

Mit der Verwendung von ilivalidator und INTERLIS als Validierungskomponente steht nun die Türe offen für alles was die beiden hergeben. Ein anderer Test-Datensatz beinhaltet die Abfallmengen pro Gemeinde pro Jahr und pro Abfallart. Das Modell sieht so aus:

INTERLIS 2.3;

MODEL SO_AFU_Abfallmengen_Gemeinden_20230629 (de)
AT "https://afu.so.ch"
VERSION "2023-06-29"  =

  TOPIC Abfallmengen_Gemeinden =

    CLASS Abfallmengen_Gemeinden =
      /** Erhebungsjahr
       */
      jahr : MANDATORY INTERLIS.GregorianYear;
      /** Art des Abfalls
       */
      abfallart : MANDATORY TEXT*100;
      /** Kilogramm Abfall pro Einwohner
       */
      abfall_kg_pro_einwohner : MANDATORY 0.00 .. 1000.00;
      /** Was bedeutet das genau?
       */
      wiederverwertung : MANDATORY (ja, nein);
      /** Aufzählabfallartersatz und Showcase für Constraints.
       */
      !!@ ilivalid.msg = "Falscher Wert im Attribut 'abfallart': '{abfallart}'"
      MANDATORY CONSTRAINT abfallart=="Kehricht" OR abfallart=="Kehricht / Sperrgut" OR abfallart=="Papier / Karton" OR abfallart=="Grüngut" OR abfallart=="Textil" OR abfallart=="Weissblech" OR abfallart=="Aluminium" OR abfallart=="Metalle" OR abfallart=="Motoren / Speiseöl" OR abfallart=="Sonderabfälle" OR abfallart=="Strassensammlerschlamm" OR abfallart=="Wischgut" OR abfallart=="Glas (Glasbruch + Glassand)";
    END Abfallmengen_Gemeinden;

  END Abfallmengen_Gemeinden;

END SO_AFU_Abfallmengen_Gemeinden_20230629.

Das Modell verwendet für das Attribut wiederverwendung einen Aufzähltyp, d.h. es darf nur ja oder nein als Wert verwendet werden. Sehr hässlich aber wirkungsvoll ist der MANDATORY CONSTRAINT. Er dient als Ersatz für einen Aufzähltyp und prüft, ob nur erlaubte Abfallarten vorhanden sind. Man ist mit der Prüfung nicht auf das einzelne Objekte / den einzelnen Record eingeschränkt. Mit einem SET CONSTRAINT lassen sich Dinge über verschiedene Objekte / den ganzen Datensatz hinweg prüfen. So als spontanes Beispiel: Die Gesamtzahl der gelieferten Objekte darf einen bestimmten Wert nicht überschreiten: SET CONSTRAINT INTERLIS.objectCount(ALL)==100;. Oder noch bisschen exotischer ein Plausiblity Constraint, der prüft, ob ein Prozentteil der Objekte eine Bedingung erfüllen (z.B. abfall_kg_pro_einwohner muss in mindestens 30 Prozent der Fälle kleiner als 500 Kilogramm sein). Alles Dank INTERLIS frei Haus: korrekte Datentypen und eine sehr mächtige Datenprüfung.

INTERLIS leicht gemacht #37 - The State of INTERLIS native (Summer 2023)

Thu, 22 Jun 2023 00:00:00 +0000

Letzten Herbst habe ich ili2c, ilivalidator und ili2pg mit GraalVM zu einem Native Image kompiliert. Daraus resultiert - im Gegensatz zu den offiziell publizierten Versionen - eine betriebssystemabhängige Variante, die jedoch keine Java-Installation benötigt. Das Kompilieren übernimmt eine Github Action und somit können mindestens drei Betriebssysteme (Windows, Ubuntu-Linux, macOS) problemlos angeboten werden.

Einen Haken hat die ganze Sache aber: Die Performance ist massiv schlechter als bei den Java-Varianten. Dies wird vor allem bei der Prüfung mit ilivalidator zum Problem. Es gab bereits relativ lange eine Enterprise-Version von GraalVM, die sich diesem Problem annahm. Die Java-Variante kann in unserem Fall anscheinend massiv vom JIT-Compiler profitieren und während der Laufzeit immer mehr den Code optimieren. Das ist mit einem Native Image nicht mehr möglich. Das muss alles vorher passieren. Dies ist bei der Enterprise-Variante mit «Profile-Guided Optimizations» möglich. Die Anwendung wird zuerst geprofiled und dabei Informationen gesammelt. Mit diesen Informationen wird anschliessend der Native Image Builder gefüttert und daraus sollte eine bessere Performance resultieren. Eine zweite Baustelle ist der Garbager Collector. Die Community-Variante verfügt nur über den Serial GC, die Enterprise-Variante zusätzlich über den Garbage First Garbage Collector (G1GC), jedoch nur unter Linux. Nun hat aber auch die Enterprise-Variante einen Haken und man vermutet wohl richtig: Enterprise == $.

Mit dem neusten GraalVM-Release (Version 23) gibt es keine Enterprise-Variante mehr. Der Nachfolger heisst «Oracle GraalVM» und ist frei. Man sollte sich sicherheitshalber wohl die «GraalVM Free Terms and Conditions (GFTC) license» und die FAQ gut durchlesen.

Mit all den Enterprise-Feature, die nun frei verfügbar sind, steht einem Performance-Vergleich nichts mehr im Wege. Geprüft wird ilivalidator 1.13.3 mit unserem Fruchtfolgeflächen-Datensatz. Zuerst habe ich nur die einzelnen Objekte geprüft (--singlePass). Das hat zur Folge, dass die AREA-Prüfung nicht ausgeführt wird. Als Testrechner habe einen Hetzner-Cloud-Server verwendet.

Variante	Dauer (mins:secs)
Standard	1:33
PGO	1:00
PGO und G1GC	1:04
JVM	0:33

Variante

Dauer (mins:secs)

Standard

1:33

PGO

1:00

PGO und G1GC

1:04

JVM

0:33

Eine spürbare Verbesserung vor allem dank PGO ist sichtbar. Gegen die JVM-Variante haben die Native Images aber immer noch keine Chance. Wie sieht es aus, wenn ich das XTF komplett prüfe (also v.a. inklusive der AREA-Prüfung):

Variante	Dauer (mins:secs)
Standard	13:32
PGO	10:13
PGO und G1GC	8:19
JVM	6:08

Variante

Dauer (mins:secs)

Standard

13:32

PGO

10:13

PGO und G1GC

8:19

JVM

6:08

Die Unterschiede werden grösser. Die PGO+G1GC-Variante ist fünf Minuten schneller als die Standardvariante. Es gibt zwar immer noch eine Lücke zur reinen Java-Variante zu schliessen, aber absolut faszinierend was sich rausholen lässt mit einem anderen Garbage Collector und den PGO.

Wie sieht es bei ili2pg aus? Die Datenbank läuft in einem Docker-Container. Die Prüfung des Datensatzes wurde ausgeschaltet (--disableValidation):

Variante	Dauer (mins:secs)
Standard	0:40
PGO	0:35
PGO und G1GC	0:19
JVM	0:20

Variante

Dauer (mins:secs)

Standard

0:40

PGO

0:35

PGO und G1GC

0:19

JVM

0:20

Es bräuchte wohl grössere Datensätze, um hier grössere Abstände zu sehen. Jedenfalls scheint PGO+G1GC auch hier gut mithalten zu können. Der Einfluss der Anwendung dürfte auf die reine Ausführungszeit geringer sein, da die Datenbank natürlich viel abarbeiten muss.

Die ilitools als Native Image werden immer interessanter und dank der frei verfügbaren Oracle GraalVM Distribution ist die Herstellung auch kein Problem mehr.

INTERLIS leicht gemacht #36 - Mapping rules matter und weitere Performancebeobachtungen

Sun, 14 May 2023 00:00:00 +0000

Ich bin zur Zeit am Entwickeln einer Anwendung, welche die Geodaten des Kantons als STAC-Katalog bereitstellt. Im Prinzip ist sie in einer ersten, einfachen Form fertig, nur konnte ich sie bei uns noch nicht in Betrieb nehmen, weil der OPTIONS-Request in der Firewall gesperrt ist. Dieser wird benötigt, wenn der STAC-Browser unseren Katalog anzapfen will. Was bei uns aufgrund der Umstände eine Woche geht, dauert bei Digitalocean eine Stunde:

JSON: ~~https://sogis-sodata-stac-fvxwq.ondigitalocean.app/catalog.json~~ https://data.geo.so.ch/stac/catalog.json
STAC-Browser: ~~https://radiantearth.github.io/stac-browser/#/external//sogis-sodata-stac-fvxwq.ondigitalocean.app/catalog.json?.language=en~~ https://radiantearth.github.io/stac-browser/#/external//data.geo.so.ch/stac/catalog.json?.language=en

Als Input dient mir die XML-Datei, welche aus unserer Metadatenbank exportiert wird. Die erste Frage, die sich mir stellte: Wie kommen die Daten in eine Datenbank? Am einfachsten schien mir der Weg über ein INTERLIS-Modell. Ich schreibe ein Modell, das sehr nahe an der STAC-Spezifikation ist (JSON-Schemas) und bringe mit XSLT die XML-Datei in die korrekte Form. Anschliessend importiere ich die Daten mit ili2pg in eine PostgreSQL-Datenbank. Den Ansatz verwenden wir übrigens auch für die eCH-Objektwesen-Meldungen. Die kommen ebenfalls in einer XML-Datei daher und müssten mit einer 1:1-Schnittstelle importiert werden. Verstehe wer will.

Mein work-in-progress INTERLIS-STAC-Datenmodell ist sehr einfach und besteht aus einer Klasse. In der Klasse gibt es Attribute, die wiederum aus Listen von Strukturen bestehen: So enthält eine «Collection» ein oder mehrere «Items».

Beim Entwickeln habe ich eine XTF-Datei verwendet, die drei Collections enthält. Der Import in die Datenbank ging sehr schnell, so dass es nicht störte, dass dies bei jedem live reload (d.h. nach jeder Codeänderung) gemacht wurde. Als es darum ging das System mit einer kompletten XTF-Datei zu testen, war ich verwirrt. Wir haben 93 Collections, der Import ging aber gefühlt ewig. Ich kam aus dem Staunen nicht mehr raus. Erst die --trace-Option hat mir geholfen. Ich sah sehr viele SQL-Befehle und dann ging mir ein Licht auf: Obwohl ich nur 93 Objekte in die Datenbank importieren muss, sind viel mehr SQL-Inserts notwendig. Es gibt insgesamt circa 70'000 Items. Items sind im INTERLIS-Datenmodell als Struktur modelliert. Strukturen werden standardmässig als Tabelle in der Datenbank abgebildet. Neben den Items sind noch viele weitere Attrbute als Strukturen modelliert. Insbesondere schmerzen natürlich Attribute der Item-Struktur, weil diese wiederum sehr viele separate Insert-Statements auslösen (weil es viele Items gibt).

Was machen? JSON to the rescue. Ili2db hat die Fähigkeit Strukturen nicht als Tabellen in der Datenbank abzubilden, sondern als JSON-Objekt. Die JSON-Objekte sind in der «Mutter-Tabelle» in einem JSON-Feld (oder je nach Datenbank: Text-Feld) gespeichert. Wichtig scheint mir der Hinweis, dass es mit dieser Abbildungvariante für Strukturen keinen Informationsverlust gibt. Die Daten können auch wieder exportiert werden. Damit die Strukturen als JSON-Objekt abgebildet werden, muss das Attribut im Datenmodell entsprechend annotiert werden:

STRUCTURE Item =
    Identifier : MANDATORY TEXT;
    Title : TEXT;
    Date: MANDATORY FORMAT INTERLIS.XMLDate "1990-1-1" .. "2100-12-31";
    !!@ili2db.mapping=JSON
    Boundary : BoundingBox;
    Geometry : MTEXT; !! FIXME
    !!@ili2db.mapping=JSON
    Assets : BAG {1..*} OF Asset;
END Item;

Einige Attribute hatte ich bereits annotiert gehabt. Nur die BoundingBox des Items nicht. Und allein dieses führte zur gefühlt ewigen Importdauer. Die nachfolgende Tabelle zeigt die Dauer eines Imports in Abhängigkeit der Strukturabbildungsregeln (ohne JSON, alles mit JSON, alles mit JSON ausser Items):

Abbildungsregel	Dauer (mins:secs)
ohne JSON	9:39
alles mit JSON	0:10
alles mit JSON (ausser Items)	2:45

Abbildungsregel

Dauer (mins:secs)

ohne JSON

9:39

alles mit JSON

0:10

alles mit JSON (ausser Items)

2:45

Die Zeiten sind mit Vorsicht zu geniessen und würden in der Produktion nicht ganz so extrem ausfallen. Die Tests habe ich auf macOS mit einer gedockerten Datenbank gemacht. In dieser Kombi ist Datenbank-I/O relativ lahm.

Wie erwähnt hatte ich bereits einige der Strukturen bewusst als JSON-Objekt abbilden lassen. Der Grund dafür war, dass ich mich entschieden hatte, sämtliche Logik zum Herstellen der JSON-Dateien (gemäss STAC-Spezifikation) in der Datenbank mit den PostgreSQL-JSON-Funktionen zu machen. Zu dieser Thematik gibt es interessante Artikel. Die Businesslogik in der Anwendung selber ist nun praktisch inexistent. Es werden nur Controller benötigt.

Weil die Anzahl der DB-Queries dermassen matchentscheidend ist, habe ich ein paar weitere Vergleiche gemacht. Wenn die Anzahl der Queries wichtig ist, ist entsprechend die Geschwindigkeit der Query auch entscheidend. Weniger die Dauer direkt auf dem DB-Server, sondern die Dauer vom Absetzen des Requests in der Anwendung bis zur Antwort. Dazu habe ich bei Digitalocean eine gemanagte Datenbank erstellt und verglich wie lange ein Import meiner 93 Objekte dauerte. Als Abbildungsregel habe ich «alles mit JSON (ausser Items)» verwendet. Einmal importierte ich die Daten vom lokalen Rechner und einmal von einem Digitalocean-Server im gleichen Rechenzentrum.

Ort	ping (ms)	Dauer (mins:secs)
lokal	24	46:52
Rechenzentrum	0.7	01:51

Ort

ping (ms)

Dauer (mins:secs)

lokal

46:52

Rechenzentrum

0.7

01:51

Die ping-Spalte zeigt die Dauer eines PING-Requests. Unterschied ist krass aber ziemlich plausibel. Netzwerkrequests sind halt einfach teuer. Dazu ein guter Artikel.

Bei ili2db kommt noch hinzu, dass für jeden Record, der in die Datenbank geschrieben wird, ein SELECT nextval($1) gemacht wird. De fakto eine Verdoppelung der Requests.

Es gibt in ili2db die Option --importBatchSize rows. Mit diesem können die INSERT-Befehle gebündelt werden (analog dazu --exportFetchSize rows). Vergleich mit/ohne batch-Option, jeweils vom lokalen Rechner zur Digitalocean-DB:

importBatchSize	Dauer (mins:secs)
n/a	69:25
5000	35:14

importBatchSize

Dauer (mins:secs)

n/a

69:25

5000

35:14

Die Zeiten sind nicht mit den Tests (lokal vs Rechenzentrum) vergleichbar, da ich eine andere Internetverbindung verwendet habe.

Conclusion (aus der Sicht eines möglichst schnellen Imports):

Es muss eine sehr schnelle (latenzarme) Verbindung zwischen ili2db und der Datenbank vorhanden sein.
Falls möglich sollten Strukturen mit JSON abgebildet werden.
Die Requests sollten gebatched werden. Dies würde ich aber noch vertiefter prüfen wollen, ggf. hat das auch unter gewissen Umständen einen negativen Impact.
SELECT nextval($1): Vielleicht hat jemand eine gute Idee.
Entwicklung einer «smart3Inheritance»-Methode, die Assoziationen als JSON-Objekte abbildet.

Zu «smart3Inheritance»: Keine Ahnung, ob das im grösseren Kontext sinnvoll ist und/oder gut umsetzbar ist. Wenn ich aber z.B. an eine Klasse mit einem Geometrieattribut denke, die eine Beziehung zu Dokumenten hat, könnten die Dokumente als JSON-Objekt in einem JSON-Feld in der Tabelle mit der Geometrie abgebildet werden. Ist wohl sowieso das, was man will, wenn man die Daten bloss anzeigen will (und nicht editieren will).

INTERLIS leicht gemacht #35 - Automatisierung steigern mit dem Daten-Repository

Wed, 10 May 2023 00:00:00 +0000

Seit ili2db 4.10.0 gibt es neue Möglichkeiten seine Prozesse nochmals einfacher zu automatisieren: Man kann mit einem einzigen ili2db-Befehl Daten aus einem Daten-Repository herunterladen und in eine Datenbank importieren. Das Daten-Repository ist das Äquivalent zum Modell-Repository: Es werden beliebige Daten in strukturierter Form bereitgestellt. Die strukturierte Form ist in diesem Fall natürlich wieder eine INTERLIS-Transferdatei. Im Rahmen unseres neuen Datenbezuges habe ich ein solches Daten-Repository erstellt. Die oberste Ebene eines Daten-Repositories besteht aus "DatasetMetadata"-Objekten. Unsere Hoheitsgrenzen als Beispiel:

<DatasetIdx16.DataIndex.DatasetMetadata TID="33">
    <id>ch.so.agi.av.hoheitsgrenzen</id>
    <version>current</version>
    <model>
        <DatasetIdx16.ModelLink>
        <name>SO_Hoheitsgrenzen_Publikation_20170626</name>
        <locationHint>https://geo.so.ch/models</locationHint>
        </DatasetIdx16.ModelLink>
    </model>
    <epsgCode>2056</epsgCode>
    <publishingDate>2023-05-13</publishingDate>
    <owner>https://agi.so.ch</owner>
    <boundary>
        <DatasetIdx16.BoundingBox>
        <westlimit>7.340693492284002</westlimit>
        <southlimit>47.074299169536175</southlimit>
        <eastlimit>8.03269288687543</eastlimit>
        <northlimit>47.50119805032911</northlimit>
        </DatasetIdx16.BoundingBox>
    </boundary>
    <title>
        <DatasetIdx16.MultilingualText>
        <LocalisedText>
            <DatasetIdx16.LocalisedText>
            <Language>de</Language>
            <Text>Hoheitsgrenzen</Text>
            </DatasetIdx16.LocalisedText>
        </LocalisedText>
        </DatasetIdx16.MultilingualText>
    </title>
    <shortDescription>
        <DatasetIdx16.MultilingualMText>
        <LocalisedText>
            <DatasetIdx16.LocalisedMText>
            <Language>de</Language>
            <Text><![CDATA[Als Hoheitsgrenzen werden die Landesgrenzen, Kantonsgrenzen und die Grenzen der politischen Gemeinden bezeichnet. Die Hoheitsgrenzen liegen auf Grundstücksgrenzen. Sie sind Bestandteil der amtlichen Vermessung.]]></Text>
            </DatasetIdx16.LocalisedMText>
        </LocalisedText>
        </DatasetIdx16.MultilingualMText>
    </shortDescription>
    <keywords>Landesgrenzen,Kantonsgrenzen,Gemeindegrenzen,Bezirksgrenzen,schöne Steine,Inventar Hoheitsgrenzsteinen</keywords>
    <technicalContact>https://agi.so.ch</technicalContact>
    <furtherInformation>https://so.ch/verwaltung/bau-und-justizdepartement/amt-fuer-geoinformation/amtliche-vermessung/hoheitsgrenzen/</furtherInformation>
    <knownWMS>
        <DatasetIdx16.WebService_>
        <value>https://geo.so.ch/api/wms</value>
        </DatasetIdx16.WebService_>
    </knownWMS>
    <knownWFS>
        <DatasetIdx16.WebService_>
        <value>https://geo.so.ch/api/wfs</value>
        </DatasetIdx16.WebService_>
    </knownWFS>
    <furtherWS>
        <DatasetIdx16.WebService_>
        <value>https://geo.so.ch/api/data/v1</value>
        </DatasetIdx16.WebService_>
    </furtherWS>
    <knownPortal>
        <DatasetIdx16.WebSite_>
        <value>https://geo.so.ch/map?l=ch.so.agi.bezirksgrenzen</value>
        </DatasetIdx16.WebSite_>
    </knownPortal>
    <files>
        <DatasetIdx16.DataFile>
        <fileFormat>application/interlis+xml;version=2.3</fileFormat>
        <file>
            <DatasetIdx16.File>
            <path>files/ch.so.agi.av.hoheitsgrenzen.xtf</path>
            </DatasetIdx16.File>
        </file>
        </DatasetIdx16.DataFile>
    </files>
</DatasetIdx16.DataIndex.DatasetMetadata>

In diesem Kontext interessant sind die Attribute "id" und "files". Das "id"-Attribut benötige ich später zum eindeutigen Ansprechen des Datensatzes, den ich bei mir importieren will. Das "files"-Atttribut zeigt auf die Datei (resp. Dateien), welche zu diesem Datensatz vorhanden sind. Das "path"-Attribut ist zwingend ein relativer Pfad (siehe dazugehöriges Datenmodell). D.h. man kann nicht auf irgendeine Datei auf irgendeinem Server zeigen. Sondern die Datei muss auf dem gleichen Server liegen, wie die ilidata.xml-Datei. Dies ist bewusst so gewählt: Damit wird verhindert, dass man auf etwas zeigt, das man nicht unter Kontrolle hat.

Bevor ich die Datei importieren kann, erstelle ich in einem separaten Schritt das Schema mit den leeren Tabellen:

java -jar ili2pg-4.11.0.jar --dbhost localhost --dbport 54321 --dbdatabase pub --dbusr ddluser --dbpwd ddluser --dbschema agi_hoheitsgrenzen_pub_v1 --models SO_Hoheitsgrenzen_Publikation_20170626 --nameByTopic --defaultSrsCode 2056 --createFk --createFkIdx --createMetaInfo --createUnique --createNumChecks  --createTextChecks --createDateTimeChecks --createEnumTabs --strokeArcs --schemaimport

Den Datensatz aus einem Daten-Repository spreche ich beim Import über ilidata:<id> an:

java -jar ili2pg-4.11.0.jar --dbhost localhost --dbport 54321 --dbdatabase pub --dbusr ddluser --dbpwd ddluser --dbschema agi_hoheitsgrenzen_pub_v1 --models SO_Hoheitsgrenzen_Publikation_20170626 --import ilidata:ch.so.agi.av.hoheitsgrenzen

In der Konsole sieht man anhand der Logeinträge (Info: search in repository http://models.interlis.ch/ for BID <ch.so.agi.av.hoheitsgrenzen> etc. pp.), dass ili2pg den Datensatz "ch.so.agi.av.hoheitsgrenzen" in den Daten-Repositories sucht und im Kanton Solothurn findet und anschliessend importiert.

Das funktioniert natürlich auch mit z.B. ili2gpkg und mit einem Befehl, also ohne vorgängiges Anlegen des Schemas / der Tabellen:

java -jar ili2gpkg-4.11.0.jar --dbfile hoheitsgrenzen.gpkg --models SO_Hoheitsgrenzen_Publikation_20170626 --nameByTopic --defaultSrsCode 2056 --createFk --createFkIdx --createMetaInfo --createUnique --createNumChecks  --createTextChecks --createDateTimeChecks --createEnumTabs --strokeArcs --doSchemaImport --import ilidata:ch.so.agi.av.hoheitsgrenzen

Beinahe fast schon Feenstaub. INTERLIS mal wieder dem Rest um Längen voraus.

Was passiert, wenn ich Datensätze importieren will, die aus verschiedenen Dateien bestehen? Z.B. die kommunalen Nutzungsplanung:

<files>
    <DatasetIdx16.DataFile>
    <fileFormat>application/interlis+xml;version=2.3</fileFormat>
    <file>
        <DatasetIdx16.File>
        <path>files/2503.ch.so.arp.nutzungsplanung.kommunal.xtf</path>
        </DatasetIdx16.File>
        <DatasetIdx16.File>
        <path>files/2514.ch.so.arp.nutzungsplanung.kommunal.xtf</path>
        </DatasetIdx16.File>
        <DatasetIdx16.File>
        <path>files/2463.ch.so.arp.nutzungsplanung.kommunal.xtf</path>
        </DatasetIdx16.File>
        <DatasetIdx16.File>
        <path>files/2542.ch.so.arp.nutzungsplanung.kommunal.xtf</path>
        </DatasetIdx16.File>
        ....
    </file>
    </DatasetIdx16.DataFile>
</files>

Es wird nur die erste Datei importiert. Scheint mir noch nicht ganz ausgereift zu sein. Hier würde sich wohl auch die Frage nach einer Unterstützung von --dataset stellen.

Man kann nicht nur Daten in einem Daten-Repository referenzieren und bereitstellen, sondern auch Konfigurationen. Also mit welchen Paramatern ein Schema angelegt werden soll. Eine solche Konfigurationsdatei ("ch.so.agi.hoheitsgrenzen.ini") sieht für unser Beispiel so aus:

[ch.ehi.ili2db]
models=SO_Hoheitsgrenzen_Publikation_20170626
nameByTopic=true
defaultSrsCode=2056
createFk=true
createFkIdx=true
createMetaInfo=true
createUnique=true
createNumChecks=true
createTextChecks=true
createDateTimeChecks=true
createEnumTabs=true
strokeArcs=true

Der dazugehörige Eintrag in der ilidata.xml-Datei:

<DatasetIdx16.DataIndex.DatasetMetadata TID="4">
    <id>ch.so.agi.hoheitsgrenzen_config</id>
    <version>1</version>
    <owner>mailto:agi@bd.so.ch</owner>
    <categories>
        <DatasetIdx16.Code_>
            <value>http://codes.interlis.ch/type/metaconfig</value>
        </DatasetIdx16.Code_>
        <DatasetIdx16.Code_>
            <value>http://codes.interlis.ch/model/SO_Hoheitsgrenzen_Publikation_20170626</value>
        </DatasetIdx16.Code_>
    </categories>
    <files>
        <DatasetIdx16.DataFile>
            <fileFormat>text/plain</fileFormat>
            <file>
                <DatasetIdx16.File>
                    <path>ch.so.agi.hoheitsgrenzen.ini</path>
                </DatasetIdx16.File>
            </file>
        </DatasetIdx16.DataFile>
    </files>
</DatasetIdx16.DataIndex.DatasetMetadata>

Die Code_-Einträge sind - soweit ich die Dokumentation verstehe - freiwillig. Die Konfigurationsdatei mit den Optionen wird in den "file"-Attributen referenziert.

Der ili2pg-Befehl verkürzt sich jetzt stark, da viele Optionen in der ini-Datei vorhanden sind. Weil ich für diese Konfigurationsdatei noch kein Repository haben, muss ich sie direkt ansprechen:

java -jar ili2pg-4.11.0.jar --dbhost localhost --dbport 54321 --dbdatabase pub --dbusr ddluser --dbpwd ddluser --dbschema agi_hoheitsgrenzen_pub_v1 --metaConfig ch.so.agi.hoheitsgrenzen.ini --schemaimport

Würde die ini-Datei in einem Daten-Repository liegen, müsste die metaConfig-Option um ein "ilidata" ergänzt werden: --metaConfig ilidata:ch.so.agi.hoheitsgrenzen.ini.

Der ili2gpkg-Befehl von vorhin wird ebenfalls massiv kürzer:

java -jar ili2gpkg-4.11.0.jar --dbfile hoheitsgrenzen.gpkg --metaConfig ch.so.agi.hoheitsgrenzen.ini --doSchemaImport --import ilidata:ch.so.agi.av.hoheitsgrenzen

Was bringt uns das nun alles?

Das automatische Herunterladen und Importieren von Daten ist für Endbenutzer interessant, die regelmässig und automatisch Daten bei sich integrieren. Man muss jedoch ID des Datensatzes kennen, um von dieser Automatisierung zu profitieren, was wohl z.B. bei Lisa Liegenschaft nicht der Fall sein dürfte. Für uns wiederum könnte es für das lokale Entwickeln von Datenumbauten etc. interessant sein. Wir kennen plusminus die ID der Datensätze und können so Entwicklungsumgebungen auf Knopfdruck herstellen.

Die Bereitstellung der Konfigurationsdateien für die Schemaerstellung machen wir heute bereits ähnlich, jedoch mit einem selbstgestrickten Werkzeug. Dieses können wir mit ili2pg-pur ersetzen.

Daten-Repository:

Das Daten-Repository stelle ich innerhalb einer Spring Boot-Anwendung her. Zwei von drei Dateien (ilisite.xml und ilimodels.xml) sind statische Dateien und nicht interessant. Die ilidata.xml-Datei stelle ich beim Hochfahren der Anwendung aus einer XML-Datei her, die aus unserer Metadatenbank exportiert wird. Zu Beginn habe ich erwähnt, dass die Dateien auf dem gleichen Server liegen müssen wie die ilidata.xml-Datei. Hier musste ich klein wenig bescheissen. Das ist bei uns nicht der Fall und ich habe einen einfachen Proxy in die Anwendung eingebaut, welcher die Datei zuerst von einem anderen Server herunterlädt. Ein weiterer Grund für den Proxy ist der Umstand, dass die Dateien bei uns als Zipdateien abgelegt sind. Diese müssen aber als XTF-Datei vorliegen, damit es funktioniert. Dieses Entzippen hat zu einer interessante Frage geführt: Wenn das Repository nun rege genützt würde, werden sehr viele Daten produziert beim Entzippen. Wie gehe ich damit um? Ich kann die XTF-Datei erst löschen, wenn sie vollständig an den Benutzer, der sie angefordert hat, geschickt wurde. Dann kann ich sie aber nicht mehr löschen, weil der Request fertig ist. Erste, einfache Idee war ein eingebauter Cronjob, der alle XX Minuten das Verzeichnis mit den heruntergeladenen und entzippten Daten löscht. Das fand ich aber doch nicht so prickelnd, weil man entweder viel zu oft aufräumt oder zu wenig oft. Eine meines Erachtens gute Variante ist Erweiterung der Spring InputStreamResource-Klasse. Diese InputStreamResource wird als Body dem Client zurückgeliefert. Man kann diese Klasse dahingehend erweitern, indem man die "close"-Methode überschreibt und in dieser die unnötigen Dateien löscht. So kümmert sich jeder Request um seine Artefakte.

ÖREB-Kataster richtig gemacht #14 - A quick look aufs PDF

Wed, 18 Jan 2023 00:00:00 +0000

Ok, schauen wir noch ein bisschen die PDF (aka statischer Auszug) an. Sicher nicht die systemkritischste Komponente. Aber man will einen einheitlichen Auftritt und die Frage ist, kriegt man ihn?

Ich habe mich auf Dinge beschränkt, die einem mehr oder weniger direkt ins Auge springen. Bei einigen dieser Dinge ist die Frage wie man es formal nachprüfen kann. Mich dünkt z.B. die Schrift an einer Stelle zu gross. Und nun? Strichlupe? Ich habe mich für den Weg via Import in Inkscape entschieden. Inkscape hat einen brauchbaren PDF-Import und Texte bleiben als Texte erhalten. Weil ich nicht weiss, wie gut und korrekt dieser letzten Endes ist, bleibt natürlich eine gewisse Unsicherheit.

Ich habe die Analysen nach ÖREB-PDF-Generator zu gruppieren versucht. In der Hoffnung, dass die Gruppierung stimmt. Verwendet ein Kanton Generator X, gelten die Aussagen oftmals auch für einen anderen Kanton, der denselben Generator einsetzt.

Neben den rein visuellen Dingen, habe ich die Konformität des verlangten PDF-Formates versucht zu überprüfen. Die Weisung verlangt, dass das PDF entweder ein PDF/A-1 oder PDF/A-2a ist. Die Überprüfung ist leider nicht ganz trivial. Wikipedia beschreibt das Problem sehr gut: «Eine Validierung von gültigem PDF/A ist über entsprechende Prüfwerkzeuge möglich (siehe Weblinks). Diese Software-Tools sind sich jedoch häufig uneinig darüber, ob eine erzeugte Datei entsprechend PDF/A gültig ist. Der Grund dafür ist, dass die zugrundeliegenden Normen unterschiedlich interpretiert werden.» Ich habe zwei Online-Validatoren verwendet.

pyramid-oereb (mapfish print)

Als erstes fällt auf, dass das Gemeindewappen mit dem Gemeindenamen ergänzt wird. Meines Erachtens steht nichts davon in der Weisung. Und weil auf dem Titelblatt explizit die Gemeinde aufgelistet wird, finde ich das mindestens überflüssig.

Auf der Titelseite ist die erste Inhaltszeile von «Katasterverantwortliche Stelle» nicht bündig und ist zu Nahe am der Trennlinie.

Auf der zweiten Seite (dem Inhaltsverzeichnis) stimmt die Grösse des Textes nicht. Die jeweiligen Titel sind in der Schriftgrösse 8pt, die Auflistung der Themen in Schriftgrösse 9pt. Die Schriftgrösse der Themen muss aber 8pt sein. Die Ergänzung des Themas mit «(Rechtsgültig)» sollte nicht sein. Nur «nicht-rechtsgültige» müssen mit dem Rechtsstatus in Klammer ergänzt werden.

Die Beschreibung eines Typs auf den einzelnen ÖREB-Seiten ist zu gross: sie darf nur 8pt gross ein und nicht 9pt. Es scheint auch nicht sauber vertikal zentriert zu sein.

Der Kanton Zug verwendet auch Mapfish Print aber lustigerweise liegt das PDF in der Version 1.7 vor, was nicht PDF/A-1-konform, jedoch PDF/A-2-konform sein könnte.

Das PDF ist gemäss beiden Validatoren nicht formatkonform.

pdf4oereb

Wir im Kanton Solothurn verwenden eine XSL/XSL-FO-Tranformation bei der Herstellung des PDF aus dem XML. Was mich nicht ganz korrekt dünkt, ist der eigentliche Namen des Inhaltsverzeichnis-Eintrags eines Themas. Gemäss Weisung ist die Logik: «Thema: Subthema». Bei uns steht nur der Name des Subthemas. Ich frage mich, ob sich hier DATA-Extract und PDF-Weisung nicht widersprechen. Entweder wir benennen unsere Subthemen um oder man müsste im XML noch irgendwo den sprechenden Namen des Themas verwalten. Oder man müsste die ganze Table of Contents- vs. Themen-Geschichte bei den einzelnen ÖREB anders leben. Aber wie? Ist wohl wirklich nicht ganz widerspruchsfrei.

Das PDF validert mit beiden Validatoren gegen PDF/A-1a.

Kantone NW, OW, UR

Die drei PDF dünken mich sehr ähnlich, es gibt aber einige Unterschiede.

Im Kanton Uri weisen die Gemeindewappen den Gemeindenamen auf. Die Symbole sind zu klein. Im Kanton Uri noch kleiner als z.B. im Kanton NW. Die Trennlinie ist zu breit (1pt statt 0.2pt). Der Abstanz zwischen Bild und Auflistung der Typen ist zu klein. Zwischen dem Anteil und dem Prozentzeichen darf es keinen Leerschlag geben.

Die Schriftgrösse im Inhaltsverzeichnis ist zu klein. Sie darf nicht 6pt sein, sondern muss 8pt sein.

Das PDF ist gemäss beiden Validatoren nicht formatkonform.

Kanton Zürich

Interessanterweise kann ich das PDF nicht gleich gut wie andere in Inkscape importieren. Es fehlen die Texte (was aber noch rein gar nichts über die Qualität des PDF aussagt). Was jedoch sofort auffällt ist, dass im Kanton Zürich praktisch alles kursiv geschrieben ist. Warum?

Bei den einzelnen Typen steht manchmal ein Asterix hinter den Quadratmeter und Prozent. Mir auch nicht klar. Ebenfalls steht ein überflüssiger Leerschlag zwischen Anteil und dem Prozentzeichen.

Die Liste auf der letzten Seite bei «Begriffe und Abkürzungen» stammt wohl noch aus der ersten Version. Sie müsste umfangreicher und länger sein.

Das PDF ist gemäss beiden Validatoren nicht formatkonform.

Kanton Wallis

Der Kanton Wallis hat noch einige Version-1-Restanzen: Der Titel «Allfällige Eigentumsbeschränkungen, zu denen noch keine Daten vorhanden sind» ist nicht mehr korrekt. Ebenso gibt es keine vollständige Legende mehr. Die Abstände zwischen verschiedenen Elementen stimmt oftmals nicht.

Das ÖREB-Katasterlogo ist nicht rechtsbündig und verzerrt.

Was mich ein wenig irritiert ist, dass man anscheinend die falsche Farbe der Links nicht erkennt, resp. noch niemand erkannt hat. Auch die Schriftart ist nicht korrekt. Bei den Links wird anstelle Cadastra Helvetica verwendet.

Das PDF ist gemäss beiden Validatoren nicht formatkonform.

Kanton Luzern

Der Kanton Luzern verwendet ebenfalls eine eigene Lösung.

Auf der Titelseite fehlt der Stand der amtlichen Vermessung. Die Schriften sind zu gross: 8.5pt statt 8pt. Im Inhaltsverzeichnis wird die alte Bezeichung «Allfällige…» verwendet. Das Gemeindelogo weist den Gemeindenamen auf.

Bei den einzelnen ÖREB-Seiten fehlt der kleine Untertitel, der Auskunft über den Rechtsstatus liefert. Die Legende ist «komisch» aufgebaut. Irgendwie scheint es Unterkapitel zu geben, z.B. gibt es beim Zonenplan in der Legend das Unterkapitel «Grundnutzung» und «Überlagerungen». Der eigentliche Legendentext, z.B. «Zone für öffentliche Zwecke» wird ebenfalls mit Subkontext versehen («Zonentyp Gemeinde: Zone für öffentliche Zwecke»). Scheint mir nicht der Weisung zu entsprechen. Die Einrückungen der Links auf die Dokumente fehlt und deren Farbe ist nicht korrekt. Die weiteren Informationen und Hinweise folgen fälschlicherweise nach den zuständigen Stellen. Sie sollten vor den zuständigen Stellen gelistet werden.

Das PDF ist gemäss beiden Validatoren nicht formatkonform.

Fazit

Wahrlich kein Weltuntergang aber irgendwie, auf einem anderen Level, trotzdem leicht verstörend. Wir können es uns leisten mindestens 5 Mal ein Werkzeug für den identischen Arbeitsschritt zu bauen (dafür aber keines wirklich korrekt). Zu viel Geld? Zu viele Programmierer, die sich verwirklichen wollen? Zu viele Leute, die reinreden, was alles konfigurierbar sein muss? Fehlanreize? Ich weiss es nicht.

Nachtrag 2023-01-23

Ich habe eine Java-Bibliothek gefunden, die PDF/A-Dateien validiert. Auf Basis dieser Bibliothek habe ich einen zusätzlichen Check im ÖREB-Kataster-Validierungstool erstellt. Erfreulicherweise validiert das PDF der Kantone Nidwalden und Obwalden. Uri interessanterweise nicht, auch wenn ich immer noch denke, dass sie mit der gleichen Software hergestellt werden. Leider werden wohl die pyramid-oereb-Kantone ein Problem bekommen. Wobei mir nicht ganz klar ist, ob es im verlinkten Ticket nur um die Transparenz in den Symbolen der Bundesdaten geht oder um ein gröberes Problem bei der eingesetzten Lösung und was das Telefongespräch genau «resolved» hat. PDF/A bleibt aus Anbietersicht unbefriedigend: Support in Libs nicht so toll und Prüfung des Resultates nicht gerade Glückssache aber auch nicht non-trivial. Ich verstehe, dass man PDF/A anbieten will aber anscheinend überfordert diese Anforderung das Gesamtsystem ÖREB-Kataster Schweiz.

ÖREB-Kataster richtig gemacht #13 - map.oereb.services und weitere Beobachtungen

Wed, 11 Jan 2023 00:00:00 +0000

Um die URL ein wenig einprägsamer zu machen, habe ich die Resultate der Prüfungen der kantonalen ÖREB-Kataster-Dienste unter monitoring.oereb.services publiziert (Digitalocean 10-Dollar-Deployment. Und irgendwie verstehe ich nicht wie genau das Restarten des Containers funktioniert, wenn der Health Check fehl schlägt. Oder übersehe ich was?). Ein Kanton hat sich bereits bewegt: Der Kanton Zürich hat «Versions» und «GetEGRID» korrigiert.

Die ÖREB-Spezifikationen und Weisungen sind gut, insbesondere die des ÖREB-Webservices und des DATA-Extracts. Mit dem XML-Output lässt sich z.B. das PDF erzeugen. Man muss (und soll) nicht zwei unterschiedliche Wege für die Herstellung des XML und des PDF beschreiten. Sondern das XML herstellen und daraus das PDF ableiten. Somit lassen sich bereits viele Fehler vermeiden, z.B. Inhalt XML != Inhalt PDF usw.

Eine andere Anwendungsmöglichkeit des XML-Auszuges ist die Aufbereitung/Ableitung zum dynamischen Auszug, sprich zu einer Webanwendung. Die Webanwendung braucht bloss den XML-Auszug für ein Grundstück abzurufen und kann aus den Informationen eine mehr oder weniger schicke Anwendung konfigurieren. Ich denke, einige der Clients der Kantone funktionieren (hoffentlich) so. Macht man das nun mit dem Anspruch, dass es schweizweit funktionieren soll - wir sind ja standardisiert - gewinnt man wieder Erkenntnisse über die Spezialitäten der Kantone und wohl auch noch über Fehler, die man sonst weniger gut entdecken würde. Gesagt, getan: map.oereb.services. Es gibt sicher noch das eine oder andere Grundstück, wo es nicht funktioniert. Mal was Null, was man abfangen sollte o.ä. Und es fehlen genügend funktionierende Dienste, die Änderungen mit und ohne Vorwirkung publizieren, um die Gruppierung / Reihenfolge des Clients zu validieren. Oder ich habe die betroffenen Grundstücke nicht gefunden.

Zuerst ein paar nicht-ÖREB-Bemerkungen:

Die Anwendung ist komplett in Java mit GWT geschrieben. Als Toolkit wird Domino Kit verwendet. Das führt zu einem sehr angenehmen Entwickeln, da man sich im gleichen Ökosystem (Sprache, IDE, Build Tools) bewegt wie sonst auch. Mit GraalVM zu einem Native Image runterkompilieren und die «Java»-Anwendung startet 0.06 Sekunden.

Will man etwas wie eine Adressen- und Grundstücksuche anbieten, reichen die Möglichkeiten des ÖREB-Webservices nicht mehr aus. Es fehlt schlichtweg die Möglichkeit mittels Freitext zu suchen. Soweit auch nicht schlimm und wohl auch nicht sinnvoll. Der Search-Service der GeoAdmin API hilft uns. Der Dienst liefert eine Koordinate zurück. Mit dieser kann man einen EGRID beim ÖREB-Webservice abfragen. Nun müsste man die Anfrage an den Service eines jeden Kantons machen. Das wird nicht performen. Abhilfe schafft auch hier wieder die GeoAdmin API indem man den Feature Resource Dienst verwendet und wissen will, in welchem Kanton (ch.swisstopo.swissboundaries3d-kanton-flaeche.fill) die soeben erhaltene Koordinate liegt. Mit diesem Wissen kann man direkt den Service des betroffenen Kantons mit dem GetEGRID-Request beglücken. Der vermeintlich unnötige GetEGRID-Request ist notwendig, um zu eruieren, ob es sich um eine Liegenschaft oder um ein Baurecht handelt, wenn man einen Auszug mittels Klick in die Karte anfordert und es an dieser Stelle mehrere Grundstücke gibt.

Für die Hintergrundkarte verwende ich den ÖREB-Situationsplan von geodienste.ch. Leider fehlt ein schweizweiter WMTS dieser Hintergrundkarte. Aus diesem Grund wirkt das Zoomen und Pannen nicht so «snappy».

Nun zu den ÖREB-Kataster spezifischen Bemerkungen und Beobachtungen:

Inkompatible Kantone

Von den momentan vorhandenen Versions-2-Kantonen, können folgende Kantone nicht für diesen Anwendungsfall verwendet werden (oder es wäre nur mit unnötigem Geknorze möglich):

AI: WMS verlangt Authentifizierung, Beispielrequest.
AR: WMS verlangt Authentifizerung
BS: GEOMETRY=true beim GetEGRID-Request führt zu Fehlern.
FR: Geometrie fehlt beim GetEGRID-Request.
LU: Liefert keinen Referenz-WMS im Auszug mit.
NW: Liefert keinen Referenz-WMS im Auszug mit.
OW: Liefert keinen Referenz-WMS im Auszug mit.
SG: WMS verlangt Authentifizerung.
UR: Die Geometrien weisen ein falsches Koordinatensystem auf.
VS: Anstelle eines WMS wird eine ESRI-Irgendwas-Dienste-URL mitgeliefert.

Es funktionieren die Kantone AG, BE, BL, GR, JU, NE, SO, TG, TI, ZG, ZH.

CORS

Ich wollte ohne Umwege über ein Backend den XML-Auszug anfordern und im Browser verarbeiten. D.h. das XML wird vom Browser angefordert. Nun geht das leider bei vielen Kantonen nicht, da die «CORS-Header» nicht gesetzt werden. Die KGK hat vor geraumer Zeit die Kantone darüber informiert. Damals ging es um die GetCapabilities-Antwort eines WMS, die vom Browser ohne die Header nicht verarbeitet werden kann:

Funktioniert hat es (ohne alle zu prüfen) in den Kantonen BE, SO und TG. Um dennoch an den XML-Auszug zu kommen, musste ein einfacher Proxy her, der serverseitig das XML anfordert und an den Browser zurückschickt.

Layer-Opazität

Es gibt das Attribut layerOpacity, das die Deckkraft des Kartenelements regelt. In den Kantonen JU und ZH ist der Wert «1». Das bedeutet, dass die Karte komplett deckend ist. Wahrscheinlich nicht so gewollt.

Reihenfolge

Die Reihenfolge der Themen wie auch der Dokumente ist in der Weisung definiert. Beim Kanton Zürich ist mir aufgefallen, dass die Reihenfolge der gesetzlichen Grundlagen nicht stimmt. Das RPG wird ganz am Ende aufgelistet und sollte eigentlich als erstes geführt werden. Der Kanton Aargau verwendet hier «None». Das habe ich netterweise im Code abgefangen. Die Reihenfolge der Themen habe mir nicht angeschaut.

Die gerenderte Reihenfolge meines Clients müsste ich auch vertieft verifizieren, ob sie stimmt. Im ZH-Fall habe ich es im XML nachgeprüft.

Performance

Vielleicht ein heikles Thema. Mich dünkt, dass einige Dienste langsam sind. Ein denkbare Erklärung kann auch der «ÖREB-Habasch» sein, der im betroffenen Kanton wütet. Auffallend ist jedoch, dass Kantone mit der gleichen Software eher zu den langsameren gehören. Als Extrembeispiel dient der Kanton Aargau. Die GetEGRID-Anfrage dauert für ein Einfamilienhaus-Grundstück zwischen 1 und 6 Sekunden. Das ist m.E. nicht mehr nachvollziehbar. Warum soll eine Point-in-Polygon-Abfrage so viel Zeit in Anspruch nehmen? Der Extract nimmt zwischen 5 und 12 Sekunden in Anspruch. Im Kanton Bern ist es circa 1 Sekunde für den GetEGRID-Request und 3 Sekunden für den Extract. Die Kantone BL und NE sind ähnlich. Im Issue-Tracker findet man Meldungen zu einer Performance-Verschlechterung in den neueren Versionen. Ich habe jedenfalls in Erinnerung, dass diese Kantone in der Version 1.0 schneller waren.

Am anderen Ende der Skala sind die Kantone TG, ZH und SO: Da sind die GetEGRID-Requests im tieferen 3-stelligen Millisekundenbereich und der Extract gibt es für nicht allzu grosse Grundstücke im Subsekunden-Bereich.

Url-Encoding

Was ich echt nicht verstehe, sind gewisse Url-Encodings. Warum macht man sowas: «https%3A%2F%2Fwww.oereb2.apps.be.ch%2Fimage%2Fsymbol%2Fch.Nutzungsplanung%2Flegend_entry.png%3Fidentifier%3D3bcf516e-6419-4657-9190-a075e60c9512»? Warum encodiert man den Doppelpunkt und die beiden Slashs des Url-Schemas? Das ist doch nie nötig? Und ist bloss mühsam wenn man damit arbeiten will.

Identische Namen für unterschiedliche Dokumente

Beim Kanton Aargau erkennt man das ÖREBlex-Datenmodell wieder. Dort gibt es pro Entscheid ein Dokument, das Anhänge haben kann (oder so ähnlich). Das führt dazu, dass im XML unterschiedliche Dokumente den gleichen Titel aufweisen. Ob das sinnvoll ist, weiss ich nicht so recht. Tendiere zu nein. Der Kanton Aargau hat das jedenfalls visuell ansprechend im dynamischen Auszug gelöst (siehe Nutzungsplanung). Dito im PDF. Ganz streng genommen, sieht das wahrscheinlich die Weisung zum statischen Auszug nicht vor. In meinem Client wird jedes Dokument aufgelistet, egal ob es den gleichen Titel trägt. Also auch wieder ein Spezialität, die man als Entwickler kennen müsste, weil mindestens nicht offensichtlich.

Was man auch automatisch durch eine Maschine testen sollte, ist der layerIndex der Map-Elemente. Wenn sämtliche Elemente, also auch die Hintergrundkarte, den gleichen Wert aufweisen, weiss man nicht in welcher Reihenfolge die Bilder geschichtet werden müssen. Und wohl müsste im Regelfall (oder immer) die Hintergrundkarte - nomen est omen - tatsächlich im Hintergrund sein, also den kleinsten Wert aufweisen.

ÖREB-Kataster richtig gemacht #12 - Revisited: ÖREB-Kataster Compliance Test Suite

Sun, 1 Jan 2023 00:00:00 +0000

Ich habe die Test Suite um die Validierung der Endpunkte «versions» und «capabilities» erweitert und verschiedene Testresultate ein wenig unter die Lupe genommen.

versions

Beim Versions-Output prüfe ich neben der Schemakonformität tatsächlich auch den korrekten Wert der Version. Dies muss gemäss Weisung «extract-2.0» sein und nicht bloss «2.0». Loben darf man den Kanton Luzern (und Solothurn), der das korrekt macht, im Gegensatz zu allen anderen. Beim Kanton Zürich kommt gar nix resp. 404 zurück. Der Kanton Wallis ist auch hier wieder auf Kriegsfuss mit den Namensräumen. In diesem Fall steht nicht mal eine XML-Deklaration (<?xml version='1.0'?>) am Anfang des Dokumentes. Was zwar streng genommen nicht zwingend ist aber, nun ja, gute Praxis wäre («should»).

capabilities

Hier wird nur die Schemakonformität geprüft. Das Capabilities-Dokument bekommen die meisten hin. Der Kanton Freiburg leitet jedoch mit Status Code 307 weiter, was den Test fehl schlagen lässt. Die Kantone NW, OW und UR sind nicht schemakonform, weil der Topic-Code mit einer Zahl beginnt. Wieso sie das so machen, ist mir nicht klar. Der Topic-Code sollte doch gleich sein, wie später im Extract? Mein Lieblingskanton, der Kanton Tessin, hat zu lange Gemeindenummern (z.B. 531002) und der Kanton Wallis hat wiederum Namespace-Probleme: Einerseits ist das Root-Element GetCapabilitiesResponse einem falschen Namespace zugewiesen (http://schemas.geo.admin.ch/swisstopo/OeREBK/15/Extract), was die Prüfung sofort abbrechen lässt und andererseits sind Topics vom Typ «Theme», die einem anderem Namespace zugewiesen werden müssen, was hier nicht gemacht wird. Das Kantonskürzel bei kantonalen Themen muss in Grossbuchstaben geschrieben sein und nicht in Kleinbuchstaben (ch.vs.Ueberlagernde_Nutzungsplanung).

Plan für das Grundbuch

Ein Kränzchen muss man den Kantonen BE und BL winden. Diese verwenden für die Hintergrundkarte den Situationsplan (aka Plan für das Grundbuch) von geodienste.ch. Das hat mich natürlich getriggert und ich musste den Dienst auch bei uns testen. Leider werden die Gebäudenummern dargestellt, was im Kanton Solothurn dazu führt, dass Platzhalter-Werte dargestellt werden. Wir kennen keine eigentlichen Gebäudenummern und darum füllen die NF-Geometer Platzhalter ab, damit überhaupt ein EGID erfasst werden kann. Ist mir momentan noch nicht ganz klar, wie wir das lösen können. Sinnvoll wäre die Benutzung des geodienste.ch Services allemal, da er für teures Geld erstellt wurde und nun verwenden die aller meisten Kantone ihn nicht…

Stabilität

Interessant zu beobachten ist die Stabilität der Dienste, soweit dies mit solchen einfachen Tests überhaupt möglich ist. Die sonstigen Musterschüler BL und NE kämpfen hier ein wenig. Der Kanton BL hat nachweislich Aussetzer, die oftmals einen Auszug mit eingebetteten Bildern betreffen. Weil ich zuerst am eigenen Code zweifelte, habe ich bei Statuscake ein paar Tests am Laufen, die alle 5 Minuten einen Request machen. Statuscake bestätigt meine eigenen Beobachtungen. Das passiert maximal ein paar Mal pro Tag und kann natürlich irgendwas sein. Nicht zwingend der Dienst selber, sondern auch was unterwegs zwischen Eingang ins Kantonsnetz und ÖREB-Service.

Beim Kanton Neuenburg funktionieren plötzlich die Auszüge mit Bildern nicht mehr. Der Server wirft einen 500er Status Code. Interessanterweise funktioniert das PDF noch, jedoch im dynamischen Auszug werden keine Karten mehr dargestellt, obwohl die restliche Logik noch zu funktionieren scheint. Einmal mehr: Was sind gute Health-Checks für Kartendienste?

Embedded Images

Zu guter Letzt habe ich die eingebetteten Bilder angeschaut. Die Kantone AR, BS und SG funktionieren nicht, wenn man die Bilder anfordert und können nicht getestet werden.

Eine leider nicht ganz geklärte Frage ist, ob die Bilder mit 300 dpi ausgeliefert werden müssen. Die Weisung nimmt nur bei den Symbolen Stellung. Meines Erachtens ist es sinnvoll die Bilder in einer «brauchbaren» Qualität auszuliefern. Damit mit dem XML auch das PDF erstellt werden kann. Oder als Kunde will man vielleicht die Bilder in einer Word-Datei oder ähnlichem verwenden. Auch für solche Anwendungsfälle sind die 96 dpi wohl nicht wirklich genügend. Die Kanton AG, BE, BL, GR, LU, TI, ZG liefern keine 300 dpi aus.

Eine eher eigenwillige Darstellung für den Plan für das Grundbuch verwenden die Kantone LU (blaue Gewässer), UR (eher «einfach») und ZG (düster und dicke Linien):

Getreu dem Motto «Quadratisch, praktisch, gut» liefert der Kanton Luzern zudem seine Bilder in einem quadratischen Format aus.

Wir im Kanton Solothurn sind meines Erachtens auch nicht ganz korrekt unterwegs beim Plan für das Grundbuch der Titelseite. Auf Wunsch der Nachführungsgeometer stellen wir bei uns den sogenannten «zukünftigen» Stand der Grundstücke dar. D.h. bei einer Mutation werden die immer noch rechtsgültigen (schwarzen) Grenzen nicht dargestellt, sondern in rot die zukünftigen Grenzen. Beim Plan für das Grundbuch für die ÖREB wird der rechtsgültige Zustand dargestellt (und keine projektierten Grundstücke).

Der Kanton Wallis liefert keine eingebetteten Bilder aus und liefert auch bei WITHIMAGES=true nur einen Verweis auf einen ESRI-Webdienst (!= WMS). Die Bilder der einzelnen ÖREB haben fälschlicherweise bereits den Plan für das Grundbuch als Hintergrund:

Das Bild resp. den Esri-Kartendienst-Request für die Titelseite (PlanForLandRegisterMainPage) wird nicht ausgeliefert und im Plan für das Grundbuch für die ÖREB (PlanForLandRegister) sind die Gebäude ausgefüllt.

Der Kanton Zürich liefert wie bereits in der ÖREB-Kataster Version 1.0 die Bilder der ÖREB mit Plan für das Grundbuch, Nordpfeil, Massstab und Bandierung:

Der Plan für das Grundbuch für die ÖREB (PlanForLandRegister) ist irgendwie merkwürdig:

Conclusions

Ich weiss nicht genau welche Kataster in welchem Abnahme-Status sind. Die gezeigte Folie an der letzten ÖREB-Kataster-Veranstaltung war ähm irgendwie eher ein Zufallsprodukt (sorry). Übrigens: Kann jemand diese Zip-Datei öffnen? In einer dieser Präsentationen sollte die Übersichtskarte mit den Status der Kantone sein. Leider kann ich sie nicht öffnen.

Trotz allem Erreichten im «Gesamtsystem» ÖREB-Kataster darf man sich nicht zu stark auf die Schultern klopfen. Anscheinend ist auch die technische Umsetzung des ÖREB-Katasters für die Kantone non-trivial. Trotzdem will man es 26 Mal umsetzen. Viele Kantone verwenden den gleichen Software-Stack. Abgesehen von tendenziell marginalen Fehlern, scheint es hier also eher ein Konfigurations- und Betriebsproblem zu sein? Ist der Software-Stack zu kompliziert? Fehlt Wissen in den Kantonen? Ich weiss es nicht.

Bei ganz wenigen dünkt mich die Qualität schlichtweg ungenügend (teilweise wegen eines vermeintlichen Details). Wie soll ein Benutzer damit umgehen, wenn er nicht bloss einen Knopf im dynamischen Auszug drückt (anscheinend fokussiert sich unser aller Aufmerksamkeit da drauf), sondern wirklich mit den Schnittstellen arbeiten will und muss? Das ist in diesen Fällen schlichtweg nicht möglich oder verschiedentlich nur mit grausigen Workarounds (= Zusatz-Code = Zusatzaufwand. Ja ja und technisch ist immer alles möglich… technical debs und so). Hier sollte sowohl der Kanton und auch die Aufsicht besser hinschauen.

Die Abnahme resp. die Validierung des Katasters darf nicht unterschätzt werden. Klar kann man gegen das Schema prüfen. Jedoch ist das Schema relativ tolerant: D.h. eine einfache Schemaprüfung validiert positiv auch wenn man eingebettete Bilder anfordert aber keine zurück bekommt. Die Prüfung ist also abhängig vom Request und es sind sehr viele Kombinationen möglich. Ich prüfe z.B. nur XML-Auszüge. Man wollte als Option unbedingt noch JSON als (optionales) Outputformat, das bedeutet nun aber auch erhöhter Prüfungsaufwand und erhöhte Fehleranfälligkeit.

Leicht kritisch darf man zukünftige Weiterentwicklungen (weitere Rechtszustände, behördenverbindliche Daten, Grundstücksinformationsystem, …) hinterfragen: Einfacher wird es nicht und wir kriegen bereits ein relativ einfaches Konstrukt nicht wirklich sauber auf die Reihe.

Alhamdulillah ist der ÖREB-Kataster nicht systemkritische Infrastruktur.

Ich bleibe dabei:

INTERLIS leicht gemacht #34 - ilivalidator for Python 0.0.2

Sat, 31 Dec 2022 00:00:00 +0000

Ich habe ein paar Features implementiert:

Ilivalidator erlaubt es mehrere INTERLIS-Transferdateien gleichzeitig und gemeinsam zu prüfen. Sollen mehrere Dateien gleichzeitig (sprich mit einem Aufruf) geprüft werden, reicht es, wenn man die Dateien beim Kommandozeilenaufruf aneinander reiht:

java -jar ilivalidator.jar OeREBKRM_V2_0_Gesetze.xml OeREBKRM_V2_0_Themen.xml

Die Dateien werden unabhängig voneinander geprüft. Im vorliegenden Fall sind die ÖREB-Themen und die Gesetze miteinander verknüpft (Assoziation mit externen Rollen). Ob diese Verknüpfung stimmig ist, möchte man in der Regel wohl prüfen. D.h. die Dateien müssen gemeinsam geprüft werden:

java -jar ilivalidator.jar --allObjectsAccessible OeREBKRM_V2_0_Gesetze.xml OeREBKRM_V2_0_Themen.xml

Ilivalidator meldet auch mit dieser Option keine Fehler. Wenn man im Themen.xml nun einen Verweis auf ein Gesetz verfälscht, z.B. <Gesetz REF="mich.gibt.es.nicht"/>, meldet ilivalidator einen Fehler:

Error: line 54: OeREBKRMkvs_V2_0.Thema.ThemaGesetz: No object found with OID mich.gibt.es.nicht.

Wird --allObjectsAccessible nicht verwendet, wird korrekterweise kein Fehler gefunden.

Neu kann man auch mit «ilivalidator for Python» mehrere Dateien prüfen. Der zwingende Methodenparameter data_file_names ist eine Liste:

from ilivalidator import Ilivalidator

valid = Ilivalidator.validate(['OeREBKRM_V2_0_Gesetze.xml','OeREBKRM_V2_0_Themen.xml'])

Will man wie eingangs erklärt die Dateien gemeinsam prüfen, muss der Parameter --allObjectsAccessible übergeben werden. Dies funktioniert mit einem Dictionary, das optional ist:

from ilivalidator import Ilivalidator

settings = {Ilivalidator.SETTING_ALL_OBJECTS_ACCESSIBLE: True}
valid = Ilivalidator.validate(['OeREBKRM_V2_0_Gesetze.xml','OeREBKRM_V2_0_Themen.xml'], settings)

Die Namen der Parameter sind als «Konstanten» verfügbar. Im Original ist --allObjectsAccessible eine Option ohne Argument. Hier muss (falls es verwendet wird) entweder True oder False gesetzt werden.

Neu sind folgende Optionen implementiert:

SETTING_ILIDIRS: --modeldir
SETTING_MODELNAMES: --models
SETTING_ALL_OBJECTS_ACCESSIBLE: --allObjectsAccessible
SETTING_LOGFILE: --log
SETTING_LOGFILE_TIMESTAMP: --logtime
SETTING_XTFLOG: --xtflog
trace: --trace

Optionen, die im Original ohne Argument funktionieren, müssen hier immer mit einem Boolean-Werte verwendet werden.

Zusätzlich habe ich mit pytest angefangen Tests zu schreiben. Bei der Native Shared Library ist mir noch nicht klar was und wie genau getestet werden kann/soll.

Ein einfachster ilivalidator-Webservice mit Flask (ohne Grüsel-Systemcalls):

pip install Flask
pip install ilivalidator==0.0.2

ilivalidator-webservice.py:

import os
from flask import Flask, flash, request, redirect, url_for
from werkzeug.utils import secure_filename
from ilivalidator import Ilivalidator
import tempfile

UPLOAD_FOLDER = '/tmp'
ALLOWED_EXTENSIONS = {'xtf', 'xml', 'itf'}

app = Flask(__name__)
app.config['UPLOAD_FOLDER'] = UPLOAD_FOLDER

def allowed_file(filename):
    return '.' in filename and \
           filename.rsplit('.', 1)[1].lower() in ALLOWED_EXTENSIONS

@app.route('/', methods=['GET', 'POST'])
def upload_file():
    if request.method == 'POST':
        # check if the post request has the file part
        if 'file' not in request.files:
            flash('No file part')
            return redirect(request.url)
        file = request.files['file']
        # If the user does not select a file, the browser submits an
        # empty file without a filename.
        if file.filename == '':
            flash('No selected file')
            return redirect(request.url)
        if file and allowed_file(file.filename):
            filename = secure_filename(file.filename)
            filepath = os.path.join(app.config['UPLOAD_FOLDER'], filename)
            file.save(filepath)

            temp_dir = tempfile.TemporaryDirectory()
            log_file = os.path.join(temp_dir.name, "mylog.log")

            settings = {Ilivalidator.SETTING_LOGFILE: log_file}
            valid = Ilivalidator.validate([filepath], settings)

            with open(log_file,"r") as f:
                content = f.read()
                return content

            return "should not reach here"
    return '''
    <!doctype html>
    <title>Upload new File</title>
    <h1>Upload new File</h1>
    <form method=post enctype=multipart/form-data>
      <input type=file name=file>
      <input type=submit value=Upload>
    </form>
    '''

(Grundgerüst copy/paste von hier.)

Die Flask-Anwendung starten:

flask --app ilivalidator-webservice run

Und mit curl eine INTERLIS-Transferdatei hochladen (oder mit dem Browser):

curl -X POST -F file=@OeREBKRM_V2_0_Gesetze.xml http://127.0.0.1:5000

Der Output sollte der Inhalt des Logfiles der Validierung sein:

What’s next? Keine Ahnung. Ich persönlich habe keinen grossen Bedarf an den ilitools in Python. Trotzdem finde ich es eine sinnvolle Sache und es könnte der Verbreitung und Akzeptanz von INTERLIS helfen. Dann müssten aber die Python Aficionados und geostandards.ch aus dem Sonnenaufgang hervor geritten kommen.

ÖREB-Kataster richtig gemacht #11 - ÖREB-Kataster Compliance Test Suite Webservice

Thu, 22 Dec 2022 00:00:00 +0000

Im Oktober habe ich einen Prototypen eines ÖREB-Kataster-Checkers vorgestellt. Das Ganze habe ich als Webservice deployed, der alle paar Stunden die Prüfungen macht. Geprüft wird lange nicht alles was geprüft werden könnte, sondern nur einige Aspekte, die mir wichtig scheinen (oder einfach zu implementieren waren):

HTTP Status Code
Response Content Type
Schemakonformität
Gibt es Geometrie-Elemente, wenn solche vorhanden sein müssen (resp. umgekehrt)?
Sind die Geometrien im Bezugsrahmen LV95?
Gibt es eingebettete Bilder, wenn solche vorhanden sein müssen (resp. umgekehrt)?
Sind alle Bundesthemen-Codes im XML-Inhaltsverzeichnis vorhanden? (ConcernedTheme, NotConcernedTheme, ThemeWithoutData)

Beim Response Content Type lasse ich application/xml; charset=UTF-8 als korrekt durchgehen, auch wenn die Weisung nur von application/xml spricht. Ob alle Bundesthemen-Codes vorhanden sein müssen, ist mir selber nicht ganz klar. Wenn man z.B. die neuen Themen noch nicht umgesetzt hat, könnten sie fehlen. Aber in diesem Fall sollten sie sinnvollerweise bei den Themen ohne Daten erscheinen.

Einige erwähnenswerte Beobachtungen:

Verschiedene Kantone (BS, GR, NW, OW, UR, VS, ZH) verwenden einen falschen Status Code bei der Weiterleitung zum dynamischen Auszug. Entweder wird 301 oder 302 verwendet, korrekt ist 303. Der Kanton Wallis ist ein Spezialfall. Dazu später mehr.

Einige Kantone (AG, BS, GR, TI) scheinen noch nicht eine aktuelle pyramidoereb-Version zu verwenden. Da gab es noch ein Problem mit der Schemakonformität und dem QRCode/QRCodeRef-Element.

Der Content Type ist in seltenen Fällen falsch (und kein Folgefehler): Die Kantone Obwalden, Nidwalden und Uri verwenden beim Extract text/xml; charset=utf-8.

Bei vielen Kantonen fehlen meines Erachtens verschiedene Bundesthemen-Codes im Extract. Es gibt zwei Fälle zu unterscheiden: Das sind die Kantone (AG, AR, BE, SG, ZH), welche die neuen Themen noch nicht umgesetzt haben. Ich finde, wenn man schon das Rahmenmodell Version 2 verwendet, sollten diese Themen unter ThemeWithoutData gelistet werden. Dann gibt die Kantone (AI, BS, LU, NW, OW, TG, UR), die zusätzlich (oder nur) bestehende Themen in keinem der drei «Themen» im Inhaltsverzeichnis auflisten. So gibt es z.B. in keinem dieser Kantone eine Nutzungsplanung (ch.Nutzungsplanung). Sondern es gibt das kantonale Derivat davon (ch.KT.xxxxx). Das dünkt mich falsch. Wenn man die Nutzungsplanung unterteilen will, sollte das mit Subthemen gemacht werden.

Kommen wir zu den exotischeren Fällen:

Im Kanton Aargau scheint es im Kontext des ÖREB-Katasters keine NBIdent zu geben. Im Extract steht <data:IdentDN>N/A</data:IdentDN>. Wenn ich den (hoffentlich korrekten) NBIdent aus den Daten der amtlichen Vermessung verwende, funktioniert der GetEGRID-Request jedoch trotzdem nicht.

Im Kanton Appenzell Innerrhoden funktionieren Aufrufe mit WITHIMAGES=true nicht.

Im Kanton Freiburg werden beim GetEGRID-Aufruf mit GEOMETRY=true keine Geometrie zurückgeliefert. Im Kanton Basel-Stadt funktioniert ein Aufruf mit GEOMETRY=true weder bei GetEGRID noch beim Extract. In beiden Fällen werden Fehler zurückgeliefert.

Der Kanton Uri verwendet konsequent keine LV95-Koordinaten in den Geometrien, sondern Pseudo-Mercator (EPSG:3857). Ich bin mir nicht sicher, ob das überhaupt irgendwo explizit geregelt ist. Aber man darf schon davon ausgehen, dass man LV95 ausspucken sollte. Zudem im Capabilities-Dokument auch der Kanton Uri dies so bestätigt.

Der Kanton Zürich weist das Limit-Element beim GetEGRID-XML dem falschen Namespace zu, was zu Schemakonformitätsfehlern führt.

Der Kanton Luzern liefert leider immer eingebettete Bilder mit, auch wenn er dies explizit nicht sollte. Dafür fehlt der Verweis auf den WMS. Das ist sehr ärgerlich und wahrscheinlich der mühsamste Fehler. Die Schnittstelle wird so ad absurdum geführt: Die Anfragezeit ist deutlich länger (weil ja die Bilder produziert werden müssen) und für Aussenstehende ist der Dienst unbrauchbar, weil die WMS-Referenzen fehlen. Man kann keinen dynamischen Auszug bedienen. Ein Schelm wer Böses denkt.

Ein anderes Sorgenkind ist der Kanton Wallis: Er leitet die Anfragen konsequent mit 307 (Temporary Redirect) weiter. Der Grund ist, soweit ich das nachvollziehen kann, der «trailing slash» im Pfad der Url: …/getegrid/xml/?EN=2643445,1130616. Ein solcher Request wird zu …/getegrid/xml?EN=2643445,1130616 weitergeleitet (ohne den letzten Slash). Ich finde das nicht ein gutes Vorgehen: In der Weisung gibt es explizit eine Weiterleitung (zum dynamischen Auszug). D.h. Weiterleitungen haben eine gewisse Semantik. Ein Anwender der Schnittstelle muss seinen HTTP-Client nun so konfigurieren, dass er für die statischen Auszüge weiterleitet (Browser macht das automatisch, curl nicht), wahrscheinlich aber für den dynamischen Auszug nicht, weil das sowieso anders gehabt werden muss. Als weiteres Ungemach wartet dann eine XML-Datei ohne Namespaces und ohne Geometrien. Die WMS-Referenzen zeigen auf ArcGIS-REST-Services und nicht auf WMS.

Manchmal kommt es vor, dass ein Request nicht funktioniert. Entweder ist der Dienst noch nicht wirklich stabil oder der Hund liegt bei mir begraben. Klar ist, dass ich keine Retries mache. Das muss ich beobachten.

Fehler in der Analyse bitte melden.

INTERLIS leicht gemacht #33 - Python loves INTERLIS

Sun, 11 Dec 2022 00:00:00 +0000

Die GeoBeer-Events sind eine tolle Sache. Wenn man aber den Mund mit zunehmender Menge Bier immer voller nimmt, ist man halt selber schuld: Für einen Github-Stern versprach ich, dass ich einen Proof of Concept der Java-INTERLIS-Werkzeuge als Python-Package mache, weil das mit GraalVM «ganz einfach und schnell geht».

Die Idee ist, dass man z.B. ilivalidator wie praktisch jedes andere Python Package installieren kann:

pip install ilivalidator

Und natürlich ohne den ganzen Java-Zauber, d.h. es soll ganz ohne Java funktionieren. Über die Jahre habe ich bereits einiges mit GraalVM in dieser Richtung gemacht. Darum auch die Euphorie, dass das alles kein Problem sei. Die grösste Unbekannte war für mich eher wie man ein Python Package macht (inkl. Shared Library) und das zum Download für pip bereitstellt. Das Ganze soll natürlich ebenfalls als Github Action in einer OS-Matrix laufen. Aber der Reihe nach:

Mit GraalVM lassen sich nicht bloss die INTERLIS-Werkzeuge zu einem Native Image kompilieren, sondern es lassen sich auch sogenannte Native Shared Libraries machen. Das sind Bibliotheken, die man in einem C/C++-Programm verwenden kann (aka *.so und *.dll). Diese lassen sich auch in einem Python-Skript gut ansteuern und verwenden. Wenn man nicht das komplette Programm zu einem Native Image kompilieren will, sondern zu einer Shared Library, muss man ein paar Zeilen zusätzlichen Code schreiben. Nämlich eine statische Java-Methode:

package ch.so.agi.ilivalidator.libnative;

import org.graalvm.nativeimage.IsolateThread;
import org.graalvm.nativeimage.c.function.CEntryPoint;
import org.graalvm.nativeimage.c.type.CCharPointer;
import org.graalvm.nativeimage.c.type.CTypeConversion;
import org.interlis2.validator.Validator;

import ch.ehi.basics.settings.Settings;

public class IlivalidatorLib {

    @CEntryPoint(name = "ilivalidator")
    public static boolean validate(IsolateThread thread, CCharPointer dataFilename) {
        var settings = new Settings();
        boolean valid = Validator.runValidation(CTypeConversion.toJavaString(dataFilename), settings);
        return valid;
    }
}

Diese statische Methode muss mit @CEntryPoint annotiert werden, damit sie im C/C++-Programm aufrufbar wird. Es gibt ein wenig GraalVM-Boilerplate (IsolateThread thread), der uns aber nicht gross stören soll. Weil es ein Proof of Concept ist, ist die Methode sehr einfach gehalten. Es kann nur der Dateinamen der zu prüfenden INTERLIS-Transferdatei übergeben werden. Als Typ muss CCharPointer verwendet werden, der später zu einem Java-String umgewandelt wird. Es können nur wenige Typen verwenden werden. Es wird als nicht möglich sein z.B. eine Settings-Klasse zu übergeben. Das ist aber weniger schlimmer als zuerst befürchtet. Die Settings können z.B. als JSON-String übergeben werden und anschliessend in der Methode zu ihren korrekten Optionen gemappt werden. Das Resultat nach dem Kompilieren mit GraalVM sind Header-Dateien und die Shared Library. Im Gegensatz zu Java-Bibliothekn muss die Shared Library für jedes Betriebssystem kompiliert werden.

Python bietet mit ctypes eine Bibliothek, die Funktionen in einer Shared Library aufrufen kann. Die Python-Ilivalidator-Klasse sieht so aus:

import platform

from ctypes import *
from importlib_resources import files

if platform.uname()[0] == "Windows":
    lib_name = "libilivalidator.dll"
elif platform.uname()[0] == "Linux":
    lib_name = "libilivalidator.so"
else:
    lib_name = "libilivalidator.dylib"

class Ilivalidator:
    def validate(data_file_name):
        lib_path = files('ilivalidator.lib_ext').joinpath(lib_name)
        # str() seems to be necessary on windows: https://github.com/TimDettmers/bitsandbytes/issues/30
        dll = CDLL(str(lib_path))
        isolate = c_void_p()
        isolatethread = c_void_p()
        dll.graal_create_isolate(None, byref(isolate), byref(isolatethread))
        dll.ilivalidator.restype = bool

        result = dll.ilivalidator(isolatethread, c_char_p(bytes(data_file_name, "utf8")))
        return result

Ilivalidator.validate = staticmethod(Ilivalidator.validate)

Zuerst musst die Library geladen werden. Anschliessend wird in Zeile 23 die ilivalidator-Funktion in der Shared Library aufgerufen.

Nun kam der wirklich schwere Teil: Wie macht man ein Python Package und wie stelle ich dieses bereit? Als totaler Python-Fremdling war das eine echte Herausforderung. Einfach weil man es nicht kennt und aus einer völlig anderen Welt kommt. Nach ein wenig Einlesen und Googeln hatte ich mein Package soweit und konnte es auf test.pypi.org veröffentlichen.

Eine weitere Herausforderung war das Testen unter Windows. Vorallem fehlte mir die Windows-Testumgebung. Klar kann ich relativ einfach den Code mit einer Github Action auf einem Windows-Runner testen. Das Debuggen ist jedoch so ziemlich schwierig. Auf meinem Macbook Air mit UTM geht das wegen des ARM-Prozessors schon mal nicht (so gut), da es keinen Github Runner für Windows ARM gibt, der die Shared Library kompilieren könnte. Darum musste das alte Intel-Macbook her. Netterweise bietet Microsoft Windows 11 Images für verschiedene Hypervisoren. Die Kombination mit Virtualbox erwies sich aber als unbrauchbar, da Windows nach kurzer Zeit nicht mehr auf Eingaben reagierte. Mit dem leider nicht freien Parallels funktioniert es aber sehr gut. Somit konnte ich das Python Package auch unter Windows 11 testen und paar Fehler ausmerzen. Klammerbemerkung: Warum man einfach mal str() verwenden soll, damit es unter Windows läuft, weiss nur der liebe Gott oder ein Python-Guru. Erinnert mich an meine C-Experimente während des Studiums: Hat man das Prinzip mit den Zeigern nicht so wirklich verstanden, probiert man es mit *foo und wenn das nicht funktioniert, versucht man &foo. Profis am Werk.

Nun denn, here it is: https://pypi.org/project/ilivalidator/

Das Package lässt sich mit pip installieren:

pip install ilivalidator

Innerhalb eine Python-Skripts kann ich ilivalidator wie folgt aufrufen:

from ilivalidator import Ilivalidator

valid = Ilivalidator.validate('tests/data/254900.itf')
print("The file is valid: {}".format(valid))

Es sind keine ilivalidator-Optionen exponiert und somit ist es wirklich nur ein Proof of Concept. Aber nun steht alles und man müsste Fleissarbeit leisten. Die anderen Java-INTERLIS-Werkzeuge lassen sich analog als Python Package bereitstellen.

Weil es kein pures Python Package ist (sondern abhängig von Native Shared Libraries ist), muss man für jedes Betriebssystem, Betriebssystemvariante und Prozessor-Architektur das Package herstellen. Momentan lässt sich das einfach für folgende Schnittmenge bewerkstelligen: Die Betriebssysteme und Prozessor-Architekturen, die GraalVM Native Image unterstützt und die frei verfügbaren Github Action Runner. In meiner Github Action kompiliere ich auf Ubuntu 22.04, macOS 12 und Windows 2022 jeweils auf x86_64 (also nicht ARM). Man könnte z.B. für Linux ARM bei Oracle Cloud gratis einen Self-Hosted Runner erstellen oder analog für Apple Silicon bei Hetzner einen Mac mini mieten. Die verfügbaren Kombinationen finden sich auf pypi.org unter «Download files».

So, jetzt will ich meinen Github-Stern.

GraalVM Polyglot Superpowers #1 - SpatioTemporal Asset Catalogs (Stac)

Mon, 14 Nov 2022 00:00:00 +0000

SpatioTemporal Asset Catalogs sind der neue heisse Scheiss in der (Cloud-Native-)Geowelt:

«At its core, the SpatioTemporal Asset Catalog (STAC) specification provides a common structure for describing and cataloging spatiotemporal assets.»

Umgangssprachlich heisst das: JSON-Dateien mit Links auf Datensätze mit bisschen Metainformation und der Möglichkeit verschiedene Zeitstände anzubieten. Eigentlich gibt es das dank INSPIRE bereits auf Basis von Atomfeed und OpenSearch (mit einer Helvetisierung in eCH-0056). So richtig durchgesetzt hat sich das nicht, was schade ist, da man damals bereits darauf geachtet hat das Rad nicht mehr neu zu erfinden, sondern vorhandene Nicht-GIS-Technologien zu verwenden. Die Helvetisierung war ein Totalflop, was man sich im Nachhinein leider eingestehen muss.

Die Stac-Spezifikation besteht aus vier «semi-unabhängigen» Spezifikationen, was zeitweilig ein wenig verwirrend sein kann. Die Chose ist aber auf Github relativ gut beschrieben. Nur manchmal wünschte ich mir ein INTERLIS-Modell zwecks besserer Lesbarkeit. Etwas was mich eben verwirrt, sind Ankündigungen, dass ein Release Candidate einer Stac-Spez veröffentlicht wurde. Hä, warum, die ist noch schon fertig? Nein, es gibt vier davon. Die ersten drei beschreiben meines Erachtes nur statische Dinge (Item, Catalog und Collection), also im Prinzip die JSON-Schemen. Die Vierte im Bunde, die Stac API Spezifikation, spezifiert eine Rest-API. Um diese geht es hier nicht, sondern um die Herstellung der statischen Dateien und das Bereitstellen dieser.

Wir verwalten sämtliche Informationen zu einem Datenthema in einer Metadatenbank. Aus diesen Informationen erzeugen wir unterschiedliche Konfigurationsdateien, um die verschiedenen Dienste zu bedienen, die dann zur Laufzeit nicht auf die Metadatenbank zugreifen müssen, sondern nur auf diese Konfigurationsdatei. Einer dieser Dienste ist die sogenannten Datensuche, sprich unsere zukünftige Datenabgabe. Für diese stellen wir eine XML-Datei aus der Metadatenbank her mit den benötigten Informationen aller zum Download stehenden Geodaten. Die Datensuche-Anwendung liest beim Start diese XML-Datei, erstellt einen Suchindex und füllt das GUI ab. Auf dieser Basis könnte man auch gleich den Stac-Catalog erzeugen: XML-Datei als Input und die Stac-JSON-Dateien als Output via Webserver bereitstellen. Für das Herstellen von Stac-Catalogen dünkt mich vor allem die Python-Bibliothek pystac tauglich. Das würde aber bedeuten, dass ich eine komplette Anwendung mit Python machen müsste. GraalVM to the rescue.

GraalVM bietet unter anderem eine Python-Implementierung an. Das Spannende für mich ist, dass man polyglot programmieren kann. D.h. man kann zwischen Java und Python Objekte austauschen:

class StacCreator:
    def create(self, collection_file_path, theme_publication, files_server_url, root_url):
        collection_id = theme_publication.getIdentifier()
        ...

Der Python-Methode create wird eine theme_publication übergeben. Dies ist ein POJO, das aus dem Parsen der XML-Datei in Java erzeugt wurde. In der Python-Methode kann ich zum Beispiel auf die Getter-Methode getIdentifier() zugreifen, welche mir den Identifier der Themenbereitstellung liefert usw.

Mein Ziel ist es also möglichst wenig Python schreiben zu müssen. Nur gerade das, was notwendig ist, um die Stac-Kataloge zu erzeugen. Kein Parsen der XML-Dateien, keinen Webserver hochfahren etc. Müsste ich alles lernen und habe ich bereits in meiner Spring Boot Anwendung vorliegen.

Als Grundlage diente mir Tim Felgentreffs ausgezeichneter Blogbeitrag «Supercharge Your Java Apps with Python». Interessanter als das Geschriebene zu wiederholen, ist zu erwähnen, was mir nicht gelungen ist resp. nur über Umwege.

Zuerst wollte ich die Anwendung zu einem Native Image kompilieren, damit man GraalVM nicht installieren muss. Das geht mit Spring Boot leider noch nicht. Weil die Anwendung, wenn überhaupt, im Regelfall in einem Dockercontainer laufen würde, ist das nicht das Ende der Welt. Die grössere Herausforderung ist/war der Umgang mit dem venv-Ordner. GraalVM erstellt diesen und speichert die notwendigen Python-Bibliotheken in dieser virtuellen Umgebung. Wie paketiert man das in der Java-Welt? Am elegantesten wäre natürlich, wenn wir den venv-Ordner als normale Ressource behandeln können und in die Spring Boot Fat-Jar packen könnten. Die Enttäuschung kommt beim Starten der Anwendung: Es findet die PyStac-Bibliothek nicht. Grund dafür ist, dass das unterliegende Truffle-Filesystem kein Jar-Filesystem implementiert, sondern «nur» das normale Filesystem. Wenn die Anwendung nur in einem Docker-Container laufen würde, könnte man den venv-Ordner beim Builden des Images reinkopieren. Das finde ich einschränkend. Ich mag immer noch den Gedanken, dass eine Java-Awendung, jetzt halt eine polyglote Java-Anwendung, mit java -jar sodata-stac.jar gestartet werden kann. Ich habe mich dazu entschlossen den venv-Ordner zu zippen und die Zip-Datei in die Jar-Datei zu kopieren. Diese Zip-Datei wird beim Hochfahren der Anwendung aus den Ressourcen kopiert und entpackt. Vielleicht kann man das eleganter lösen. Mir ist aber nichts besseres in den Sinn gekommen.

Ein ein weiteres Problem ist die Kompatibilität der Python-Bibliotheken. Diese ist nicht immer garantiert und man ist in diesem Fall aufgeschmissen. Bei mir lief aber alles rund mit PyStac.

Ist polyglotes Programmieren sinnvoll? It depends. Ich sehe schon Vorteile (auch wenn jetzt gleich die Microservice-Marktschreier ums Eck kommen werden): Ich bin froh, wenn ich in der Java-Welt, wo ich einiges kenne (Build-Tools, IDE, Frameworks, Paketierung …), verbleiben kann und nur das absolut nötigste auslagern muss. Und welche GIS-Abteilung hat tatsächlich die notwendige Grösse und hat verschiedene Teams, die an verschiedenen Microservices arbeiten?

Es funktioniert übrigens auch umgekehrt, d.h. mittels Graalpython auf Java-Klassen zugreifen. Das habe ich in einem älteren Blogbeitrag am Beispiel ili2gpkg gezeigt.

Nachfolgend Links zum Code und zu interessanten Webseiten, die mir weitergeholfen haben. Wer es ausprobieren will:

docker run -p 8080:8080 -v ~/tmp:/stac sogis/sodata-stac-jvm

Im lokalen ~/tmp-Ordner liegen die Stac-Dateien. Die Links auf die Assets funktionieren nicht, da es sich um Fantasie-Daten handelt.

Links:

INTERLIS leicht gemacht #32 - The State of INTERLIS native

Tue, 1 Nov 2022 00:00:00 +0000

Der Titel ist (zu) bedeutungsschwanger und schlaumeierisch. Es geht weniger um INTERLIS selbst, sondern ob die Lieblingswerkzeuge eines jeden Geoinformatikers (ili2db, ilivalidator und ili2c) zu einem Native Image kompilierbar sind und diese sinnvoll zu gebrauchen sind. Ein Native Image ist ahead-of-time kompilierter Java-Code. Dieses Native Image benötigt keine Java Virtuelle Maschine mehr. Dafür muss es für jedes Betriebssystem eigens kompiliert werden. Ich fand die Idee ziemlich cool, als ich das erste Mal davon hörte. Meine Einstiegsdroge war ein Blogbeitrag von Chris Seaton. Damals wohl Mitarbeiter bei Oracle Labs. Ein Native Image kann man nicht mit dem normalen JDK herstellen, sondern man benötigt (noch) GraalVM. Ein Teil der GraalVM wird wieder zurück in das OpenJDK-Projekt fliessen, wo es glaub ursprünglich sogar herkam. Im Kern also bereits eine alte Idee.

Warum möchte man überhaupt Java-Anwendungen zu einem Native Image kompilieren? Solche Native Images sind kleiner (im Vergleich zu einer JVM plus Anwendungscode) und starten extrem schnell, was sie spannend macht für Cloud Deployments. Sie benötigen zudem weniger RAM und CPU. Aber all das ist nicht allgemeingültig und Nachteile gibt es auch. Wie erwähnt muss man für jedes Betriebssystem ein separates Native Image kompilieren. Das Kompilieren dauert relativ lange und im Gegensatz zum Just-in-Time-Compiler finden zur Laufzeit keine Optimierungen statt.

Im Fall der INTERLIS-Werkzeuge kann man sich schon vorstellen, dass ein Native Image ein paar Vorteile bringt:

Zugang zur Anwendung vereinfachen: Für viele Anwender ist das Installieren der Java-Anwendung eine Herausforderung. Man muss die Zip-Datei herunterladen und entpacken und dann - wenn man das GUI verwenden will - müssen die Einstellungen auf dem Computer korrekt sein, damit ein Doppelklick die Anwendung startet. Zudem muss eine JVM vorhanden sein, die ebenfalls installiert werden will. Hier könnte es eventuell schon helfen, wenn alles in ein einzelnes ausführbares Binary verpackt wird.
Einbinden in andere (Nicht-Java-)Systeme: QGIS Model Baker verwendet ili2db für das ganze INTERLIS-Handling. Model Baker ist ein QGIS-Plugin, geschrieben in Python. Das Python-Plugin hat somit als Abhängigkeit eine JVM und die Java-Anwendung selber. Die Kommunikation zwischen dem Plugin und ili2db geschieht mittels Systemcalls. Stünde ili2db als Native Image zur Verfügung, fällt die Java-Abhängigkeit weg. Champions League wäre wenn man alles direkt ins Plugin bringen könnte, was nicht ganz undenkbar ist, da man mit GraalVM auch Shared Libraries herstellen kann. Wie das funktionieren könnte, kann man hier nachlesen.

Anfang 2019 habe ich erste Gehversuche mit ilivalidator und Native Image gemacht. Damals war das noch ziemlich knorzig. Wie sieht es heute aus?

Als erstes habe ich mir ili2c vorgenommen. Der Swing/AWT-Support von GraalVM ist noch verbesserungsfähig. Weil Liberica NIK (abgleitet von GraalVM) meint, sie hätten besseren Swing/AWT-Support, habe ich dieses zum Kompilieren verwendet. Mit dem Tracing Agent muss man aber auf jedem Betriebssystem wegen der GUI-Komponenten gewisse Konfigurationsdateien herstellen, was auch nicht spassig ist mit einem MacBook Air M1. UTM sei dank. Man kann sogar Windows ARM (Insider Preview) installieren. Nur leider gibt es dafür Liberica NIK nicht. Darum musste für Windows noch ein älteres Intel MacBook herhalten, was wiederum ein käsiges Erlebnis war. Das Resultat war semi-erfolgreich. Auf Ubuntu funktioniert das GUI tadellos. Auf macOS funktioniert es auch, nur darf man das Fenster nicht verkleinern oder vergrössern. Dann schmiert es ab. Auf Windows habe ich es nicht getestet. Ansonsten ist das Kompilieren zum Native Image problemlos gegangen. Und der INTERLIS-Compiler funktioniert als Native Image auf der Konsole tadellos.

Als nächstes kam ili2pg dran. Da wollte ich das GUI schon a priori nicht unterstützen und wollte auch in der Github Action Pipeline direkt GraalVM verwenden, was massiv einfacher ist, als Liberica NIK: Für GraalVM gibt es eine Action, bei Liberica muss man alles händisch, selber machen. Leider kann man es nicht mit GraalVM kompilieren, da im Quellcode bereits eine Swing-Klasse verwendet wird. Interessanterweise (wenn ich es richtig verstanden habe) ist es ein GUI, das mir mitteilt, dass ili2pg kein GUI unterstützt? Nun denn, back to Liberica NIK. Erlebnis und Ergebnis wie bei ili2c.

Als letztes habe ich mir ilivalidator angeschaut. Hier wusste ich, dass es extra Native-Image-fähig gemacht wurde und das GUI speziell behandelt wird. Also nur GraalVM verwendet, kompiliert und fertig. Einfach und schnell (also relativ schnell kompiliert). Funktioniert einwandfrei.

Die Native Images für jedes der Werkzeuge gibt es im jeweiligen «Native»-Github-Repo unter Releases:

Von meinen ersten Experimenten mit GraalVM wusste ich, dass ilivalidator signifikant langsamer ist im Vergleich zur Java-Variante. Ob das nun in den fast vier Jahren anders geworden ist? Nein. Die Fruchtfolgeflächen des Kantons Solothurn dauern circa 8 Minuten mit der Java-Variante und 16 Minuten mit dem Native Image. Warum ist mir nicht klar. Beide Varianten verwendeten den Serial GC. Die Native Images sind nicht super geeignet für «long running and high throughput»-Prozesse. Vielleicht ist die Validierung von grösseren XTF ein solcher?

Wie weiter? Ich fände es gut, wenn es die INTERLIS-Werkzeuge als Native Images gibt. Dabei lassen sich vielleicht zwei Fliegen mit einer Klappe schlagen. Die Swing-GUI würde ich entfernen und sie mit JavaFX (bessere Native Image Unterstützung) machen. Eventuell sogar in einem anderen Repo.

Der Performance-Einbruch von ilivalidator sollte genauer untersucht werden, damit man Klarheit hat, ob das der momentane Stand der möglichen Native-Image-Performance ist oder mit Code-Änderungen im ilivalidator etwas verbessert werden kann.

ÖREB-Kataster richtig gemacht #10 - ÖREB on steroids

Tue, 18 Oct 2022 00:00:00 +0000

Ich wollte 200 Requests/Sekunde und ich erhielt 200 Requests/Sekunde. Aber der Reihe nach:

Wegen des ÖREB-Spassvogels habe ich mit jMeter begonnen unseren ÖREB-Webservice zu benchmarken. Und nachdem ich das Zusammenspiel verschiedener Konfigurationsparameter verstanden zu haben glaubte, wollte ich ans Limit gehen. Was bringt man mit dem Teil mit handelsüblicher Hardware raus? Vor Augen hatte ich den grössten Cloudserver, den Hetzner zu bieten hat: CCX62. 48 vCPU und 192 GB RAM. Ungefähr 500 Euro pro Monat. Diese Cloudserver sind ziemlich praktisch, da sehr einfach aufzusetzen und sehr günstig und damit super geeignet für solche Tests.

Um den Workflow zu testen, habe ich mit einem kleineren Server begonnen: CPX51. Dieser hat 16 vCPU und 32 GB RAM und kostet 65 Euro pro Monat. Es ist im Gegensatz zum CCX ein «Standard-Server». Der Unterschied Standard vs Dedicated ist mir aber irgendwie immer noch nicht zu 100% klar.

Das Testsetup sieht einfachheitshalber vor, dass alles auf einem Server läuft. Also sowohl das ÖREB-Katastersystem (Datenbank und Webservice) wie auch jMeter. Sowohl für die Datenbank wie auch für den Webservice verwendet ich Dockerimages. Das DB-Image ist unser ÖREB-Entwicklungsimage. Das Image für den Webservice entspricht dem Produktionsimage. Von beiden Images wird jeweils nur ein Container hochgefahren. Limits werden den Containern keine gesetzt.

Als Datengrundlage dienen mir die ÖREB-Katasterdaten des Kantons Solothurn. D.h. ich importiere auch für den ganzen Kanton die Grundstücke der amtliche Vermessung. Ebenfalls importiere ich sämtliche Bundesdaten und natürlich sämtliche Konfigurations-XML. Angefordert werden aber nur Grundstücke innerhalb der Bauzone, um zu verhindern, dass Auszüge ohne Eigentumsbeschränkungen angefordert werden.

Getestet wird nur der XML-Auszug ohne eingebettete Bilder und ohne Geometrien. Ganz falsch und realitätsfremd dürfte der Benchmark nicht sein, da dies einem häufigen Usecase entspricht (Anfrage via Web GIS Client aka dynamischer Auszug). Zudem bei der Variante mit den eingebetteten Bildern der Herstellungsprozess dieser Bilder der dominierende Faktor sein wird (also letzten Endes der eingesetzte WMS-Server).

Zum Starten habe ich mit einem Thread (also einem «parallelen» Request) begonnen:

Im Durchschnitt erreiche ich so 7 Requests/Sekunde. Ich weiss nicht woher die Steigerung gegen Ende kommt. Ist das tatsächlich die JVM, die sich warm läuft?

Das Maximum, das ich mit dem günstigeren Hetzner-Server raushole, ist bei 16 Threads. Dabei weise ich dem Webservice 50 DB-Connections zu und erlaube ihm selber 16 Worker-Threads:

Im Durchschnitt sind es 57 Requests/Sekunde. Peakperformance liegt bei knapp unter 70.

Nach dem Wechsel auf den grossen Server kann man so richtig aus dem vollen Schöpfen:

Bei 196 parallelen Request erreiche ich das Maximum. Der Anwendung werden 180 DB-Connections und 60 Worker-Threads erlaubt:

Durchschnittlich werden so 211 Requests/Sekunde gemacht. Die Peakperformance liegt bei etwas über 220.

Ich denke die 200+ Requests/Sekunde dürfte auch für die KGK genügend sein. Wahrscheinlich hätte ein CH-weiter Kataster nie diese Anforderungen:

RAM war im Gegensatz zu den CPU-Kernen nie ein Thema. Sieht eventuell anders aus, wenn man mit den eingebetteten Images hantieren muss resp. das PDF herstellen muss.

Vielleicht hilft der Benchmark auch dem einen oder anderen «XML ist langsam»-Vertreter.

Ein weiteres Fazit: Man braucht keine Cloud und/oder kein Openshift, um performante Dienste anbieten zu können. Im Prinzip reicht ein anständiger Server. Und man kommt so gar nicht auf den Gedanken den Webservice mit 100 Millicores laufen zu lassen, dafür mit 10 Replikas… Scale up before you scale out.

INTERLIS leicht gemacht #31 - ili2repo

Mon, 17 Oct 2022 00:00:00 +0000

INTERLIS-Modellablagen sollten ab einem gewissen Zeitpunkt nicht mehr manuell nachgeführt werden. In einem früheren Beitrag habe ich gezeigt, wie wir das mittels eines Gradle-Tasks machen. Hier nun eine vielleicht miliztauglichere Variante:

Das Kommandozeilenwerkzeug ili2repo durchsucht ein Verzeichnis und seine Unterverzeichnisse nach INTERLIS-Modelldateien und erstellt daraus die ilimodels.xml-Datei. Es gibt zwei Varianten des Werkzeuges, welche hier heruntergeladen werden können.

Die JVM-/Java-Variante (ili2repo-<Version>.zip) benötigt eine installierte Java Runtime 17 oder höher, ist jedoch betriebssystemunabhängig. Die Zip-Datei muss entpackt werden. Im Verzeichnis sind zwei Unterverzeichnisse lib und bin. Im lib-Verzeichnis sind sämtliche benötigten Java-Bibliotheken. Im bin-Verzeichnis ist eine Shellskript-Datei resp. eine Batch-Datei. Diese dienen zur Auführung des Programmes.

Linux/macOS:

./bin/ili2repo --help

Windows:

./bin/ili2repo.bat --help

Die Native Binaries sind für das jeweilige Betriebssystem kompilierte Versionen, die keine Java Runtime benötigten. Aus diesem Grund muss für jedes Betriebssystem ein separates Binary hergestellt werden (GraalVM to the rescue). Es stehen Binaries für Windows, Linux und macOS zur Verfügung (siehe Betriebssystemabkürzung im Namen der Zip-Datei). Das macOS-Binary läuft auf Intel wie auch auf Apple Silicon Prozessoren.

./ili2repo --help

Im Gegensatz zu der Java-Variante erscheinen beim ersten Aufruf auf macOS und Windows Warnungen wegen fehlender Signierung des Binaries resp. wegen des unbekannten Entwicklers der Software. Man muss dem Betriebssystem das Ausführen des Programms einmalig explizit erlauben. Unter macOS erscheint direkt nach dem erstmaligen Ausführen von ./ili2repo:

In den «Einstellungen» - «Security & Privacy» - «General» muss man mit «Allow Anyway» die Software entblocken:

Wenn man den obigen Befehl nochmals ausführt, erscheint wieder eine Meldung:

Diese Meldung muss man mit «Open» bestätigen.

Mit ./ili2repo --help kann endlich die Hilfe angezeigt werden.

Für das Erstellen einer ilimodels.xml-Datei muss die Option --directory gefolgt vom Verzeichnisnamen mit den Datenmodellen angegeben werden:

./ili2repo --directory=path/to/models/

Es werden ebenfalls sämtliche Unterverzeichnisse nach Datenmodellen durchsucht. Die ilimodels.xml-Datei wird im obersten Verzeichnis erstellt (hier models). Sie wird mit ilivalidator geprüft.

Es werden folgende Metaattribute innerhalb des Datenmodells berücksichtigt und in die ilimodels.xml-Datei geschrieben:

technicalContact
furtherInformation
Title
shortDescription

Mit der Option --init wird im gleichen Verzeichnis eine ilisite.xml-Datei erstellt.

Im obersten Verzeichnis (Rootverzeichnis) sollten keine Datenmodelle platziert werden, sondern nur in Unterverzeichnissen. Da ilimodels.xml selber ein INTERLIS-Datenmodell ist und zum einem bestimmten Zeitpunkt noch nicht fertig ist, entsteht ein Durcheinander.

Es werden sämtliche Unterverzeichnisse berücksichtigt, so auch replaced- oder obsolete-Ordner. Bei einem mehr oder weniger offiziellen Konsens was wie behandelt werden soll, werde ich das ändern.

Der Servermodus --server dient zum Testen der vorgängig erzeugten ilimodels.xml-Datei. Es wird dazu ein ganz simpler HTTP-Server gestartet. Die INTERLIS-Modellablage ist unter der Url http://localhost:8820 verfügbar:

Der Servermodus benötigt ebenfalls die Option --directory, damit ili2repo weiss welches Verzeichnis bereitgestellt werden soll. Es wird aber keine ilimodels.xml-Datei erstellt.

ÖREB-Kataster richtig gemacht #9 - Der ÖREB-Spassvogel: Ein Drama in Akten

Sun, 16 Oct 2022 00:00:00 +0000

Oder vielleicht sind es auch mehrere Spassvögel. Wir wissen es nicht. Aber was ist passiert?

Plötzlich schlug unser OpenShift-Cluster Alarm. Genauer gesagt die Livenessprobe. Als Livenessprobe haben wir den Standard-Health-Endpoint von Spring Boot verwendet. Dieser Endpoint prüft, ob die Anwendung gesund ist. Zur Beurteilung werden dazu auch die sogenannten Backing-Services herangezogen. D.h. in unserem Fall die Datenbank. Falls bei der Prüfung nun keine Datenbankverbindung mehr hergestellt werden kann, ist die Anwendung nicht mehr gesund und die Livenessprobe schlägt fehl und der Container wird neu gestartet.

Aber warum gingen uns die Datenbankverbindungen aus? Irgend ein Habasch flutete uns mit XML-Anfragen. Wir haben bei uns zwei Instanzen/Pods mit dem Webservice am Laufen. Jeder Pod erhält 10 Datenbankverbindung resp. es wird ein DB-Connectionpool mit maximal 10 Verbindungen aufgebaut. Pro Anfrage benötigt die Anwendung 3 DB-Connections. Auch wenn die Abwicklung der Anfrage im Regelfall sehr schnell passiert, skaliert die Sache natürlich mit bloss 10 zur Verfügung stehender DB-Verbindungen nicht wirklich. Werden wir mit Anfragen geflutet und lassen diese auch auf die Anwendung los, hat diese eher früher als später ein Problem: Die DB-Verbindungen gehen aus und die Livenessprobe schlägt fehl, weil der Health-Endpoint ein SELECT 1 macht, um zu prüfen, ob die Datenbank noch da ist resp. die Anwendung darauf zugreifen kann. Dass in einem solchen Fall nun der Pod neu gestartet wird, löst das Problem gar nicht, da dieser sofort wieder geflutet wird. Und zu guter Letzt geht es ja weniger um die Livenessprobe, sondern dass die «normalen» Benutzer des ÖREB-Katasters keine Anfragen machen mehr können, weil alles verstopft ist und/oder nicht mehr läuft.

Was machen? Als erstes haben wir gerade den Holzhammer hervorgenommen und die IP des Spassvogels in unserem API-Gateway (nginx) gesperrt. Im Wissen, dass der Spassvogel sich schnell eine neue IP besorgen kann. Zusätzlich haben wir mit ungutem Gefühl die Livenessprobe ausgeschaltet, weil die ja so nix bringt. Es dauerte dann nicht lange und es ging wieder von vorne los…

Also mussten wir mit mehr Hirn ran: Nach bisschen Überlegen kommt man auf die Idee eines Rate Limiters. Dieser sorgt dafür, dass nur ein eine konfigurierte Anzahl an Requests pro Zeiteinheit vom API-Gateway an die Anwendung weitergereicht wird. Das führte zu folgender Situation:

Kurz vor 18:00 Uhr haben wir den Rate Limiter eingeschaltet. Das führte bei Statuscake dazu, dass es plötzlich viele Ausfallmeldungen (rote Balken) des ÖREB-Webservices gab. Das war jedoch kein Ausfall des Servers, sondern wir haben den Test so konfiguriert, dass er fehlschlägt, wenn die Antwort länger als 15 Sekunden dauert. Weil wir wussten, dass wir mit Requests geflutet werden, haben wir zuerst einfach nur den 15-Sekunden-Threshold hochgeschraubt. Und siehe da: Kurz nach 12:00 Uhr wurde alles wieder grün. Was uns aber störte und wir nicht ganz verstanden haben, war der Umstand, dass auch Requests im Web GIS Client circa 20 Sekunden dauerten. Erstens ist das für den Anwender nicht toll und zweitens haben wir es nicht verstanden, weil der Rate Limiter nach der IP limitiert. Es stellte sich heraus, dass wir den Rate Limiter noch nicht korrekt konfiguriert hatten und dieses «Group-by-IP» nicht funktionierte. Als wir das korrigierten, sah die Grafik wieder super aus, d.h. fair use Benutzer (meistens via Web GIS Client) sind nicht mehr betroffen.

Der Spassvogel hat wirklich eine Woche lang XML- und PDF-Auszüge à discretion gesaugt, insgesamt zwischen 1000 und 1500 Auszüge pro Stunde. Summa summarum und geschätzt, waren es sämtliche Grundstücke des Kantons… Warum macht man sowas? Sinnvoll erscheint mir das nicht. Was will man mit den vielen Dateien machen? Man weiss ja nicht, ob etwas noch aktuell ist oder bereits veraltet!? Hier ein Ausschnitt aus einer Logging-Auswertung mit logit.io:

Wir sind aber noch nicht fertig. Mit der Livenessprobe sind wir wie eingangs erwähnt nicht zufrieden, weil sie nicht das prüft, was sie soll. Und die Anwendung selber (also der ÖREB-Webservice) funktioniert zwar einwandfrei aber nur weil das API-Gateway sie vor Überlastung schützt.

Für die Livenessprobe ist der Standard-Health-Endpoint, welche die Backing-Services berücksichtigt schlichtweg das Falsche. Der Server ist ja trotzdem live aber eben nicht ready (Readinessprobe) Requests abzuarbeiten. [Spring Boot] hat dafür zwei separate Endpunkte. Für den Liveness-Endpunkt werden die Backing-Services nicht mehr berücksichtigt.

Bleibt noch die Anwendung selber: Mit den Standardeinstellungen lassen wir die Anwendung bis zu 200 Threads (Requests) gleichzeitig abarbeiten (sehr vereinfacht beschrieben, weil kompliziert und ich nur denke, dass ich es richtig verstanden habe). Wie eingangs beschrieben, haben wir aber der Anwendung nur 10 Datenbankverbindungen zugewiesen und pro Request werden drei davon benötigt. Da muss man kein Einstein sein, um zu merken, dass das nicht aufgeht. Die maximale Anzahl sogenannter Worker-Threads muss im Einklang mit anderen Rahmenbedingungen sein: RAM, CPU aber auch DB-Connections. D.h. wir reduzieren diese Worker-Threads auf circa 3 oder 4. Das bedeutet jedoch nicht, dass weitere Requests mit einem 429 (too many requests) o.ä. beantwortet werden, denn es gibt verschiedene Queues, die dann greifen und wo die Requests parkiert werden (weiter weg von der eigentlich Anwendung, aber immer noch im Applikationsserver). Tests mit jMeter haben gezeigt, dass bei 32 parallelen Requests mit nur 3 Worker-Threads trotzdem alle Requests korrekt bearbeitet werden.

Der Spassvogel ist und bleibt zwar nicht ganz 100. Aber wir haben immerhin viel gelernt.

ÖREB-Kataster richtig gemacht #8 - ÖREB-Kataster Compliance Test Suite

Sun, 2 Oct 2022 00:00:00 +0000

Der ÖREB-Kataster ist durch das Rahmenmodell und verschiedene Weisungen gut spezifiert. Das bedeutet, dass man eigentlich weiss, was man umsetzen muss. Das heisst ebenfalls, dass man das Umgesetzte gut prüfen kann. Warum sollte man das prüfen? Die sauber spezifizierte M2M-Schnittstelle bringt einfach nichts, wenn sie bei jedem Kanton anders ist.

So eine Prüfbibliothek wäre ausserdem schick, um End-zu-End- oder Systemtests zu machen. Gesagt, getan: Ich habe mir als Proof-of-Concept eine Anwendung resp. eine Bibliothek geschrieben, die im Prinzip die beiden Aspekte - Aufruf des Services und Auszug - prüft (Stand heute: Teile davon). Das Ganze unter einen Hut zu bringen, fand ich noch herausfordernd:

Es gibt verschiedene Möglichkeiten einen Auszug (oder die GetEGRID-Antwort) anzufordern. Das kann z.B. eine Koordinate sein oder NBIdent und Grundstücksnummer. Und man kann eine Antwort mit oder ohne Geometrie resp. mit oder ohne Bilder anfordern. Das führt dazu, dass es viele Kombinationen gibt, die geprüft sein wollen und die verschiedenen Konfigurationen müssen von jemandem definiert werden. Hat man die Antwort, reicht es nicht diese gegenüber einem Schema zu prüfen, da der Inhalt ja abhängig von den Inputparametern ist. Das wiederum müsste bei der Konfiguration der Tests auch berücksichtigt werden.

Ich habe mich daher entschieden, so wenig wie möglich von einem Menschen konfigurieren zu lassen und die vielen Kombinationen durch die Maschine selber zu machen. Das heisst, man muss nur den Service-Endpunkt und die notwendigen Parameter angeben, die für den Aufruf benötigt werden (z.B. EGRID oder EN). Fehlen die Parameter, wird der Test, welcher diese Parameter benötigt, nicht durchgeführt. Wenn IDENTDN und NUMBER fehlen, werden keine Tests durchgeführt, welche diese beiden benötigen. Momentan ist das alles über ein Ini-File zu konfigurieren:

[SO]
SERVICE_ENDPOINT=https://geo.so.ch/api/oereb/
EN=2600595,1215629
IDENTDN=SO0200002457
NUMBER=168
EGRID=CH807306583219

Was als Resultat zu erwarten ist, kann oftmals anhand der Request-Parameter eruiert werden: Falls GEOMETRY=true verwendet wird, muss in der Antwort ein Geometry-Element vorhanden sein. Was aber ohne menschliches Zutun nicht wirklich funktioniert, ist der Umgang mit leeren Antworten. Es kann korrekt sein, dass eine Antwort leer ist (also kein Grundstück). Woher weiss die Maschine das, ohne dass man es konfigurieren würde? Dieser Fall ist momentan nicht abgefangen. Bei der Konfiguration der Tests muss man also sicher sein, dass z.B. für den definierten EGRID auch wirklich ein Auszug zurückkommt.

Geprüft werden momentan der GetEGRID- und extract-Aufruf und die jeweiligen Antworten. Folgende Checks werden durchgeführt:

Stimmt der HTTP Status Code?
Stimmt der Response Content Type?
Ist die Antwort schemakonform?
Gibt es Geometrie-Elemente, wenn solche vorhanden sein müssen (resp. umgekehrt)?
Gibt es eingebettete Bilder, wenn solche vorhanden sein müssen (resp. umgekehrt)?
Sind alle Bundesthemen-Codes im XML-Inhaltsverzeichnis vorhanden? (ConcernedTheme, NotConcernedTheme, ThemeWithoutData)

Alle mir bekannten ÖREB-Kataster-V2-Webservice habe ich geprüft. Examplarisch ein Screenshot von unserem Dienst. Die Gesamtshow gibt es hier.

Unser Fehler wurde auch bei der Abnahme erkannt und ist folgendes:

Wir sind für den Fall, dass keine Geometrien angefordert werden, nicht schemakonform: Es fehlt die Boundingbox. Klammerbemerkung: Man schaue sich die Request time an. Der Request dauerte 9s. Das sind circa 8.5 Sekunden zu lang. Grund dafür sind die Spezialisten, die seit geraumer Zeit bei verschiedenen Kantonen ziemlich stupide Tausende Requests in kürzester Zeit absetzen…

Das Gesamtbild ist in etwa folgendes: Die Fehler wiederholen sich. Man erkennt - behaupte ich mal - anhand der Fehler, welches System ein Kanton einsetzt. Typische Fehler sind:

Grundstückstyp fehlt in der GetEGRID-Antwort
Geometrieelement fehlt in der GetEGRID-Antwort
Response Content Type ist «falsch».
Status Code bei der URL-Weiterleitung ist falsch.
Fehlende Bundesthemen-Codes

Die Exoten dürfen auch nicht fehlen:

Keine NBIdents in der Antwort vorhanden resp. «N/A». In den Daten der amtlichen Vermessung gibt es für dieses Grundstück aber einen NBIdent.
Fehlender «/». Anstelle von /oereb/getegrid/xml/?EN=YYYYYYYY,XXXXXXXX funktioniert der Aufruf nur ohne den letzten Slash.
Ignorieren von XML-Namespaces, d.h. es wird nur genau einer verwendet.

Wo ich mir aber selber nicht ganz sicher bin:

Ist der Response Content Type application/xml; charset=UTF-8 wirklich falsch? In der Weisung steht nur application/xml. Eine interessante Erklärung was eine andere Spez erwartet, gibt es hier.

Und stimmt mein Test bezüglich der Bundesthemen-Codes? Meines Erachtens müssen alle Bundesthemen-Codes bei den «Themes» vorkommen. Momentan gibt es jetzt Kantone, die formell keine Nutzungsplanung (ch.Nutzungsplanung) publizieren.

Ausserdem könnte man sich eventuell darauf einigen wie Links enkodiert werden sollen. Da gibt es unterschiedlichste Varianten. Es wird alles enkodiert, z.B. https://geo.so.ch wird zu https%3A%2F%2Fgeo.so.ch oder noch spannender ist das Verpacken eines solchen Links in einem CDATA-Block… Innerhalb eines Auszuges werden die Varianten auch gerne gemischt. Ich denke, dass man sich auf das Minimum beschränken sollte, was XML verlangt (z.B. «&» wird zu «amp»).

INTERLIS leicht gemacht #30 - INTERLIS Repository Checker

Wed, 31 Aug 2022 00:00:00 +0000

Die INTERLIS-Modellablagen (aka INTERLIS-Repos) sind ein wichtiger Baustein im INTERLIS-Ökosystem. Sie dienen zur zentralen Publikation von INTERLIS-Modellen und helfen beim Arbeiten mit kompatiblen Werkzeugen. In erster Linie heisst das, dass man sich nicht mehr gross um die Modelldateien kümmern muss. Sie sind einfach «da». Die Werkzeuge suchen und finden (hoffentlich) die benötigten Modelle in einem der Repositories. Für automatisierte Prozesse sollte man sich aber in der Regel nicht auf die Modellablagen verlassen, sondern die benötigten Modelle zum Prozess kopieren oder sich ein lokales Repository anlegen, welches alle benötigten Modelle spiegelt. Man will sich ja nicht unnötig von externen Anwendungen abhängig machen.

Viele Kantone und einige Vereine betreiben eine INTERLIS-Modellablage. Damit die Werkzeuge auch mit den Modellablagen problemlos zusammenspielen, sollten die Modellablagen auch korrekt sein. Der INTERLIS-Compiler bietet die Funktion --check-repo-ilis an, welche eine Ablage prüft. Leider ist nirgends gross dokumentiert was genau geprüft wird. Für die Prüfung zuständig ist die Klasse CheckReposIlis. Es werden folgende Sachverhalte geprüft:

Existiert in der Modellablage eine ilimodels.xml-Datei?
Ist die ilimodels.xml-Datei schemakonform? D.h. die Datei wird nicht mit ilivalidator geprüft, sondern sie wird «nur» gegen das XML-Schema geprüft.
Sind die Modelle syntaktisch korrekt? (Prüfung mit dem Compiler).
Stimmen die Metainformationen (wie z.B. md5-Hash) in der ilimodels.xml-Datei?
Wahrscheinlich noch der eine oder andere übersehene Punkt.

Ich habe den Code nun in eine kleine Webanwendung gepackt, welche diese Prüfungen für INTERLIS-Modellablagen regelmässig durchführt und visualisiert. In Abweichung zu den oben erwähnten Tests, verwende ich für die Prüfung der ilimodels.xml-Datei ilivalidator. Die Repo-Prüffunktion im Compiler gibt es bereits länger als es ilivalidator gibt. Vielleicht gibt es aber noch andere Gründe warum eine XML-Schemaprüfung gemacht wird. Zusätzlich prüfe ich auch noch die ilisite.xml-Datei. Ebenfalls mit ilivalidator. Konkret hat das den Nachteil, dass ein Fehler nicht gefunden wird, der mittels Schemaprüfung entdeckt wird.

Für mich schwierig war, dass alle Fehler, welche der Compiler loggt, wenn man --check-repo-ilis verwendet, bei mir ebenfalls in der Logdatei landen. Eventuell gibt es da noch die eine oder andere Meldung, die fehlt. Richtig nachhaltig ist meine Prüfmethode nicht, da ich den Code einfach kopiere und an einigen Stellen anpasse. Maintenance hell.

Verpackt als Dockerimage, lässt sich die native kompilierte Spring Boot Anwendung einfach und schnell starten:

docker run -p 8080:8080 -e TZ=Europe/Zurich sogis/interlis-repo-checker:latest

Konfigurieren lässt sie sich Anwendung mit einigen wenigen Env-Variablen:

CONNECT_TIMEOUT und READ_TIMEOUT: Connect und read Timout für Protokollhandler, die java.net.URLConnection verwenden. Damit kann gesteuert werden, dass beim Lesen der Repositories nicht zu lange gewartet wird, bis eine Verbindung aufgebaut wird oder der Server die Antwort liefert.
REPOSITORIES: Kommaseparierte Liste der Repositories, die geprüft werden sollen.
CHECK_CRON_EXPRESSION: (Spring Boot) Cron Expression, die steuert wie häufig die Prüfung durchgeführt wird.
WORK_DIRECTORY: Verzeichnis in das die Prüfresultate gespeichert werden.
WORK_DIRECTORY_PREFIX: Präfix für WORK_DIRECTORY.

Die voreingestellten Werte sind in der application.properties-Datei definiert.

Nach dem Start der Webanwendung werden einmalig alle Modellablagen geprüft und es muss nicht gewartet werden bis der Cronjob läuft. Nach ein paar Minuten sollte sich unter http://localhost:8080 folgendes Bild zeigen:

Zwei Repositories weisen momentan bereits Fehler in der ilisite.xml-Datei auf. Die Fehlermeldung von ilivalidator ist Error: unknown xml file. Das Problem ist, dass der INTERLIS-Namespace fehlt. Anstelle von:

<TRANSFER xmlns="http://www.interlis.ch/INTERLIS2.3">

steht nur:

<TRANSFER>

In der ilimodels.xml-Datei gibt es allerlei Fehler: Doppelte TID, zu lange Texte und unerlaubte Zeichen. Spannender wird es bei den Modellen selbst. Ein Kanton listet das Modell INTERLIS als Abhängigkeit auf. Diese Modell wird vom Compiler nicht gefunden. Das Modell darf nicht gelistet werden. Die Meldung sollte aber eine andere sein. Dann gibt es eigentliche Modellfehler und Unstimmigkeiten zwischen dem Modell und dem Eintrag in der ilimodels.xml-Datei.

Viele der Fehler lassen sich vermeiden, wenn man a) die Modellablagen nicht händisch nachführt (wer hat schon Bock einen md5-Hash abzutippen?) und b) nach dem Nachführen die Modellablagen auch prüft. Siehe dazu http://blog.sogeo.services/blog/2022/07/19/interlis-leicht-gemacht-number-28.html.

~~Der Repochecker läuft unter folgender URL: https://geo.so.ch/repochecker~~ Das Teil scheint mir noch ein Memoryleak zu haben und ist darum nicht online. Wer es testen will, einfach den obigen Dockerbefehl ausführen.

INTERLIS leicht gemacht #29 - REST-API für ilivalidator-web-service

Sun, 24 Jul 2022 00:00:00 +0000

Unser ilivalidator-web-service hat einige Neuerungen spendiert bekommen, unter anderem:

Konfiguration

Es ist möglich eigene Konfigurationen (aka toml- resp. ini-Dateien und zusätzliche INTERLIS-Modelle) zu verwenden. Der Webservice berücksichtigt zwei Verzeichnisse (config/toml/ und config/ili) während der Prüfung einer INTERLIS-Transferdatei. Es werden standardmässig einige Solothurner Konfigurationen reinkopiert, was jedoch unterbunden werden kann. Das config-Verzeichnis und die beiden Unterverzeichnisse werden im Webservice via URL http://localhost:8080/config exponiert. Damit wird für die Benutzer die Prüfung transparenter, da sie eine allfällige zusätzliche Konfiguration sehen:

Siehe: https://github.com/sogis/ilivalidator-web-service#configuration-and-running

REST-API

Es gibt neben dem GUI neu eine REST-API für eine M2M-Kommunikation. Da es sich um long running tasks handelt, kann kein synchroner Prozessablauf gewählt werden, d.h. man kann nicht eine Datei hochladen und die Verbindung zum Server bleibt offen, bis die Prüfung durch ist. Im GUI wird aus diesem Grund auf das Websocket-Protokoll gesetzt. Bei der REST-API verwenden wir jedoch «nur» HTTP.

Wenn man eine Datei hochlädt, erhält man als Antwort den Statuscode 202 ACCEPTED und den Header Operation-Location, der auf eine Ressource zeigt.

curl -i -X POST -F file=@254900.itf http://localhost:8080/rest/jobs

liefert:

HTTP/1.1 202
Operation-Location: http://localhost:8080/rest/jobs/4d4aa583-6575-4200-a39c-621a5190d36d
Content-Length: 0
Date: Sat, 23 Jul 2022 16:40:50 GMT

Die Ressource /rest/jobs/4d4aa583-6575-4200-a39c-621a5190d36d liefert mir Informationen über den Stand der Validierung meiner Datei:

curl -i -X GET http://localhost:8080/rest/jobs/4d4aa583-6575-4200-a39c-621a5190d36d

liefert:

HTTP/1.1 200
Retry-After: 30
Content-Type: application/json
Transfer-Encoding: chunked
Date: Sat, 23 Jul 2022 16:43:12 GMT

{"createdAt":"2022-07-23T16:42:15.68317767","updatedAt":"2022-07-23T16:42:15.68317767","status":"PROCESSING"}

Es gibt einen Retry-Header, der Clients anweist, 30 Sekunden zu warten bis zur nächsten Abfrage. Ist die Validierung abgeschlossen, enthält die Antwort Links zu den Logdateien:

HTTP/1.1 200
Content-Type: application/json
Transfer-Encoding: chunked
Date: Sat, 23 Jul 2022 16:43:29 GMT

{"createdAt":"2022-07-23T16:42:15.68317767","updatedAt":"2022-07-23T16:43:16.011457796","status":"SUCCEEDED","logFileLocation":"http://localhost:8080/logs/ilivalidator_8148789347157812698/254900.itf.log","xtfLogFileLocation":"http://localhost:8080/logs/ilivalidator_8148789347157812698/254900.itf.log.xtf"}

Siehe: https://github.com/sogis/ilivalidator-web-service/blob/master/docs/rest-api-de.md

Die Joborchestrierung ist mit JobRunr umgesetzt. Eine Bibliothek für verteiltes Background Processing. Die Persistierung wird über eine Datenbank gemacht. JobRunr hat viele Features und Einstellungsmöglichkeiten, ist aber trotzdem sehr einfach in der Handhabung. Ein interessantes Feature ist der Umgang mit nicht beendeten Jobs, z.B. bei einem Server-Absturz. Diese werden nach einem Restart nochmals ausgeführt. Es geht also nichts verloren. Verteile Prozessierung bedeutet in diesem Fall über die Grenzen der JVM und über die Grenzen von Servern hinweg, solange die «Arbeitstiere» Zugriff auf die gemeinsame Datenbank haben. Im absolut einfachsten Fall gibt es aber nur einen Webservice, dieser fungiert als Schnittstellenserver als auch als Validierungsserver und verwendet eine In-Memory-Datenbank.

ilivalidator Cluster

Was kann man mit der neuen REST-API und deren Umsetzung mit JobRunr machen? Zum Beispiel einen ilivalidator Cluster mit 15 Worker. Dazu reicht eine einfache docker-compose-Konfiguration:

version: '3'
services:
  frontend:
    image: sogis/ilivalidator-web-service:2
    environment:
      TZ: Europe/Zurich
    ports:
      - 8080:8080
      - 8000:8000
    volumes:
      - type: bind
        source: /tmp/docbase
        target: /docbase
      - type: bind
        source: /tmp/work
        target: /work
  worker:
    image: sogis/ilivalidator-web-service:2
    deploy:
      replicas: 15
    environment:
      TZ: Europe/Zurich
      JOBRUNR_DASHBOARD_ENABLED: "false"
      REST_API_ENABLED: "false"
      UNPACK_CONFIG_FILES: "false"
      CLEANER_ENABLED: "false"
    volumes:
      - type: bind
        source: /tmp/docbase
        target: /docbase
      - type: bind
        source: /tmp/work
        target: /work

Es wird ein (1) Frontend-Schnittstellen-Service gestartet, welcher die Uploads entgegennimmt. Es wird ein worker-Service mit 15 Replicas gestartet, die als JobRunr-Backgroundserver arbeiten. Beide Services verwenden das gleiche Dockerimage. Beim worker-Service werden einige Funktionalitäten ausgeschaltet, da diese nicht benötigt werden. Zudem ist der worker-Service von aussen nicht erreichbar. Sauberer wäre natürlich, wenn man Ressource-Limiten (RAM, CPU) setzt. Dies ist im Nicht-Swarm-Mode mit der Version 3 für die CPU nicht möglich und darum wird darauf verzichtet. Das sollte für unseren Test egal sein.

Nun benötigt man genügend Server-Ressourcen, d.h. man mietet sich bei Digitalocean einen 40vCPU-Server mit 160GB RAM. Man sollte ihn einfach nicht vergessen zu löschen, da das Teil monatlich mit $1260.00 zu Buche schlägt.

Als Testdaten verwende ich die AV-Daten des Kantons Bern, die ich via geodienste.ch heruntergeladen habe. Es handelt sich um 339 Gemeinden. Ein simples Jbang-Skript lädt mir die Daten via REST-API zum Server hoch. Nun geht die Post ab. Nachfolgend ein Screenshot des JobRunr-Dashboards und eine docker stats-Ausgabe:

Sämtliche 339 Gemeinden konnten innerhalb von circa 17 Minuten geprüft werden. Limitierender Faktor war zu guter Letzt die Gemeinde Bern, welche 8 Minuten benötigt, wobei 2 davon als einzige Gemeinde. Diese sollte also möglichst zu Beginn hochgeladen werden.

Anschliessend versuchte ich 29 Worker zu verwenden, was aber nicht erfolgreich funktionierte. Ein Drittel der Dockercontainer wurden wieder runtergefahren. Der Grund war mir auf die Schnelle nicht klar (Hinweis: Ressourcen setzen!). Eventuell wird unter gewissen Umständen der I/O zum Problem, wenn 30+ Replicas grossen Traffic verursachen.

Im Grunde genommen kann man den ilivalidator-web-service so einfachst beliebig horizontal skalieren. Aus Gründen sollten die Worker nicht auf dem gleichen Server laufen und Ressourcen (limits und reservations oder äquivalente Einstellungen) gesetzt werden.

INTERLIS leicht gemacht #28 - INTERLIS-Modellablagen erstellen und pflegen

Tue, 19 Jul 2022 00:00:00 +0000

Hat man mehr als drei Modelle in seiner INTERLIS-Modellablage (aka INTERLIS-Repo aka Repo) gelten zwei Regeln:

Die Herstellung und das Pflegen der Modellablage muss automatisch passieren.
Die für die Modellablage benötigten Informationen müssen aus den INTERLIS-Modellen kommen.

Eine Lösung wie man beide Regeln befolgt, ist hier kurz vorgestellt:

Eine Auslegeordnung zeigt, dass einzig die ilimodels.xml-Datei häufig ändert und natürlich die Modelle selbst. Die Grundidee ist, dass man einen Ordner bestimmt, wo alle Modelle gespeichert sind (gerne auch mit Unterordner) und daraus mit vorhandenen Bibliotheken und wenig eigenem Code die ilimodels.xml-Datei herstellt. Wir haben ein Gradle-Plugin geschrieben, damit wir das Herstellen sauber in einem Gradle-Build einbetten können und mit anderen atomaren Prozessschritten verknüpfen können. Der Code für das Herstellen ist simpel und entspricht dem Schreiben einer XTF-Datei mit einem XtfWriter. Der minimale Gradle-Task für das Herstellen der ilimodels.xml-Datei sieht so aus:

plugins {
    id "ch.so.agi.interlis-repository-creator" version "1.3.17"
}

import ch.so.agi.tasks.InterlisRepositoryCreator

task createIliModels(type: InterlisRepositoryCreator) {
    modelsDir = file("models/")
    dataFile = "ilimodels.xml"
}

Diese paar Zeilen speichert man in einer build.gradle-Datei und mit einem gradle-Aufruf in dem Verzeichnis, wo die build.gradle-Datei gespeichert ist, wird die ilimodels.xml-Datei erstellt. Es werden alle Modelle berücksichtigt, die im Unterverzeichnis models vorliegen. Es gibt zusätzliche Optionen:

repoModelName: Entweder IliRepository09 oder IliRepository20
modelRepos: Modellablagen, die beim Kompilieren der eigenen Modelle verwendet werden sollen.
technicalContact: Der technische Kontakt, der in der ilimodels.xml-Datei bei den Modell erscheinen soll, falls es kein gleichlautendes Metaattribut im Modell gibt.
ilismeta: Wird ilismeta=true gesetzt, wird zum Modell zusätzlich die IlisMeta07-Datei erstellt.

Die ilimodels.xml-Datei ist auch eine INTERLIS-Transferdatei. Das zugrundeliegende Modell ist sehr tolerant, d.h. es sind nur wenige Attribute nicht optional. Es muss einzig der Namen, die Version und ein relativer Pfad auf die Modell-Datei vorhanden sein. Alle übrigen Attribute sind optional. Diese drei Pflichtattribute ergeben sich aus dem Modell resp. aus der Modelldatei selber. Die MD5-Checksumme kann man ebenfalls aus der Datei berechnen lassen. Andere interessante Attribute lassen sich nicht mehr automatisch ableiten. Einige dieser Attribute kann man sinnvollerweise als Metaattribute im Modell erfassen. Seit kurzem kann man im INTERLIS-UML-Editor für jedes Element beliebige Metaattribute erfassen, was diese Arbeit enorm erleichtert. So kann man z.B. das Metaattribut shortDescription im Modell erfassen und diese Information in die ilimodels.xml-Datei schreiben lassen. Nach diesem Prinzip funktioniert unser Gradle-Plugin. Neben shortDescription werden auch die Metaattribute Title, Issuer, technicalContact und furtherInformation - falls vorhanden - berücksichtigt. Für die letzten drei gab es im INTERLIS-UML-Editor bereits eine speziellen Eintrag zum Erfassen. Aus diesem Grund dürften diese in vielen Fällen vorhanden sein.

Früher hätte man die ilimodels.xml-Datei und die Modelle mit FTP gleich in die Produktion kopiert. Machen wir natürlich nicht mehr, sondern wir erstellen ein Dockerimage auf Basis von nginx. Ist das Dockerimage erstellt, können wir einen Container starten und die Modellablage mit dem INTERLIS-Compiler prüfen (--check-repo-ilis).

Dieser gesamte Prozess (Herstellung, Prüfung, Image in Docker-Registry pushen) wird mit Gradle gemacht. Aus diesem Grund haben wir das Gradle-Plugin für die Herstellung der ilimodels.xml-Datei geschrieben. Wäre es z.B. Maven, müsste man ein Maven-Plugin schreiben etc. Der Prozess kann lokal ausgeführt werden oder mittels Github-Action. Womit wir mehr oder weniger am Ende angelangt sind: Die Herstellung und Pflege ist automatisiert und das Wissen zum Abfüllen der ilimodels.xml-Datei stammt aus den Modellen.

Die INTERLIS-Modellablage ist die einzige Anwendung, welche bei uns automatisch in die Produktionsumgebung deployed wird. Notfalls muss man ein Rollback ausführen, wenn man merkt, dass trotz der Tests etwas schief gelaufen ist. Zudem sollte man sich gut überlagen, ob man sich bei kritischen Prozessen auf externe Dienste (unnötigerweise) verlassen will und nicht einfach die benötigten Modelle zu seinem Prozess kopiert. Klammerbemerkung: Oder man macht in seiner Organisation einen INTERLIS-Modellablagen-Mirror, der die externen Ablagen regelmässig spiegelt.

Jedenfalls kann jeder Mitarbeiter bei uns, der in seiner Arbeit gerade etwas mit einem INTERLIS-Datenmodell macht, höchst effizient durcharbeiten und muss nicht zuerst zu einem Ops-Menschen gehen, um das Modell in der Ablage verfügbar zu machen.

PS: Es gibt in unserer Modellablage noch ein kleines Goodie. Die ilimodels.xsl-Datei sorgt dafür, dass die ilimodels.xml-Datei automatisch vom Browser mittels XSLT in eine HTML-Seite gerendert wird.

Oh und wenn ich mir die wichtigste und bekannteste INTERLIS-Modellablage so anschaue, scheint mir das arg kompliziert zu sein. Da wird sehr viel mit Javascript gelöst. Und das Witzigste: es scheint pro Unterordner (also plusminus pro Bundestelle) eine beinahe identische Javascript-Datei zu geben: ARE vs. V+D. So auf ersten Blick unterscheiden sich diese Dateien nur in einem Wort: var S3B_ROOT_DIR = 'ARE'; vs var S3B_ROOT_DIR = 'V_D'; Welcome to maintainance hell…

State of INTERLIS model finder - Summer 2022

Mon, 18 Jul 2022 00:00:00 +0000

Einleitung

Der INTERLIS model finder ist aus der Not geboren. Wenn ich auf die Schnelle ein Modell anschauen wollte und nicht wusste, ob es ein Modell des BLW oder des BAFU ist, erging es mir wie bei der Verwendung von USB-Typ-A-Steckern: Erster Versuch, geht nicht. Also umdrehen und nochmals versuchen. Geht auch nicht. Nun dann, nochmals umdrehen und plötzlich geht es. Also zuerst beim BLW schauen, dort das Modell nicht gefunden, weiter zum BAFU, dort auch nichts gefunden und wieder zurück zum BLW und plötzlich sieht man es.

Technologie

Die Grundidee ist, mit im INTERLIS-Compiler vorhandenen Methoden, die verschiedenen INTERLIS-Modellablagen (d.h. die dazugehörigen ilimodels.xml-Dateien) zu lesen und zu interpretieren und anschliessend mit Lucene zu indexieren. Weil es (noch) sehr wenige Informationen sind, die man indexiert, muss man das nicht einmal persistieren, sondern kann den Index beim Hochfahren der Anwendung erstellen und dann natürlich regelmässig updaten (z.B. einmal pro Tag). Das Frontend ist mit GWT und Domino-ui als zusätzliche Bibliothek erstellt. Als Web-Framework ist Spring Boot gesetzt.

Damit entsteht eine modulare Java-Anwendung. Der Vorteil: Man kann im Java-Ökoystem verweilen und muss nicht mehrere Technologie-Stacks mischen. Klar schreibt man am Ende des Tages eine Browser-Anwendung und muss sich auch diesbezüglich ein wenig auskennen aber ich muss z.B. nicht zwei Build-Tools und -Prozesse kennen etc. pp. Es werden auch nicht drei Docker-Images benötigt (Datenbank, Backend, Frontend), sondern maximal ein Docker-Image. «notfalls» reicht auch eine JVM: java -jar modelfinder.jar und schon läuft die Anwendung.

Die Anwendung wird mit GraalVM zu einem native image kompiliert. Dann ist keine JVM mehr notwendig und die Anwendung startet viel schneller. In OpenShift weisen wir der Anwendung 100MB RAM und 100m CPU zu. Eine Anwendung, die in einer JVM läuft, würde mit diesen beschränkten Ressourcen wohl gar nicht mehr starten.

Features

Was kann der INTERLIS model finder? Es werden alle Ablagen durchsucht, welche irgendwie mit https://models.interlis.ch verknüpft sind. Es werden die Attribute aus der ilimodels.xml-Datei indexiert (Details siehe LuceneSearcher.java).

Bei der Eingabe im Suchfeld werden die Attribute file, title, issuer, technicalcontact, furtherinformation und idgeoiv durchsucht. Das Resultat wird gruppiert nach der Modellablage. Bis ili2c Version 5.2.7 ist es nicht möglich exakt die URL der Modellablage zu bestimmen. Aus diesem Grund stimmt der Namen von Ablagen nicht, die einen Pfad aufweisen, da in diesem Fall nur die Domain verwendet wird.

Steuern lässt sich das Verhalten der Anwendung mittels Query-Parameter:

query=[searchTerms]: Damit kann via URL eine Suche gestartet werden. Z.B. query=Wald sucht in allen Ablagen nach Modellen, bei denen das Wort «Wald» indexiert wurde.
expanded=[true|false]: Wird expanded=true verwendet, sind die Modellablagen aufgeklappt und die Treffer sind sichtbar.
ilisite=[repository name]: Damit lässt sich die Suche auf eine Modellablage einschränken. Achtung: Wegen der Domain-vs-Modellablagen-URL-Problematik (siehe oben) darf unter Umständen (noch) nicht die genaue URL der Modellablage verwendet werden, sondern nur der Domainname.
nologo=[true|false]: Falls nologo=true wird das Logo nicht dargestellt.

Wenn man Modelle, die irgendwas mit «Wald» zu tun haben, in der Modellablage des Bundes suchen will, die Resultate gleich sichtbar aufgeklappt haben und nicht immer das Solothurner Logo anschauen will, geht das so: https://geo.so.ch/modelfinder/?expanded=true&ilisite=models.geo.admin.ch&nologo=true&query=wald.

Profitipp #1: Kann man sich natürlich (ohne den query-Parameter) z.B. als Bookmark abspeichern.

Ein spannendes Feature ist der partielle OpenSearch-Support. Besucht man die Webseite mit Firefox zum ersten Mal, erscheint im Suchfenster die Lupe mit einem Pluszeichen auf grünem Grund:

Wenn man auf die Lupe klickt, erscheint ein kleines Fenster, wo man "Add search engine 'INTERLIS model finder'" auswählen muss. Neben Wikipedia und anderen Suchen, sollte nun ein INTERLIS-Icon vorhanden sein. Tippt man «Wald» in das Suchfeld werden Resultate aus der Standardsuche vorgeschlagen und vorangegangene Suchbegriffe, es reicht ein Klick auf das INTERLIS-Icon und es wird nach INTERLIS-Modellen gesucht. Das funktioniert zu jedem Zeitpunkt, d.h. man muss sich nicht auf der INTERLIS model finder Webseite befinden. Wird INTERLIS model finder in Firefox zur Standardsuche gemacht, werden Treffer vorgeschlagen:

Profitipp #2: Man kann trotz Freitextsuche relativ streng den Kanton (oder Bund) eingrenzen indem man zusätzlich zum eigentlichen Suchterm z.B. noch «so.ch» miteintippt.

Natürlich kann man es niemandem übel nehmen, der nicht die Modellsuche als Standardsuche definiert. Trotzdem lässt sich die Suchfunktionalität in Wert setzen, indem man einen Shortcut setzt:

Jetzt ist es möglich mit @models und Tab-Taste klicken in der Address Bar nach Modell zu suchen und gleich auch Vorschläge zu bekommen:

In ähnlicher Form funktioniert das auch mit Chrome (Chromium). Dort ist die OpenSearch-Unterstützung zusätzlich mittels Tab-to-search noch besser umgesetzt. Aber ich weiss nicht, ob das funktioniert, wenn sich die OpenSearch-Funktionalität hinter einem Pfad versteckt (wie hier) und nicht direkt hinter einem Domainnamen.

Wie und ob es bei Safari funktioniert? Keine Ahnung.

Ausblick

Schnell kommt der Vorschlag, dass man auch nach Klassen etc. suchen könnte. Ja, aber ich denke, das wird bezüglich UX/UI herausfordernd. Reicht hier eine Freitextsuche oder muss geführter gesucht werden, um halbwegs sinnvolle Treffer zu bekommen. Hat überhaupt jemand schon einmal dieses Bedürfnis wirklich gehabt?

Der sinnvolle Umgang mit alten Modellversionen ist mir auch nicht so richtig klar. Sollen die überhaupt gefunden werden können? Sollen die bewusst gefiltert werden können?

Am wichtigsten scheint mir, dass die ilimodels.xml-Datei mit sinnvollen Inhalten gefüllt ist. Stand heute finde ich das aktuelle Naturgefahren-MGDM nicht, weil nirgends das Wort «Naturgefahren» vorkommt. Weder in der ilimodels.xml-Datei noch im Modell selber. In diesem konkreten Fall könnten die Tags-Attribute helfen oder die shortDescription, die dann indexiert werden können. Das führt zur Fragestellung: «Wie erstelle und pflege ich eine INTERLIS-Modellablage». Dazu später mehr.

ÖREB-Kataster richtig gemacht #7 - Multi-Tenancy

Sun, 12 Jun 2022 00:00:00 +0000

Im letzten Teil wollte ich zeigen, dass das Solothurner System auch mit Daten anderer Kantone reibungsfrei, einfach und transparent funktioniert. Das tut es. Ein wichtiger Aspekt hat aber gefehlt: Der Testaufbau beinhaltete nur Daten eines Kantons. Herausforderung akzeptiert. Zwei Kantone sind langweilig, nehmen wir noch einen dritten hinzu. Das Schwierigste ist in der Regel in den Besitz von Daten im Rahmenmodell zu kommen. Weil diese nun nicht einfach vom jeweiligen Kanton herunterladbar sind, erzeuge ich aus dem MGDM der belasteten Standorte des Kantons Schwyz selber die Rahmenmodell-Transferstruktur. Die Daten im MGDM kann man auf geodienste.ch herunterladen. Den Datenumbau machen wir nicht mit dem im letzten Teil erwähnten mgdm2oereb-Tool, sondern mit unserem Sql-Ansatz. D.h. ich importiere die Daten im MGDM mit ili2pg in die Datenbank, erzeuge ein Schema mit leeren Rahmenmodell-Tabellen und mit der «Power of Sql» baue ich die Daten von einer Struktur in die andere. Für den Datenexport kommt wieder ili2pg zum Zug. Diesen Ansatz verwenden wir bei uns konsequent für das Herstellen des Rahmenmodells und auch sonst für praktisch alles (z.B. KGDM → MGDM). Die einzelnen Befehle und die SQL-Queries kann man sich im Github-Repo zu Gemüte führen. Das mgdm2oereb-Tool kann nicht verwendet werden, weil es mit der Version 1.5 des MGDM funktioniert. Die Daten des Kantons Schwyz liegen jedoch in der Version 1.4 vor.

Haben wir die KbS des Kantons Schwyz nun im Rahmenmodell vorliegend, können wir die Konfigurationsdateien erstellen. Klammerbemerkung: Dabei sogar eine Premiere. Einmal im Leben geobasisdaten.ch verwendet und zwar um die gesetzlichen Grundlagen des KbS im Kanton Schwyz herauszufinden. Wie beim Kanton Schaffhausen mache ich bloss das Minimum. D.h. ich schalte eine Gemeinde frei (Schwyz) damit sich die Fleissarbeit für mich in Grenzen hält. Die Konfigurationsdateien sind im PoC-Repo zu finden. Der Datenimport, den wir mit GRETL (unser ETL-Werkzeug mit integriertem ili2pg etc.) machen, ist um die SZ-Jobs angewachsen.

Und das ist es eigentlich auch bereits. Sind sämtliche Daten importiert, kann man Requests für drei Kantone machen:

SO:

SH:

SZ:

Die Antwort des SZ-Beispieles:

Mission accomplished. Aber leider auch nicht ganz so erfolgreich. Das PDF sieht zwar tiptop aus und auf den ersten Blick auch korrekt (gut, bis auf die hässliche fette Umrandung des geodienste.ch-WMS), aber auf den zweiten Blick sieht man die überflüssigen gesetzlichen Grundlagen. Es werden auch Gesetze und Verordnungen der Kantons Schaffhausen und Solothurn aufgelistet. Warum? Des Rätsels Lösung ist einfach. In den ch.KANTON.agi.oereb_themen_V2_0.xtf-Dateien weisen wir einem ÖREB-Thema weitere (kantonale oder kommunale) gesetzliche Grundlagen zu. D.h. in unserem gemeinsamen ÖREB-Katastersystem sind dem Thema ch.BelasteteStandorte gesetzliche Grundlagen von drei Kantonen zugewiesen. Das ist falsch. Entweder müsste man das Rahmenmodell anpassen (wie auch wegen der fehlenden Beziehung einer Gemeinde zu einer KVS) oder man löst es applikatorisch indem man Konventionen einführt (mit Baskets und/oder Datasets). Aber für mich noch kein Abbruchkriterium für eine gemeinsame ÖREB-Katasterinfrastruktur.

Die Architektur bleibt für mich faszinierend einfach. Sie hat klare Schnittstellen, ist effizient und transparent und basiert auf robusten, vorhandenen Werkzeugen (PostGIS, ili2db, ilivalidator, …). «Standing on the shoulders of giants» quasi. Vielleicht sollten wir wieder vermehrt einfache Dinge einfach lösen. Technisch wie auch organisatorisch.

ÖREB-Kataster richtig gemacht #6 - Quod erat demonstrandum

Thu, 2 Jun 2022 00:00:00 +0000

Teil 1 - 5 zeigen wie man sich einen ÖREB-Kataster zusammenstöpselt. Dass das funktioniert, ist nicht sonderlich erstaunlich, da es ziemlich 1:1 dem entspricht, was wir und wie es wir im Einsatz haben. Funktioniert es auch mit in anderen Kantonen?

Ja, klar. Man nehme z.B. die KbS des Kantons Schaffhausen im Rahmenmodell. Diese werden direkt aus dem MGDM mittels XSLT hergestellt. Die Idee finde ich interessant, freue mich aber auf die Transformation für Fälle von MGDM, wo man Geodaten filtern muss. Welcome to XPath hell… Zudem natürlich alle Bundesdaten. Benötigt werden insbesondere noch die Konfiguration-INTERLIS-Transferdateien. Das sind:

Zuständige Stellen: Für unsere Gesamtsystem wird zwingend die katasterverantwortliche Stelle benötigt. Sie landet auf dem PDF-Ausdruck und natürlich auch in der XML-Datei.

Optional werden sämtliche zuständigen Stellen des Kantons und der Gemeinden benötigt. Werden diese zentral nachgeführt und verwaltet, kann in den Geodaten nur noch darauf verwiesen werden und sie müssen nicht mitgeliefert werden. Das hat den Vorteil, dass bei Mutationen einfach und schnell reagiert werden kann und dies nur an einer Stelle gemacht werden muss. Zudem ist es einfach «sauberer», wenn im ÖREB-Kataster z.B. die Staatskanzlei nur einmal vorkommt und nicht x-fach. Die Staatskanzlei eines Kantons gibt es in der Realwelt ebenfalls nur einmal.

https://github.com/oereb/oereb-sh/blob/main/oereb_config/ch.sh.agi.oereb_zustaendigestellen_V2_0.xtf

Gesetze: Eine Transferdatei mit den Gesetzen wird zwingend benötigt, um die kantonalen gesetzlichen Grundlagen verwalten zu können.

https://github.com/oereb/oereb-sh/blob/main/oereb_config/ch.sh.sk.oereb_gesetze_V2_0.xtf

Themen: Die Themen-Konfiguration ist ebenfalls zwingend notwendig. Sie wird benötigt, um die kantonalen gesetzlichen Grundlagen den Themen zuzuweisen. Zusätzliche kantonale Themen und Subthemen werden auch in dieser Datei verwaltet.

https://github.com/oereb/oereb-sh/blob/main/oereb_config/ch.sh.agi.oereb_themen_V2_0.xtf

Verfügbarkeit: Die Verfügbarkeits-Konfiguration wird zwingend für die Steuerung der verfügbaren Themen und Gemeinden benötigt. Ebenfalls wird das Datum des Standes der Daten der amtlichen Vermessung in dieser Konfiguration verwaltet.

https://github.com/oereb/oereb-sh/blob/main/oereb_config/ch.sh.agi.oereb_verfuegbarkeit_V2_0.xtf

Grundbuch: Wird zwingend benötigt, falls es Grundbuchkreise (o.ä.) gibt.

https://github.com/oereb/oereb-sh/blob/main/oereb_config/ch.sh.agi.oereb_grundbuchkreis_V2_0.xtf

MapLayering: Falls man die Opazität und die Reihenfolge der WMS-Bilder (resp. des Darstellungsdienstes) steuern will, ist diese Konfigruation zwingend.

https://github.com/oereb/oereb-sh/blob/main/oereb_config/ch.sh.agi.oereb_maplayering_V2_0.xtf

Logo: Wird zwingend für die Verwaltung der Logos der Gemeinden und des Kantons benötigt.

https://github.com/oereb/oereb-sh/blob/main/oereb_config/ch.sh.agi.oereb_logo_V2_0.xtf

Texte: Wird zwingend benötigt, falls es neben den Bundestexten noch weitere kantonale Texte für den Glossar gibt. In meinen Beispiel für den Kanton Schaffhausen habe ich keine zusätzlichen Texte eingeführt.

Die Aufsplittung der Konfiguration kann man teilweise (es muss ja immer noch modellkonform sein) selber wählen. Wahrscheinlich macht man das eher themen-/kontextbezogen und abhängig vom Nachführungszyklus.

Im Dockerfile resp. in der docker-compose.yml-Datei sieht man die übriggebliebene Konfiguration, die man nicht mittels INTERLIS-Dateien verwalten kann:

Timezone
Datenbankverbindung
Datenbankschema
Minimale Grösse der Geometrien, die berücksichtigt werden beim Verschnitt.
URL der katasterverantwortlichen Stelle
WMS für die Hintergrundkarte(n)

Pro ÖREB-Webservice-Instanz kann somit nur eine KVS vorhanden sein kann. D.h. es bräuchte im Rahmenmodell noch etwas wie «KVS pro Gemeinde», damit es nicht für jeden Kanton eine eigene Webservice-Instanz braucht.

Auf Stufe Datenbank könnte man bereits heute mehrere Kantone in das gleiche Schema schmeissen und es würde funktionieren.

Die Konfiguration mittels Rahmenmodell ist sehr transparent und man muss für verschiedene Schritte das Rad nicht neu erfinden:

Nachführung: Entweder schnell mal von Hand oder mit QGIS.
Validierung und Import in das Katastersystem: ilivalidator und ili2pg

Schreiten wir zur Tat und implementieren wir ein ÖREB-Katastersystem für den Kanton Schaffhausen:

docker-compose up (im oereb_stack-Ordner)

Das startet eine leere ÖREB-Datenbank und den ÖREB-Webservice. Die GRETL-Jobs konnte ich mit minimalen Anpassungen aus Teil 3 übernehmen.

Die magischen Env-Variablen müssen wir setzen:

export ORG_GRADLE_PROJECT_dbUriOerebV2="jdbc:postgresql://oereb-db/oereb"
export ORG_GRADLE_PROJECT_dbUserOerebV2="gretl"
export ORG_GRADLE_PROJECT_dbPwdOerebV2="gretl"

Sämtliche Datenimports werden mit einem Befehl im Ordner oereb_gretljobs angestossen:

./start-gretl.sh --docker-image sogis/gretl:latest --docker-network oereb_stack_default --job-directory $PWD :oereb_av:replaceCadastralSurveyingData :oereb_plzo:importPLZO :oereb_bundesgesetze:importData :oereb_bundeskonfiguration:importBundeskonfiguration :oereb_kantonskonfiguration:importKantonskonfiguration :oereb_bundesdaten:importData :oereb_kbs:importData

Ich habe nur die Gemeinde Schaffhausen freigeschaltet. Aus diesem Grund wird auch nur die amtliche Vermessung dieser Gemeinde heruntergeladen und importiert. Der gesamte Importprozess dauert bei mir circa fünf Minuten, wobei das meiste für die amtliche Vermessung und die PLZ/Ortschaften draufgeht.

Testrequest «KbS ÖV und Baulinien Nationalstrassen»:

Testrequest «KbS (mgdm2oereb)»:

Eine Unschönheit weist der Auszug bei den gesetzlichen Grundlagen auf: Das USG und die USGV erscheinen doppelt. Das rührt daher, weil die gesetzlichen Grundlagen ebenfalls in den Geodaten bei den Dokumenten mitgeliefert werden und dann ebenfalls nochmals in meiner Konfiguration dem Thema zugeordnet werden. Die gesetzlichen Grundlagen sollten nicht mit den Geodaten mitgeliefert werden.

Die Frage, die mich aber nachts fast nicht mehr schlafen lässt: Warum um Herrgottswillen steht da auf dem geodienste.ch-WMS «frei erhältlich»? Habe ich irgendwie falsche WMS-Endpunkte angezapft oder ist das ein spezieller WMS-Layer? Ich habe das Root-Element als Layer-Parameter gewählt.

ÖREB-Kataster richtig gemacht #5 - ÖREB-Webservice

Sat, 14 May 2022 00:00:00 +0000

Der ÖREB-Webservice ist das eigentliche Herz des ÖREB-Katasters und das einzige Originäre. Trotzdem ist er im Prinzip sehr simpel. Er macht pro Aufruf ein paar Datenbankabfragen und wandelt das Resultat nach XML um. Wobei man sich um das eigentliche Formatieren nicht einmal kümmern muss. Doch dazu später mehr. Der PDF-Auszug wird sinnvollerweise direkt aus dem XML abgeleitet und wird nicht mit zusätzlichen Datenbankabfragen gesondert hergestellt.

Die Basis des Webservices ist Spring Boot. Ein Java-Framework, das wir für sehr vieles einsetzen. Sämtliche ÖREB-Magie geschieht praktisch in einem Controller. Der Controller nimmt die Anfragen (GetEgrid, GetExtractById, …) entgegen und sammelt anschliessend die Daten in der Datenbank zusammen.

Die XML-Datei als solches müssen wir nicht selber formatieren, sondern wir verwenden JAXB, das uns diese Arbeit abnimmt. Wir müssen bloss die Resultate aus der Datenbank in Java-Objekte umwandeln. Aus den Java-Objekten erzeugt JAXB die XML-Datei selbständig. Die Java-Klassen müssen vorgängig einmalig - ebenfalls mit JAXB - aus dem XML-Schema erzeugt werden. Manchmal kann das auch mühsam werden, wenn - wie in in der Version 1 des Rahmenmodelles - die Geometriekodierung auf GML basiert. Dann enstehen, aufgrund der Komplexität des GML-Standards, hunderte von Java-Klassen. Die meisten natürlich für unseren Anwendungsfall völlig unnötigt. Weil in der Version 2 des Rahmenmodelles die Geometriekodierung auf INTERLIS basiert, schrumpft dies auf ein paar Klassen zusammen.

Die Umwandlung der XML-Datei in eine PDF-Datei machen wir mit XSLT und XSL-FO. Die XSL-Transformation wandelt das XML in eine «ASCII-PDF»-Datei um. Die Transformation mit XSL-FO formatiert diese «ASCII-PDF»-Datei in eine richtige PDF-Datei. XSLT ist ein lebendiger Standard, der in der Version 3 sehr mächtig ist. Sogar Browser unterstützen XSLT. Leider nur die Version 1. Trotzdem lassen sich einige sinnvolle Anwendungen für XSL-Transformationen im Browser finden, so z.B. die ilimodels.xml-Datei einer INTERLIS-Modellablage lesbarer zu gestalten: https://geo.so.ch/models/ilimodels.xml. XSL-FO wird leider als Standard nicht mehr weiterentwickelt. Zukünftig könnte vielleicht CSS Paged Media diese Rolle übernehmen. Jedoch gibt es immer noch lebendige XSL-FO-Softwareprojekte, die stetig weiterentwickelt werden, z.B. Apache FOP, das auch wir einsetzen.

Die Umwandlung der XML-Datei in eine PDF-Datei haben wir in eine separate Bibliothek ausgelagert, die vom Webservice referenziert wird. Sie unterstützt alle Landessprachen und kann mit eingebetteten Bildern oder mit WMS-GetMap-Requests umgehen. Veröffentlicht wird die Bibliothek auf Maven-Central oder als Standalone-CLI-Tool auf Github. Die Verwendung des CLI-Tools ist im README.md beschrieben. Die XML-Datei wird vor der Transformation nicht auf Schemakonformität geprüft. Dieser Schritt könnte/sollte man eventuell noch einbauen. Für einige sehr spezifische Teilprozesse mussten eigene XSLT-Funktionen mit Java implementiert werden. Dabei handelt es sich vor allem um grafische Transformationen, wie z.B. das Herstellen des Overlay-Images bestehend aus Rubberband, Massstabsbalken und Nordpfeil. Es gibt ausserdem einen (quick 'n' dirty) Webservice mit einem hässlichen GUI und einer M2M-Schnittstelle.

Neben der ÖREB-Datenbank und dem ÖREB-WMS ist der ÖREB-Webservice die dritte Software-Komponente des ÖREB-Katasters. Die docker-compose Datei muss entsprechend erweitert werden. Im Rahmen dieser Blogreihe erstellen wir kein separates Dockerimage für den Webservice, sondern verwenden das Image, welches auch wir in Betrieb haben. Das Dockerfile zeigt die wenigen notwendigen Einstellungsmöglichkeiten. Einige der Optionen (z.B. Hintergrundkarte, …) müssten noch als Umgebungsvariable exponiert werden, damit nicht nur der Kanton Solothurn dieses Image verwenden kann. Ergänzt werden muss die Compose-Datei um folgenden Eintrag:

  webservice:
    image: sogis/oereb-web-service:2
    environment:
      TZ: Europe/Zurich
      DBURL: jdbc:postgresql://db:5432/oereb
      DBUSR: dmluser
      DBPWD: dmluser
      TMPDIR: /tmp/
      DBSCHEMA: live
      MININTERSECTION: "0.1"
    ports:
      - 8080:8080
    depends_on:
      - qgis-server
      - db

Mit docker-compose up kann man die drei Container starten und falls der Webservice erfolgreich gestartet ist, erscheint unter http://localhost:8080 die Meldung «oereb web service». Der Webservice wird trotzdem gestartet, wenn z.B. die Datenbank-Url oder die Login-Credentials falsch sind. In diesem Fall meldet sich der Webservice jedoch «krank». Unter dem Health-Endpoint erscheint die Meldung "status": "DOWN" anstelle von "UP".

Falls der DB-Container seit Teil 4 gestoppt wurde, müssen wir die Daten nochmals importieren:

./start-gretl.sh --docker-image sogis/gretl:latest --docker-network \
oereb-stack_default --job-directory $PWD motherOfAllTasks

Wurden die Daten wieder importiert, können wir einen Testrequest machen und einen E-GRID an einer bestimmen Koordinate suchen:

http://localhost:8080/getegrid/xml/?EN=2600573,1215488&GEOMETRY=true

Sieht der Output plausibel aus, können wir mit dem eruierten E-GRID einen XML-Auszug anfordern:

http://localhost:8080/extract/xml?EGRID=CH955832730623

Auch hier gibt es nicht viel zu sagen. Im Browser sollte eine XML-Datei angezeigt werden. Der Webservice unterstützt keinen JSON-Output. Ich finde die Weisung diesbezüglich unglücklich: XML-Output ist Pflichtformat, JSON ist optional. Ich bin der Meinung man sollte sich auf ein Format beschränken. Stand heute würde ich klar immer noch XML vorziehen. Die Schemaunterstützung von XML ist viel erwachsener, entsprechend auch die Werkzeuge. Oftmals hört man in diesem Kontext das Argument «aber JSON ist schneller». Gemeint ist (wohl?), dass aufgrund der absoluten Dateigrösse weniger Daten vom Server an den Clienten geschickt werden müssen, was natürlich stimmt. Jetzt kommt ein grosses ABER: Wenn man seinen Webserver nicht komplett falsch konfiguriert hat, werden die zu sendenden Daten komprimiert. Der Grössenvorteil von JSON gegenüber XML schmilzt so natürlich ziemlich dahin. Und man sollte für eine gute User Experience nicht bloss die Zeit für das Übertragen des Auszugs zählen, sondern die gesamte Zeitdauer, beginnend vom Klicken in die Karte bis zum fertigen Auslieferen des PDF oder XML. Somit dürfte matchentscheidender sein wie schnell das eigentliche Herstellen des Auszuges auf dem Server dauert. Insbesondere die Datenbankabfragen inkl. Verschnitte etc. werden viel mehr ins Gewicht fallen als ein paar Kilobyte mehr, die übertragen werden müssen. Ausserdem sollten die dynamischen Clienten so konfiguriert sein, dass sie nicht zwingend immer auch eingebettete Bilder anfordern, sondern bloss die WMS-Requests. Denn die Bilder braucht man nicht für die Darstellung im Web GIS Client. Und das Herstellen dieser Bilder ist sehr teuer.

Zurück zu unserem Webservice: Ein Request mit eingebetteten Bildern funktioniert nicht (richtig):

http://localhost:8080/extract/xml?EGRID=CH955832730623&WITHIMAGES=true

Es erscheint zwar eine XML-Datei im Browser aber das <Image>-Element enthält bloss einen minimalen Platzhalter-Blob. Und in der Konsole, in der wir den Service mit docker-compose gestartet haben, erscheinen Fehlermeldungen: failed to get wms image. Was ist passiert?

Im dritten Teil haben wir vor dem Import der Daten eine Umgebungsvariable (ORG_GRADLE_PROJECT_geoservicesUrl) gesetzt, welche die URL des Darstellungsdienstes in den kantonalen Daten steuert. Unter dieser URL (http://localhost/wms/oereb) ist der WMS-Server aber nicht erreichbar, sondern es muss der korrekte Port (8083) mitangegeben werden (siehe dazu die docker-compose-Datei). Wenn wir die Umgebungsvariable nochmals korrekt setzen und anschliessend die kantonalen Daten importieren, funktioniert es aber immer noch nicht. Warum?

Nun hier wird es leider ein wenig kompliziert. Erstens muss erwähnt werden, dass es nur unter macOS und Windows nicht funktioniert. Das hat damit zu tun, dass Docker auf diesen beiden Betriebssystemen nicht nativ läuft, sondern immer noch eine sehr kleine VM dazwischen ist. Zweitens gibt es die Probleme nur bei der Verwendung von localhost. D.h. der Webservice findet den WMS-Server (beiden laufen in einem Docker-Container) immer noch nicht. Abhilfe schafft die Verwendung von http://host.docker.internal:8083/wms/oereb anstelle von localhost. Das aber führt leider dazu, dass im XML-Auszug nun die URL der Darstellungsdienste (<ReferenceWMS>) von ausserhalb der Container, also wenn man z.B. die URL in die Browserleiste kopiert, nicht funktioniert. Diese Kröte muss man leider unter macOS und Windows während des lokalen Testens oder Entwickelns schlucken.

Zu Testen fordern wir für das Grundstück eine PDF-Datei an:

http://localhost:8080/extract/pdf?EGRID=CH955832730623

Das Resultat sollte ein, den Weisungen entsprechender, PDF-Auszug sein:

Mit dem ÖREB-Webservice und den anderen bereits vorgestellten Komponenten steht eine einfache, transparente und performante ÖREB-Katasterinfrastruktur zur Verfügung. Wir sind damit sehr zufrieden, sei es während der Weiterentwicklung oder während des Betriebes. Es wurde nichts Unnötiges erfunden. Insbesondere der Fokus auf das Rahmenmodell und damit auf das INTERLIS-Ökosystem hilft ungemein.

ÖREB-Kataster richtig gemacht #4 - ÖREB-WMS

Sat, 23 Apr 2022 00:00:00 +0000

Als WMS-Server verwenden wir QGIS-Server. Für die (Nicht-)Anforderungen des ÖREB-Katasters ginge aber wohl jeder halbwegs konforme WMS-Server. Als erstes müssen wir die Layer unserer Daten konfigurieren. Die Datenquelle ist die Datenbank aus Teil 2, die wir im Teil 3 mit Daten befüllt haben. Es gibt in der Datenbank die Schemen stage_wms und live_wms. Ersteres dient zur Verifikation, der in die Katasterstruktur importieren Daten. Das zweite Schema ist das eigentliche Produktionsschema. Damit die QGIS-Projektdatei aber unabhängig vom Schemennamen aufgebaut werden kann, verwenden wir nicht direkt Datenbankverbindungsparameter (Host, DB-Name, User, Passwort), sondern das sogenannte Connection Service File. Mit grosser Wahrscheinlichkeit werden mindestens zwei benötigt. Eines für das lokale Arbeiten und eines für den Betrieb, da sich die Verbindungsparameter unterscheiden werden. Das Service-File für das lokale Arbeiten sieht bei mir so aus:

[oereb]
host=localhost
port=54323
dbname=oereb
user=gretl
password=gretl
sslmode=disable
options=-c search_path=public,live_wms

QGIS-Desktop muss man das Service-File bekannt machen, indem man unter Preferences - System - Environment eine PGSERVICEFILE-Variable mit dem Pfad zur Datei setzt. Die erste Zeile des Service-Files ist der Name der Verbindung. In QGIS-Desktop muss man im Datenbank-Connection-Fenster einzig dieser Name eintippen:

Die letzte Zeile (options=) bestimmt den Suchpfad von Datenbanktabellen. Weil wir wollen, dass in der QGIS-Projektdatei nur die Tabellennamen stehen aber keine Schemennamen, definieren wir einen sogenannten Suchpfad. Dieser bestimmt in welchen Schemen die Tabelle gesucht wird, wenn das QGIS-Projekt geladen wird. Wenn ich mich aber richtig erinnere, musste ich beim Zusammenstöpseln des QGIS-Projektes nachträglich im Texteditor die Schemennamen rauslöschen, weil der search_path nur beim Lesen des Projektes greift, wenn die Tabelle kein Schemennamen im Projekt definiert hat.

Wenn man keinen Validierungsschritt verwenden will, ist das alles unnötig und die Schemennamen dürfen im Projektfile stehen.

Nach bisschen Fleissarbeit sieht es bei mir so aus:

Mindestens die vorgebenen Themen hat jeder Kanton. Dazu kommen kantonale ÖREB-Themen. Bei uns z.B. das Thema Einzelschutz.

Nun geht es um das Verpacken des ÖREB-WMS in ein Docker-Image. Als Basis-Image verwende ich unser QGIS-Server-3.16-Image. Wir betreiben QGIS-Server in Kombination mit Apache Webserver und nicht mit nginx. Super glücklich sind wir mit dem Image nicht. Ob aber die Kombination mit nginx besser ist, ist uns auch nicht klar. Es scheint als scheiden sich hier die Geister. Uns stört aber vor allem, dass unser Image als root laufen muss, eine stattliche Grösse aufweist und dass niemand wirklich weiss in welcher Konfiguration man das Teil unter grosser Last in einem Kubernetes-Cluster laufen lassen soll. Aber andere Baustelle…

Auf dem Basis-Image aufbauend, müssen wir für den ÖREB-WMS nicht mehr grosse Handstände machen. Es müssen lediglich die QGIS-Projektdatei und das Servicefile reinkopiert werden. Das Servicefile in dieser Form würde man in einer Produktionsumgebung nicht reinbrennen oder dann das Image nicht öffentlich publizieren oder die Credentials mit Umgebungsvariablen injizieren.

Das Dockerfile:

FROM sogis/qgis-server-base:3.16

LABEL maintainer="Amt fuer Geoinformation Kanton Solothurn <agi@bd.so.ch>"

# copy .qgs
COPY qgis /data

RUN chown -R www-data:www-data /data

#pg_service.conf File
COPY conf/pg_service.conf /etc/postgresql-common/pg_service.conf
ENV PGSERVICEFILE="/etc/postgresql-common/pg_service.conf"

#sed command to change URL rewrite
RUN sed -i 's/\^\/qgis\//\^\/wms\//g' /etc/apache2/sites-enabled/qgis-server.conf

#tell apache/qgis-server where to find the pg_service.conf file
RUN echo 'SetEnv PGSERVICEFILE "/etc/postgresql-common/pg_service.conf"' > /etc/apache2/mods-enabled/env.conf

HEALTHCHECK --interval=30s --timeout=10s --start-period=60s CMD curl http://localhost

Erstellt wird das Image in einer Github Action und wird via Github Container Registry publiziert. Wie bei der ÖREB-Datenbank wird sowohl ein Image für linux/amd64 wie auch für linux/arm64 erstellt. Weil es jedoch das Ubuntugis-Repo nur für linux/amd64 gibt (?), wird im ARM-Image die QGIS-Version aus dem normalen Ubuntu-Repository (3.10) installiert. Für das lokale Entwickeln soweit kein Problem. Möchte man QGIS 3.16 auf auch ARM-Rechner verwenden, muss man es wohl selber kompilieren.

Zusammen mit der ÖREB-Datenbank haben wir nun schon zwei Komponenten des ÖREB-Katasters. In einem weiteren Github-Repository beginne ich mit einer docker-compose-Datei mit der man die Komponenten zusammen starten kann:

docker-compose up

Wichtig ist, dass der Name des Datenbank-Services im docker-compose-File gleich heisst, wie der host-Name im Service-File (db), das wir in das WMS-Image reingebrannt haben. Sonst kann sich der WMS-Server nicht mit der Datenbank verbinden. Funktioniert alles, liefert der Server ein GetCapabilities-Dokument zurück. Schlägt z.B. die Verbindung zur Datenbank fehl, erscheint im Browser die Fehlermeldung Layer(s) not valid. Daten sind aber noch keine in der Datenbank. Mit den Gretl-Jobs aus Teil 3 können wir Daten einfach importieren:

export ORG_GRADLE_PROJECT_dbUriOerebV2="jdbc:postgresql://db/oereb"
export ORG_GRADLE_PROJECT_dbUserOerebV2="gretl"
export ORG_GRADLE_PROJECT_dbPwdOerebV2="gretl"
export ORG_GRADLE_PROJECT_geoservicesUrl="http://localhost/wms/oereb"

./start-gretl.sh --docker-image sogis/gretl:latest --docker-network oereb-stack_default --job-directory $PWD motherOfAllTasks

Man beachte den anderen Docker-Netzwerk-Namen und bei den «magischen» Umgebungsvariablen für Gretl die leicht andere Datenbank-Url. Auch hier musste der Hostname der Datenbank angepasst werden.

Ein paar Minuten später kann man das Werk in QGIS-Desktop anschauen:

Der WMS ist momentan unter der URL http://localhost:8083/wms/oereb erreichbar. Die URL des Darstellungsdienstes ist Bestandteil der Geobasisdaten und steht auch im XML-Auszug. Sie kann verwendet werden, um z.B. die Bilder für das PDF herzustellen. Wenn der Darstellungsdienst nicht von einer anderen Stelle bereitgestellt wird, sondern direkt aus der ÖREB-Datenbank publiziert wird, führt das zum Umstand, dass ich je nach Umgebung (lokal, Test, Integration, Produktion) die URL des Darstellungsdienst anpassen muss. Die URL anpassen, heisst die Daten verändern. So gesehen müsste der URL eher eine Konfiguration des Katastersystems sein und nicht Inhalt der Geobasisdaten.

Im nächsten Teil geht es um den ÖREB-Webservice (DATA-Extract und statischer Auszug).

ÖREB-Kataster richtig gemacht (und einfacher) #3 - ÖREB-Gretljobs

Tue, 19 Apr 2022 00:00:00 +0000

Im dritten Teil schlägt die Stunde der ÖREB-Gretljobs. Gretljobs? Gretl?

Als wir uns vor Jahren daran machten unser Cronjob- und Datenintegrationschaos (oder allgemeiner ETL-Prozesse) zu beseitigen, kamen wir auf die Idee ein Build-Tool zu verwenden. Der Grund für diese Entscheidung war, dass ein solcher Prozess (= Job) immer in Teilschritte (= Tasks) runtergebrochen werden kann. Beispiel: Daten werden heruntergeladen (Task 1), Daten werden entzippt (Task 2), Daten werden geprüft (Task 3), Daten werden importiert (Task 4) und Daten werden in eine andere Datenbankstruktur umgebaut (Task 5). Als Build-Tool verwenden wir Gradle. Einerseits gibt es out-of-the-box bereits viele Funktionen und Plugins und andererseits ist es relativ einfach erweiterbar. Erweiterbar muss es sein, weil wir ein paar «Geo-Tasks» benötigen (z.B. INTERLIS-Import etc.) oder andere Funktionen, die es weder im Core noch in einem Plugin gibt. Unsere Erweiterungen packten wir ebenfalls in ein Plugin und somit war Gretl (Gradle ETL) geboren.

Ein minimales Beipiel, das eine INTERLIS-Datei prüft, sieht wie folgt aus (der Code muss als build.gradle-Datei gespeichert werden):

import ch.so.agi.gretl.tasks.*
import ch.so.agi.gretl.api.*

apply plugin: 'ch.so.agi.gretl'

buildscript {
    repositories {
        maven { url "http://jars.interlis.ch" }
        maven { url "http://jars.umleditor.org" }
        maven { url "https://repo.osgeo.org/repository/release/" }
        maven { url "https://plugins.gradle.org/m2/" }
        mavenCentral()
    }
    dependencies {
        classpath group: 'ch.so.agi', name: 'gretl',  version: '2.1.+'
    }
}

defaultTasks 'validate'

task validate(type: IliValidator){
    dataFiles = ["fubar.xtf"]
}

Im Verzeichnis, wo die build.gradle-Datei liegt, kann man den Job mit gradle aufgerufen werden. Die zu prüfende Datei fubar.xtf muss natürlich vorhanden sein und Gradle (und Java) installiert sein. Das Interessante sind die sogenannten Tasks. Von diesen Tasks kann es beliebig viele geben und sie können auch voneinander abhängig (dependsOn) sein. Einen Überblick über alle unsere Jobs (und Inspiration) erlangt man in unserem gretljobs-Repo. Eine möglichst vollständige Dokumentation unserer selbst programmierten Tasks findet man ebenfalls im Repo oder man kann sich die Gretl-Präsentation an der FOSSGIS 2019 zu Gemüte führen. Die ganze Sache läuft nun seit circa fünf Jahren und wir könnten zufriedener nicht sein. Zur Orchestrierung sämtliche Jobs verwenden wir übrigens Jenkins, was sich ebenfalls sehr bewährt hat: Perfekte Übersicht über sämtliche Jobs und Logfiles immer am gleichen Ort. Viel mehr braucht es nicht:

Jenkins wird hier der Einfachheithalber keine Rolle spielen, da ein Gretl-Job eben auch ganz ohne Schnick-Schnack nur in der Konsole ausgeführt werden kann. Wir haben das Gretl-Plugin mit sämtlichen Abhängigkeiten in ein Docker-Image gepackt. So sind wir sicher, dass wir immer die gleichen Versionen der Abhängigkeiten verwenden und sind zugleich unabhängig von einer Java-Installation. Das Image ist seit kurzem auch auf einem Apple Silicon Rechner lauffähig. Man sieht: eine gewisse Leidensfähigkeit und Durchhaltewillen als Macbook-Anwender der neueren Generation muss man mitbringen.

Zurück zum eigentlichen Ziel: Dem Import aller benötigten Daten in die ÖREB-Datenbank (aus Teil 2) für den Betrieb des ÖREB-Katasters. Und mit allen Daten sind eben nicht nur Geodaten gemeint, sondern auch Konfiguration im weiteren Sinne, d.h. Gesetzliche Grundlagen, Themen, Logos, Texte. Sowohl für Bund und Kanton (Gemeinden). Ein wichtige Konfiguration im engeren Sinne sind z.B. die freigeschalteten Gemeinden (wo ist der ÖREB-Kataster verfügbar?). Dafür gibt es im Modell OeREBKRMkvs_V2_0 die Klasse GemeindeMitOeREBK. In dieser Klasse kann man feingranular verwalten, welche Themen in welcher Gemeinde vorhanden sind. Alle diese Daten(sätze) sind bei uns in einer INTERLIS-Transferdatei vorhanden resp. für die Bundesthemen stellt sie bereits Swisstopo zur Verfügung. Es gibt absolut keine Notwendigkeit diese Konfigurationen mit etwas selber Gestricktem zu definieren und zu verwalten. Mit der ersten Version des ÖREB-Katasters konnte man aufgrund des fehlenden Konfigurations-Teilmodelles noch nicht vollständig und konsequent mit dem Rahmenmodell (resp. den Daten) einen XML-Auszug und das PDF herstellen. Damals entwickelten wird unser sogenanntes «Annex-Datenmodell», der Vorläufer des heutigen Konfigurationsmodells, damit wir trotzdem in der INTERLIS-Bubble bleiben konnten.

Stehen die Datensätze online zur Verfügung, müssen die Gretl-Jobs diese nur noch herunterladen, validieren und importieren (siehe Teil 1 «sauberer Schnitt» und «Zuständigkeiten»). Matchentscheidend ist die Reihenfolge wie die Gretl-Jobs ausgeführt werden: Die Daten werden in eine Datenbank importiert. Die Beziehungen zwischen Klassen werden mittels Fremdschlüsseln abgebildet. D.h. man kann keine Daten importieren, wenn die Daten auf ein Objekt zeigen, dass noch nicht in der Datenbank vorhanden ist. In unserem Fall müssen zwingend die zuständigen Stellen vorhanden sein, wenn man Geobasisdaten importieren will und die zuständigen Stellen nicht mit den Daten mitgeliefert werden. Man kann (mit einer ili2pg-Option) das Erstellen der Fremdschlüsseln zwar ausschalten, was aber meines Erachtens nicht sinnvoll ist. Diese gibt es ja aus guten Gründen und wenn man immer und immer wieder Daten in den DB-Tabellen austauscht, passiert garantiert irgendwann mal ein Fehler und die Daten passen nicht mehr zusammen (Stichwort referentielle Integrität). Herausfordernd wird es, wenn – bleiben wir beim Beispiel der zuständigen Stellen – der Name oder die Adresse der zuständigen Stelle ändert. Dieser Record kann in der Datenbank nicht einfach so ausgetauscht werden, weil ein anderer Record einen Fremdschlüssel auf die zuständige Stelle hat. Die meisten solcher Fälle können mit ili2db-Magie gelöst werden indem man die --update-Option verwendet. Das Objekt in der Datenbank wird nicht gelöscht, sondern – nomen est omen – upgedatet. Das funktioniert natürlich nicht, wenn die zuständige Stelle gelöscht werden soll und es immer noch Objekte gibt, die auf diese zuständige Stelle verweisen. In diesem Fall bleibt einem nichts anderes übrig, als zuerst diese Objekte zu löschen und anschliessend auch die zuständige Stelle. Aus diesem Grund ist es sehr wichtig, dass Gradle (das Build-Tool, die Basis von Gretl) verschiedene Hilfsmittel anbietet, welche die Ausführungs-Reihenfolge der Tasks garantiert (dependsOn, mustRunAfter, finalizedBy).

Bei der Organisation der Gretl-Jobs sind der Fantasie keine Grenzen gesetzt. Es gibt viele richtige Varianten. Im vorliegenden Fall habe ich mich für einen Haupt-Gretl-Job entschieden, der aus verschiedenen Sub-Jobs besteht. So kann man mit einem Befehl alles Notwendige importieren aber trotzdem noch einzelne Schritte selbständig ausführen, z.B. das Ersetzen sämtlicher Bundesgeobasisdaten. Ein Blick hinter die Kulissen erlaubt das Gretljobs-Repo. Es gibt eine build.gradle-Datei im Root-Verzeichnis, welche den Haupt-Gretl-Job definiert. Zusätzlich gibt es eine settings.gradle-Datei, die dem Haupt-Gretl-Job die Sub-Jobs bekannt macht.

Meine gewünschte Import-Reihenfolge soll folgende sein:

Grundlagedaten, da diese von nichts abhängig sind: Amtliche Vermessung und PLZ/Ortschaften.
Bundesgesetze
Bundeskonfigurationen
Kantonale Konfigurationen (beinhalten auch kantonale Gesetze)
Bundesdaten (alle)
Kantonsdaten (Auswahl): kommunale und kantonale Nutzungsplanung (einige Gemeinden), KbS, Grundwasserschutz

Erreicht wird das durch eine Kombination von mustRunAfter-Optionen in Tasks der Sub-Jobs und einem einzelnen Task im Haup-Gretl-Job, welcher von allen Import-Tasks der einzelnen Sub-Jobs abhängig ist. Die Reihenfolge wie die Tasks resp. Jobs ausgeführt werden, entspricht nicht zwingend der Reihenfolge wie sie in der dependsOn-Option definiert sind. Deshalb sind die mustRunAfter-Optionen (siehe Beispiel) notwendig. Mit dieser Definition der Tasks und Jobs und Abhängigkeiten zwischeneinander kann man mit einem Befehl alle Daten importieren aber zu einem späteren Zeitpunkt z.B. nur noch die Geobasisdaten in der Datenbank austauschen.

Schaut man sich die verschiedenen build.gradle-Dateien im Repo an, erkennt man, dass sie alle sehr ähnlich sind. Ich denke, man sieht sehr gut, dass die zu erledigende Arbeit eines Sub-Jobs in einzelne kleine Schritte (= Tasks) aufgesplittet wurde, was der Transparenz sehr zuträglich ist (Fehlersuche etc.). Die vorliegende Aufteilung in die Sub-Jobs ist vielleicht nicht ultra-logisch, was darauf zurück zu führen ist, dass ich vieles von unseren produktiven Gretl-Jobs für den ÖREB-Kataster übernommen habe, diese aber für Demo-Zwecke nicht zwingend sinnvoll gruppiert sind.

Wer es nun durchspielen will, hier die notwendigen wenigen Schritte.

Datenbank aus Teil 2 mittels docker-compose up (damit ein Netzwerk angelegt wird) starten. Die docker-compose-Datei ist nichts anderes als der docker run-Befehl. Anschliessend setzen wir für Gretl einige Umgebungsvariablen, damit man z.B. Datenbank-Credentials nicht in der build.gradle-Datei hardcodieren muss:

export ORG_GRADLE_PROJECT_dbUriOerebV2="jdbc:postgresql://oereb-db/oereb"
export ORG_GRADLE_PROJECT_dbUserOerebV2="gretl"
export ORG_GRADLE_PROJECT_dbPwdOerebV2="gretl"
export ORG_GRADLE_PROJECT_geoservicesUrl="http://localhost/wms"

Umgebungsvariablen, die mit ORG_GRADLE_PROJECT_ starten, müssen nicht manuell im Build-Skript ausgelesen werden, sondern stehen automatisch zur Verfügung. Für das Auführen der Gretl-Jobs verwenden wir unser Docker-Image, welches wir mit einem Shell-Skript bedienen. Das Shell-Skript ist nicht viel mehr als ein docker run-Befehl. Früher hatte das Skript noch weitere Funktionen, die aber nicht mehr benötigt werden. Zum Auflisten sämtlicher Task aller (Sub-)Jobs muss folgender Befehl verwendet werden:

./start-gretl.sh --docker-image sogis/gretl:latest --docker-network oereb-gretljobs_default --job-directory $PWD tasks --all

Wenn man «Gretl pur» verwenden würde, also ohne Docker, entspräche das dem Befehl: gradle tasks --all. Mit dem Shell-Skript können wir das Docker-Image, das Docker-Netzwerk und das Job-Directory auswählen. Damit der Gretl-Docker-Container mit dem Datenbank-Container kommunizieren kann, müssen sie im gleichen Netzwerk sein. Falls das Datenbank-Container-Netzwerk anders heisst (docker network ls), muss selbstverständlich dieser Namen verwendet werden.

Zum Importieren sämtlicher Daten reicht der Befehl:

./start-gretl.sh --docker-image sogis/gretl:latest --docker-network oereb-gretljobs_default --job-directory $PWD motherOfAllTasks

Funktioniert die Kommunikation zwischen den Images, sollte man in der Konsole sehen, welche Tasks Gretl gerade abarbeitet. Bei mir dauert der Import (Download, i.d.R. Validierung, Import) meiner Datenauswahl in das live-Schema auf einem Macbook Air (und somit sehr schlechter I/O-Performance mit Docker) circa 6 Minuten. Am längsten dauerte der Import der PLZ/Ortschaften und die amtliche Vermessung. Bei den PLZ/Ortschaften sind halt viele Daten dabei, die mich geografisch nicht interessieren. Hat alles ohne Fehler funktioniert, quittiert Gradle die Arbeit mit BUILD SUCCESSFUL. Ansonsten sollte eine mehr oder weniger sinnvolle Fehlermeldung in der Konsole erscheinen.

Zum Beweis laden wir einige Tabellen in QGIS:

Will man zukünftig nur die Bundesdaten ersetzen, reicht folgender Befehl:

./start-gretl.sh --docker-image sogis/gretl:latest --docker-network oereb-gretljobs_default --job-directory $PWD oereb_bundesdaten:importData

Und 35 Sekunden später sind alle Bundesdaten ersetzt.

Wer jetzt Interesse an Gretl, seinen Fähigkeiten und Einsatzmöglichkeiten in einer GDI hat, darf sich gerne melden. Im nächsten Teil geht es dann ruhiger zu und her: Es entsteht der ÖREB-WMS.

ÖREB-Kataster richtig gemacht #2 - ÖREB-Datenbank

Mon, 18 Apr 2022 00:00:00 +0000

Wie im ersten Teil der «ÖREB-Kataster richtig gemacht»-Serie angekündigt, geht es im zweiten Teil um die ÖREB-Datenbank.

Die Grundidee ist, dass sämtliche Daten, die für den Betrieb des Katasters notwendig sind, in einem Schema vorliegen. Wobei das weniger wichtig ist (und schlussendlich aus zwei Gründen nicht ganz eingehalten wird), als dass sämtliche Geobasisdaten inkl. der Rechtsvorschriften in den gleichen Tabellen vorhanden sind. In «ili2pg-Sprech» bedeutet das, dass mit ili2pg das Transferstruktur-Teilmodell des ÖREB-Rahmenmodells in der Datenbank abgebildet wird und anschliessend können sämtliche ÖREB-Themen in dieses eine Schema importiert werden. Ein ÖREB-Webservice muss sich so nur um eine einzige Datenquelle kümmern und kann mit einer einzigen SQL-Abfrage sämtliche betroffenen Eigentumsbeschränkungen sämtlicher ÖREB-Themen eruieren («Cookie-Cutter»). In das gleiche Schema importieren wir ebenfalls die Konfigurationen (Logos, Texte, Themen, gesetzliche Grundlagen, …), die amtliche Vermessung und die PLZ/Ortschaften.

Aus betrieblichen Gründen erstellen wir bei uns zwei identische solche Schemen: live und stage. Das live-Schema dient als Produktions-Umgebung und das stage-Schema dient den Fachstellen für die Validierung der importierten Daten in den ÖREB-Kataster vor dem definitiven Freischalten. Ein ÖREB-Webservice muss einzig mit einem Schemanamen parametrisiert werden, um eine Validierungsumgebung zu erhalten.

Das Erstellen des Schemas mit ili2pg ist leider nicht ganz so super-trivial wie man sich das wünscht. Der Hauptgrund ist, dass man im gleichen Schema INTERLIS 1 und INTERLIS 2 Modelle abbilden will. Das funktioniert mit einem einzelnen ili2pg-Befehl nicht. Wenn man aber zwei Befehle ausführen muss und man mit der --createScript-Option das SQL in eine Datei schreiben will, muss man das erzeugte SQL noch leicht anpassen, weil sonst z.B. versucht wird Sequenzen doppelt zu erstellen. Ein SQL-Skript wird benötigt, weil wir so beim erstmaligen Hochfahren der Datenbank (als Dockercontainer) das Schema und die Tabellen anlegen wollen.

Langer Rede, kurzer Sinn: Man muss irgendwie mit ili2pg die SQL-Skripte erstellen, diese noch leicht anpassen und dann zusammensetzen. Soweit keine Hexerei. Man kann dazu z.B. ein Shellskript schreiben oder, weil man sowieso Java benötigt, mit jbang ein Java-Skript (also sowas wie ein Skript in Java geschrieben) schreiben. Das Skript befindet sich im Github-Repository. Technisch ist es nicht sonderlich interessant. Es wird mit der ili2db-Bibliothek direkt gearbeitet und anschliessend mit Regex-Magie und Suchen und Ersetzen die notwendigen Anpassungen gemacht. Schaut man sich das Skript ein wenig genauer an, fällt auf, dass es neben den beiden erwähnten Schemen auch noch die beiden Schemen live_wms und stage_wms erstellt. Dabei handelt es sich um Schemen mit Tabellen, die dem ÖREB-Darstellungsdienst (WMS) als Quelle dienen. Die Originaltabellen des Rahmenmodells sind normalisiert, was für die Verwendung in WMS-Servern nicht hilfreich ist. Entweder erstellt man Datenbankviews oder -tabellen und denormalisiert. Wir haben uns für Tabellen entschieden, weil wir die Dokumente als JSON-codierten Text in einer Spalte speichern und so via WMS-GetFeatureInfo verfügbar machen wollen. Das ist aus Sicht ÖREB-Kataster nicht zwingend notwendig. Uns dient die Spalte aber im Validierungsprozess. Da somit der Datenumbau vom Rahmenmodell in unsere denormalisierte Struktur aufwändiger ist, reicht die Performance mit Views nicht mehr. Damit das Anlegen der WMS-Tabellen analog funktioniert, haben wir ein INTERLIS-Datenmodell erstellt. Das Modell muss in separaten Schemen abgebildet werden, weil andere ili2db-Optionen verwendet werden sollen.

Das Skript kann mit folgenden Befehl ausgeführt werden:

jbang create_schema_sql.java

Ist jbang nicht installiert, kann man das Skript (unter Linux und macOS) wie folgt ausführen:

curl -Ls https://sh.jbang.dev | bash -s - create_schema_sql.java

Das Resultat ist eine setup.sql-Datei. Mit dieser lassen sich nun sämtliche Schemen und sämtlichen Tabellen in einer PostgreSQL/PostGIS-Datenbank erstellen. Die Datei interessiert mich direkt aber nicht, da ich sie selber nicht benötige, sondern der Docker-Container beim erstmaligen Hochfahren die SQL-Befehle ausführt. Für das Docker-Image verwende ich unser PostgreSQL/PostGIS-Basisimage (sogis/postgis:14-3.2). Bis es offizielle PostGIS-Images gibt, welche auf ARM-Prozessoren (Apple Silicon) laufen, muss ich mich selber um ein solches Image kümmern, was wiederum nicht sonderlich aufwändig ist, weil das offizielle PostgreSQL-Image glückerlicherweise für ARM-Prozesseren verfügbar ist. Richtig viel passiert im Dockerfile nicht mehr. Es werden einzig zwei Dateien in den Ordner /docker-entrypoint-initdb.d kopiert: Die soeben erstellt Datei setup.sql dient dazu die Tabellen und Scheman in der Datenbank zu erstellen. Die Datei initdb-user.sh wird benötigt um einige Benutzer in der Datenbank zu erstellen und diesen die benötigten Rechte zuzuweisen.

Das Dockerimage wird mit folgendem Befehl erstellt:

docker build -t ghcr.io/oereb/oereb-db:latest .

Beim Starten des Containers müssen Umgebungsvariablen mitgeliefert werden:

docker run --rm --name oerebdb -p 54323:5432 -e POSTGRES_PASSWORD=mysecretpassword -e POSTGRES_DB=oereb -e POSTGRES_HOST_AUTH_METHOD=md5 -e PG_READ_PWD=dmluser -e PG_WRITE_PWD=ddluser -e PG_GRETL_PWD=gretl ghcr.io/oereb/oereb-db:latest

POSTGRES_PASSWORD: Passwort des postgres-Benutzers
POSTGRES_DB: Name der Datenbank
POSTGRES_HOST_AUTH_METHOD: Siehe https://github.com/claeis/ili2db/issues/448. Oder mit den Worten von Tom Petty: «Time to move on»
PG_READ_PWD: Passwort eines read-only Benutzers (dmluser/dmluser). Siehe auch initdb-user.sh.
PG_WRITE_PWD: Passwort eines read/write Benutzers (ddluser/ddluser). Siehe auch initdb-user.sh.
PG_GRETL_PWD: Passwort eines read/write Benutzers (gretl/gretl). Siehe auch initdb-user.sh.

Man kann natürlich in initdb_user.sh komplett andere Benutzer und ein eigenes Dockerimage erstellen. Diese drei Benutzer sind bei uns intern häufig die Regel für Entwicklungsumgebungen.

Die Datenbank oereb mit unseren vier erstellten Schemen ist nach kurzer Zeit verfügbar (aber leer):

Wird der Docker-Container gestoppt, verliert man sämtliche Daten. In unserem Fall ist das noch nicht so tragisch, da bis jetzt noch keine Daten importiert wurden. Jedoch gehen auch die vier Schemen verloren. D.h. bei jedem Container-Neustart, werden diese Schemen wieder erzeugt. Will man dieses Verhalten verhindern, muss man das Datenbankverzeichnis auf dem lokalen Dateisystem persistieren. Das lokale Verzeichnis muss mit korrekten Permissions erzeugt werden.

mkdir -m 0777 ~/pgdata
docker run --rm --name oerebdb -p 54323:5432 -v ~/pgdata:/var/lib/postgresql/data:delegated .... (siehe oben)

Das Herstellen und Testen des Images übernimmt eine Github Action. Die Images gibt es für amd64- (Intel, AMD) wie auch für arm64-Systeme (Apple Silicon) in der Github Container Registry.

Weil eine leere Datenbank nichts bringt, zeige ich im dritten Teil, wie man alle notwendigen Daten einfach importiert.

ÖREB-Kataster richtig gemacht #1 - Übersicht

Sun, 17 Apr 2022 00:00:00 +0000

Ich habe bereits während der Realisierung der ersten Version des ÖREB-Katasters über unsere Architektur geschrieben. Diese Lösung hat sich sehr bewährt. Wir hatten damals zwei bestehende Softwarelösungen angeschaut und uns trotzdem für etwas Eigenes entschieden. Eine der bestehenden Lösung kann meines Erachtens zu viel, die andere habe ich irgendwie nie ganz verstanden.

Im Rahmen unserer Realisierung der zweiten Version des ÖREB-Katasters möchte ich detailliertere Einblicke in unser System geben und auch ein paar Skripte und Docker-Images bereitstellen, damit man das ausprobieren kann. Und ich gebe die Hoffnung nicht auf, dass auch Swisstopo bei passender Gelegenheit die ganze Sache durchspielt und sieht, was es zu tun gibt und damit ein vertiefteres technisches Verständnis für die Materie bekommt.

Die Erläuterungen zum Rahmenmodell des ÖREB-Katasters zeigen in Kapitel 4 «Organisatorischer Rahmen» folgende Abbildung:

In der Mitte steht die Katasterverantwortliche Stelle (KVS), welche in irgendeiner Ausprägung den ÖREB-Kataster betreibt. Die Pfeile deuten die Datenflüsse resp. die Schnittstellen an:

Gemeinden, Staatskanzlei und die Bundeskanzlei liefern die Gesetzlichen Grundlagen
Die zuständigen Stellen liefern die Geobasisdaten inkl. der Rechtsvorschriften.
Aus der amtlichen Vermessung kommen die Liegenschaften und die PLZ/Ortschaften.

Aus dieser Organisation ergeben sich die Anforderungen an das ÖREB-Rahmenmodell. Es gibt somit INTERLIS-Modelle, welche den ganzen Kataster und die Organisation dazu beschreibt.

Legen wir den Augenmerk vom eher Organisatorischen auf die technischen Rahmenbedingungen:

Die Bundesthemen inkl. der gesetzlichen Grundlagen, der Logos und der Texte des Bundes liegen als INTERLIS-Transferdatei im Rahmenmodell vor.
Ein kantonales Thema wird in einer Fachanwendung bewirtschaftet, welche die Daten im INTERLIS-Rahmenmodell bereitstellt.
Die Daten der amtlichen Vermessung liegen als INTERLIS-Transferdatei vor.
Seit Rahmenmodell V2.0 gibt es ein Konfigurations-Teilmodell, welches z.B. die Logos und die statischen Texte beinhaltet oder die Verfügbarkeit der Gemeinden steuern kann.
Es gibt ein elaboriertes Toolset für das Arbeiten mit INTERLIS-Datenmodellen und -Transferfiles: ili2pg und ilivalidator

Für uns war bei der Lösungsfindung wichtig, dass sowohl die Realisierung als auch der Betrieb des ÖREB-Katasters möglichst einfach, transparent und effizient verläuft. Zusammen mit den vorhandenen Rahmenbedingungen ergab sich (vereinfacht) folgende Architektur:

Erläuterung:

Es gibt eine ÖREB-Datenbank mit einem Schema, welches sämtliche Daten (Geobasisdaten, amtliche Vermessung, Konfiguration, …) beinhaltet. Der Import resp. das Ersetzen der Daten wird mit ili2pg durchgeführt. Die Daten werden vor dem Import mit ilivalidator geprüft.
Es braucht einen Webdienst, der den DATA-Extract (aka XML) und den statischen Auszug (das PDF) herstellt. Dieser Dienst muss bloss mit einer Datenbank (der ÖREB-Datenbank) im Sinne einer «Cookie-Cutter»-Abfrage kommunizieren. Das Resultat dieser Abfrage muss nach XML umformatiert werden und das XML muss zu einem PDF gemacht werden. Mehr muss diese Anwendung nicht können.
Sämtliche Geobasisdaten müssen im ÖREB-Rahmenmodell vorliegen, damit sie mit den vorhandenen Werkzeugen in die ÖREB-Datenbank importiert und bei einer Nachführung ersetzt werden können. Konsequenz: Einige kantonale Themen müssen vom kantonalen Erfassungsmodell in das ÖREB-Rahmenmodell umgebaut werden. Auch für diesen Schritt können wir auf bewährte Methoden und Werkzeuge zurückgreifen (Stichwort SQL und ili2pg).
Konfigurationen (Logos, Themen, Texte, …) und gesetzliche Grundlagen des Bundes und des Kantons müssen ebenfalls im dafür vorgesehenen Teilmodell vorliegen.
In der Übersicht fehlt bewusst der dynamische Auszug.

Die Idee war/ist alles was mit Daten und Datenimport/-export zu tun hat mit INTERLIS und den bekannten INTERLIS-Werkzeugen zu machen, also die Reduzierung auf eine einzelne Schnittstelle. Auch weil hier bereits alles vorhanden ist.

Diese Architektur liefert uns die Basis für eine grösstmögliche Transparenz (z.B. beim Protokollieren von neuen Publikationen in den Kataster) und eine sehr gute Qualitätskontrolle inkl. sauberer Schnitte zwecks Zuweisung der Verantwortlichkeiten. So ist das System auch praktisch unabhängig vom Ort, wo es installiert ist, da es keine Laufzeitabhängigkeiten zu bestehenden GDI-Komponenten hat (z.B. Erfassungsdatenbank).

Im zweiten Teil gehe ich vertieft auf die Herstellung und Organisation der ÖREB-Datenbank ein und stelle ein Docker-Image inkl. Import-Skripte zur Verfügung.

INTERLIS leicht gemacht #27 - ilivalidator/ili2db JVM-Benchmarking

Sun, 28 Nov 2021 00:00:00 +0000

Java und die JVM entwickeln sich. Momentan sind wir bei Version 17 angelangt. Zeit zu schauen, ob sich die Entwicklung auch auf die Geschwindigkeit von ilivalidator und ili2db niederschlägt.

Testumgebung

Weil ich neben unterschiedlichen Versionen der «normalen» JVM auch die GraalVM testen will, kann ich nicht die Benchmarks nicht direkt auf macOS mit einem Apple Silicon Prozessor ausführen, sondern ich verwende Multipass, um die Benchmarks in einer Ubuntu-ARM-VM laufen zu lassen. Das Gute an Multipass ist, dass es einfach ist und im Gegensatz zu z.B. VirtualBox auch auf einem Apple Silicon Rechner läuft. Zudem ist für den ili2db-Benchmark eine PostgreSQL-Datenbank notwendig. Weil unter macOS der I/O mit Docker sehr schlecht ist und damit garantiert der limitierende Faktor des Benchmarks sein würde, kommt mir das Ausweichen auf Linux gerade recht.

Die Benchmarks selber sind sehr einfach gehalten. Es sind sowas wie «Java-Skripte». Nämlich eine Java-Klasse, die mit jbang ausgeführt wird.

Den Code gibt es hier: https://github.com/edigonzales/ilivalidator-java-perf-test

Benchmark

Ubuntu 20.04
4 CPUS / 8 GB
JVM mit -Xmx2048m
ilivalidator 1.11.11
ili2pg 4.6.1

Es wurde die amtliche Vermessung (ITF) sämtlicher 107 Solothurner Gemeinden, alle vorhandenen Nutzungsplanungsdaten (53 Gemeinden, XTF) und das MOpublic des gesamten Kantons als einzelne XTF-Datei geprüft. Für das Benchmarking von ili2pg wurde nur die amtliche Vermessung sämtlicher Gemeinden und das MOpublic verwendet. Die 53 Gemeinden der Nutzungsplanung waren mengenmässig schlichtweg zu wenig representativ, d.h. der Import (jeweils ohne Validierung) ging zu schnell.

Insbesondere wurden mit Java 17 jeweils zwei unterschiedliche Garbage Collectors getestet. Der seit Java 9 standardmässig verwendete Garbage First Garbage Collector (G1GC) und der Throughput Collector (ParallelGC). Letzterer war in Java 8 der Standard-GC und noch immer verfügbar in neueren Java-Versionen.

Es wurden jeweils drei Durchläufe gemacht und die Zeit gemittelt.

Resultate

Für ilivalidator ergeben sich folgende Resultate:

Table 1. Amtliche Vermessung (107 Gemeinden) - INTERLIS 1
Java Version	Avg. Time (mins:secs)
Java 8 (temurin)	10:21
Java 17 (temurin + G1GC)	10:06
Java 17 (temurin + ParallelGC)	9:39
Java 17 (graalvm + G1GC)	11:25
Java 17 (graalvm + ParallelGC)	11:07

Table 2. Nutzungsplanung Kanton SO (53 files) - INTERLIS 2
Java Version	Avg. Time (mins:secs)
Java 8 (temurin)	8:02
Java 17 (temurin + G1GC)	7:44
Java 17 (temurin + ParallelGC)	7:12
Java 17 (graalvm + G1GC)	7:39
Java 17 (graalvm + ParallelGC)	7:08

Table 3. MOpublic Kanton Solothurn (1 file, 2.4 GB) - INTERLIS 2
Java Version	Avg. Time (mins:secs)
Java 8 (temurin)	7:47
Java 17 (temurin + G1GC)	7:59
Java 17 (temurin + ParallelGC)	7:22
Java 17 (graalvm + G1GC)	8:03
Java 17 (graalvm + ParallelGC)	7:21

Für ili2pg ergeben sich folgende Resultate:

Table 4. Amtliche Vermessung (107 Gemeinden) - INTERLIS 1
Java Version	Avg. Time (mins:secs)
Java 8 (temurin)	25:45
Java 17 (temurin + G1GC)	25:12
Java 17 (temurin + ParallelGC)	24:53
Java 17 (graalvm + G1GC)	25:37
Java 17 (graalvm + ParallelGC)	25:00

Table 5. MOpublic Kanton Solothurn (1 file, 2.4 GB) - INTERLIS 2
Java Version	Avg. Time (mins:secs)
Java 8 (temurin)	12:26
Java 17 (temurin + G1GC)	12:36
Java 17 (temurin + ParallelGC)	11:48
Java 17 (graalvm + G1GC)	12:37
Java 17 (graalvm + ParallelGC)	11:47

Fazit

Java 17 mit ParallelGC ist die schnellste Variante.
GraalVM bringt für diesen Anwendungsfalls nichts resp. ist eventuell sogar kontraproduktiv.
ili2db-Benchmarks sind nicht sehr aussagekräftig, da wohl sehr viel vom Lesen/Schreiben von/in die Datenbank abhängig ist.

Interessant ist ein Vergleich mit meinem 2016er-MacBookPro. Die Validierung der amtlichen Vermessung aller 107 Gemeinden dauerte circa 25 Minuten. Also 2.5 Mal so lange wie mit dem MacBook Air mit Apple Silicon, das lüfterlos knapp handwarm wird.

Für die Praxis fast noch interessanter ist der Vergleich mit geodienste.ch. Dort dauert die Validierung der amtlichen Vermessung circa eine Stunde. Ich muss noch abklären, ob das gleiche gemacht wird. Aber falls ja, müssten sie sich besser ein paar Mac minis ins Rechenzentrum schieben…

INTERLIS leicht gemacht #26 - Runtime Parameter

Mon, 1 Nov 2021 00:00:00 +0000

Wer kennt sie nicht? Die INTERLIS-Laufzeitparameter (siehe Referenzhandbuch Kapitel 2.11). Also zum Beispiel ich. Jedenfalls waren sie mir lange nicht bekannt. Sie sind jedoch die Lösung für eine bekannte Herausforderung: Die Nachführungsgeometer schicken die Geschäfte via AVGBS ans Grundbuch. Der Name der Transferdatei muss dabei gewisse Konventionen erfüllen. Ganz einfach formuliert, muss der Name der Datei einem Attributwert innerhalb der Datei entsprechen. In Tat und Wahrheit ist es leicht komplexer aber es geht ums grundlegende Prinzip. Wie kann ilivalidator nun prüfen, ob der Namen der zu prüfenden Datei einem Werte eines Attributes der zu prüfenden Daten selbst entspricht? Runtime Parameter to the rescue!

So wie ich das Referenzhandbuch verstehe, ist die Verfügbarkeit von Laufzeitparametern vom System abhängig:

«Nebst den eigentlichen Daten und den Metadaten können auch einzelne Datenelemente definiert werden, bei denen erwartet wird, dass sie von einem Bearbeitungs-, Auswerte- oder Darstellungssystem zur Laufzeit bereitgestellt werden. Sie heissen Laufzeitparameter.»

Unser Auswertesystem ilivalidator kennt zum jetzigen Zeitpunkt folgende Laufzeitparameter:

RuntimeSystemName: Name der Software, z.B. «ilivalidator» (ilivalidator)
RuntimeSystemVersion: Version der Software, z.B. «1.11.11» (ilivalidator)
OperatingSystemName: Betriebssystem, z.B. «Mac OS X» (ili2c)
HostName: Name des Hosts, z.B. «localhost» (ili2c)
CurrentUserName: Name des Users, der den Prozess startet, z.B. «stefan» (ili2c)
CurrentDateTime: Zeitpunkt des Prozesstarts, z.B. «2017-08-22T15:00:00.000» (ili2c)
CurrentTransferfile: Name der zu prüfenden Datei, z.B. «SO0200002403_1180.xml» (ilivalidator)

Machen wir ein Beispiel anhand eines sehr einfachen Modelles:

INTERLIS 2.3;
MODEL Testmodel
  AT "mailto:stefan.ziegler@bd.so.ch" VERSION "2019-01-27" =

  IMPORTS MinimalRuntimeSystem01;

    TOPIC Topic =

        CLASS ClassA =
            attr2 : TEXT;
            MANDATORY CONSTRAINT attr2==PARAMETER MinimalRuntimeSystem01.CurrentTransferfile;
        END ClassA;

    END Topic;

END Testmodel.

Das Modell muss das MinimalRuntimeSystem01-Datenmodell importieren. Dieses ist Stand heute noch in keiner Modellablage vorhanden, muss also lokal vorliegen. Die Klasse hat genau ein Attribut attr2 und einen MANDATORY CONSTRAINT, der die gewünschte Prüfung übernimmt.

Der Inhalt der Datei SO0200002403_1180.xtf sieht wie folgt aus:

<?xml version="1.0" encoding="UTF-8"?>
<TRANSFER xmlns="http://www.interlis.ch/INTERLIS2.3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <HEADERSECTION SENDER="sogis" VERSION="2.3">
  </HEADERSECTION>
  <DATASECTION>
    <Testmodel.Topic BID="b1">
      <Testmodel.Topic.ClassA TID="o1">
        <attr2>SO0200002403_1180.xtf</attr2>
      </Testmodel.Topic.ClassA>
    </Testmodel.Topic>
  </DATASECTION>
</TRANSFER>

Ich kann ilivalidator wie gewohnt starten und erhalte das Resultat der Prüfung.

java -jar ilivalidator-1.11.11.jar SO0200002403_1180.xtf

Ändere ich entweder den Namen der Datei oder den Wert des Attributes attr2, erscheint eine Fehlermeldung:

Error: line 7: Testmodel.Topic.ClassA: tid o1: Mandatory Constraint Testmodel.Topic.ClassA.Constraint1 is not true.

Die Fehlermeldung kann man mit einem Metaattribut gehaltvoller machen:

!!@ ilivalid.msg = "attr2 = {attr2} entspricht Dateinamen."
MANDATORY CONSTRAINT attr2==PARAMETER MinimalRuntimeSystem01.CurrentTransferfile;

Ilivalidator kennt noch eine weitere Syntax für die Verwendung der Laufzeitparameter in Constraints:

MANDATORY CONSTRAINT attr2==MinimalRuntimeSystem01.getParameterValue("MinimalRuntimeSystem01.CurrentTransferfile");

Muss man für die Validierung eine eigene InterlisFunction implementieren und benötigt Laufzeitparameter, können diese via TransferDescription ausgelesen werden. Die benötigen Methoden sind getActualRuntimeParameters() resp. getActualRuntimeParameter(…). In Unit-Tests muss z.B. der CurrentTransferfile-Parameter explizit selber gesetzt werden, weil es ja keine Datei gibt, die geprüft wird, sondern nur Objekte:

Iom_jObject iomObjA = new Iom_jObject(ILI_CLASSA, OBJ_OID1);
iomObjA.setattrvalue("attr2", "SO0200002601_3396.xml");
ValidationConfig modelConfig = new ValidationConfig();
modelConfig.mergeIliMetaAttrs(td);
LogCollector logger = new LogCollector();
LogEventFactory errFactory = new LogEventFactory();
Settings settings = new Settings();
Map<String,Class> newFunctions = new HashMap<String,Class>();
newFunctions.put("SO_FunctionsExt.RuntimeDummy", RuntimeDummyIoxPlugin.class);
settings.setTransientObject(Validator.CONFIG_CUSTOM_FUNCTIONS, newFunctions);
td.setActualRuntimeParameter(ch.interlis.ili2c.metamodel.RuntimeParameters.MINIMAL_RUNTIME_SYSTEM01_CURRENT_TRANSFERFILE, "SO0200002601_3396.xml");
Validator validator=new Validator(td, modelConfig, logger, errFactory, new PipelinePool(), settings);
validator.validate(new StartTransferEvent());
validator.validate(new StartBasketEvent(ILI_TOPIC,BID1));
validator.validate(new ObjectEvent(iomObjA));
validator.validate(new EndBasketEvent());
validator.validate(new EndTransferEvent());

INTERLIS leicht gemacht #25 - Geschützte Attribute

Mon, 25 Oct 2021 00:00:00 +0000

Im Kanton Solothurn können Geodaten seit circa 15 Jahren frei bezogen und genutzt werden. Es gibt jedoch einige sensible Informationen, die man nicht jedermann zugänglich machen kann. Oftmals sind es personenbezogene Daten wie z.B. eine Telefonnummer des Imkers. Wie gehen wir damit um?

Für die Publikation der Daten als WMS-Layer (resp. als Kartenlayer im Web GIS Client) lösen wir es applikatorisch. D.h. der Layer wird zweimal als WMS-Layer publiziert. Einmal als öffentlicher Layer ohne die nicht-öffentlichen Attribute und einmal als passwortgeschützter Layer mit den nicht-öffentlichen Attributen. Eine weitere Variante ist das Erstellen einer View in der Datenbank, die nur die öffentlichen Attribute enthält. Diese View wird anschliessend als WMS-Layer publiziert. Für diese Variante wäre eine bessere Unterstützung von Views in ili2db wünschenswert.

Wie gehen wir aber mit der Abgabe von Rohdaten vor? Wie können wir verhindern, dass die nicht-öffentlichen Attribute ebenfalls ohne Authentifizierung und Authorisierung bezogen werden können? Um die Lösungsvarianten besser zu verstehen, muss man sich unsere Rahmenbedingungen vor Augen führen: Daten werden in einem normalisierten INTERLIS-Datenmodell in der Edit-Datenbank erfasst und nachgeführt. Mit SQL bauen wir die Daten in ein sehr einfaches, d.h. denormalisiertes INTERLIS-Datenmodell ohne Assoziationen um und speichern die Daten in der Publikationsdatenbank. Aus dieser Publikationsdatenbank bedient sich auch der WMS- und WFS-Dienst. Die Erfahrung zeigt, dass die meisten Datenbezüger die Daten nicht im Ursprungsmodell (d.h. in der normalisierten Form) haben wollen, sondern im Publikationsmodell. Die Daten werden also mit ili2pg in eine INTERLIS-Transferdatei exportiert und anschliessend mit ili2gpkg in eine GeoPackage-Datei umgewandelt. Daraus erstellen wir Shapefiles und DXF-Dateien.

Eine erste Idee war die nicht-öffentlichen Attribute im Publikationsdatenmodell mit einem Metaattribut zu versehen. Ili2pg hätte dann dahingehend erweitert werden müssen, dass Attribute mit diesem Metaattribut nicht exportiert werden. Das führt jedoch zum Problem, dass dieses Attribut nie ein Pflichtattribut sein darf. Da sonst die Daten nicht mehr zwingend modellkonform sind. Ein weiterer Nachteil ist, dass man als Empfänger anhand der Daten (resp. des Datenmodelles) nicht mehr erkennt, ob man nun den öffentlichen oder den nicht-öffentlichen Datensatz vor sich liegen hat.

Die zweite Idee war das Maskieren von Attributwerten: Ein Text-Attribut wird z.B. mit «XXXXXXXXX» maskiert. Was macht man aber mit anderen Datentypen? Für Zahlenwerte schreibt man «99999»? Oder für ein Datum «9999-12-31»? Da wird es ziemlich gruselig. Auch für diese Variante müsste man ili2pg anpassen.

Die dritte und bisher beste Variante ist ohne Anpassung von ili2pg bereits heute möglich: zwei Datenmodelle. Das Basismodell beinhaltet sämtliche öffentlichen Attribute. Das spezialisierte Modell erweitert die Klassen des Basismodelles um die nicht öffentlichen Attribute. Als Beispiel verwenden wir die Bienenstandorte. Neben einigen öffentlichen Attributen gibt es zwei nicht-öffentliche Atribute: den Namen und die Telefonnummer des Imkers. Das Modell sieht so aus:

INTERLIS 2.3;

MODEL SO_ALW_Bienenstandorte_20211020 (de)
AT "mailto:stefan@localhost"
VERSION "2021-10-20"  =
  IMPORTS GeometryCHLV95_V1;

  TOPIC Bienenstandorte =
    OID AS INTERLIS.UUIDOID;

    CLASS Bienenstandort =
      Nummer : MANDATORY TEXT*16;
      Standort : MANDATORY GeometryCHLV95_V1.Coord2;
      Bemerkung : TEXT*200;
    END Bienenstandort;

  END Bienenstandorte;

END SO_ALW_Bienenstandorte_20211020.

MODEL SO_ALW_Bienenstandorte_restricted_20211020 (de)
AT "mailto:stefan@localhost"
VERSION "2021-10-20"  =
  IMPORTS SO_ALW_Bienenstandorte_20211020;

  TOPIC Bienenstandorte
  EXTENDS SO_ALW_Bienenstandorte_20211020.Bienenstandorte =

    CLASS Bienenstandort (EXTENDED) =
      Name : MANDATORY TEXT*255;
      Telefonnummer : TEXT*20;
    END Bienenstandort;

  END Bienenstandorte;

END SO_ALW_Bienenstandorte_restricted_20211020.

Die Klasse Bienenstandort wird mit zwei Attributen erweitert. Das zusätzliche Attribut Name ist ein Pflichtattribut.

Mit folgendem ili2pg-Befehl werden die leeren Tabellen angelegt:

java -jar /Users/stefan/apps/ili2pg-4.6.0/ili2pg-4.&.0.jar \
--dbhost localhost --dbport 54322 --dbdatabase pub --dbusr ddluser --dbpwd ddluser \
--dbschema alw_bienenstandorte_pub --models SO_ALW_Bienenstandorte_restricted_20211020 \
--defaultSrsCode 2056 --createGeomIdx --createFk --createFkIdx --createUnique \
--createMetaInfo --createNumChecks --nameByTopic --strokeArcs \
--createBasketCol \
--modeldir ".;http://models.geo.admin.ch" \
--schemaimport

Es muss das "restricted"-Modell verwendet werden und man muss zwingend --createBasketCol verwenden. Aufgrund der bewussten Einfachheit des Modelles und der Abbildungsregeln von ili2pg wird nur eine einzige (Daten-)Tabelle in der Datenbank erzeugt:

Zusätzlich zu den erwartenden Attributen wird ein t_type-Attribut angelegt. Dieses Attribut speichert die Information zu welcher Klasse ein Record gehört. Wir gehen davon aus, dass immer alle Records Bestandteil beider Datenmodelle sind und wir nur Attribute filtern wollen (und keine Zeilen). In diesem Fall entspricht der Wert von t_type immer dem SQL-Namen der "restricted"-Klasse: so_lw_b0211020bienenstandorte_bienenstandort (siehe Tabelle t_ili2db_classename).

Bevor jedoch Daten in der Tabelle gespeichert werden können, muss ein Basket in der Tabelle t_ili2db_basket erstellt werden:

WITH topics AS
(
    SELECT DISTINCT
        split_part(iliname, '.', 1) || '.' || split_part(iliname, '.', 2) AS topicname
    FROM
        alw_bienenstandorte_pub.t_ili2db_classname
    WHERE
        iliname ILIKE '%restricted%'
)
INSERT INTO
    alw_bienenstandorte_pub.t_ili2db_basket
    (
        t_id,
        topic,
        attachmentkey
    )
SELECT
    nextval('alw_bienenstandorte_pub.t_ili2db_seq'),
    topics.topicname,
    'foo'
FROM
    topics
;

Das Topic muss das "restricted"-Topic sein. Ich erstelle zwei Records, je einer mit nur öffentlichen Attributen und einer mit zusätzlichen, nicht-öffentlichen Attributen. Spannend wird der Export der Daten. Als erstes will ich sämtliche Daten exportieren (also auch die nicht-öffentlichen Attribute);

java -jar /Users/stefan/apps/ili2pg-4.5.0/ili2pg-4.5.0.jar \
--dbhost localhost --dbport 54322 --dbdatabase pub --dbusr ddluser --dbpwd ddluser \
--dbschema alw_bienenstandorte_pub --models SO_ALW_Bienenstandorte_restricted_20211020 \
--modeldir ".;http://models.geo.admin.ch" \
--disableValidation \
--export restricted.xtf

Das erzeugt mir eine XTF-Datei mit meinen zwei Objekten:

<?xml version="1.0" encoding="UTF-8"?>
<TRANSFER xmlns="http://www.interlis.ch/INTERLIS2.3">
  <HEADERSECTION SENDER="ili2pg-4.5.0-fc023c8d2d8cd44d792927e45dc80c1ad973f095" VERSION="2.3">
    <MODELS>
      <MODEL NAME="Units" VERSION="2012-02-20" URI="http://www.interlis.ch/models"/>
      <MODEL NAME="CoordSys" VERSION="2015-11-24" URI="http://www.interlis.ch/models"/>
      <MODEL NAME="GeometryCHLV03_V1" VERSION="2017-12-04" URI="http://www.geo.admin.ch"/>
      <MODEL NAME="GeometryCHLV95_V1" VERSION="2017-12-04" URI="http://www.geo.admin.ch"/>
      <MODEL NAME="SO_ALW_Bienenstandorte_20211020" VERSION="2021-10-20" URI="mailto:stefan@localhost"/>
      <MODEL NAME="SO_ALW_Bienenstandorte_restricted_20211020" VERSION="2021-10-20" URI="mailto:stefan@localhost"/>
    </MODELS>
  </HEADERSECTION>
  <DATASECTION>
    <SO_ALW_Bienenstandorte_restricted_20211020.Bienenstandorte BID="1">
      <SO_ALW_Bienenstandorte_restricted_20211020.Bienenstandorte.Bienenstandort TID="ce04e93c-bcaa-45ca-871c-1cc1a8f2c683">
        <Nummer>1234</Nummer>
        <Standort>
          <COORD>
            <C1>2600000.000</C1>
            <C2>1200000.000</C2>
          </COORD>
        </Standort>
        <Bemerkung>foo</Bemerkung>
        <Name>Lisa Liegenschaft</Name>
        <Telefonnummer>555-1234</Telefonnummer>
      </SO_ALW_Bienenstandorte_restricted_20211020.Bienenstandorte.Bienenstandort>
      <SO_ALW_Bienenstandorte_restricted_20211020.Bienenstandorte.Bienenstandort TID="e10f19fa-b60d-4c78-833f-4b3b3bd4890c">
        <Nummer>4321</Nummer>
        <Standort>
          <COORD>
            <C1>2600010.000</C1>
            <C2>1200010.000</C2>
          </COORD>
        </Standort>
        <Bemerkung>bar</Bemerkung>
      </SO_ALW_Bienenstandorte_restricted_20211020.Bienenstandorte.Bienenstandort>
    </SO_ALW_Bienenstandorte_restricted_20211020.Bienenstandorte>
  </DATASECTION>
</TRANSFER>

Wenn ich die Daten mit ilivalidator prüfe, erhalte ich einen Fehler: Attribute Name requires a value. Was absolut korrekt ist. Obwohl Name ein zwingendes Attribut ist, konnte ich einen Record in der Datenbank speichern, der diese Information nicht enthält. Das muss so sein, weil es für beide Klassen nur eine Tabelle gibt. Die Tabelle muss also auch fähig sein Records vom Basis-Klassen-Typ zu speichern. Aus diesem Grund muss das Attribut Name nullable sein. Für unseren Usecase ist das kein Problem, da es sich «nur» um die Publikationsmodelle und -daten handelt. Die originäre Nachführung der Daten geschieht in den Erfassungsmodellen. Notfalls kann man die Daten bereits in der Datenbank mit ili2pg und dem Modus --validate prüfen.

Spannender ist der Befehl zum Exportieren der Daten im öffentlichen Datenmodell:

java -jar /Users/stefan/apps/ili2pg-4.5.0/ili2pg-4.5.0.jar \
--dbhost localhost --dbport 54322 --dbdatabase pub --dbusr ddluser --dbpwd ddluser \
--dbschema alw_bienenstandorte_pub --models SO_ALW_Bienenstandorte_restricted_20211020 \
--exportModels SO_ALW_Bienenstandorte_20211020 \
--modeldir ".;http://models.geo.admin.ch" \
--disableValidation \
--export public.xtf

Der Befehl ist bis auf die Option --exportModels identisch. Die Option bestimmt gemäss welchem Modell die Daten exportiert werden. Das Resultat sieht wie gewünscht aus:

<?xml version="1.0" encoding="UTF-8"?>
<TRANSFER xmlns="http://www.interlis.ch/INTERLIS2.3">
  <HEADERSECTION SENDER="ili2pg-4.5.0-fc023c8d2d8cd44d792927e45dc80c1ad973f095" VERSION="2.3">
    <MODELS>
      <MODEL NAME="SO_ALW_Bienenstandorte_20211020" VERSION="2021-10-20" URI="mailto:stefan@localhost"/>
    </MODELS>
  </HEADERSECTION>
  <DATASECTION>
    <SO_ALW_Bienenstandorte_20211020.Bienenstandorte BID="1">
      <SO_ALW_Bienenstandorte_20211020.Bienenstandorte.Bienenstandort TID="ce04e93c-bcaa-45ca-871c-1cc1a8f2c683">
        <Nummer>1234</Nummer>
        <Standort>
          <COORD>
            <C1>2600000.000</C1>
            <C2>1200000.000</C2>
          </COORD>
        </Standort>
        <Bemerkung>foo</Bemerkung>
      </SO_ALW_Bienenstandorte_20211020.Bienenstandorte.Bienenstandort>
      <SO_ALW_Bienenstandorte_20211020.Bienenstandorte.Bienenstandort TID="e10f19fa-b60d-4c78-833f-4b3b3bd4890c">
        <Nummer>4321</Nummer>
        <Standort>
          <COORD>
            <C1>2600010.000</C1>
            <C2>1200010.000</C2>
          </COORD>
        </Standort>
        <Bemerkung>bar</Bemerkung>
      </SO_ALW_Bienenstandorte_20211020.Bienenstandorte.Bienenstandort>
    </SO_ALW_Bienenstandorte_20211020.Bienenstandorte>
  </DATASECTION>
</TRANSFER>

INTERLIS leicht gemacht #24 - Ilivalidator in/mit QGIS

Tue, 12 Oct 2021 00:00:00 +0000

Wer kennt es nicht? Daten in QGIS nachgeführt, mit ili2pg exportiert und ilivalidator meldet Fehler:

Error: SO_AWJF_Foerderprogramm_Biodiversitaet_Publikation_20200519.Biotopflaechen.Biotopflaeche.Geometrie: Intersection coord1 (2610894.968, 1249766.404), tids 4b76926f-cef2-4b9e-8750-f3aef21385eb, 4b76926f-cef2-4b9e-8750-f3aef21385eb
Error: line 22: SO_AWJF_Foerderprogramm_Biodiversitaet_Publikation_20200519.Biotopflaechen.Biotopflaeche: tid dc58062e-4251-433b-b124-835356dc873e: duplicate coord at (2621389.108, 1244991.863, NaN)
Error: SO_AWJF_Foerderprogramm_Biodiversitaet_Publikation_20200519.Biotopflaechen.Biotopflaeche.Geometrie: Overlay coord1 (2617574.166, 1240369.683), coord2 (2617621.209, 1240261.671), tids 8ed21983-6692-4f99-b306-f084a364440f, 8ed21983-6692-4f99-b306-f084a364440f
Error: line 36: SO_AWJF_Foerderprogramm_Biodiversitaet_Publikation_20200519.Biotopflaechen.Biotopflaeche: tid 01857f02-9fca-4e18-83af-f97de8744ecd: duplicate coord at (2635087.966, 1247870.588, NaN)

Entweder wieder doppelte Vertexpunkte (duplicate coords) oder minimalste Überlappungen (Intersection, Overlay) werden schonungslos aufgedeckt. Es gibt in QGIS verschiedene Mittel, damit diese Fehler schon gar nicht gemacht werden können und auch Werkzeuge, die solche Fehler nachträglich aufdecken. Warum aber nicht den Prüfalgorithmus von ilivalidator näher zu QGIS bringen? Damit ist sichergestellt, dass die Geometrien nach einem Export auch tatsächlich valide INTERLIS-Geometrien sind.

Aber wie soll das gehen? Ilivalidator ist in Java geschrieben und QGIS will entweder C++ oder Python. Des Rätsels Lösung habe ich hier (im unteren Teil) beschrieben. Ich will für diese zusätzliche Geometrieprüfung in QGIS keine Java-Runtime installiert haben, sondern im Idealfall maximal nur ein Python-Plugin herunterladen und gut ist. Mit GraalVM können einzelne Java-Methoden zu shared libraries (*.so, *.dylib, *.dll) kompiliert werden. Diese wiederum können relativ einfach in Python verwendet werden.

Die Java-Methode, welche Geometrien nach INTERLIS-Spezifikation validiert, gibt es hier in einem Github-Repo. Es ist im Prinzip sehr viel Copy/Paste aus der iox-ili-Bibliothek, welche die eigentliche INTERLIS-Validierung für ilivalidator durchführt. Copy/Paste darum, weil die Geometrievalidierungs-Methoden nicht zum öffentlichen API gehören und auch weil für den vorliegenden Anwendungsfall Informationen fehlen, welche die Originalmethoden benötigen, z.B. den Wert für erlaubte Overlaps. Dieser steckt im Datenmodell, welches mir beim Datenerfassen in QGIS nicht zur Verfügung steht. Auch fehlt mir die Auflösung der Geometrien. In der Regel ist das bei uns ein Millimeter. Darum werden diese Werte resp. daraus abgeleitet Werte in meiner Copy/Paste-Methode hardcodiert.

Ein grosser Teil der Magie der Geometrievalidierung von z.B. Flächengeometrien (im Sinne der Surfacetopologie) steckt in der Methode validatePolygon (ff.) der Klasse ItfSurfaceLinetable2Polygon.

Unter Linux lässt sich die Copy/Paste-Java-Methode dann wie folgt zu einer shared library kompilieren:

./gradlew clean lib:build shadowJar && \
native-image --no-fallback --no-server -cp lib/build/libs/lib-all.jar --shared -H:Name=libgeomvalidator

Unter Ubuntu 20.04 musste ich noch ein paar Pakete installieren:

sudo apt-get install build-essential
sudo apt install libstdc++-8-dev
sudo apt-get install zlib1g-dev

Wobei das letzte Paket nur unter Ubuntu 20.04 auf einem Apple Silicon Rechner (also einem ARM-Prozessor) notwendig war. Ubuntu (die ARM-Variante) läuft hier als virtuelle Maschine in UTM inkl. QGIS ganz passabel.

Der native-image-Befehl erzeugt aus der Jar-Datei die verschiedenen Header-Dateien und die shared library (*.so-Datei). Mit einem Dummy-C-Programm prüfe ich, ob das ganze auch funktioniert:

#include <stdlib.h>
#include <stdio.h>

#include <libgeomvalidator.h>

int main(int argc, char **argv) {
    graal_isolate_t *isolate = NULL;
    graal_isolatethread_t *thread = NULL;

    if (graal_create_isolate(NULL, &isolate, &thread) != 0) {
        fprintf(stderr, "graal_create_isolate error\n");
        return 1;
    }

    char * layername = "my_layer_name";
    char * fid = "afid";
    char * wktGeom = "POLYGON ((2609000 1236700, 2609200 1236700, 2609200 1236700, 2609200 1236600, 2609000 1236600, 2609000 1236700))";
    printf("%d\n", geomvalidator(thread, layername, fid, wktGeom));

    if (graal_detach_thread(thread) != 0) {
        fprintf(stderr, "graal_detach_thread error\n");
        return 1;
    }

    return 0;
}

Als Parameter werden neben der Geometrie (im WKT-Format), der Layername und eine Feature-Id der Methode übergeben. Dies entspricht beinahe der Signatur der Originalmethode von ilivalidator: Die Feature-Id entspricht der TID, der Layername dem qualifizierten Attributnamen. Was in diesem Kontext nicht unerwähnt bleiben darf, ist die Tatsache, dass als Übergabe- und Rückgabeparameter nur Nicht-Objekttypen verwendet werden können. Abhilfe schafft oftmals die Serialisierung in ein geeignetes Format (z.B. JSON).

Das C-Programm lässt sich kompilieren und ausführen:

cc  geomvalidator.c -I. -L. -lgeomvalidator -o geomvalidator
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH && ./geomvalidator

Output in der Konsole entspricht dem zu erwarteten Ergebnis (siehe WKT-String im C-Programm):

duplicate coord at (2609200.0, 1236700.0, NaN)

Nun können wir einen Schritt weitergehen und versuchen sämtliche Geometrien eines Layers in QGIS mit dem ilivalidator-Algorithmus zu prüfen. Dazu schreiben wir kein Plugin, sondern als Proof-of-Concept reicht die Python-Konsole:

Das Skript validate_data.py, welches die Validierung macht, ist relativ simpel:

from ctypes import *
dll = CDLL("/home/stefan/sources/geomvalidator-libnative/libgeomvalidator.so")
isolate = c_void_p()
isolatethread = c_void_p()
dll.graal_create_isolate(None, byref(isolate), byref(isolatethread))
dll.geomvalidator.restype = int

layer = QgsVectorLayer("/home/stefan/sources/geomvalidator-libnative/data/ch.so.awjf.foerderprogramm_biodiversitaet.gpkg|layername=biotopflaechen_biotopflaeche", "biotopflaechen_biotopflaeche", "ogr")
if not layer.isValid():
    print ("failed to load layer")

for f in layer.getFeatures():
    result = dll.geomvalidator(isolatethread, c_char_p(bytes("biotopflaechen_biotopflaeche", "utf8")), c_char_p(bytes(str(f.id()), "utf8")), c_char_p(bytes(f.geometry().asWkt(), "utf8")))

Die Zeilen 1 bis 6 dienen dazu die shared library als Python-Binding verfügbar zu machen. Es gibt dazu verschiedene Varianten. Ich habe mich für die ctypes-Variante entschieden. Ist zwar ziemlich low-level, aber von Vorteil ist für mich vor allem, dass bereits alles in einer Python-Standard-Installation dabei ist.

Zeile 8 importiert die Tabelle einer Geopackage-Datei als QGIS-Vektorlayer. Die Validierung der Geometrien geschieht in der Schleife über sämtliche Geometrien des Layers in den Zeilen 12 - 13. Das erstmalige Ausführen war ernüchternd: Nichts passierte. Aber die Post ging nicht in der Python-Konsole in QGIS ab, sondern im Terminal aus dem QGIS gestartet wurde:

Die shared library loggt nach stderr. Trotzdem hätte ich eigentlich erwartet, dass man den Output in der Python-Konsole sieht. Aber wahrscheinlich ist das Verhalten logisch und ich verstehe es nur nicht. Vergleicht man den Output der Prüfung des QGIS-Layers mittels shared library mit dem ilivalidator-Logfile, kann man mit sich und der Welt zufrieden sein:

Das Ganze ist natürlich bloss eine Spielerei aber zeigt es doch die Fähigkeiten und Möglichkeiten von GraalVM und dass Java sehr flexibel eingesetzt werden kann.

INTERLIS leicht gemacht #23 - Paketierte ilitools

Wed, 21 Jul 2021 00:00:00 +0000

Etwas nervte mich seit langem an INTERLIS-UML-Editor auf macOS: Eine Java-Anwendung kann man nicht einfach ins Dock ziehen und gut ist.

Früher gab es für JavaFX das Tool javapackager, das JavaFX-Anwendungen und alle anderen Java-Anwendungen betriebssystemabhängig zu einem Paket inkl. Java-Runtime schnürt. Dieses konnte dann wie jede andere Anwendung auf Linux, Windows oder macOS installiert werden. Praktisch war auch, dass man sich nicht um eine Java-Installation zu kümmern brauchte, weil die Runtime eben mitgeliefert wurde. Leider flog das Tool mit JavaFX aus dem JDK.

Ein paar Jahre (Java 16) später taucht es unter dem Namen jpackage in einer sehr ähnlichen Form wieder auf. Einige Features sind nicht mehr vorhanden, so z.B. JavaFX-spezifische Features. Das Wichtigste ist aber immer noch möglich: betriebssystemabhängige Installationspakete für Java-Anwendungen inkl. Runtime erstellen.

Im einfachsten Fall sieht ein Befehl so aus:

jpackage --icon icon-umleditor-128x128.icns --name umleditor --type dmg --input libs --main-jar umleditor-3.7.6.jar --app-version 3.7.6 -d output

--icon: Das Icon für die Anwendung. Dateiformat ist leider je nach Betriebssystem unterschiedlich.
--name: Name der Anwendung
--type: dmg und pkg für macOS, deb und rpm für Linux, exe und msi für Windows. «Cross-Herstellung» - also rpm-Pakete auf Windows herstellen, geht nicht.
--input: Das Verzeichnis mit den Jar-Dateien.
--main-jar: Die Jar-Datei mit der Main-Klasse
--app-version: Versionsnummer
-d: Das Verzeichnis, wo das Paket gespeichert wird.

Der Befehl liefert mir im Verzeichnis output die Datei ilivalidator-1.11.10.dmg. Diese .dmg-Datei kann ich jetzt wie gewohnt ausführen und die Anwendung installieren:

Mit ein wenig Zusatzeffort kann man das Ganze hinsichtlich der Grösse optimieren. Standardmässig wird einfach die gesamte Java-Runtime reinkopiert. Bei mir ergibt das eine 56MB grosse DMG-Datei. Man kann mit jlink selber eine Java-Runtime herstellen. Damit diese kleiner wird, muss man die von der Anwendung (also vom INTERLIS-UML-Editor) benötigten Module als Parameter angeben. Dieses Information liefert mir jdeps. Und hier wird es ein wenig hakelig, vor allem bei nicht-modularen Java-Anwendungen:

jdeps --class-path 'libs/*' --multi-release base -recursive --ignore-missing-deps --print-module-deps umleditor-3.7.6.jar

liefert mir: java.base,java.desktop,java.management,java.sql. Mit dieser Information erzeuge ich mit jlink meine spezifische Java-Runtime:

 jlink --add-modules java.base,java.desktop,java.management,java.sql --output umleditor-jre

Der jpackage-Befehl wird um den Parameter --runtime-image umleditor-jre erweitert. Das Paket ist nun nur noch 40MB gross.

Weil dank Geowerkstatt momentan richtig Schwung in der GUI-Programmierung von ilivalidator ist, habe ich für die Anwendungen ilivalidator, ili2gpkg, ili2c und INTERLIS-UML-Editor solche Pakete für Ubuntu, Windows und macOS erstellt: ilitools.sogeo.services.

Die Pakete werden mit einer Github Action erstellt. Dabei musste ich feststellen, dass die DMG-Dateien bei mir nicht funktionieren. Aus diesem Grund bin ich auf PKG umgeschwenkt. MacOS bemängelt natürlich immer noch, dass die Pakete nicht signiert sind. Dies wäre technich aber möglich. Die anderen beiden Varianten konnte ich mangels fehlendem Betriebssystem nicht testen.

Den beiden Anwendungen ilivalidator und ili2gpkg habe ich mit --java-option -Xmx2G zwei Gigabyte Heap zugewiesen. Es gäbe noch einige weitere spannende Optionen, die man ausprobieren könnte. So sind verschiedene Launcher möglich, was aber bei mir nicht wirklich funktioniert hat. Eventuell können diese Launcher dazu verwendet werden, die Anwendung mit einem GUI zu starten oder in der Konsole. Eine gute Übersicht mit Erläuterung der Möglichkeiten gibt es hier.

INTERLIS leicht gemacht #22 - Python goes INTERLIS / INTERLIS goes Python

Tue, 2 Feb 2021 00:00:00 +0000

Auf einem jungfräulichen Betriebssystem installiere ich als erstes Java. Eigentlich als zweites, denn um verschiedene Java-Versionen einfach installieren zu können, verwende ich SDKMAN!. Aber es gibt auch genauso die Liebhaber von Python. Insbesondere in der Geo-Welt scheint Python viele Anhänger zu haben.

Es geschehen ja noch Zeichen und Wunder und INTERLIS wird immer wie mehr verwendet. Eine INTERLIS-«Produktefamilie» - namentlich ili2db und ilivalidator ist mit Java geschrieben. Das wiederum passt nun nicht so ganz in die Geo-Welt, die lieber Python verwendet. Ebenso wenig matcht das mit QGIS-Plugins (insb. Model Baker), die mit INTERLIS umgehen wollen resp. müssen. Was tun? Es gibt verschiedene Möglichkeiten:

Jython ist eine Java-Implementierung von Python. Das bedeutet in erster Linie, dass eine JVM benötigt wird, um Python-Skripte auszuführen. Ansonsten kann aber «ganz normal» Python programmiert werden. Leider gibt es keine 3er-Version, sondern es wird nur Python 2.7 unterstützt. Die Unterstützung von bekannten Python-Bibliotheken und -Frameworks ist relativ gut. Das Interessante ist aus Sicht INTERLIS, dass auch beliebige Java-Klassen im Python-Code verwendet werden können, ohne dass System-Calls abgesetzt werden müssen. Wenn ich mit ili2gpkg Daten in eine GeoPackage-Datei importieren will, sieht das wie folgt aus:

#!/usr/bin/env jython
import sys

from ch.ehi.ili2db.base import Ili2db
from ch.ehi.ili2db.base import Ili2dbException
from ch.ehi.ili2db.gui import Config
from ch.ehi.ili2gpkg import GpkgMain

print sys.path

settings = Config()
GpkgMain().initConfig(settings)
settings.setFunction(Config.FC_IMPORT)
settings.setDoImplicitSchemaImport(True)
settings.setModels("DM01AVCH24LV95D")
settings.setDefaultSrsCode("2056")
settings.setNameOptimization(Config.NAME_OPTIMIZATION_TOPIC)
settings.setCreateEnumDefs(Config.CREATE_ENUM_DEFS_MULTI)
settings.setDbfile("254900.gpkg")
Config.setStrokeArcs(settings, Config.STROKE_ARCS_ENABLE)
settings.setValidation(False)
settings.setItfTransferfile(True)
settings.setDburl("jdbc:sqlite:" + settings.getDbfile())
settings.setXtffile("254900.itf")
try:
    Ili2db.run(settings, None)
except Ili2dbException, value:
    print value

Dem Skript muss man via JYTHONPATH die Java-Klassen bekannt machen:

export JYTHONPATH=~/apps/ili2gpkg-4.4.5/ili2gpkg-4.4.5.jar:~/apps/ili2gpkg-4.4.5/libs/antlr-2.7.7.jar:~/apps/ili2gpkg-4.4.5/libs/base64-2.3.9.jar:~/apps/ili2gpkg-4.4.5/libs/ehibasics-1.4.0.jar:~/apps/ili2gpkg-4.4.5/libs/ehisqlgen-1.13.8.jar:~/apps/ili2gpkg-4.4.5/libs/ili2c-core-5.1.5.jar:~/apps/ili2gpkg-4.4.5/libs/ili2c-tool-5.1.5.jar:~/apps/ili2gpkg-4.4.5/libs/ili2db-4.4.5.jar:~/apps/ili2gpkg-4.4.5/libs/iox-api-1.0.3.jar:~/apps/ili2gpkg-4.4.5/libs/iox-ili-1.21.4.jar:~/apps/ili2gpkg-4.4.5/libs/jackson-core-2.9.7.jar:~/apps/ili2gpkg-4.4.5/libs/jts-core-1.14.0.jar:~/apps/ili2gpkg-4.4.5/libs/sqlite-jdbc-3.8.11.2.jar

Zukunftsträchtiger (?) und sicher hipper ist eine andere Python-Implementierung. Nämlich die Python-Implementierung für die GraalVM. GraalVM bietet zudem Implmentierungen für Java, Ruby, R und Node.js an und ermöglicht wirklich polyglote Anwendungen. Die Python-3-Implementierung steckt leider noch in den Kinderschuhen. Das merkt man insbesondere, wenn man beliebte Frameworks und Bibliotheken verwenden will. Viele von diesen werden nicht unterstützt. Der Fokus der Entwickler liegt momentan bei Numpy und SciPy. Im Prinzip funktioniert es wie mit Jython:

import java

Config = java.type('ch.ehi.ili2db.gui.Config')
Ili2db = java.type('ch.ehi.ili2db.base.Ili2db')
Ili2dbException = java.type('ch.ehi.ili2db.base.Ili2dbException')
GpkgMain = java.type('ch.ehi.ili2gpkg.GpkgMain')

settings = Config()
GpkgMain().initConfig(settings)
settings.setFunction(Config.FC_IMPORT)
settings.setDoImplicitSchemaImport(True)
settings.setModels("DM01AVCH24LV95D")
settings.setDefaultSrsCode("2056")
settings.setNameOptimization(Config.NAME_OPTIMIZATION_TOPIC)
settings.setCreateEnumDefs(Config.CREATE_ENUM_DEFS_MULTI)
settings.setDbfile("254900.gpkg")
Config.setStrokeArcs(settings, Config.STROKE_ARCS_ENABLE)
settings.setValidation(False)
settings.setItfTransferfile(True)
settings.setDburl("jdbc:sqlite:" + settings.getDbfile())
settings.setXtffile("254900.itf")
try:
    Ili2db.run(settings, None)
except Ili2dbException as value:
    print(value)

In dieser Variante muss der CLASSPATH korrekt gesetzt werden:

export CLASSPATH=~/apps/ili2gpkg-4.4.5/ili2gpkg-4.4.5.jar:~/apps/ili2gpkg-4.4.5/libs/antlr-2.7.7.jar:~/apps/ili2gpkg-4.4.5/libs/base64-2.3.9.jar:~/apps/ili2gpkg-4.4.5/libs/ehibasics-1.4.0.jar:~/apps/ili2gpkg-4.4.5/libs/ehisqlgen-1.13.8.jar:~/apps/ili2gpkg-4.4.5/libs/ili2c-core-5.1.5.jar:~/apps/ili2gpkg-4.4.5/libs/ili2c-tool-5.1.5.jar:~/apps/ili2gpkg-4.4.5/libs/ili2db-4.4.5.jar:~/apps/ili2gpkg-4.4.5/libs/iox-api-1.0.3.jar:~/apps/ili2gpkg-4.4.5/libs/iox-ili-1.21.4.jar:~/apps/ili2gpkg-4.4.5/libs/jackson-core-2.9.7.jar:~/apps/ili2gpkg-4.4.5/libs/jts-core-1.14.0.jar:~/apps/ili2gpkg-4.4.5/libs/sqlite-jdbc-3.8.11.2.jar

Werden, wie in diesem Fall, Java-Bibliotheken verwendet, muss Python im JVM-Modus gestartet werden (was wiederum die Startzeit fast quälend langsam macht):

graalpython --jvm --vm.cp=$CLASSPATH ili2db.py

Je nach Anwendungsfall sind das valable Lösungen. Insbesondere auch weil die Hürde einer Java-Runtime in Zeiten von Docker je nachdem sehr tief ist. Wo dieser Ansatz nicht funktioniert, ist bei QGIS-Plugins. Im Model-Baker-Plugin sind die System-Calls relativ elaboriert und sicher ziemlich robust. Andererseits braucht man immer noch eine Java-Runtime, was mich in diesem konkreten Fall stört. Mit der GraalVM können Anwendungen zu nativem Code kompiliert werden und brauchen zur Laufzeit keine Java-Runtime mehr. Tönt cool, ist hip, hat aber auch Nachteile. Es können jedoch nicht nur komplette Java-Awendungen zu nativem Code kompiliert werden, sondern auch einzelne (statische) Java-Methoden zu shared libraries (*.so, *.dylib, *.dll). Diese wiederum - so die Idee - könnte man mittels Python-Bindings in QGIS-Plugins ansprechen. Somit wäre man die Laufzeitanforderung Java los. Gesagt getan:

package ch.so.agi.ili2db.libnative;

import java.io.File;
import java.io.IOException;
import java.nio.file.Paths;
import java.util.Map;

import org.graalvm.nativeimage.IsolateThread;
import org.graalvm.nativeimage.c.function.CEntryPoint;
import org.graalvm.nativeimage.c.type.CCharPointer;
import org.graalvm.nativeimage.c.type.CTypeConversion;

import com.fasterxml.jackson.databind.ObjectMapper;

import ch.ehi.ili2db.base.Ili2db;
import ch.ehi.ili2db.base.Ili2dbException;
import ch.ehi.ili2db.gui.Config;
import ch.ehi.ili2pg.PgMain;

public class Ili2dbLib {

    @CEntryPoint(name = "ili2pg")
    public static int ili2pg(IsolateThread thread, CCharPointer settings) {
        try {
            Config config = json2config(CTypeConversion.toJavaString(settings));
            Ili2db.run(config, null);
        } catch (Ili2dbException e) {
            e.printStackTrace();
            System.err.println(e.getMessage());
            return 1;
        } catch (IOException e) {
            e.printStackTrace();
            System.err.println(e.getMessage());
            return 1;
        }
        return 0;
    }

    public static Config json2config(String jsonString) throws IOException {
        ObjectMapper mapper = new ObjectMapper();
        Map<String, Object> map = mapper.readValue(jsonString, Map.class);

        Config config = new Config();
        new PgMain().initConfig(config);

        if (!map.containsKey("function")) {
            throw new IllegalArgumentException("missing function parameter");
        } else {
            String function = (String) map.get("function");

            if (function.equalsIgnoreCase("import")) {
                config.setFunction(Config.FC_IMPORT);
            }
        }

        // TODO if/else/exceptions etc.
        config.setDoImplicitSchemaImport(true);
        config.setConfigReadFromDb(true);
        config.setModels((String) map.get("models"));

        config.setDbhost((String) map.get("dbhost"));
        config.setDbport((String) map.get("dbport"));
        config.setDbusr((String) map.get("dbusr"));
        config.setDbusr((String) map.get("dbusr"));
        config.setDbpwd((String) map.get("dbpwd"));
        config.setDburl((String) map.get("dburl"));
        config.setDbschema((String) map.get("dbschema"));

        config.setDefaultSrsCode((String) map.get("defaultSrsCode"));

        if (map.containsKey("strokeArcs")) {
            Config.setStrokeArcs(config, Config.STROKE_ARCS_ENABLE);
        }

        if ((Boolean) map.get("disableValidation")) {
            config.setValidation(false);
        }

        if ((Boolean) map.get("doSchemaImport")) {
            config.setDoImplicitSchemaImport(true);
        }

        String fileName = (String) map.get("file");
        if (fileName.toLowerCase().endsWith("itf")) {
            config.setItfTransferfile(false);
        } else {
            config.setItfTransferfile(true);
        }
        config.setXtffile(new File(fileName).getAbsolutePath());

        return config;
    }
}

Es gibt bei der Implementierung einer solchen statischen Methode einige Einschränkungen. Zum einen, dass sie eben statisch sein muss und zum anderen, dass die Übergabe von Parametern recht eingeschränkt ist. Viel mehr als Integer, Double und String geht nicht. Beliebige Objekte können nicht ausgetauscht werden, was das Vorhaben nicht einfacher macht. Eine Möglichkeit ist, dass die Objekte (die übergeben werden sollen) nach JSON serialisiert und als String übergeben werden. Hat man den Java-Code, muss man die Methode zu einer shared library kompilieren (konkret hier für Linux):

./gradlew clean lib:build shadowJar && \
native-image --no-fallback --no-server -cp lib/build/libs/lib-all.jar --shared -H:Name=libili2db

Das Produkt sind verschiedene Headerfiles und die Bibliothek selbst. Die simpelste Form von Python-Bindinds ist der Weg über ctypes. Das ergibt circa folgenden Code:

settings = "{ \"dbhost\" : \"192.168.56.1\", \"dbport\" : \"54321\", \"dbdatabase\" : \"edit\", \"dbusr\" : \"admin\", \"dbpwd\" : \"admin\", \"dburl\" : \"jdbc:postgresql://192.168.56.1:54321/edit\", \"dbschema\" : \"npl_2551\", \"defaultSrsCode\" : \"2056\", \"strokeArcs\" : \"enable\", \"disableValidation\" : true, \"models\" : \"SO_Nutzungsplanung_20171118\", \"doSchemaImport\" : true, \"function\" : \"import\", \"file\" : \"./lib/src/test/data/2551.xtf\" }"
print(settings)

from ctypes import *
dll = CDLL("./libili2db.so")
isolate = c_void_p()
isolatethread = c_void_p()
dll.graal_create_isolate(None, byref(isolate), byref(isolatethread))
dll.ili2pg.restype = int
result = dll.ili2pg(isolatethread, c_char_p(bytes(settings, "utf8")))
result

Ein wenig syntactic sugar drum herum und es sieht gar nicht mehr so schlimm aus. Ein Nachteil ist, dass zusätzlicher ili2db-Code entstehen würde, der ebenfalls von irgend jemandem gepflegt werden will.

INTERLIS leicht gemacht #21 - INTERLIS ohne INTERLIS

Wed, 23 Sep 2020 00:00:00 +0000

Die Dienststelle muss einige seiner in die Jahre gekommenen Fachanwendungen ablösen und wählt dafür eine «Plattform» eines Anbieters aus. Die Idee dahinter ist, dass dank des Plattformgedankens Synergien genützt werden können: technisch aber auch v.a. finanziell. Klingt gut, hat aber auch ein paar gravierende Nachteile. Im konkreten Fall fiel die Wahl auf eine Plattform, die überhaupt nichts mit GIS am Hut hat, aber trotzdem «GIS machen» können soll. Das Tragische ist, dass die GIS-Anforderungen eigentlich überschaubar sind: Häufig muss man nur einen Punkt in einer Karte absetzen und ein paar Attribute dazu erfassen. Soweit keine Raketenwissenschaft.

Für das Verheiraten von GIS-freien Webanwendungen und unserem Web GIS Client haben wir eine Schnittstelle auf Basis Websocket eingeführt. Damit können sich die beiden Awendungen koppeln und Daten austauschen. Die Fachanwendung muss also nicht «GIS können», sondern nur Websocket und bisschen JSON rumschicken. Im aktuellsten Fall gibt es nun zusätzlich die Anforderung, dass die Geometrien nicht nur Punkte sind, sondern Polygone. Die Polygone müssen zudem sauber, d.h. überlappungsfrei erfasst werden können. Natürlich kann man sowas auch in einem Web GIS Client umsetzen. Das Kosten/Nutzen-Verhältnis muss aber berücksichtigt werden. Vor allem wenn es Werkzeuge wie QGIS gibt, die sehr gute Digitalisierungswerkzeuge mitbringen.

Wie verheiraten wir aber jetzt QGIS mit der Fachanwendung, die im Browser läuft? Einerseits sollen zu einem Geschäftsfall in der Fachanwendung Geometrien erfasst werden und andererseits sollen die gemeinsamen Daten (also Geometrie und Sachattribute aus der Fachanwendung) regelmässig für Interessierte im Web GIS Client aktualisiert und dargestellt werden. Was wir nicht machen wollen, ist für QGIS einen Websocket-Provider entwickeln lassen. Was machen? Back to the roots: Datenaustausch mit Dateien und bisschen Copy/Paste. Grundidee ist etwa folgende:

Der Anwender beginnt mit der Erfassung des Polygons / Multipolygons in QGIS. Diese Geometrie erhält einen fixen Identifikator. Diesen Identifikator muss man in die Fachanwendung übertragen und dort können die weiteren Informationen zum Geschäftsfall erfasst werden. Dieses Vorgehen öffnet natürlich Tür und Tor für Fehler. Wie damit umgehen? Wie verhindern? INTERLIS.

Wir müssen nur ein Datenmodell erstellen, das die Geometrie von den Sachdaten in zwei Klassen aufteilt und eine Beziehung zwischen den Klassen herstellen. Die Beziehung muss jedoch so definiert werden (Zauberwort EXTERNAL), dass Bezüge zwischen Objekten in unterschiedlichen Behältern zugelassen werden.

MODEL SO_AFU_Abbaustellen_20200918 (de)
AT "http://afu.so.ch"
VERSION "2020-09-18"  =
  IMPORTS GeometryCHLV95_V1;

  TOPIC Abbaustellen =
    OID AS INTERLIS.UUIDOID;

    /** Abbaustelle (aus Fachanwendung ohne Geometrie)
     */
    CLASS Abbaustelle =
      Nummer : MANDATORY TEXT*1024;
      Name : MANDATORY TEXT*1024;
      Bemerkungen : MTEXT*1024;
    END Abbaustelle;

    /** Geometrie zu einer Abbaustelle. Getrennte Erfassung (Fachanwendung - Desktop-GIS)
     */
    CLASS Geometrie =
      Geometrie : MANDATORY GeometryCHLV95_V1.SurfaceWithOverlaps2mm;
    END Geometrie;

    /** Verknüpfung zwischen genau einer Abbaustelle und einer Geometrie.
     *
     * In welcher Tabellen wird der Fremdschlüssel in der Datenbank angelegt? In welcher Klasse wird die Beziehung im XTF eingebettet?
     *
     * Falls bei beiden (Basis-)Rollen die maximale Kardinalität kleiner gleich 1 ist, wird bei der Ziel-Klasse der zweiten  Rolle eingebettet. (Kap. 3.3.9 (und 3.3.7)).
     */
    ASSOCIATION Abbaustelle_Geometrie =
      Geometrie (EXTERNAL) -- {1} Geometrie;
      Abbaustelle -- {1} Abbaustelle;
    END Abbaustelle_Geometrie;

  END Abbaustellen;

END SO_AFU_Abbaustellen_20200918.

Die Fachanwendung schickt uns für die Integration in die GDI (zur Publikation im Web GIS Client) nur eine INTERLIS-Transferdatei mit Objekten der Klasse Abbaustelle:

<?xml version="1.0" encoding="UTF-8"?>
<TRANSFER xmlns="http://www.interlis.ch/INTERLIS2.3">
  <HEADERSECTION SENDER="ili2pg-4.4.2-7b1d50437cd6970a801b16d177c4e27151414569" VERSION="2.3">
    <MODELS>
      <MODEL NAME="CoordSys" VERSION="2015-11-24" URI="http://www.interlis.ch/models"/>
      <MODEL NAME="Units" VERSION="2012-02-20" URI="http://www.interlis.ch/models"/>
      <MODEL NAME="GeometryCHLV03_V1" VERSION="2017-12-04" URI="http://www.geo.admin.ch"/>
      <MODEL NAME="GeometryCHLV95_V1" VERSION="2017-12-04" URI="http://www.geo.admin.ch"/>
      <MODEL NAME="SO_AFU_Abbaustellen_20200918" VERSION="2020-09-18" URI="http://afu.so.ch"/>
    </MODELS>
  </HEADERSECTION>
  <DATASECTION>
    <SO_AFU_Abbaustellen_20200918.Abbaustellen BID="bX">
      <SO_AFU_Abbaustellen_20200918.Abbaustellen.Abbaustelle TID="5c6be6dd-7111-42fd-9eae-bd46fefa3c93">
        <Nummer>5432</Nummer>
        <Name>Hellstätt</Name>
        <Bemerkungen>Fubar</Bemerkungen>
        <Geometrie REF="5e5bb99e-2f68-499e-aebe-d01f05b9ea88"/>
      </SO_AFU_Abbaustellen_20200918.Abbaustellen.Abbaustelle>
    </SO_AFU_Abbaustellen_20200918.Abbaustellen>
  </DATASECTION>
</TRANSFER>

Das Attribut REF im Element Geometrie enthält den fixen Identifikator der Geometrie. Der GIS-Teil sieht in INTERLIS so aus (siehe TID):

<?xml version="1.0" encoding="UTF-8"?>
<TRANSFER xmlns="http://www.interlis.ch/INTERLIS2.3">
  <HEADERSECTION SENDER="ili2pg-4.4.2-7b1d50437cd6970a801b16d177c4e27151414569" VERSION="2.3">
    <MODELS>
      <MODEL NAME="CoordSys" VERSION="2015-11-24" URI="http://www.interlis.ch/models"/>
      <MODEL NAME="Units" VERSION="2012-02-20" URI="http://www.interlis.ch/models"/>
      <MODEL NAME="GeometryCHLV03_V1" VERSION="2017-12-04" URI="http://www.geo.admin.ch"/>
      <MODEL NAME="GeometryCHLV95_V1" VERSION="2017-12-04" URI="http://www.geo.admin.ch"/>
      <MODEL NAME="SO_AFU_Abbaustellen_20200918" VERSION="2020-09-18" URI="http://afu.so.ch"/>
    </MODELS>
  </HEADERSECTION>
  <DATASECTION>
    <SO_AFU_Abbaustellen_20200918.Abbaustellen BID="b1">
      <SO_AFU_Abbaustellen_20200918.Abbaustellen.Geometrie TID="5e5bb99e-2f68-499e-aebe-d01f05b9ea88">
        <Geometrie>
          <SURFACE>
            <BOUNDARY>
              <POLYLINE>
                <COORD>
                  <C1>2629140.305</C1>
                  <C2>1245681.759</C2>
                </COORD>
                <COORD>
                  <C1>2629143.746</C1>
                  <C2>1245586.181</C2>
                </COORD>
                <COORD>
                  <C1>2629227.280</C1>
                  <C2>1245582.550</C2>
                </COORD>
                <COORD>
                  <C1>2629240.470</C1>
                  <C2>1245648.689</C2>
                </COORD>
                <COORD>
                  <C1>2629196.696</C1>
                  <C2>1245685.773</C2>
                </COORD>
                <COORD>
                  <C1>2629140.305</C1>
                  <C2>1245681.759</C2>
                </COORD>
              </POLYLINE>
            </BOUNDARY>
          </SURFACE>
        </Geometrie>
      </SO_AFU_Abbaustellen_20200918.Abbaustellen.Geometrie>
    </SO_AFU_Abbaustellen_20200918.Abbaustellen>
  </DATASECTION>
</TRANSFER>

Liegen sowohl die Daten aus der Fachanwendung wie auch die Geometrien als INTERLIS-Transferdatei vor, kann ilivalidator die Daten prüfen:

java -jar ilivalidator-1.11.6.jar --allObjectsAccessible abbaustellen_geometrie.xtf abbaustellen_fachanwendung.xtf

Wobei es hier noch einen Bug gibt: https://github.com/claeis/ilivalidator/issues/276.

Man muss aber die Geometrien gar nicht nach INTERLIS exportieren, um die Konsistenz zwischen Fachanwendungsdaten und Geometriedaten zu prüfen. Der Versuch eines Importes der Fachanwendungsdaten in die Datenbank reicht für den Fall von Sachobjekten, die ins Nirvana zeigen. In diesem Fall können die Daten gar nicht importiert werden, weil der Primary Key (zum Fremdschlüssel) fehlt («dangling reference»).

Wie überzeugt man aber die Firma, die kein GIS machen will, von INTERLIS? Gar nicht. Man sagt einfach, dass sie einfachstes XML herstellen müssen:

Variante 1: Jaxb

Eine Möglichkeit ist der Weg über das automatische Erzeugen von Java-Klassen aus dem XSD, welches aus dem INTERLIS-Datenmodell einmalig automatisch erstellt werden muss. Diese Java-Klassen muss ich dann nur noch mit Inhalt befüllen und kann sie nach XML (also XTF) serialisieren. Dieses Serialisieren übernimmt ebenfalls die Programmierbibliothek. D.h. ich muss mich nicht um XML-Formatierungen etc. kümmern, sondern nur um den Inhalt.

Ein Abbaustellen-Element wird z.B. wie folgt erstellt:

SOAFUAbbaustellen20200918AbbaustellenAbbaustelle abbaustelle = new SOAFUAbbaustellen20200918AbbaustellenAbbaustelle();
abbaustelle.setTID(abbauObj.getTid());
abbaustelle.setNummer(abbauObj.getNummer());
abbaustelle.setName(abbauObj.getName());
abbaustelle.setBemerkungen(abbauObj.getBemerkungen());

Ein komplettes Minimalbeispiel gibt es hier.

Variante 2: Templating

Eine zweite Variante ist die Verwendung einer Templating-Engine. Templating klingt zuerst immer einfach und effizient, hat aber meines Erachtens den Nachteil wenn es um Fehlersuche geht und/oder wenn es komplizierter wird. In diesem Fall ist es natürlich sehr einfach. Ein wenig Groovy-Magie:

import groovy.text.markup.MarkupTemplateEngine
import groovy.text.markup.TemplateConfiguration

class Abbaustelle {
    String tid
    String nummer
    String name
    String bemerkungen
    String geomRef
}

def model = [abbaustellen: [new Abbaustelle(tid: "5c6be6dd-7111-42fd-9eae-bd46fefa3c93", nummer: "5432", name: "Hellstätt", bemerkungen: "Fubar", geomRef: "5e5bb99e-2f68-499e-aebe-d01f05b9ea88")]]

def template = """
xmlDeclaration()
TRANSFER(xmlns: "http://www.interlis.ch/INTERLIS2.3") {
    HEADERSECTION(SENDER: "some-groovy-fairy-dust", VERSION: "2.3") {
        MODELS {
            MODEL(NAME: "CoordSys", VERSION: "2015-11-24", URI: "http://www.interlis.ch/models")
            MODEL(NAME: "GeometryCHLV03_V1", VERSION: "2017-12-04", URI: "http://www.geo.admin.ch")
            MODEL(NAME: "GeometryCHLV95_V1", VERSION: "2017-12-04", URI: "http://www.geo.admin.ch")
            MODEL(NAME: "SO_AFU_Abbaustellen_20200918", VERSION: "2020-09-18", URI: "http://afu.so.ch")
        }
    }
    DATASECTION {
        'SO_AFU_Abbaustellen_20200918.Abbaustellen'(BID: "bX") {
            abbaustellen.each { abbauObj ->
                'SO_AFU_Abbaustellen_20200918.Abbaustellen.Abbaustelle'(TID: abbauObj.tid) {
                    Nummer(abbauObj.nummer)
                    Name(abbauObj.name)
                    Bemerkung(abbauObj.bemerkungen)
                    Geometrie(REF: abbauObj.geomRef)
                }
            }
        }
    }
}
"""
TemplateConfiguration config = new TemplateConfiguration();
config.setAutoIndent(true)
config.setAutoNewLine(true)
def abbaustellenXml = new MarkupTemplateEngine(config).createTemplate(template).make(model)

println abbaustellenXml

INTERLIS ohne INTERLIS für Fachanwendungen, die GIS machen müssen aber kein GIS machen können und kein GIS machen wollen.

INTERLIS leicht gemacht #20 - ilivalidator goodies

Mon, 23 Sep 2019 00:00:00 +0000

Die Daten der Nutzungsplanung nehmen beim ÖREB-Kataster eine sehr wichtige Rolle ein. Das setzt eine hohe inhaltliche, aber auch strukturelle Qualität der digitalen Daten voraus. Die Daten werden in einem kantonalen Datenmodell erfasst, das sowohl MGDM wie auch ÖREB-Rahmenmodell kompatibel ist. Die Daten werden durch externe Planungs- und Ingenieurbüros im Auftrag der Gemeinde erfasst. So weit, so gut.

Wo gearbeitet wird, passieren auch Fehler. Insbesondere schmerzen diese in der Weiterverarbeitung der Daten, wie jetzt bei der Integration in den ÖREB-Kataster. Damit diese möglichst frühzeitg entdeckt werden, drängt sich natürlich die maschinelle Prüfung mit ilivalidator auf. Das wird zwar von Beginn an gemacht, wie sich aber jetzt herausstellt, reicht die pure Modellprüfung nicht, damit eine robuste und transparente Weiterverarbeitung sichergestellt ist. Dank den Möglichkeiten von ilivalidator kann die Prüfung an notwendigen Stellen verschärft werden. Bei einigen Veschärfungen ist mir - Stand heute - schlichtweg nicht klar, warum man damals nicht das Modell bereits so modelliert hat…

Multiplicity

Das Boolean-Attribut Rechtsvorschrift in der Klasse Dokument ist nicht mandatory. Für die Weiterverarbeitung müssen wir aber wissen, ob ein Dokument eine Rechtsvorschrift ist oder eben nicht. Um das Datenmodell nicht ändern zu müssen, kann man in einem «Valididierungsmodell» einen zusätzlichen Constraint definieren. Dazu muss man eine View der Dokumentenklasse erstellen und in dieser View den Constraint definieren:

CONTRACTED MODEL SO_Nutzungsplanung_20171118_Validierung_20190129 (de)
AT "http://www.geo.so.ch"
VERSION "2019-01-29"  =
  IMPORTS SO_Nutzungsplanung_20171118;

  VIEW TOPIC Rechtsvorschriften_Validierung =
  DEPENDS ON SO_Nutzungsplanung_20171118.Rechtsvorschriften;

	VIEW v_Dokument
    	PROJECTION OF SO_Nutzungsplanung_20171118.Rechtsvorschriften.Dokument;
    =
        ALL OF Dokument;
        !!@ ilivalid.msg = "Attribut 'Rechtsvorschrift' muss definiert sein."
        MANDATORY CONSTRAINT DEFINED(Rechtsvorschrift);
    END v_Dokument;

  END Rechtsvorschriften_Validierung;

END SO_Nutzungsplanung_20171118_Validierung_20190129.

Das Validierungsmodell muss in der Config-Toml-Datei referenziert werden:

["PARAMETER"]
additionalModels="SO_Nutzungsplanung_20171118_Validierung_20190129"

Der Programmaufruf ist wie folgt:

java -jar ilivalidator.jar --config myconfig.toml 2502.xtf

Falsche Dokumentenlinks

Dabei geht es nicht um falsche Links im INTERLIS-Sinn (das prüft ilivalidator von sich aus), sondern um Links, die nicht auf eine vorhandene HTTP-Ressource zeigen. Dazu macht man sich die Möglichkeit zu Nutze ilivalidator mit eigenen in Java geschriebenen Funktionen zu erweitern. Im Prinzip müsste die Funktion nur den Status Code eines HEAD-Befehls überprüfen. Das mit HEAD ist aber tricky, da der Befehl aufgrund von Firewalls resp. falsch konfigurierten Webservern nicht immer etwas sinnvolles oder richtiges zurückliefert. Daher muss man wohl oder übel trotzdem einen GET-Request absetzen. Bei mir sind jetzt alle Status Codes grösser 200 und kleiner 400 in Ordnung. Alles andere führt zu einem Fehler.

Die kompilierte Java-Klasse muss beim Aufruf ilivalidator bekannt gemacht werden indem man ein Plugins-Verzeichnis angibt (--plugins /path/to/plugin/dir/). Es reicht nicht, sie einfach im Classpath vorzuhalten. Dies ist vor allem dann nicht immer ideal, wenn man ilivalidator nicht bloss auf der Kommandozeile aufruft, sondern z.B. als Web Service.

Damit die Funktion in einem Constraint verwendet werden kann, muss sie vorgängig in einem Modell deklariert werden. Entweder macht man das im oben erwähnten Validierungsmodell oder man macht ein weiteres Modell, damit die Funktion mittels IMPORTS auch in weiteren Modellen verwendet werden kann.

Das Validierungsmodell muss dann zusätzlich zu SO_Nutzungsplanung_20171118 auch das neue Modell importieren. Anschliessend kann der Constraint definiert werden:

!!@ ilivalid.msg = "Dokument 'https://geo.so.ch/docs/ch.so.arp.zonenplaene/Zonenplaene_pdf/{TextImWeb}' wurde nicht gefunden."
MANDATORY CONSTRAINT SO_FunctionsExt.checkHttpRessource(TextImWeb, "https://geo.so.ch/docs/ch.so.arp.zonenplaene/Zonenplaene_pdf/");

Falsch verknüpfte Dokumente in HinweisWeitereDokumente

Zusätzlich zu den Rechtsvorschriften müssen die gesetzlichen Grundlagen und können weitere Informationen und Hinweise im ÖREB-Kataster erfasst werden. Entsprechend wurde das Rahmenmodell modelliert:

ASSOCIATION HinweisWeitereDokumente =
    Ursprung -- {0..*} Dokument;
    Hinweis (EXTERNAL) -- {0..*} Dokument;
    /** Hinweis auf spezifische Artikel.
    */
    ArtikelNr : BAG {0..*} OF OeREBKRM_V1_1.ArtikelNummer_;
END HinweisWeitereDokumente;

Das sieht auf den ersten Blick relativ harmlos aus. Zur Nemesis wird es aber beim Prozessieren in einer Datenbank. Abgebildet wird die Assoziation klassisch in einer Cross-Reference-Table. Theoretisch kann diese Spirale unendlich sein. D.h. um alle Dokumente zu einem ÖREB zu erhalten, muss die SQL-Query rekursiv sein. Rekursion bedeutet aber immer auch: «Kann gnadenlos in die Hosen gehen.» Nämlich dann, wenn kein geeignetes Abbruchkriterium definiert wurde. Das lernt man auf die schmerzhafte Weise: Zum Beispiel dann, wenn der DB-Server nur noch abgeschossen werden kann. Mit blindlings in guten Treu und Glaube die Query rattern lassen, ist somit nicht.

Es gibt verschiedene Hebel:

Die Query so schreiben, dass nur bis zu einer Tiefe von z.B. zehn Iterationen Dokumente gesucht werden. Viel mehr ist wohl kaum sinnvoll und auch kaum so erfasst.
Auf Datenbankseite die Executiontime einschränken oder die Grösse der Logfiles beschränken.
Die Daten vor dem Import in die Datenbank sauber prüfen, weil hier die Ursache der Probleme liegt.

Der erste aufgetretene Problemfall war, dass ein Dokument A auf sich selber zeigt. Das kann man mit einem MANDATORY CONSTRAINT in der Assoziation prüfen. Kniffliger wurden folgende Fälle: Dokument A → Dokument B → Dokument C → Dokument A. Dass ich eine eigene Java-Funktion schreiben musste, war mir schnell klar. Der erste Gedanken war zudem auch: kleine Sache. Überlegt man sich das aber ein wenig, merkt man schnell, dass so einfach die Sache nicht ist. Der dritte Gedanken war dann: Das Problem hat sicher schon jemand anderes gelöst und in letzer Konsequenz ist diese ganze Verschachtelung/Verknüpfung bloss ein Graph. Der Graph ist gerichtet und es dürfen keine Self-Loops und Kanten dürfen nicht mehrfach vorkommen. Bibliotheken dazu gibt es mehr als genug. Ich habe mich für jgrapht entschieden. Die ganze herausfordernde Arbeit - zu prüfen, ob falsche Verknüpfungen vorliegen - nimmt mir die Bibliothek ab und ich muss mich nur noch um das Integrieren in die ilivalidator-Welt bemühen.

Hier wird die Integration der Zusatzfunktion für den Betrieb noch ein wenig komplizierter, da wir eine Drittbibliothek verwenden müssen. Für den Aufruf auf der Konsole ist es - soweit ich mich erinnere - noch mühsamer. Ilivalidator findet auf Anhieb die Drittbibliothek nicht und mann muss den Befehl anders formulieren. Wenn man die Zusatzfunktion in einem Web Service einsetzen will, ist es wieder einfacher, da man sowieso ein Buildtool verwendet, das sich um die Abhängigkeiten kümmert.

Nichtsdestotrotz muss sinnvollerweise zusätzlich auch an den ersten beiden Hebeln angesetzt werden.

Typen müssen zwingend mit einem Dokument verknüpft sein

Im kantonalen Nutzungsplanungsmodell ist die Assoziation zwischen den Typen (= Eigentumsbeschränkungen) und den Dokumenten sehr lasch. Ein Typ kann keines oder mehrere Dokumente haben und ein Dokument kann keinem oder mehreren Typen zugeordnet sein. Im ÖREB-Kataster muss jede Eigentumsbeschränkung mindestens ein Dokument haben. D.h. wir müssen für verschiedene Typen zwingend prüfen, ob sie mit einem Dokument verknüpft sind.

Der erste Teil geht sehr elegant:

CONSTRAINTS OF Typ_Grundnutzung =
    !!@ ilivalid.msg = "Typ '{Typ_Kt}' (Typ_Grundnutzung) ist mit keinem Dokument verknüpft."
    MANDATORY CONSTRAINT INTERLIS.objectCount(Dokument)>=1
END;

Dieser Constraint muss im Modell nach der Assoziation stehen. Er prüft ob die Summe der verknüpften Dokumente zu einem Objekt Typ_Grundnutzung grösser gleich 1 ist. Das gilt bei uns nicht für alle Typen der Grundnutzung, sondern nur für ein Subset. Ob es kürzer und schöner geht, weiss ich nicht. Bei mir sieht das Filtering der Typen so aus:

CONSTRAINTS OF Typ_Grundnutzung =
    !!@ ilivalid.msg = "Typ '{Typ_Kt}' (Typ_Grundnutzung) ist mit keinem Dokument verknüpft."
    MANDATORY CONSTRAINT
        (
            INTERLIS.objectCount(Dokument)>=1
            AND
            (
                Typ_Kt == #N110_Wohnzone_1_G
                OR
                Typ_Kt == #N111_Wohnzone_2_G
                OR
                .... viele mehr
            )
        )
        OR
        (
            Typ_Kt == #N180_Verkehrszone_Strasse
            OR
            Typ_Kt == #N181_Verkehrszone_Bahnareal
            OR
            ... viele mehr
        );
END;

Subset von verknüpften Objekten bilden eine AREA

Die Objekte der Lärmempfindlichkeitstufen werden im kantonalen Modell bei den überlagernden Flächen der Nutzungsplanung erfasst. Die Geometrien der Lärmempfindlichkeitsstufen alleine betrachtet, müssen eine AREA bilden, d.h. sie dürfen sich nicht überlappen. Da die Geometrien und die Typen aber in zwei verschiedenen Klassen verwaltet werden, muss ähnlich vorgegangen werden wie beim vorangegangenen Beispiel, nur dass dieses Mal ein SET CONSTRAINT verwendet werden muss:

CONSTRAINTS OF Ueberlagernd_Flaeche =
    !!@ name = laermempfindlichkeitsAreaCheck
    !! !!@ ilivalid.msg = "Lärmempfindlichkeitstypen überlappen sich."
    SET CONSTRAINT
        WHERE
        (
            Typ_Ueberlagernd_Flaeche->Typ_Kt==#N680_Empfindlichkeitsstufe_I
            OR
            Typ_Ueberlagernd_Flaeche->Typ_Kt==#N681_Empfindlichkeitsstufe_II
            OR
            Typ_Ueberlagernd_Flaeche->Typ_Kt==#N682_Empfindlichkeitsstufe_II_aufgestuft
            OR
            Typ_Ueberlagernd_Flaeche->Typ_Kt==#N683_Empfindlichkeitsstufe_III
            OR
            Typ_Ueberlagernd_Flaeche->Typ_Kt==#N684_Empfindlichkeitsstufe_III_aufgestuft
            OR
            Typ_Ueberlagernd_Flaeche->Typ_Kt==#N685_Empfindlichkeitsstufe_IV
            OR
            Typ_Ueberlagernd_Flaeche->Typ_Kt==#N686_keine_Empfindlichkeitsstufe
        ) : INTERLIS.areAreas(ALL, UNDEFINED, >> Geometrie);
END;

Bugs

Es sind bei der Erarbeitung dieser zusätzlichen aber notwendigen Validierungen einige Bugs in ilivalidator entdeckt worden:

Für die meisten konnte ich einen, teilweise sehr unschönen, Workaround finden. Aber das Bugfixing müssen wir zügig angehen.

GraalVM #1 - INTERLIS polyglot gemacht

Sat, 23 Feb 2019 00:00:00 +0000

GraalVM? Was ist das? Eine «High-performance polyglot VM». Fazit: Wirklich sowas wie der Heilige Gral. Oder gemäss Homepage:

GraalVM is a universal virtual machine for running applications written in JavaScript, Python, Ruby, R, JVM-based languages like Java, Scala, Kotlin, Clojure, and LLVM-based languages such as C and C++.

GraalVM removes the isolation between programming languages and enables interoperability in a shared runtime. It can run either standalone or in the context of OpenJDK, Node.js, Oracle Database, or MySQL.

— https://www.graalvm.org/

Das erste Mal bin ich darübergestolpert als Oracle eine Open Source Community Version veröffentlicht hat und das sicher den üblichen Kanälen eine Nachricht wert war. Vor kurzem habe ich wieder was darüber gelesen, als ich was mit Project Fn machen wollte. Das Problem mit Java sind bei FaaS-Geschichten die «cold start times». Das soll mit GraalVM besser sein. Ein wenig rumgegoogelt und eine höchst interessante Zusammenstellung der Möglichkeiten von GraalVM gefunden. Ganz abgefahren wird es bei Punkt 8 «Java code as native library».

Man kann mit Graal Java-Code zu native executables kompilieren. Damit wird eine JVM für die Ausführung des Programmes unnötig. Es funktioniert jedoch nicht nur mit kompletten Programmen, sondern auch mit Bibliotheken, die anschliessend z.B. in einem C-Pogramm als shared libraries eingebunden werden können. Ganz so einfach oder perfekt wie man sich das jetzt vielleicht vorstellt, ist es natürlich nicht. Es gibt verschiedene Bedingungen und Einschränkungen, die leider (noch) viel zu schnell auftreten.

So ein kleines Programm wie im verlinkten Blog geht natürlich problemlos. Funktioniert aber auch was grösseres wie z.B. ilivalidator?

Als erstes besorgt man sich GraalVM von Github. Ich habe bei mir die Umgebungsvariable GRAALVM_HOME gesetzt, die auf das Verzeichnis /Users/stefan/apps/graalvm-ce-1.0.0-rc12/Contents/Home zeigt. Unter Linux kann das z.B. so ausssehen: /home/vagrant/graalvm-ce-1.0.0-rc12. Die JAVA_HOME-Umgebungsvariable zeigt ebenfalls auf dieses Verzeichnis.

java -version liefert bei mir folgenden Output:

openjdk version "1.8.0_192"
OpenJDK Runtime Environment (build 1.8.0_192-20181024123616.buildslave.jdk8u-src-tar--b12)
GraalVM 1.0.0-rc12 (build 25.192-b12-jvmci-0.54, mixed mode)

Als nächstes wird der ilivalidator-Quellcode heruntergeladen und mit Gradle kompiliert: gradle clean build bindist -x test. Einige der Tests laufen bei mir nicht durch, darum das -x. bindist erstellt eine Zipdatei mit der ilivalidator.jar-Datei und den benötigten Bibliotheken (iox-ili, ili2c, …). Am besten hängt man folgende Befehle zusammen, da die Zip-Datei sowieso immer ausgepackt werden muss:

gradle clean build bindist -x test && unzip dist/ilivalidator-1.10.1-SNAPSHOT.zip -d dist/ilivalidator

Mit dem Programm $GRAALVM_HOME/bin/native-image kann ilivalidator in eine native executable kompiliert werden, die keine virtuelle Maschine mehr benötigt. So plusminus aus ein wenig Anleitung und Internet der erste Versuch:

$GRAALVM_HOME/bin/native-image --verbose --no-server -cp "libs/antlr-2.7.6.jar:libs/ehibasics-1.2.0.jar:libs/ili2c-core-4.7.10.jar:libs/ili2c-tool-4.7.10.jar:libs/iox-api-1.0.3.jar:libs/iox-ili-1.20.10.jar:libs/jts-core-1.14.0.jar:ilivalidator-1.10.1-SNAPSHOT.jar" org.interlis2.validator.Main

Läuft nicht durch. Es gibt Fehler bezüglich java2d- und awt-Klassen:

Hier entschied ich mich alles GUI-Zeugs aus ilivalidator zu entfernen. Gleichzeitig habe ich die Möglichkeit der ilivalidator Custom Functions entfernt, da - soweit ich es verstanden habe - zum Zeitpunkt des Kompilierens klar sein muss, welche Klassen verwendet werden. Das ist bei den Custom Functions nicht der Fall, da diese erst beim Starten von ilivalidator geladen/registriert werden. Also: Brutal viel gelöscht und auskommentiert.

Irgendeinmal war das Erstellen des Binaries erfolgreich. Das Resultat ist eine circa 20MB grosse ausführbare Datei org.interlis2.validator.main. Der anschliessende Versuch ilivalidator auszuführen, war leider nur halb erfolgreich, da das native executable eine Ressource nicht finden konnte. Es handelte sich dabei um eine Versions-Properties-Datei. Der Umgang mit Ressourcen ist klar geregelt. Da bin ich wahrscheinlich falsch abgebogen: Ich dachte, es wäre einfacher das zu ignorieren und dass es einfacher wäre kurz mal den Quellcode anzupassen. Falsch, weil andere benötigte Bibliotheken (iox-ili, ili2c) ebenfalls eine solche Datei haben und diese zur Laufzeit ausgelesen werden und der Inhalt in die Konsole geschrieben wird. D.h. den Quellcode der weiteren Bibliotheken musste ich auch anpassen.

Trotzdem herrschte Freude, als ./org.interlis2.validator.main --help funktionierte:

Der logische nächste Schritt ist das Prüfen einer INTERLIS-Transferdatei, was natürlich auch nicht auf Anhieb funktionierte:

Die Fehlermeldung ist klar und die Lösung auch: Man muss das HTTP- und HTTPS-Protokoll freischalten. Das passt, da ilivalidator die benötigten INTERLIS-Modelle in den Modellablagen suchen geht und daher via HTTP und HTTPS kommunizieren muss. Mehr Informationen zu diesem Thema findet sich ebenfalls im Github-Repo von Graal.

Nächster Versuch, nächster Fehler:

ClassNotFoundException… Irgendeinmal versteht man auch mit Halbwissen immer wie mehr und/oder bekommt den richtigen Riecher für des Rätsels Lösung. Liest man sich durch die Limitations, bleibt man hoffentlich beim Kapitel «Reflection» hängen. Meine ClassNotFoundException könnte (?) ja in diese Kategorie fallen. Die Lösung ist auch relativ einfach. Man muss dem native-image-Befehl (-H:ReflectionConfigurationFiles=../../reflection.json) in einer JSON-Datei mitteilen, welche Klassen mittels Reflection verwendet werden:

[
  {
    "name" : "antlr.CommonToken",
    "methods": [
      { "name": "<init>", "parameterTypes": [] }
    ]
  }
]

Es folgen noch weitere Fehlermeldungen bezüglich fehlenden Klassen. Diese habe allesamt in der JSON-Datei eingetragen. Der nächste Fehler war wieder eine nicht vorhandene Ressource. Da wurde es mir zu blöde und anstatt den Code anzupassen, habe ich einfach dem native-image-Befehl die Option gemäss Fehlermeldung (-H:IncludeResourceBundles=…) mitgeliefert.

Und voilà, die Validierung läuft durch:

Mein vollständiger Befehl lautet:

$GRAALVM_HOME/bin/native-image --verbose --enable-url-protocols=http,https -H:ReflectionConfigurationFiles=../../reflection.json -H:IncludeResourceBundles=ch.interlis.ili2c.metamodel.ErrorMessages --report-unsupported-elements-at-runtime --allow-incomplete-classpath -H:-UseServiceLoaderFeature --delay-class-initialization-to-runtime=com.sun.naming.internal.ResourceManager$AppletParameter -H:+ReportExceptionStackTraces --no-server -cp "libs/antlr-2.7.6.jar:libs/ehibasics-1.2.0.jar:libs/ili2c-core-4.7.10.jar:libs/ili2c-tool-4.7.10.jar:libs/iox-api-1.0.3.jar:libs/iox-ili-1.20.11-SNAPSHOT.jar:libs/jts-core-1.14.0.jar:ilivalidator-1.10.1-SNAPSHOT.jar" org.interlis2.validator.Main

Einen kleinen Haken hat die Sache noch: Wenn ilivalidator zur Laufzeit wirklich via HTTPS kommunizieren muss, fliegt es mir um die Ohren, wegen einer nicht vorhandenen Bibliothek: The sunec native library, required by the SunEC provider, could not be loaded. Auch dazu gibt es bereits Informationen und einen aufschlussreichen Issue auf Github. Ich habe es gleich gelöst wie der Reporter des Tickets, d.h. in der Datei $GRAALVM_HOME/jre/lib/security/java.security den SunEC-Provider auskommentiert.

Links, die geholfen haben:

Ob ilivalidator das ideale Beispiel / der ideale Einsatzzweck für native executables ist, weiss ich nicht. Performancemässig bringt es wohl gar nichts. Interessanter dürfte es vielleicht für das QGIS Model Baker-Projekt sein. Da kann man sich vorstellen, dass der Umgang der ili2pg/ili2gpkg-Abhängigkeiten einfacher werden könnte. Oder man erstellt nicht die ganze Anwendung, sondern bloss eine shared library, damit die INTERLIS-Validierungsfunktionen von ilivalidator einfacher in anderen Programmiersprachen resp. Programmen eingebunden werden kann und die Validierungsfunktionen nicht mittels externen Java-Aufrufen erfolgen müssen.

INTERLIS leicht gemacht #19 - Modellablage automatisieren

Fri, 22 Feb 2019 00:00:00 +0000

Es ging relativ lange bis ich überhaupt geschnallt habe, dass die INTERLIS-Modellablage auch eine INTERLIS-Transferdatei mit dazugehörigem INTERLIS-Modell ist. Im Grunde genommen sind es zwei Modelle (IliRepository09 und IliSite09) und zwei Transferdateien, wobei letztere in der Regel kaum nachgeführt werden muss. Bei uns ist diese Nachführung ein händischer Prozess:

Neues Modell in einen Filesystem-Ordner auf einem Server kopieren.
Anpassen der ilimodels.xml-Datei inkl. Berechnen md5-Prüfsumme der neuen Modell-Datei.
Überprüfen der Dateirechte auf dem Filesystem, damit die Dateien später für andere Mitarbeiter und den Webserver lesbar bleiben
Validieren der ilimodels.xml-Datei mit ilivalidator.
Prüfen der INTERLIS-Modellablage mit ili2c und dem --check-repo-ilis-Befehl.
Ein Nacht warten bis der Filesystem-Ordner in die globale Zone kopiert wurde. Erst dann steht das Modell im Internet allen zur Verfügung.

Bei diesem Nachführungsprozess nervt fast alles. Zuviele manuelle Prozesse, furchtbares Gefrickel mit den Dateirechten, eine Nacht warten, bis wirklich verfügbar…

Eine erste Idee war den Nachführungsprozess «irgendwie» mit QGIS und ili2pg zu machen. Ich hätte alles in einem GitHub-Repository abgelegt, d.h. sowohl Modelle wie auch QGIS und Datenbank (mit Vagrant). Schien schlussendlich auch wieder kompliziert. Überhaupt war da plötzlich die Frage, ob man menschlichen Input braucht, ausser das Modell irgendwo hinzukopieren? Es stellte sich heraus, dass es unter gewissen Umständen keinen manuellen Eingriff braucht. Was heisst das?

Die erste mir bekannte Modellablage hat die TID in der ilimodels.xml-Datei stark formalisiert. Jedes Amt bekommt einen eigenen Range. Dieses Vorgehen haben wir bei der Einführung unserer Modellablage übernommen. Will man das nicht, ist die Automatisierung schon wieder einfacher geworden.

Einige optionale Attribute in der ilimodels.xml-Datei ergeben sich nicht zwingend oder direkt aus dem eigentlichen Modell. Oftmals könnte man sich mit INTERLIS-Metaattributen behelfen. Bedingt aber, dass diese für jedes Modell sauber erfasst sind. Die gemäss IliRepository09-Modell zwingend notwendigen Attribute ergeben sich jedoch problemlos aus den zu publizierenden Modellen selber.

Zwischenfazit: Es braucht keine menschlichen und manuellen Eingriffe für das Erstellen der ilimodels.xml-Datei, wenn man Zugriff auf die zu publizierenden INTERLIS-Modelle hat. Das führt zur Idee, dass man die INTERLIS-Modelle in einem Github-Repository verwalten kann. Bei Änderungen im Github-Repository läuft eine CI/CD-Pipeline ab, welche die INTERLIS-Modellablage mindestens in eine Testumgebung deployed. Sowas in der Art wäre schön.

Zuerst braucht es etwas, dass aus einem Haufen von INTERLIS-Modellen die ilimodels.xml-Datei erstellt. Das scheint mit iox-ili kein Hexenwerk zu sein, sondern ein paar Zeilen Java-Code. Diese paar Zeilen Java-Code packt man in einen Gradle-Custom-Task und schon kann man mit GRETL die ilimodels-xml-Datei erstellen. D.h. das Erstellen der ilimodels.xml-Datei wird losgetriggert durch einen Commit in das Github-Repository und mit einem Gradle-Build-Job, der das GRETL-Plugin verwendet, ausgeführt. Als CI-Werkzeug wird Travis CI verwendet. Ginge aber auch problemlos mit z.B. Jenkins.

Als GRETL-Task ist die Herstellung der ilimodels.xml-Datei ein blosses Konfigurieren:

task createIliModelsXml(type: IliRepositorizer) {
    description = "Create ilimodels.xml file."
    modelsDir = file("models/")
    dataFile = "ilimodels.xml"
}

Die entstandene Datei kann man mit einem ilivalidator-Task prüfen:

task validateIliModelsXml(type: IliValidator) {
    description = "Validate ilimodels.xml file."
    dataFiles = ["ilimodels.xml"]
    logFile = "ilivalidator.log"
}

Aber: Ich will nicht bloss das Erstellen der Datei automatisieren, sondern auch das Deployment schneller und effizienter gestalten und mich nicht wieder mit Dateirechten herumschlagen müssen. Warum also nicht die INTERLIS-Modelle und die ilimodels.xml- und ilisite.xml-Datei in ein Docker-Image brennen und mit nginx bereitstellen. Das Docker-Image kann in der Openshift-Infrastruktur des Kantons deployed werden. In Openshift kann man Image Streams als «scheduled» taggen. In diesem Fall wird alle z.B. 15 Minuten geprüft, ob sich im Image in der Registry was geändert hat. Falls ja, wird das Image neu deployed.

Das Erstellen des Docker-Images kann man entweder mit einem Shell-Skript automatisieren oder auch direkt im Gradle Build-File mit einem Plugin steuern. Das Dockerfile ist einmalig zu schreiben. Dieses ändert sich in der Regel nicht bei einer Änderung von Modellen, ausser wenn neue Ordner reinkopiert werden müssen.

Bevor ich das hergestellte Image in die Docker-Registry hochladen kann/darf, muss ich die darin enthaltene INTERLIS-Modellablage prüfen. D.h. ein Docker-Container muss gestartet werden und mit ili2c die Modellablage geprüft werden. Den Docker-Container hochfahren, mache ich ebenfalls mit Gradle.

Wie soll man den ili2c-Befehl für die Prüfung der Modellablage absetzen und wie das Ergebnis der Prüfung richtig interpretieren? Es bestünde natürlich auch hier die Möglichkeit einen eigenen Custom Task zu schreiben. Aber es geht einfacher: Gradle kennt den Task-Typ «JavaExec». Damit lässt sich eine Java-Applikation (in einem neuen Prozess) starten. Die Java-Applikation (in unserem Fall ili2c) wird als Buildscript-Dependency definiert, damit sie automatisch herunterladen wird.

Der eigentliche Task sieht wie folgt aus:

task checkInterlisRepository(type: JavaExec) {
    classpath = buildscript.configurations.classpath
    main = 'ch.interlis.ili2c.Main'
    args  "--check-repo-ilis", "http://localhost:8080"
}

Simpel. Der Task wirft korrekterweise eine Fehlermeldung, wenn die Prüfung der INTERLIS-Modellablage nicht erfolgreich ist. Damit werden auch die nachfolgenden Gradle-Tasks nicht ausgeführt (d.h. das Hochladen in die Docker-Registry).

Zum Ausprobieren:

docker run -p 8080:8080 sogis/sogis-interlis-repository

Im Browser:

localhost:8080

Bonus: Was ich momentan gerne mache, ist das Erstellen einer version.txt-Datei, die als statische Datei von einem Webserver (wenn er eh schon vorhanden ist) bereitgestellt wird. Damit sehe ich, ohne Einblick in Openshift etc. zu haben, ob die automatischen Deployments wirklich auch funktioniert haben. Der Task dazu ist:

task versionTxt()  {
    description = "Create a version.txt file with some information about the build."
    outputs.upToDateWhen { false }
    doLast {
        new File("version.txt").text = """
Version: $version
Revision: ${Grgit.open(dir: '.').head().id}
Buildtime: ${new SimpleDateFormat("dd-MM-yyyy HH:mm:ss").format(new Date())}
Application-name: sogis-interlis-repository
"""
    }
}

XSLT / XSL-FO #2 - PDF4OEREB

Mon, 31 Dec 2018 00:00:00 +0000

Nun ist es doch passiert, ein paar Feierabende und die freien Tage um Weihnachten herum investiert und - voilà - der ÖREB-PDF-Auszug mit XSLT und XSL-FO: https://gitlab.com/sogis/pdf4oereb. Will oder muss man es bloss für die eigene katasterverantwortliche Stelle umsetzen, ist es relativ schnell getan. Soll es generischer werden, muss man sich auch um die zeitintensiveren Details kümmern.

Die Umwandlung einer XML-Datei in eine PDF-Datei mit XSLT und XSL-FO besteht immer aus zwei Schritten. Im ersten wird die XML-Datei (in unserem Fall die DATA-Extract-XML-Datei) mit einem sogenannten Stylesheet in eine XSL-FO-Datei transformiert. Dies geschieht mit XSLT und XPath. Die XSL-FO-Datei wird im zweiten Schritt in eine PDF-Datei umformatiert. Die Hauptaufgabe besteht also im Erstellen des Stylesheets mit dem die erste Transformation durchgeführt werden kann. Dazu muss man sich in XSLT und XPath reinkämpfen.

Im Grossen und Ganzen ist das benötigte Stylesheet für das ÖREB-PDF keine Raketenwissenschaft. Trotzdem gelangt man an einen Punkt, wo es anscheinend mit purem XSLT nicht mehr weiter geht. Ein solches Beispiel sind die codierten URL in der XML-Datei: http%3A%2F%2Fwww.binningen.ch. Diese URL soll nicht so im PDF gerendert werden, sondern als http://www.binningen.ch. Man könnte sich mühsam eine eigene XSLT-Funktion im Stylesheet schreiben oder man weicht (mit Saxon) auf sogenannte extension functions aus. Dies sind Funktionen, welche man selber in Java implementiert und auf die man anschliessend in der XSLT-Transformation zurückgreifen kann. In unserem Beispiel ein URL-Decoder. Dazu muss ein Inferface implementiert werden. In einer Bezahlversion von Saxon wäre dieses sehr einfache Beispiel noch einfacher umsetzbar. Denn hier bestünde die Möglichkeit direkt in XSLT auf einzelne Java-Methoden zurückzugreifen.

Neben dem Decodieren der URL, musste ich noch vier weitere Funktionen in Java schreiben:

Apache FOP bekundet anscheinend Mühe mit 8bit-PNG-Bildern. Jedenfalls wurden einige (nicht alle waren betroffen) Legendensymbole eines Kantons, der sie als 8bit-PNG ausliefert nicht im PDF gerendert. Eine fixSymbol-Funktion wandelt die 8bit-Bilder in 24bit-Bilder um. Diese verursachen keine Probleme mehr.
Die Bandierung des Grundstückes, der Nordpfeil und der Massstabsbalken werden in einem «Overlay-Image» für die spätere Verwendung (Punkt 3. und 4.) gerendert. Die Geometrie des Grunstückes und die Georeferenzierung des Kartenausschnittes müssen in diesem Fall im XML mitgeliefert werden.
Kartenausschnitt der Titelseite: Zusammenfügen des in Punkt 2 erstellten Overlay-Images und des Kartenausschnittes der Titelseite, der im XML mitgeliefert wird (PlanForLandRegisterMainPage).
Zusammenfügen der Kartenausschnitte der einzelnen ÖREB (RestrictionOnLandownership) und Überlagern des Planes für das Grundbuch und des Overlay-Images.

Diese insgesamt fünf zusätzlichen Funktionen müssen dem XSLT-Transformer bekannt gemacht werden. D.h. sie müssen im CLASSPATH sein, damit Java sie findet und sie müssen beim XSLT-Transformer registriert werden. Das Registrieren kann über eine Config-Datei gemacht werden, was bei mir aber nur funktioniert hat, wenn sie ein bestimmtes Interface implementieren. Meine extension functions implementieren jedoch das einfachere Interface. Aus diesem Grund können die Funktionen nicht mit dem Standalone-Tool von Saxon verwendet werden. Anhand der Dokumentation bin ich mir aber auch nicht sicher, ob das überhaupt mit der OpenSource-Edition funktionieren darf. Testeshalber hatte es das jedenfalls. Weil ich im Grunde sowieso eine Bibliothek schreiben will, welche die gesamte Umwandlung vornimmt, ist das Nicht-Funktionieren mit dem Standalone-Tool nicht weiter tragisch. Für den Notfall habe ich eine kleines Programm geschrieben, das genau das macht (XML→PDF). Eventuell erleichtert es die Entwicklung des Stylesheets, wenn man nichts mehr an den extension functions rumschrauben muss.

Die Bilder, Logos und Symbole des XML-Auszuges können entweder eingebettet werden (als Base64-String) oder als WMS-GetMap-Request resp. URL referenziert werden. Die XSLT-Transformation versucht zuerst das eingebettete Bild zu finden, falls es nicht vorhanden ist, wird das referenzierte Bild verwendet.

«Im Prinzip» unterstützt die Transformation bereits mehrere Sprachen. Eine XSLT-Transformation ist gut parametrisierbar. Die statischen Texte (z.B. der Titel des Dokumentes) werden in Übersetzungsdateien (auch XML) ausgelagert. Je nach Parameter wird die passende Übersetzungsdatei gewählt. Die dynamischen Inhalte sind bereits MultilingualText-Elemente. Falls im Auszug mehrere Sprachelemente mitgeliefert werden, muss die entsprechende Sprache ausgewählt werden.

Herausfordernd war/ist die Gruppierung der einzelnen ÖREB (RestrictionOnLandownership). Damit ist gemeint, nach welchem Kriterium die ÖREB auf welche PDF-Seite kommen. Auf den ersten Blick ist alles klar. Es gibt 17 Themen, also maximal 17 PDF-Seiten (natürlich mehr, falls ein Thema aus Platzgründen auf zwei oder mehr Seiten gerendert werden muss). Die Weisung zum statischen Auszug lässt bereits - korrekterweise - Spielraum bei der Nutzungsplanung zu (wobei unnötig einschränkend). Dann könnte man auf die Idee kommen die Nutzungsplanung mit Subthemen abzubilden. Zwei meiner drei Beispiel-Kantone machen jedoch für die Nutzungplanung einzelne, eigene (Ober-)Themen. Ein Beispiel-Kanton macht es noch anders: Er verwendet zwar den LandUsePlan-Code aber unterschiedliche Texte dazu. Ob es hier ein richtig oder falsch gibt, weiss ich noch nicht. Wahrscheinlich mehrere richtig und hoffentlich einige falsch. Dass ein generisches Gruppieren inkl. gewünschter Sortierung in jedem Fall funktioniert, glaube ich in diesem Fall aber nicht mehr. Ziel für mich ist jedenfalls die Unterstützung von Subthemen, d.h. es wird zuerst nach Thema gruppiert und falls ein Thema noch zusätzliche Subthemen hat, wird nach diesen gruppiert.

Zwei Resultate der Umwandlung der XML-Datei in die PDF-Datei:

XML / PDF

Gut zu sehen ist der französische Titel und ein weiteres französisches Attribut («Organisme responsable du cadastre»). Für beide Texte habe ich als proof-of-concept französische Übersetzungen bereitgestellt.

XML / PDF

Wie eingangs erwähnt, denke ich, dass mit XSLT und XSL-FO der PDF-Auszug einfach zu erstellen ist, wenn man nur auf sich selber schauen mussen. Ich habe Testdatensätze dreier Kantone verwendet und der scheinbare Spielraum mit dem man das XML abfüllen kann/darf, scheint gross zu sein. D.h. kein Kanton hat es gleich gemacht. Bei einigen Feststellungen dürfte es sich wohl auch um ordinäre Bugs handeln. Aber sicher bin ich mir eigentlich fast nie. Einige Beispiele:

Kodierung von GML. Ohne es zu prüfen, scheint mir die unterschiedliche GML-Kodierung erlaubt zu sein. GML halt…
Symbole haben nicht die korrekte Grösse und das korrekte Längen- und Breitenverhältnis.
Die vom WMS gelieferten Bilder beinhalten bereits die Bandierung des Grundstückes und den Nordfpfeil und Massstabsbalken. Sollte meines Erachtens nicht so sein.
In OtherLegend eines RestrictionOnLandownership.Map-Elementes tauchen die Symbole der betroffenen ÖREB auch wieder auf. Ist für mich nicht plausibel.
LegalProvisions können sowohl direkt unter dem RestrictionOnLandownership-Element stehen oder als Verweis innerhalb eines LegalProvisions-Elementes. Das erscheint mir sinnvoll, wenn man innerhalb einer Rechtsvorschrift auf die gesetzliche Grundlage verweist.
Fehlende RestrictionOnLandownership-Elemente, falls es vom gleichen Typ (z.B. «Freihaltezone») mehrere Geometrien gibt. Oder falsche AreaShare-Werte.
Doppelte RestrictionOnLandownership-Elemente im XML: Auf dem Grundstück gibt es dann z.B. 200% Grundnutzung.
Falsch abgefüllte Information-Elemente im RestrictionOnLandownership-Element. Da gehört m.E. die Aussage rein, also «Wohnen W2» und nicht «Grundnutzung Gemeinde XY»
layerOpacity von Kartenausschnitten ist 0. D.h. sie sind 100% transparent und werden nicht dargestellt (wenn man sich daran halten würde).
Die extensions-Möglichkeit wird relativ häufig verwendet, sei es z.B. zum Speichern des LengthShare-Attributes oder zum Speichern der AreaUnit.

Man sieht: Fragen über Fragen.

Mehr Informationen zum Entwicklen und Ausführen des Programmes (Standalone oder als Web Service) gibt es im README.

Function as a Service #1 - Der kleinstmögliche INTERLIS-Webservice

Mon, 10 Dec 2018 00:00:00 +0000

Lange Zeit hatte ich überhaupt keinen Plan was genau eigentlich Serverless und/oder Function as as Service (FaaS) genau bringen soll. Serverless ist vielleicht auch ein doofer Begriff, da ja trotzdem irgendwo Server laufen müssen. Nur, dass ich mich genau nicht um Server kümmern muss, sondern ich sie als gegeben betrachten kann. FaaS deutet es dann besser an: Es geht um die Funktion. Also um die eigentliche Businesslogik. Zu guter Letzt heisst das für mich, dass ich mich nur noch darum kümmern brauche. Nicht mehr um (virtualiserte) Server, nicht mehr um Webserver in der meine Anwendung läuft, sondern nur noch um die reine Businesslogik. Was auch das Deployment vereinfachen kann.

Hat man das so halbwegs geschnallt (hoffe ich wenigstens), sucht man sich natürlich Aufgaben, die damit gelöst werden könnten. Interessanterweise gibt es tatsächlich einiges, das man so relativ elegant umsetzen kann. Ein kleines Beispiel ist ein INTERLIS-Webservice mit ilivalidator. Momentan stellen wir für die Büros, welche die Nutzungsplanung für uns digitalisieren, einen Webservice auf Basis von Spring Boot zur Verfügung. Die Anwendung wird gedockert und läuft zukünftig in der OpenShift-Umgebung des Kantons. Das Verhältnis zwischen eigentlicher Businesslogik und dem Rest ist krass: Die Prüfung der INTERLIS-Transferdatei sind bloss ein paar Zeilen Code, alles andere das x-fache.

Der Ablauf der Prüfung ist sehr einfach:

Benutzer lädt die INTERLIS-Transferdatei hoch.
Die Datei wird lokal gespeichert.
ilivalidator prüft die Datei und speichert das Logfile.
Das Logfile wird an den Benutzer zurückgesendet.

Sowohl Amazon, wie auch Google und Microsoft bieten auf ihren Plattformen FaaS an. Google ist raus, weil sie zur Zeit kein Java unterstützen. Amazon ist wohl am ältesten resp. erfahrensten, ist mir aber sogar noch unsympathischer als Microsoft… Ausschlaggebend war aber, dass ich auf die Schnelle besser verstanden habe, wie man Dateien hochladen kann. Das scheint nicht ganz so der Fokus dieser FaaS-Implementierungen zu sein. Oder aber es wird davon ausgegangen, dass die Daten in einen S3-Bucket (AWS) oder Blob-Storage (Azure?) hochgeladen werden und die Funktion dann durch den Upload getriggert wird. Das schien mir zum Ausprobieren dann doch arg kompliziert, auch wenn es vielleicht die nachhaltigere Variante wäre. Oracle hat mit Fn Project auch was am Start aber noch nicht live verfügbar, daher viel auch das weg. Bei Fn Project wird stark auf Docker gesetzt, was beim Entwicklen zur einer Docker-Image-Orgie ausartet. Die Fehlersuche dünkt mich so auch schwieriger, weil alles nur einem Container läuft.

Als erstes habe ich mir mit Vagrant eine virtuelle Maschine mit all den benötigten lokalen Azure-Tools gebastelt. Die lokale Entwicklungsumgebung von Azure hört auf dem Port 7071, d.h. man darf die Portweiterleitung für die virtuelle Maschine nicht vergessen. Läuft alles einwandfrei, kann die erste Java-Funktion entwickelt werden. Java für Azure Functions ist immer noch im sogenannten «Preview»-Status, d.h. im Gegensatz zu anderen Sprachen ist die funktionale Unterstützung eher bescheiden.

Mit Maven kann man sich ein Beispielprojekt erstellen lassen:

mvn archetype:generate -DarchetypeGroupId=com.microsoft.azure -DarchetypeArtifactId=azure-functions-archetype

Wenn nach der Region gefragt wird, wo die Funktion rattern soll, muss man auf Anhieb die richtige wählen. So wie ich es verstanden habe, kann man das nachträglich nicht mehr so einfach ändern. In der IDE der Wahl importiert man anschliessend das Maven-Projekt. Im einfachsten Fall schreibt man wirklich nur eine einzige Funktion. Der INTERLIS-Webservice sieht so aus:

public class Function {
    /**
     * This function listens at endpoint "/api/validate". Invoke it using "curl" command in bash:
     * _ curl --request POST --header "Content-Type:application/octet-stream" --data-binary @ch_254900.itf http://localhost:7071/api/validate&code={your function key}
     * Function Key is not needed when running locally, to invoke HttpTrigger deployed to Azure, see here(https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-http-webhook#authorization-keys) on how to get function key for your app.
     */
    @FunctionName("validate")
    public String run(
            @HttpTrigger(name = "req", methods = {HttpMethod.POST}, authLevel = AuthorizationLevel.FUNCTION, dataType="binary") HttpRequestMessage<Byte[]> req,
            final ExecutionContext context) {

        System.setProperty("user.home", "/tmp");

        try {
            byte[] byteFile = ArrayUtils.toPrimitive(req.getBody());
            File uploadedFile = File.createTempFile("upload", ".interlis");
            FileUtils.writeByteArrayToFile(uploadedFile, byteFile);

            String logFileName = uploadedFile.getAbsolutePath() + ".log";

            Settings settings = new Settings();
            settings.setValue(Validator.SETTING_ILIDIRS, Validator.SETTING_DEFAULT_ILIDIRS);
            settings.setValue(Validator.SETTING_LOGFILE, logFileName);

            Validator.runValidation(uploadedFile.getAbsolutePath(), settings);

            String logFileContent = new String(Files.readAllBytes(Paths.get(logFileName)));
            return logFileContent;
        } catch (Exception e) {
            e.printStackTrace();
            context.getLogger().info(e.getMessage());
            return e.getMessage();
        }
    }
}

Zeile 7: Mit dieser Annotation wird Name der Funktion, wie sie von Aussen aufrufbar ist, definiert.

Zeile 9: Mit HttpTrigger wird bestimmt, dass die Funktion durch einen HTTP-Aufruf getriggert wird. Es stehen noch andere Trigger zur Verfügung, z.B. eben Blobstorage oder Timer (was dann etwas wie einem Cronjob entspräche). authLevel definiert wie ich mich authorisieren muss. AuthorizationLevel.FUNCTION bedeutet, dass ich mich mit einem Token (aka «Function key») authorisieren muss, der an den Funktionsaufruf als GET-Parameter angehängt wird. HttpRequestMessage<Byte[]> req definiert die Input Bindings. In meinem Fall erwarte ich ein Byte-Array, weil ich eine Datei hochladen will. Hier wird es mit Java schon mal knifflig. Irgendwie ist hier noch nicht alles so wie es sein sollte oder wie ich es möchte. Einerseits sind noch spezifische Java-Bugs vorhanden und andererseits ist mir nicht ganz klar, warum man nicht Multipart-File-Uploads unterstützt. Vielleicht es es nur noch nicht umgesetzt oder aber man will es nicht unterstützen.

Zeile 12: ilivalidator resp. der INTERLIS-Compiler versucht einen lokalen Cache der benötigten Modelle im User-Home-Verzeichnis anzulegen. In der lokalen Entwicklungsumgebung hat das auch wunderbar funktioniert. War die Funktion aber auf Azure deployed, kam eine Fehlermeldung, dass das Verzeichnis nicht angelegt werden könne. Lustigerweise zeigt "user.home" auf Azure auf das C:\-Laufwerk. Workaround ist das Verändern des Properties. Ganz neu kann man im INTERLIS-Compiler (unreleased, resp. nur Snapshots) das Cache-Verzeichnis via ENV-Variable setzen.

Zeile 15 - 17: Das Speichern des Request-Bodies in einer Datei hat mich einiges an Zeit gekostet. Probleme machten natürlich wieder einmal die Umlaute. So scheint es jedenfalls zu funktionieren. Mit einem Multipart-File-Upload hat das nie solche Probleme gemacht.

Der Rest ist altbekannt und nicht Azure-relevant.

Lokal builden und starten kann ich die Funktion mit folgendem Befehl:

mvn clean package && mvn azure-functions:run

Mit curl kann ich die Funktion testen:

curl --request POST --header "Content-Type:application/octet-stream" --data-binary @ch_254900.itf http://localhost:7071/api/validate

Einen ordinären Mulitpart-Form-File-Upload würde ich mit -F file=@ch_254900.itf anstelle von --data-binary @ch_254900.itf machen. Wenn ich das - auch mit korrektem Header - probiere, schaffe ich das Parsen den Request-Bodies nicht und die Umlaute funktionieren auch nicht. Vielleicht geht das schon, wenn man in dieser Thematik versierter ist.

Das Resultat des curl-Aufrufes ist der Inhalt der ilivalidator-Logdatei.

Wenn ich die Funktion nun auf Azure deployen will, muss ich mich zuerst auf der Konsole mit az login einloggen. Komischerweise öffnet sich ein Browser, wo man anschliessend die Credentials eintippen muss. Ich gehe davon, dass das auch ohne GUI geht. Deployen geht mit Maven:

mvn azure-functions:deploy

Beim allerersten Mal dauert das relativ lange, weil komplett alles angelegt werden muss. Redeployments gehen viel schneller. Wenn die Funktion mit einem Function key (den man im Azure Web-Portal findet) geschützt ist, sieht der Aufruf so aus:

curl --request POST --header "Content-Type:application/octet-stream" --data-binary @ch_254900.itf https://ilivalidator-functions-20181205142252080.azurewebsites.net/api/validate?code=<my function key>

Das Schöne an den Azure Functions ist, dass man nur bezahlt wenn sie wirklich aufgerufen werden. Man zahlt etwas pro Aufruf und für die Ausführungsdauer. Es gibt auch einen «Free Grant» pro Monat, der gemäss unserer Benutzerstatistik völlig ausreichen würde. Hier sieht man bereits einen Vorteil von FaaS.

Wo Licht ist, ist auch Schatten:

Man kann niemandem zumuten, dass man mit curl die Daten hochladen muss. Es fehlt ein einfaches GUI resp. eine einfache Webseite zum Hochladen der Dateien. Vielleicht kann man die Webseite sogar in einem Storage auf Azure hosten, dann wäre man wieder fein raus.
Es gibt sowohl Limits was die Uploadgrösse wie auch die Ausführungszeit betrifft. Dauert die Ausführung länger oder will man grössere Dateien hochladen, muss man andere Wege mit Azure finden.
Performance ist auf den ersten Blick so lala. Vergleiche mit AWS Lambda zeigen, dass da tatsächlich noch Aufholbedarf ist. Wie matchentscheidend das ist, kommt natürlich auf den Use Case an.

XSLT / XSL-FO #1 - Mein Hammer. Wo sind die Nägel?

Sun, 9 Dec 2018 00:00:00 +0000

Wie wahrscheinlich bei vielen anderen auch, gibt es bei uns für verschiedene Layer im Web GIS Client zusätzliche PDF-Auszüge. Wir nennen sie Objektblätter und sie sind in der Regel einem einzelnen Objekt zugewiesen. Oder anders formuliert: Die Informationen eines Objektes werden aufgehübscht und angereichtert mit z.B. Fotos und einem Übersichtskärtli in einer PDF-Datei gerendert.

Geotope: Kartenausschnitt / Objektblatt
Grundstücksbeschrieb: Kartenausschnitt / Objektblatt

In einigen Fällen ist der PDF-Auszug nicht direkt an ein Objekt gebunden, sondern vielmehr abhängig vom Ort, wo der Benutzer in die Karte geklickt hat. In diesem Fall ähnelt es dem ÖREB-Auszug. Wobei die Unterschiede im Prinzip egal sind, da es schlussendlich praktisch auf das Gleiche herauskommt. Der Benutzer klickt in die Karte, im Hintergrund werden die Daten zusammengesucht und anschliessend als PDF zurückgeliefert.

Für diesen Arbeitsschritt setzen wir zur Zeit JasperReports ein. Damit können wir auf Datenbanken und Filesysteme (für Fotos etc.) zugreifen. Ebenfalls möglich sind WMS-Request, um die Übersichtskarten ins PDF zu bringen. Soweit funktioniert das ganz passabel. Der grösste Mehrwert ist jedenfalls, dass wir im Gegensatz zu früher die PDF-Auszüge immer gleich machen.

Der ÖREB-Kataster mit seinem Webservice hat da einen leicht saubereren Ansatz: Es gibt einen «Rohdatenoutput» in den Formaten XML und JSON, und einen «lesbaren» Output im PDF-Format. Ich habe natürlich genau nichts gewonnen, wenn ich das XML und das PDF komplett separiert herstelle. Sinnvoller ist es das XML als Input für das PDF zu verwenden. Dann weiss ich haargenau, dass sowohl XML wie auch das PDF auf den selben Daten beruhren und nicht durch unterschiedliche Datenbankqueries oder Businesslogik im Webservice zu stande gekommen sind.

Am Beispiel unseres Grundstückbeschriebs habe ich den «ÖREB-Auszugs-Ansatz» komplett durchgespielt:

Erstellen des XML-Schemas
XML-Output mit JAXB
Transformieren der XML-Datei in eine XSL-FO-Datei mit einem XSLT-Prozessor (Saxon).
Umwandeln/Formatieren der XSL-FO-Datei in ein PDF mit einem Formatting Objects Processor (Apache Fop).

Das Ganze noch eingepackt in eine Spring Boot Applikation, damit ähnliche Aufrufe wie beim ÖREB-Webservice möglich sind.

Das XSD kann man sich in Eclipse zusammenklicken. Nach längerem Suchen habe ich nichts besseres gefunden (jedenfalls nichts kostenloses):

JAXB erlaubt es mir mich nicht um das XML-Format zu kümmern. Ich kann mich auf die eigentliche Businesslogik konzentrieren, in diesem Fall auf das Zusammensuchen der Informationen in der Datenbank für das gewählte Grundstück und muss diese Informationen bloss in dumme Java-Klassen schreiben. Das Umformatieren der Java-Objekte nach XML übernimmt JAXB. Dafür muss ich als erstes aus dem XML-Schema die Java-Klassen herstellen. Dazu reicht folgender Aufruf:

xjc -b binding.xjb -extension Extract.xsd

Die -b-Option ist notwendig, damit das XML-Rootelement korrekt annnotiert wird. Fehlt die Option wirft Spring Boot auf den ersten Blick eine nicht ganz einfach verständliche Fehlermeldung. Das Resultat des Aufrufes sind in meinem Fall sechs Java-Klassen:

Für Gradle gibt es ein xjc-Plugin. Die Anwendung ist einfach:

xjcGenerate {
    source = fileTree('src/main/schema') { include '*.xsd' }
    bindingFiles = fileTree('src/main/schema') { include '*.xjb' }
    outputDirectory = file('src/generated/java')
    extension = true
}

Es steht jetzt ein xjcGenerate-Task zur Verfügung.

Was jetzt folgt ist das Zusammensuchen der Informationen mit ein paar SQL-Queries und das Abfüllen und Zusammenstöpseln der soeben erstellen Java-Klassen. Dem Spring Boot Controller reicht als Return-Value sogar nur eine «Root-Klasse» und er macht das Marshalling automatisch. Der Aufruf

http://localhost:8887/parcel/extract/xml/CH310663327779

liefert das folgende XML zurück: (Das base64-Encoding der Bilder habe ich hier gekürzt. Im verlinkten XML sind sie vorhanden.)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<GetExtractByIdResponse xmlns="http://geo.so.ch/schema/AGI/LandRegisterParcelDescription/1.0/Extract">
  <Extract>
    <CantonalLogo>iVBORw0KGgoAAAANSUhEUgAABLAAAACBCAAAAAD1IxwIAAAABGdBTUEAALGPC/xhBQAADPNpQ0NQa0NHQ29s....</CantonalLogo>
    <ResponsibleOffice>
      <Name>Amt für Geoinformation</Name>
      <OfficeAtWeb>http://agi.so.ch</OfficeAtWeb>
      <Email>agi@bd.so.ch</Email>
      <Street>Rötistrasse</Street>
      <Number>4</Number>
      <PostalCode>4501</PostalCode>
      <City>Solothurn</City>
      <Phone>032 627 75 92</Phone>
    </ResponsibleOffice>
    <RealEstate>
      <Number>680</Number>
      <IdentND>SO0200002513</IdentND>
      <EGRID>CH310663327779</EGRID>
      <LocalNames>Brunngrabenacker, Oberstmatt, Rumi, Rütiacker</LocalNames>
      <LandCoverShare>
        <Type>Acker_Wiese</Type>
        <Area>7194</Area>
      </LandCoverShare>
      <LandCoverShare>
        <Type>Gartenanlage</Type>
        <Area>1623</Area>
      </LandCoverShare>
      <LandCoverShare>
        <Type>Gebaeude</Type>
        <Area>1606</Area>
      </LandCoverShare>
      <LandCoverShare>
        <Type>Gebaeudeerschliessung</Type>
        <Area>2580</Area>
      </LandCoverShare>
      <LandCoverShare>
        <Type>Obstkultur</Type>
        <Area>48714</Area>
      </LandCoverShare>
      <LandCoverShare>
        <Type>uebrige_Intensivkultur</Type>
        <Area>3358</Area>
      </LandCoverShare>
      <SurveyorOffice>
        <Name>Reto Meile</Name>
        <OfficeAtWeb>www.w-h.ch</OfficeAtWeb>
        <Email>admin@w-h.ch</Email>
        <Line1>W+H AG</Line1>
        <Street>Blümlisalpstrasse</Street>
        <Number>6</Number>
        <PostalCode>4562</PostalCode>
        <City>Biberist</City>
        <Phone>032 671 26 30</Phone>
      </SurveyorOffice>
      <LandRegisterOffice>
        <Name>Amtschreiberei Region Solothurn</Name>
        <OfficeAtWeb>www.so.ch/verwaltung/finanzdepartement/grundbuchaemter/</OfficeAtWeb>
        <Email>gb.so@fd.so.ch</Email>
        <Line1>Grundbuchamt</Line1>
        <Street>Rötistrasse</Street>
        <Number>4</Number>
        <PostalCode>4501</PostalCode>
        <City>Solothurn</City>
        <Phone>032 627 75 11</Phone>
      </LandRegisterOffice>
      <Type>Liegenschaft</Type>
      <Municipality>Biberist</Municipality>
      <SubunitOfLandRegister>Biberist</SubunitOfLandRegister>
      <LandRegistryArea>65076</LandRegistryArea>
      <Map>iVBORw0KGgoAAAANSUhEUgAACGYAAAoDCAYAAAB/VcSAAACAAElEQVR42uzdBZiUVfs/cLeXhWVZukGlVLo7pQQE6....</Map>
    </RealEstate>
    <CreationDate>2018-12-08T18:01:10.592+01:00</CreationDate>
  </Extract>
</GetExtractByIdResponse>

Das Umwandeln der XML-Datei in die PDF-Datei geschieht in zwei Schritten. Der erste Schritt ist das Transformieren der XML-Datei in eine XSL-FO-Datei (ebenfalls eine XML-Datei), welche die eigentlichen Anweisungen (Layout, Styling etc.) enthält, damit ein FO-Prozessor aus dieser Zwischen-XML-Datei das PDF rendern kann. Ohne grosse Erfahrung ist es einfacher, das ganze Rumtransformieren zuerst stand-alone auf der Konsole zu machen und die Integration in die Spring Boot Applikation erst zu machen, wenn man etwas funktionierendes hat.

Für den ersten Schritt verwende ich Saxon als XSLT-Prozessor. Das Wichtigste für die Umwandlung ist aber ein Stylesheet (*.xslt), das die Anweisung für die Transformation enthält:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:extract="http://geo.so.ch/schema/AGI/LandRegisterParcelDescription/1.0/Extract" exclude-result-prefixes="extract" version="1.0">
  <xsl:output method="xml" indent="yes"/>
  <xsl:decimal-format name="swiss" decimal-separator="." grouping-separator="'"/>
  <xsl:template match="extract:GetExtractByIdResponse">
    <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <fo:layout-master-set>
        <fo:simple-page-master master-name="mainPage" page-height="297mm" page-width="210mm" margin-top="12mm" margin-bottom="12mm" margin-left="15mm" margin-right="12mm">
          <fo:region-body margin-top="45mm" background-color="#FFFFFF"/>
          <fo:region-before extent="40mm" background-color="#FFFFFF"/>
          <fo:region-after extent="10mm" background-color="#FFFFFF"/>
        </fo:simple-page-master>
      </fo:layout-master-set>
      <xsl:apply-templates/>
    </fo:root>
  </xsl:template>
  <xsl:template match="extract:Extract">
    <fo:page-sequence master-reference="mainPage" id="my-sequence-id">
      <fo:static-content flow-name="xsl-region-before">
        <fo:block>
          <fo:block-container absolute-position="absolute" top="6.7mm" left="0mm" line-height="1em" background-color="#FFFFFF">
            <fo:block font-size="10pt" font-style="italic" font-weight="700" font-family="Frutiger">
              <xsl:value-of select="extract:ResponsibleOffice/extract:Name"/>
            </fo:block>
            <fo:block font-size="10pt" font-style="italic" font-weight="400" font-family="Frutiger" margin-left="6mm" margin-top="1mm">
              <fo:block>
                <xsl:value-of select="extract:ResponsibleOffice/extract:Street"/>
                <xsl:text> </xsl:text>
                <xsl:value-of select="extract:ResponsibleOffice/extract:Number"/>
              </fo:block>
              <fo:block>
                <xsl:value-of select="extract:ResponsibleOffice/extract:PostalCode"/>
                <xsl:text> </xsl:text>
                <xsl:value-of select="extract:ResponsibleOffice/extract:City"/>
              </fo:block>
              <fo:block>
                <xsl:value-of select="extract:ResponsibleOffice/extract:Phone"/>
              </fo:block>
              <fo:block>
                <xsl:value-of select="extract:ResponsibleOffice/extract:Email"/>
              </fo:block>
              <fo:block>
                <xsl:value-of select="extract:ResponsibleOffice/extract:OfficeAtWeb"/>
              </fo:block>
            </fo:block>
          </fo:block-container>
          <fo:block-container absolute-position="absolute" top="0mm" left="123mm" background-color="#FFFFFF">
            <fo:block>
              <fo:external-graphic height="6.7mm" width="60mm" content-width="scale-to-fit" content-height="scale-to-fit">
                <xsl:attribute name="src">
                  <xsl:text>url('data:</xsl:text>
                  <xsl:text>image/png;base64,</xsl:text>
                  <xsl:value-of select="extract:CantonalLogo"/>
                  <xsl:text>')</xsl:text>
                </xsl:attribute>
              </fo:external-graphic>
            </fo:block>
          </fo:block-container>
        </fo:block>
      </fo:static-content>
      <fo:static-content flow-name="xsl-region-after">
        <fo:table table-layout="fixed" width="100%" margin-top="4mm" font-size="7pt" font-style="italic" font-weight="400" font-family="Frutiger">
          <fo:table-column column-width="50%"/>
          <fo:table-column column-width="50%"/>
          <fo:table-body>
            <fo:table-row>
              <fo:table-cell>
                <fo:block>
                  <xsl:value-of select="format-dateTime(extract:CreationDate,'[Y0001]-[M01]-[D01] [H01]:[m01]:[s01]')"/>
                </fo:block>
              </fo:table-cell>
              <fo:table-cell text-align="right">
                <fo:block>Seite <fo:page-number/>/<fo:page-number-citation-last ref-id="my-sequence-id"/></fo:block>
              </fo:table-cell>
            </fo:table-row>
          </fo:table-body>
        </fo:table>
      </fo:static-content>
      <xsl:apply-templates select="extract:RealEstate"/>
    </fo:page-sequence>
  </xsl:template>
  <xsl:template match="extract:RealEstate">
    <fo:flow flow-name="xsl-region-body">
      <fo:block-container wrap-option="wrap" hyphenate="false" hyphenation-character="-" font-weight="700" font-size="14pt" font-family="Frutiger">
        <fo:table table-layout="fixed" width="100%">
          <fo:table-column column-width="90mm"/>
          <fo:table-column column-width="90mm"/>
          <fo:table-body>
            <fo:table-row>
              <fo:table-cell>
                <fo:block>Grundstücksbeschrieb</fo:block>
              </fo:table-cell>
              <fo:table-cell>
                <fo:block>GB-Nr. <xsl:value-of select="extract:Number"/></fo:block>
              </fo:table-cell>
            </fo:table-row>
          </fo:table-body>
        </fo:table>
      </fo:block-container>
      <fo:block-container wrap-option="wrap" hyphenate="false" hyphenation-character="-" font-weight="400" font-size="10pt" font-family="Frutiger">
        <fo:table table-layout="fixed" width="100%" margin-top="8mm">
          <fo:table-column column-width="40mm"/>
          <fo:table-column column-width="30mm"/>
          <fo:table-column column-width="20mm"/>
          <fo:table-column column-width="40mm"/>
          <fo:table-column column-width="30mm"/>
          <fo:table-body>
            <fo:table-row>
              <fo:table-cell font-weight="700" padding-top="2mm">
                <fo:block>Gemeinde:</fo:block>
              </fo:table-cell>
              <fo:table-cell text-align="right" padding-top="2mm">
                <fo:block>
                  <xsl:value-of select="extract:Municipality"/>
                </fo:block>
              </fo:table-cell>
              <fo:table-cell text-align="right" padding-top="2mm">
                <fo:block/>
              </fo:table-cell>
              <fo:table-cell font-weight="700" padding-top="2mm">
                <fo:block>EGRID:</fo:block>
              </fo:table-cell>
              <fo:table-cell text-align="right" padding-top="2mm">
                <fo:block>
                  <xsl:value-of select="extract:EGRID"/>
                </fo:block>
              </fo:table-cell>
            </fo:table-row>
            <fo:table-row>
              <fo:table-cell font-weight="700" padding-top="2mm">
                <fo:block>Grundbuch:</fo:block>
              </fo:table-cell>
              <fo:table-cell text-align="right" padding-top="2mm">
                <fo:block>
                  <xsl:value-of select="extract:SubunitOfLandRegister"/>
                </fo:block>
              </fo:table-cell>
              <fo:table-cell text-align="right" padding-top="2mm">
                <fo:block/>
              </fo:table-cell>
              <fo:table-cell font-weight="700" padding-top="2mm">
                <fo:block>NBIdent:</fo:block>
              </fo:table-cell>
              <fo:table-cell text-align="right" padding-top="2mm">
                <fo:block>
                  <xsl:value-of select="extract:IdentND"/>
                </fo:block>
              </fo:table-cell>
            </fo:table-row>
          </fo:table-body>
        </fo:table>
      </fo:block-container>
      <fo:block-container wrap-option="wrap" hyphenate="false" hyphenation-character="-" font-weight="400" font-size="10pt" font-family="Frutiger">
        <fo:table table-layout="fixed" width="100%" margin-top="12mm">
          <fo:table-column column-width="40mm"/>
          <fo:table-column column-width="30mm"/>
          <fo:table-body>
            <fo:table-row>
              <fo:table-cell font-weight="700" padding-top="2mm">
                <fo:block>Grundstücksart:</fo:block>
              </fo:table-cell>
              <fo:table-cell text-align="right" padding-top="2mm">
                <fo:block>
                  <xsl:value-of select="extract:Type"/>
                </fo:block>
              </fo:table-cell>
            </fo:table-row>
            <fo:table-row>
              <fo:table-cell font-weight="700" padding-top="2mm">
                <fo:block>Grundstücksfläche:</fo:block>
              </fo:table-cell>
              <fo:table-cell text-align="right" padding-top="2mm">
                <fo:block line-height-shift-adjustment="disregard-shifts"><xsl:value-of select="format-number(extract:LandRegistryArea, &quot;#'###&quot;, &quot;swiss&quot;)"/> m<fo:inline baseline-shift="super" font-size="60%">2</fo:inline></fo:block>
              </fo:table-cell>
            </fo:table-row>
          </fo:table-body>
        </fo:table>
      </fo:block-container>
      <fo:block-container wrap-option="wrap" hyphenate="false" hyphenation-character="-" font-weight="400" font-size="10pt" font-family="Frutiger">
        <fo:table table-layout="fixed" width="100%" margin-top="12mm">
          <fo:table-column column-width="90mm"/>
          <fo:table-column column-width="90mm"/>
          <fo:table-body>
            <fo:table-row>
              <fo:table-cell font-weight="700" padding-top="2mm">
                <fo:block>Bodenbedeckung:</fo:block>
              </fo:table-cell>
              <fo:table-cell font-weight="700" padding-top="2mm">
                <fo:block>Flurnamen:</fo:block>
              </fo:table-cell>
            </fo:table-row>
            <fo:table-row>
              <fo:table-cell font-weight="400" padding-top="1mm">
                <fo:block>
                  <fo:table table-layout="fixed" width="100%" margin-top="0mm">
                    <fo:table-column column-width="50mm"/>
                    <fo:table-column column-width="20mm"/>
                    <fo:table-column column-width="10mm"/>
                    <fo:table-body border-width="0pt" border-style="solid">
                      <xsl:for-each select="extract:LandCoverShare">
                        <xsl:sort select="extract:Type"/>
                        <fo:table-row border-width="0pt" border-style="solid">
                          <fo:table-cell padding-top="1mm"><fo:block><xsl:value-of select="extract:Type"/></fo:block>
                       </fo:table-cell>
                          <fo:table-cell padding-top="1mm"><fo:block text-align="right"><xsl:value-of select="format-number(extract:Area, &quot;#'###&quot;, &quot;swiss&quot;)"/></fo:block>
                       </fo:table-cell>
                          <fo:table-cell padding-top="1mm"><fo:block margin-left="1mm" line-height-shift-adjustment="disregard-shifts">m<fo:inline baseline-shift="super" font-size="60%">2</fo:inline></fo:block>
                       </fo:table-cell>
                        </fo:table-row>
                      </xsl:for-each>
                      <fo:table-row border-width="0pt" border-style="solid" font-weight="400" font-style="italic">
                        <fo:table-cell padding-top="1mm"><fo:block>Total</fo:block>
                        </fo:table-cell>
                        <fo:table-cell padding-top="1mm"><fo:block text-align="right"><xsl:value-of select="format-number(sum(extract:LandCoverShare/extract:Area), &quot;#'###&quot;, &quot;swiss&quot;)"/></fo:block>
                        </fo:table-cell>
                        <fo:table-cell padding-top="1mm"><fo:block margin-left="1mm" line-height-shift-adjustment="disregard-shifts">m<fo:inline baseline-shift="super" font-size="60%">2</fo:inline></fo:block>
                        </fo:table-cell>
                      </fo:table-row>
                    </fo:table-body>
                  </fo:table>
                </fo:block>
              </fo:table-cell>
              <fo:table-cell font-weight="400" padding-top="2mm">
                <fo:block>
                  <xsl:value-of select="extract:LocalNames"/>
                </fo:block>
              </fo:table-cell>
            </fo:table-row>
          </fo:table-body>
        </fo:table>
      </fo:block-container>
      <fo:block-container wrap-option="wrap" hyphenate="false" hyphenation-character="-" font-weight="400" font-size="10pt" font-family="Frutiger">
        <fo:table table-layout="fixed" width="100%" margin-top="12mm">
          <fo:table-column column-width="90mm"/>
          <fo:table-column column-width="90mm"/>
          <fo:table-body>
            <fo:table-row>
              <fo:table-cell font-weight="700" padding-top="2mm">
                <fo:block>Grundbuchamt:</fo:block>
              </fo:table-cell>
              <fo:table-cell font-weight="700" padding-top="2mm">
                <fo:block>Nachführungsgeometer:</fo:block>
              </fo:table-cell>
            </fo:table-row>
            <fo:table-row>
              <fo:table-cell font-weight="400" padding-top="2mm">
                <fo:block linefeed-treatment="preserve">
                    <xsl:value-of select="extract:LandRegisterOffice/extract:Name"/>
                    <xsl:text>&#xA;</xsl:text>
                    <xsl:value-of select="extract:LandRegisterOffice/extract:Line1"/>
                    <xsl:text>&#xA;</xsl:text>
                    <xsl:value-of select="extract:LandRegisterOffice/extract:Street"/>
                    <xsl:text> </xsl:text>
                    <xsl:value-of select="extract:LandRegisterOffice/extract:Number"/>
                    <xsl:text>&#xA;</xsl:text>
                    <xsl:value-of select="extract:LandRegisterOffice/extract:PostalCode"/>
                    <xsl:text> </xsl:text>
                    <xsl:value-of select="extract:LandRegisterOffice/extract:City"/>
                    <xsl:text>&#xA;</xsl:text>
                    <xsl:text>&#xA;</xsl:text>
                    <xsl:text>Telefon </xsl:text><xsl:value-of select="extract:LandRegisterOffice/extract:Phone"/>
                    <xsl:text>&#xA;</xsl:text>
                    <xsl:value-of select="extract:LandRegisterOffice/extract:Email"/>
                    <xsl:text>&#xA;</xsl:text>
                    <xsl:value-of select="extract:LandRegisterOffice/extract:OfficeAtWeb"/>
                </fo:block>
              </fo:table-cell>
              <fo:table-cell font-weight="400" padding-top="2mm">
                <fo:block linefeed-treatment="preserve">
                    <xsl:value-of select="extract:SurveyorOffice/extract:Name"/>
                    <xsl:text>&#xA;</xsl:text>
                    <xsl:value-of select="extract:SurveyorOffice/extract:Line1"/>
                    <xsl:if test="extract:SurveyorOffice/extract:Line2">
                        <xsl:text>&#xA;</xsl:text>
                        <xsl:value-of select="extract:SurveyorOffice/extract:Line2"/>
                    </xsl:if>
                    <xsl:text>&#xA;</xsl:text>
                    <xsl:value-of select="extract:SurveyorOffice/extract:Street"/>
                    <xsl:text> </xsl:text>
                    <xsl:value-of select="extract:SurveyorOffice/extract:Number"/>
                    <xsl:text>&#xA;</xsl:text>
                    <xsl:value-of select="extract:SurveyorOffice/extract:PostalCode"/>
                    <xsl:text> </xsl:text>
                    <xsl:value-of select="extract:SurveyorOffice/extract:City"/>
                    <xsl:text>&#xA;</xsl:text>
                    <xsl:text>&#xA;</xsl:text>
                    <xsl:text>Telefon </xsl:text><xsl:value-of select="extract:SurveyorOffice/extract:Phone"/>
                    <xsl:text>&#xA;</xsl:text>
                    <xsl:value-of select="extract:SurveyorOffice/extract:Email"/>
                    <xsl:text>&#xA;</xsl:text>
                    <xsl:value-of select="extract:SurveyorOffice/extract:OfficeAtWeb"/>
                </fo:block>
              </fo:table-cell>
            </fo:table-row>
          </fo:table-body>
        </fo:table>
      </fo:block-container>
      <fo:block-container page-break-before="always" margin="0mm" padding="0mm" space-before="0mm">
        <fo:block margin="0mm" padding="0mm" space-before="0mm">
          <fo:external-graphic height="217mm" width="182mm" content-height="scale-to-fit" margin="0mm" padding="0mm" space-before="0mm" border="0.5pt solid black">
            <xsl:attribute name="src">
              <xsl:text>url('data:</xsl:text>
              <xsl:text>image/png;base64,</xsl:text>
              <xsl:value-of select="extract:Map"/>
              <xsl:text>')</xsl:text>
            </xsl:attribute>
          </fo:external-graphic>
        </fo:block>
      </fo:block-container>
    </fo:flow>
  </xsl:template>
</xsl:stylesheet>

Für das Entwicklen des Stylesheets muss man sowohl Wissen über XSLT wie auch über XSL-FO haben. XSLT-Wissen, das über apply-templates hinausgeht, wird benötigt wenn man z.B. eine For-Schleife über die Bodenbedeckungsanteile (LandCoverShare) anwenden will und die Summe über alle Anteile bilden möchte (Zeile 200ff.). XSL-FO-Wissen braucht man, um das PDF zu designen/stylen und die Daten am gewünschten Ort zu platzieren. Der Saxon-Befehl ist wie folgt:

java -jar saxon9he.jar -s:CH310663327779.xml -xsl:parceldescription_extract_fo.xslt -o:CH310663327779.fo

Das Resultat ist eine XSL-FO-Datei (base64 wiederum gekürzt):

<?xml version="1.0" encoding="UTF-8"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"
         xmlns:xsd="https://www.w3.org/2001/XMLSchema"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <fo:layout-master-set>
      <fo:simple-page-master master-name="mainPage"
                             page-height="297mm"
                             page-width="210mm"
                             margin-top="12mm"
                             margin-bottom="12mm"
                             margin-left="15mm"
                             margin-right="12mm">
         <fo:region-body margin-top="45mm" background-color="#FFFFFF"/>
         <fo:region-before extent="40mm" background-color="#FFFFFF"/>
         <fo:region-after extent="10mm" background-color="#FFFFFF"/>
      </fo:simple-page-master>
   </fo:layout-master-set>
   <fo:page-sequence master-reference="mainPage" id="my-sequence-id">
      <fo:static-content flow-name="xsl-region-before">
         <fo:block>
            <fo:block-container absolute-position="absolute"
                                top="6.7mm"
                                left="0mm"
                                line-height="1em"
                                background-color="#FFFFFF">
               <fo:block font-size="10pt"
                         font-style="italic"
                         font-weight="700"
                         font-family="Frutiger">Amt für Geoinformation</fo:block>
               <fo:block font-size="10pt"
                         font-style="italic"
                         font-weight="400"
                         font-family="Frutiger"
                         margin-left="6mm"
                         margin-top="1mm">
                  <fo:block>Rötistrasse 4</fo:block>
                  <fo:block>4501 Solothurn</fo:block>
                  <fo:block>032 627 75 92</fo:block>
                  <fo:block>agi@bd.so.ch</fo:block>
                  <fo:block>http://agi.so.ch</fo:block>
               </fo:block>
            </fo:block-container>
            <fo:block-container absolute-position="absolute"
                                top="0mm"
                                left="123mm"
                                background-color="#FFFFFF">
               <fo:block>
                  <fo:external-graphic height="6.7mm"
                                       width="60mm"
                                       content-width="scale-to-fit"
                                       content-height="scale-to-fit"
                                       src="url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAABLAAAACBCAAAAAD1IxwIAAAABGdBTUEAALGPC/xhBQ....')"/>
               </fo:block>
            </fo:block-container>
         </fo:block>
      </fo:static-content>
      <fo:static-content flow-name="xsl-region-after">
         <fo:table table-layout="fixed"
                   width="100%"
                   margin-top="4mm"
                   font-size="7pt"
                   font-style="italic"
                   font-weight="400"
                   font-family="Frutiger">
            <fo:table-column column-width="50%"/>
            <fo:table-column column-width="50%"/>
            <fo:table-body>
               <fo:table-row>
                  <fo:table-cell>
                     <fo:block>2018-12-08 18:01:10</fo:block>
                  </fo:table-cell>
                  <fo:table-cell text-align="right">
                     <fo:block>Seite <fo:page-number/>/<fo:page-number-citation-last ref-id="my-sequence-id"/>
                     </fo:block>
                  </fo:table-cell>
               </fo:table-row>
            </fo:table-body>
         </fo:table>
      </fo:static-content>
      <fo:flow flow-name="xsl-region-body">
         <fo:block-container wrap-option="wrap"
                             hyphenate="false"
                             hyphenation-character="-"
                             font-weight="700"
                             font-size="14pt"
                             font-family="Frutiger">
            <fo:table table-layout="fixed" width="100%">
               <fo:table-column column-width="90mm"/>
               <fo:table-column column-width="90mm"/>
               <fo:table-body>
                  <fo:table-row>
                     <fo:table-cell>
                        <fo:block>Grundstücksbeschrieb</fo:block>
                     </fo:table-cell>
                     <fo:table-cell>
                        <fo:block>GB-Nr. 680</fo:block>
                     </fo:table-cell>
                  </fo:table-row>
               </fo:table-body>
            </fo:table>
         </fo:block-container>
         <fo:block-container wrap-option="wrap"
                             hyphenate="false"
                             hyphenation-character="-"
                             font-weight="400"
                             font-size="10pt"
                             font-family="Frutiger">
            <fo:table table-layout="fixed" width="100%" margin-top="8mm">
               <fo:table-column column-width="40mm"/>
               <fo:table-column column-width="30mm"/>
               <fo:table-column column-width="20mm"/>
               <fo:table-column column-width="40mm"/>
               <fo:table-column column-width="30mm"/>
               <fo:table-body>
                  <fo:table-row>
                     <fo:table-cell font-weight="700" padding-top="2mm">
                        <fo:block>Gemeinde:</fo:block>
                     </fo:table-cell>
                     <fo:table-cell text-align="right" padding-top="2mm">
                        <fo:block>Biberist</fo:block>
                     </fo:table-cell>
                     <fo:table-cell text-align="right" padding-top="2mm">
                        <fo:block/>
                     </fo:table-cell>
                     <fo:table-cell font-weight="700" padding-top="2mm">
                        <fo:block>EGRID:</fo:block>
                     </fo:table-cell>
                     <fo:table-cell text-align="right" padding-top="2mm">
                        <fo:block>CH310663327779</fo:block>
                     </fo:table-cell>
                  </fo:table-row>
                  <fo:table-row>
                     <fo:table-cell font-weight="700" padding-top="2mm">
                        <fo:block>Grundbuch:</fo:block>
                     </fo:table-cell>
                     <fo:table-cell text-align="right" padding-top="2mm">
                        <fo:block>Biberist</fo:block>
                     </fo:table-cell>
                     <fo:table-cell text-align="right" padding-top="2mm">
                        <fo:block/>
                     </fo:table-cell>
                     <fo:table-cell font-weight="700" padding-top="2mm">
                        <fo:block>NBIdent:</fo:block>
                     </fo:table-cell>
                     <fo:table-cell text-align="right" padding-top="2mm">
                        <fo:block>SO0200002513</fo:block>
                     </fo:table-cell>
                  </fo:table-row>
               </fo:table-body>
            </fo:table>
         </fo:block-container>
         <fo:block-container wrap-option="wrap"
                             hyphenate="false"
                             hyphenation-character="-"
                             font-weight="400"
                             font-size="10pt"
                             font-family="Frutiger">
            <fo:table table-layout="fixed" width="100%" margin-top="12mm">
               <fo:table-column column-width="40mm"/>
               <fo:table-column column-width="30mm"/>
               <fo:table-body>
                  <fo:table-row>
                     <fo:table-cell font-weight="700" padding-top="2mm">
                        <fo:block>Grundstücksart:</fo:block>
                     </fo:table-cell>
                     <fo:table-cell text-align="right" padding-top="2mm">
                        <fo:block>Liegenschaft</fo:block>
                     </fo:table-cell>
                  </fo:table-row>
                  <fo:table-row>
                     <fo:table-cell font-weight="700" padding-top="2mm">
                        <fo:block>Grundstücksfläche:</fo:block>
                     </fo:table-cell>
                     <fo:table-cell text-align="right" padding-top="2mm">
                        <fo:block line-height-shift-adjustment="disregard-shifts">65'076 m<fo:inline baseline-shift="super" font-size="60%">2</fo:inline>
                        </fo:block>
                     </fo:table-cell>
                  </fo:table-row>
               </fo:table-body>
            </fo:table>
         </fo:block-container>
         <fo:block-container wrap-option="wrap"
                             hyphenate="false"
                             hyphenation-character="-"
                             font-weight="400"
                             font-size="10pt"
                             font-family="Frutiger">
            <fo:table table-layout="fixed" width="100%" margin-top="12mm">
               <fo:table-column column-width="90mm"/>
               <fo:table-column column-width="90mm"/>
               <fo:table-body>
                  <fo:table-row>
                     <fo:table-cell font-weight="700" padding-top="2mm">
                        <fo:block>Bodenbedeckung:</fo:block>
                     </fo:table-cell>
                     <fo:table-cell font-weight="700" padding-top="2mm">
                        <fo:block>Flurnamen:</fo:block>
                     </fo:table-cell>
                  </fo:table-row>
                  <fo:table-row>
                     <fo:table-cell font-weight="400" padding-top="1mm">
                        <fo:block>
                           <fo:table table-layout="fixed" width="100%" margin-top="0mm">
                              <fo:table-column column-width="50mm"/>
                              <fo:table-column column-width="20mm"/>
                              <fo:table-column column-width="10mm"/>
                              <fo:table-body border-width="0pt" border-style="solid">
                                 <fo:table-row border-width="0pt" border-style="solid">
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block>Acker_Wiese</fo:block>
                                    </fo:table-cell>
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block text-align="right">7'194</fo:block>
                                    </fo:table-cell>
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block margin-left="1mm" line-height-shift-adjustment="disregard-shifts">m<fo:inline baseline-shift="super" font-size="60%">2</fo:inline>
                                       </fo:block>
                                    </fo:table-cell>
                                 </fo:table-row>
                                 <fo:table-row border-width="0pt" border-style="solid">
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block>Gartenanlage</fo:block>
                                    </fo:table-cell>
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block text-align="right">1'623</fo:block>
                                    </fo:table-cell>
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block margin-left="1mm" line-height-shift-adjustment="disregard-shifts">m<fo:inline baseline-shift="super" font-size="60%">2</fo:inline>
                                       </fo:block>
                                    </fo:table-cell>
                                 </fo:table-row>
                                 <fo:table-row border-width="0pt" border-style="solid">
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block>Gebaeude</fo:block>
                                    </fo:table-cell>
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block text-align="right">1'606</fo:block>
                                    </fo:table-cell>
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block margin-left="1mm" line-height-shift-adjustment="disregard-shifts">m<fo:inline baseline-shift="super" font-size="60%">2</fo:inline>
                                       </fo:block>
                                    </fo:table-cell>
                                 </fo:table-row>
                                 <fo:table-row border-width="0pt" border-style="solid">
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block>Gebaeudeerschliessung</fo:block>
                                    </fo:table-cell>
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block text-align="right">2'580</fo:block>
                                    </fo:table-cell>
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block margin-left="1mm" line-height-shift-adjustment="disregard-shifts">m<fo:inline baseline-shift="super" font-size="60%">2</fo:inline>
                                       </fo:block>
                                    </fo:table-cell>
                                 </fo:table-row>
                                 <fo:table-row border-width="0pt" border-style="solid">
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block>Obstkultur</fo:block>
                                    </fo:table-cell>
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block text-align="right">48'714</fo:block>
                                    </fo:table-cell>
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block margin-left="1mm" line-height-shift-adjustment="disregard-shifts">m<fo:inline baseline-shift="super" font-size="60%">2</fo:inline>
                                       </fo:block>
                                    </fo:table-cell>
                                 </fo:table-row>
                                 <fo:table-row border-width="0pt" border-style="solid">
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block>uebrige_Intensivkultur</fo:block>
                                    </fo:table-cell>
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block text-align="right">3'358</fo:block>
                                    </fo:table-cell>
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block margin-left="1mm" line-height-shift-adjustment="disregard-shifts">m<fo:inline baseline-shift="super" font-size="60%">2</fo:inline>
                                       </fo:block>
                                    </fo:table-cell>
                                 </fo:table-row>
                                 <fo:table-row border-width="0pt"
                                               border-style="solid"
                                               font-weight="400"
                                               font-style="italic">
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block>Total</fo:block>
                                    </fo:table-cell>
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block text-align="right">65'075</fo:block>
                                    </fo:table-cell>
                                    <fo:table-cell padding-top="1mm">
                                       <fo:block margin-left="1mm" line-height-shift-adjustment="disregard-shifts">m<fo:inline baseline-shift="super" font-size="60%">2</fo:inline>
                                       </fo:block>
                                    </fo:table-cell>
                                 </fo:table-row>
                              </fo:table-body>
                           </fo:table>
                        </fo:block>
                     </fo:table-cell>
                     <fo:table-cell font-weight="400" padding-top="2mm">
                        <fo:block>Brunngrabenacker, Oberstmatt, Rumi, Rütiacker</fo:block>
                     </fo:table-cell>
                  </fo:table-row>
               </fo:table-body>
            </fo:table>
         </fo:block-container>
         <fo:block-container wrap-option="wrap"
                             hyphenate="false"
                             hyphenation-character="-"
                             font-weight="400"
                             font-size="10pt"
                             font-family="Frutiger">
            <fo:table table-layout="fixed" width="100%" margin-top="12mm">
               <fo:table-column column-width="90mm"/>
               <fo:table-column column-width="90mm"/>
               <fo:table-body>
                  <fo:table-row>
                     <fo:table-cell font-weight="700" padding-top="2mm">
                        <fo:block>Grundbuchamt:</fo:block>
                     </fo:table-cell>
                     <fo:table-cell font-weight="700" padding-top="2mm">
                        <fo:block>Nachführungsgeometer:</fo:block>
                     </fo:table-cell>
                  </fo:table-row>
                  <fo:table-row>
                     <fo:table-cell font-weight="400" padding-top="2mm">
                        <fo:block linefeed-treatment="preserve">Amtschreiberei Region Solothurn
Grundbuchamt
Rötistrasse 4
4501 Solothurn

Telefon 032 627 75 11
gb.so@fd.so.ch
www.so.ch/verwaltung/finanzdepartement/grundbuchaemter/</fo:block>
                     </fo:table-cell>
                     <fo:table-cell font-weight="400" padding-top="2mm">
                        <fo:block linefeed-treatment="preserve">Reto Meile
W+H AG
Blümlisalpstrasse 6
4562 Biberist

Telefon 032 671 26 30
admin@w-h.ch
www.w-h.ch</fo:block>
                     </fo:table-cell>
                  </fo:table-row>
               </fo:table-body>
            </fo:table>
         </fo:block-container>
         <fo:block-container page-break-before="always"
                             margin="0mm"
                             padding="0mm"
                             space-before="0mm">
            <fo:block margin="0mm" padding="0mm" space-before="0mm">
               <fo:external-graphic height="217mm"
                                    width="182mm"
                                    content-height="scale-to-fit"
                                    margin="0mm"
                                    padding="0mm"
                                    space-before="0mm"
                                    border="0.5pt solid black"
                                    src="url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAACGYAAAoDCAYAAAB/VcSAAACAAElEQVR42uzdBZiUVfs...')"/>
            </fo:block>
         </fo:block-container>
      </fo:flow>
   </fo:page-sequence>
</fo:root>

Der letzer Schritt ist die Umwandlung (oder das Formatieren) der XSL-FO-Datei in die PDF-Datei. Dazu kann man Apache Fop verwenden:

./fop-2.3/fop/fop -fo CH310663327779.fo -pdf CH310663327779.pdf -c fop.xconf

Die fop.xconf-Datei wird in meinem Fall benötigt, weil ich zusätzliche Schriftarten benötige.

Das Resultat ist so wie es Jasper nicht besser machen könnte:

Auf der ersten Seite sollten die Bodenbedeckungsanteile noch bündig mit den restlichen Informationen in der linken Hälfte sein. Auf der zweiten Seite ist die Amtsinformation im Header überflüssig. Aber das ist bloss noch einfaches Handwerk.

Das Highlighting des Grundstückes habe ich nicht vom WMS-Server machen lassen, sondern bewusst programmatisch mit GeoTools umgesetzt. Dies im Hinblick auf eine mögliche PDF-Erstellungslösung für den ÖREB-Kataster. Dort werden im XML-Auszug die Geometrien zum Highlighten mitgeliefert und es kann nicht via WMS-Server gemacht werden (jedenfalls habe ich es so verstanden).

Wenn man die beiden Schritte zusammen hat, kann man diese als allerletzten Schritt in die Spring Boot Applikation einbinden. Um sich über die API schlau zu machen, hilft meistens ein Blick in die Beispiele oder Tests, die im Quellcode der jeweiligen Programme vorhanden sind. Das Ziel ist erreicht, wenn der folgende Aufruf ein PDF liefert:

http://localhost:8887/parcel/extract/pdf/CH310663327779

Mit diesem Ansatz lässt sich jetzt nicht nur ein PDF aus dem XML herstellen, sondern auch andere Formate. Massiv einfacher wird es wenn man nur HTML erzeugen will. Dann fällt der zweite Schritte mit XSL-FO weg und es reicht eine Transformation mit XSLT. Für die einfachere Verifikation der Verknüpfung der Dokumente im kantonalen Nutzungsplanungsmodell habe ich das ÖREB-Auszugsschema verwendet und daraus eine HTML-Datei generiert.

Ist das die Zukunft der PDF-Herstellung in einer GDI? Leider ist XSL-FO mehr oder weniger tot. Eher mehr, weil es nicht mehr weiterentwickelt wird. XSLT scheint lebendiger zu sein. Trotzdem muss man aufgrund der vielen Informationen im Internet schliessen, dass es zumindest jetzt noch relativ häufig im Einsatz ist. Kostenpflichtige XSL-FO-Prozessoren sind ebenfalls immer noch verfügbar. Eine zukünftige Alternative könnte/dürfte CSS Paged Media sein.

Ich finde XSLT/XSL-FO aber ein sauberer und transparenterer Ansatz als Jasper. Aber vielleicht habe ich bloss einen neuen Lieblingshammer und suche Nägel.

ÖREB-Kataster: As low level as possible

Tue, 23 Oct 2018 00:00:00 +0000

Die Frage aus dem letzten Beitrag «ÖREBlex: ja oder nein?» ist falsch gestellt. Es geht nicht direkt um die Anschaffung von OEREBlex, sondern vielmehr wie Dokumente im kantonalen ÖREB-Gesamtsystem (nennen wir es mal so) in den Daten eingebunden werden.

Der Gedanke, dass die Geobasisdaten mit den Rechtsvorschriften eine Einheit bilden und so die Eigentumsbeschränkung unmittelbar beschreiben, finde ich gut und plausibel. Das Transferstrukturteilmodell des Rahmenmodells und daran angelehnte MGDM und wohl einige KGDM bilden diese Aussage ab. Ganz vereinfacht sieht das so aus:

Bei der modellbasierten Numerisierung der Nutzungsplanung war für uns - losgelöst vom Thema ÖEREB-Kataster - wichtig, dass neben den Geometrien eben auch die dazugehörigen Rechtsvorschriften und Beschlussdokumente miterfasst werden. Das kantonale Nutzungsplanungsmodell (resp. in letzter Konsequenz eben das Rahmenmodell) lässt dies zu. Gemäss der Abbildung von oben entspricht die Klasse Eigentumsbeschränkung in diesem Fall der Klasse Typ im kantonalen Modell.

Bestehende Ortsplanungen zu digitalisieren und die Verknüpfung mit Dokumenten herzustellen, die existieren und als HTTP-Ressource verfügbar sind, ist keine Hexerei. Die Herausforderung beginnt erst, wenn die Dokumente noch nicht existieren. Z.B. der Beschluss-RRB, Zonen- und Baureglemente oder allfällige Gestaltungspläne sind noch nicht vorhanden, falls eine komplette Ortsplanungsrevision oder Teilrevision gemacht wird. Erst recht ist die zukünftige URL noch nicht bekannt. Und so wie ich es verstanden habe, kommt hier ÖREBlex ins Spiel. Es kann unter anderem als «Bündelungsschicht» wie auch als Blick in die Zukunft dienen. D.h. man macht ein Päckli und das Päckli bekommt eine URL. Im Päckli selber muss noch kein Dokument vorhanden sein. Der Datenerfasser muss jetzt zu seinem Typ bloss einen Link erfassen. Ob die Dokumente, die für diese Eigentumsbeschränkung bereits vorhanden sind oder nicht, spielt keine Rolle. Dem Päckli kann man nun bei Abschluss den Beschluss-RRB und Rechtsvorschriften zuweisen.

Neben den auf der Hand liegenden Vorteilen, geht für mich hier aber die Einheit zwischen Geometrie und Rechtsvorschrift verloren. Zumindest auf der Persistenzschicht. Wenn wir das so machen würden und ein Kunde das KGDM der Nutzungsplanung bezieht, bekommt er die Geometrien und Typen, die auf einen Link zeigen, der mir eine Liste (oder XML, HTML, …) mit weiteren Links zu den Dokumenten zurückliefert. Der Kunde muss mit diesen Rückgaberesultaten umgehen können und braucht dazu wohl oder übel weitere Software oder Skripte. Darum: Dokumente gehören gleichberechtigt zu den Geometrien in ein Datenmodell (sei es KGDM, MDGM oder in die Transferstruktur).

Will man das, braucht es wohl mehr organisatorische Koordination, was ich aber für machbar halte. Ein technisches Problem ist der Umgang mit der URL der zu verlinkenden aber noch nicht vorhandenen Dokumenten. Ab einem gewissen Zeitpunkt bei einer Ortsplanung, dürfte man wohl wissen, welche Dokumente entstehen werden. Frage: Was für Möglichkeiten gibt es, das nicht vorhandene Dokument resp. die URL zum nicht vorhandenen Dokument im Modell zu erfassen:

Jemand erstellt ein Dummy-PDF und stellt es als HTTP-Ressource bereit.
Man definiert zusammen Konventionen und garantiert die Einhaltung dieser Konventionen, z.B. Link zur HTTP-Ressource besteht aus BFS-Nummer, Typ des Dokumentes etc.

Oder man verwendet das Prinzip der PURL: Eine PURL ist funktional eine URL. Anstelle der direkten URL auf das Dokument, erfasst/verlinkt man die PURL. Die PURL zeigt auf einen Server, der die zur PURL passende URL heraussucht und anschliessend ein simples HTTP redirect ausführt. Soweit technisch nichts neues. Was es nun braucht, ist jemand der dem Datenerfasser die PURL bei Bedarf liefert und wenn das Dokument vorhanden ist, dieses auf der Fileablage o.ä. ablegt. Garantiert werden muss das P = Persistent. Die PURL darf sich nicht ändern, sonst gewinnt man genau nichts.

Solange das Dokumente noch nicht real exisitert, liefert der PURL-Server den Statuscode 404 zurück. Wenn das Dokument vorhanden ist, wird ein Redirect mit Statuscode 302 gemacht.

Wie bekomme ich einen PURL-Server? Im Grundsatz braucht es sehr wenig: Apache und eine Datenbank. Rewriten und Redirecten kann Apache mit dem mod_rewrite Modul. Völlig unpraktikabel wäre die Verwaltung der Redirects von PURL auf die URL direkt in der Apache-Config Datei. Apache kennt die Direktive RewriteMap. Diese Direktive definiert externe Funktionen im Kontext von RewriteRule und RewriteCond. So kann man als Datenquelle eine Textdatei angeben oder auch ein externes Programm (ganz allgemein), das via STDIN und STDOUT kommuniziert. Für unseren Anwendungsfall ist das Einbinden einer Datenbank verheissungsvoll. Dazu braucht Apache das Modul mod_dbd. Mehr nicht.

Unter der Annahme, dass auf einem Ubuntu-Rechner Apache und PostgreSQL bereits vorhanden sind, braucht es folgendes:

sudo apt-get install libaprutil1-dbd-pgsql
sudo a2enmod rewrite
sudo a2enmod dbd
sudo /etc/init.d/apache2 restart

Unter Umständen muss der Datenbanktreiber in das modules-Verzeichnis von Apache kopiert werden:

sudo cp /usr/lib/x86_64-linux-gnu/apr-util-1/apr_dbd_pgsql*  /usr/lib/apache2/modules/

Die Apache-Config-Datei muss ergänzt werden:

Folgende Befehle sind auszuführen:

<Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
</Directory>

<IfModule mod_rewrite.c>
    DBDriver pgsql
    DBDParams "hostaddr=192.168.50.8 user=ddluser password=ddluser dbname=edit"
    DBDMin 4
    DBDKeep 8
    DBDMax 20
    DBDExptime 300

    RewriteEngine on

    RewriteMap data "dbd:select resource_url from agi_oereb_purl.redirect_map where input_url=%s"

    RewriteCond ${data:$1} =""
    RewriteRule ^/(.*) - [R=404,L]
    RewriteCond ${data:$1} !=""
    RewriteRule ^/(.*) ${data:$1} [R=302]
</IfModule>

Vieles ist selbsterklärend. RewriteMap macht die Abfrage in der Datenbank mit %s= Pfad der URL. Dies entspricht dem name-Teil der PURL. Die Query liefert die URL zum Dokument zurück.

Falls die Query nichts findet (Zeile 19), wird der Statuscode 404 vom Webserver zurückgeliefert (Zeile 20). Wird etwas gefunden (Zeile 21), wird ein Redirect zum Dokument ausgeführt (Zeile 22).

Testhalber habe ich zwei Dummyrecords in der Tabelle erfasst:

Mit curl kann man die Abfragen testen und sich die Statuscodes ausgeben lassen:

curl -X HEAD -I  http://192.168.50.8/foo

liefert:

HTTP/1.1 302 Found
Date: Tue, 23 Oct 2018 18:59:26 GMT
Server: Apache/2.4.29 (Ubuntu)
Location: https://geoweb.so.ch/zonenplaene/Zonenplaene_pdf/34-Messen/Reglemente/034_ZR.pdf
Content-Type: text/html; charset=iso-8859-1

Wird ein Dokument nicht gefunden, soll 404 ausgeliefert werden:

curl -X HEAD -I  http://192.168.50.8/fubar

liefert:

HTTP/1.1 404 Not Found
Date: Tue, 23 Oct 2018 19:00:15 GMT
Server: Apache/2.4.29 (Ubuntu)
Content-Type: text/html; charset=iso-8859-1

Der Blick in die Zukunft kann mit dem Prinzip PURL gemacht werden. Es muss dafür nicht eine teure Spezialsoftwarelösung her, die für etwas entwickelt wurde, für das es Lösungen gibt, die sehr einfach und entsprechend transparent sind. Eine einfache Lösung mit Apache und PostgreSQL passt zu unserer Organisation, die sich mit beiden Produkten bestens auskennt und bereits täglich im Einsatz hat.

ÖREB-Kataster as a Gradle Script

Sun, 21 Oct 2018 00:00:00 +0000

Seit einigen Jahren investieren wir in fundamentale Werkzeuge, Arbeitsweisen und Basisinfrastrukturen. Es ist als würde die Saat bei der technischen Umsetzung des ÖREB-Katasters langsam aufgehen. Dank (oder trotz?) den vielen Weisungen zum ÖREB-Kataster ist relativ klar was man als Kanton bieten muss. Zentral ist der ÖREB-Webservice. Dieser ist das Fleisch am Knochen. Er stellt ein paar einfache Funktionen (wie z.B. EGRID mittels Koordinate eruieren) zur Verfügung, ist aber ebenso verantwortlich für den Output des XML-/JSON-Auszugs und des statischen Auszuges (PDF).

Eine der Fragestellungen für den Kanton ist wie und mit welchen Mitteln man das umsetzt. Um das Fuder nicht zu überladen, lassen wir den dynamischen Auszug mal weg. Das wird sowieso eine Speziellanfertigung für den jeweilig eingesetzten Web GIS Client. Oder man nimmt gleich so etwas wie den Smart-Auszug.

Mir gefiel immer der Gedanke eines gemeinsamen Rahmenmodelles. Wenn man das vom Ende her denkt, ist der XML-Auszug nämlich nichts anderes als das Umformatieren des Resultates einer Datenbankabfrage. Die Datenbankabfrage selber entspricht einer absolut klassischen GIS-Aufgabe: Dem Ausstanzen eines Polygons (in unserem Fall eines Grundstückes) aus einer Datenbanktabelle mit den aggretierten ÖREB-Daten von Bund und Kanton. Und wenn wir schon dabei sind, ist das etwa das einzige Mal, dass es hier um Geoinformation geht und nicht bloss um gewöhnliches Datenmanagement.

Mit diesem Grundgedanken kann man sich dann an eine grobe Systemarchitektur machen. Die technischen und organisatorischen Rahmenbedinungungen bei uns sind:

PostgreSQL/PostGIS-Datenbanken
INTERLIS-Werkzeuge vorhanden. Daten können mit ili2pg und ilivalidator einfachst importiert, exportiert und validiert werden.
GRETL/Jenkins als Orchestrierungswerkzeug für beliebige Prozesse
Datenumbauten (kantonale Struktur → ÖREB-Transferstruktur) werden mit SQL gemacht

Aus diesen Rahmenbedinungungen und ein wenig überlegen, folgt die folgende Architektur:

ÖREB-Bundesdaten werden heruntergeladen und in die ÖREB-Katasterdatenbank mit ili2pg importiert. Gleich behandelt werden kantonale Themen (z.B. KbS), die in einer Fachanwendung nachgeführt werden. Diese Fachanwendung ist für das Bereitstellen der ÖREB-Transferstruktur verantwortlich. Weitere kantonale Daten (z.B. Nutzungsplanung) werden modelläquivalent in einer Erfassungsdatenbank vorgehalten. Mit SQL werden diese Daten in die modelläquivalente Transferstruktur in einem Staging-Schema in der Erfassungsdatenbank gebracht und mit Verweisen auf die gesetzlichen Grundlagen angereichert. Dies verbucht man hauptsächlich unter Fleissarbeit, wobei hier natürlich Besonderheiten und Datenfehler das Leben schwer machen können. Sind sie umgebaut werden sie mit ili2pg in die Transferstruktur exportiert, mit ilivalidator geprüft und anschliessend in die ÖREB-Katasterdatenbank - wo bereits die Bundesdaten warten - importiert.

Verweise auf gesetzliche Grundlagen und zuständige Stellen sind etwas, was wahrscheinlich selten in kantonalen Geodatensätzen bereits vorhanden sind. Diese Daten können in einem separaten Datenbankschema in der Erfassungsdatenbank aktuell gehalten werden. Die passenden Teilmodelle im Rahmenmodell gibt es ja, um modelläquivalente Strukturen in der Datenbank anzulegen und anschliessend mit QGIS nachzuführen. Der Nachführungsauwand dürfte sich vor allem bei den gesetzlichen Grundlagen in Grenzen halten. Bei Bedarf können die Daten wieder exportiert werden und in der ÖREB-Katasterdatenbank ausgetauscht werden.

Um den XML-Auszug erstellen zu können, fehlen noch ein paar Kleinigkeiten (die in der Transferstruktur nicht vorhanden sind) wie Logos, Glossar etc. Dazu schreibt man sich ein kleines INTERLIS-Modell und erfasst die notwendigen Daten in der Erfassungsdatenbank, exportiert die Daten und importiert sie in der ÖREB-Katasterdatenbank.

Um das eher theoretische Konzept zur Architektur mit was Greifbaren zu untermauern, habe ich mir mit GRETL ein paar Tasks zusammengeschustert, die mit den Bundesdaten und Nutzungsplanungsdaten (im kantonalen Modell) den Prozess durchspielen (Github-Repository):

Erstellen und Initialisieren der Datenbank-Schemas mit Sekundärdaten (Gesetzliche Grundlagen, zuständige Stellen, Annex Modell mit Logos, Glossar etc.)
Download und Import der Bundesdaten und der amtlichen Vermessung in die ÖREB-Datenbank und der kantonalen Daten (Nutzungpslanung) in die Erfassungsdatenbank.
Datenumbau Nutzungsplanung: Kantonales Modell → Transferstruktur
Export der Nutzungsplanung in die Transferstruktur und Import in die ÖREB-Katasterdatenbank

Erwähnenswert ist das (PRE-ALPHA!) Erstellen der einzelnen Symbole für den Legendeneintrag. Diese werden mittels GetLegendGraphic-Request erstellt. Zuvor muss jedoch ein GetStyles-Request erfolgen, um die Namen der Symbol-Regel zu kennen. Wahrscheinlich kommt man nicht umher hier gewisse Abmachungen mit der zuständigen Stelle bei der Erarbeitung der Legenden zu treffen, damit die Maschine auch wieder die Zuordnung zum Legendeneintrag in der Datenbank machen kann.

Notwendig - wenn man das mal durchspielen will - ist Vagrant, Java und Gradle. Vagrant wird für die Datenbanken und QGIS-Server benötigt. Gradle für das Ausführen der GRETL-Tasks. GRETL selber wird vom Gradle-Plugin-Repository automatisch heruntergeladen.

Folgende Befehle sind auszuführen:

vagrant up

Warten bis virtuelle Maschine hochgefahren ist, anschliessend:

gradle createSchemaOereb importFederalCodesets importFederalLegalBasis importCantonalLegalBasisToOereb createSchemaOerebAuszugAnnex createSchemaOerebNutzungsplanung importFederalLegalBasisToOerebNutzungsplanung importCantonalLegalBasisToOerebNutzungsplanung importResponsibleOfficesToOerebNutzungsplanung createOerebNutzungsplanungViews createSchemaNutzungsplanung createSchemaAmtlicheVermessung
gradle replaceFederalData replaceCantonalLandUsePlansData replaceCadastralSurveyingData importOerebAuszugAnnex
gradle deleteStaging insertStaging updateLegendEntrySymbols
gradle exportLandUsePlansToXtf replaceOerebNutzungsplanung

(Kann je nach Entwicklungsstand auch mal nicht funktionieren.)

Hat alles geklappt sind jetzt sowohl die vorhandenen vier Bundesdatensätze wie auch die Nutzungsplanung in der ÖREB-Katasterdatenbank vorhanden und können z.B. in QGIS angezeigt werden:

Hat man die ÖREB-Daten in einer Datenbank, fehlt noch der ÖREB-Webservice, der mir PDF- und XML-Auszug liefert. Ich bin ein Freund des Gedankens, dass der Service selber nur XML (oder JSON) liefern soll resp. das PDF soll aus dem XML erstellt werden. Verhindert werden soll, dass unterschiedliche Abfragen für die jeweilige Herstellung eines Formates verwendet werden müssen. Das XML ist die «single source of truth». Für das Herstellen eines PDF-Auszuges aus einem XML, gibt es den XML2PDF-Service, der in einem Schwergewichtsprojekt noch elaboriert wurde.

Wenn es einzig noch um den XML-Auszug geht, kann man etwas selber machen oder etwas bestehendes nehmen, wie z.B. pyramid_oereb. Bei pyramid_oereb müsste man wohl die modelläquivalente Struktur nochmals umbauen in die eigene Datenbankstruktur. Wenn man etwas selber macht, ist man natürlich freier. Als Proof-of-Concept und als Entscheidungsgrundlage, ob es etwas vorhandenes werden soll oder ob noch Effort in eine Entwicklung gesteckt werden soll, habe ich mir einen Webservice zusammengeschustert, der funktional natürlich völlig unvollständig ist:

Muss man XML erstellen, gibt es verschiedene Möglichkeiten dies zu tun. In unserem Fall sind XML Schema Definitionen vorhanden. Mit XML-Binding kann man automatisch Java-Klassen ableiten lassen. Das hat den Vorteil, dass ich mich als Programmierer nicht um das eigentliche Formatieren kümmern muss, sondern ich muss nur die Java-Klassen korrekt mit Daten abfüllen. Eine andere Variante wäre das Arbeiten mit einer Templating Engine.

Das automatische Herstellen der Java-Klassen mit xjc war - diplomatisch formuliert - spannend. Das ist vor allem darauf zurückzuführen, dass im ExtractData-Schema für die Geometrie-Kodierung GML verwendet wird. Von den insgesamt circa 420 Klassen, sind 357 Klassen GML-spezifisch. Notwendig für das erfolgreiche Erstellen der Klassen sind einige Konfigurationsdateien (für die GML-Besonderheiten), die man Gott sei Dank mit ein wenig Googlen im Internet findet.

Der Service selber wurde mit Spring Boot gemacht. Cloned man das Repository reicht nach dem Wechseln in das web-service-Verzeichnis:

./gradlew bootRun

um den Webservice zu starten. Funktional umgesetzt ist, wie bereits erwähnt, wenig (war vor einem Jahr schon mal weiter).

Was funktioniert ist die Suche nach einem EGRID mittels Koordinate:

http://localhost:8888/oereb/getegrid/xml/?XY=2598098,1225627

Und das Anzeigen der betroffenen resp. nicht betroffenen und nicht vorhandenen ÖREB-Themen, dem Datum und dem Flavour beim Extract-Aufruf:

http://localhost:8888/oereb/extract/reduced/xml/geometry/CH870672603279 (Flughafen Grenchen)
http://localhost:8888/oereb/extract/reduced/xml/geometry/CH933273065885 (nur Nutzungsplanung)

Meine Fazit: Identifiziert man die einzelne Teile und Prozesse des grossen Ganzen, zeigt sich schnell, dass vieles mit unseren vorhandenen Bordmitteln (aka Legobausteinen) effizient und transparent gelöst werden kann. Hilfreich ist hier sicher einmal mehr der modellbasierte Ansatz und ein unverkrampfter Umgang mit INTERLIS und Datenumbauten mit SQL (was mich immer wieder überrascht…). Ebenso hilft das tägliche Mantra: «Spatial is not special», was sich nochmals zeigen wird, wenn es um die Frage geht «ÖREBlex: ja oder nein?» (to be continued).

GeoServer Magie #1 - GetFeatureInfo mit Freemarker Templates

Mon, 10 Sep 2018 00:00:00 +0000

Daten werden ja häufig - den Regeln der Kunst entsprechend - in einem normalisierten und relationalen Datenmodell erfasst. Da kann die Geometrie als solches auch schon mal die Nebenrolle spielen. Häufig haben wir den Fall, dass einer Geometrie mehrere Fotos oder PDF zugewiesen werden müssen. Soweit noch nichts Aussergewöhnliches und auch die Umsetzung geht rasch: Dank QGIS, INTERLIS und dem QGIS-Projektgenerator ist die Sache in kürzester Zeit modelliert und die generische Fachschale auf Knopfdruck parat.

Die Diskussion startet aber spätestens wenn man dieses normalisierte Erfassungsmodell in eine für die gebräuchlichen WMS-Softwaren (also QGIS-Server, GeoServer und MapServer) taugliche Struktur bringen muss. Wenn dieser normalisierte und relationale Ansatz mit QGIS-Desktop und seinen mächtigen Formularfunktionen bei der Datenerfassung noch gut funktioniert, geht das nicht mehr so wirklich mit den genannten WMS-Servern. Diese erwarten eher resp. funktionieren am besten mit flachen und «dummen» Tabellen. Man möchte ja bloss z.B. im Web GIS Client auf eine Geometrie klicken und dann soll zumindest als Link jedes Foto oder PDF aufgelistet werden. Wie so oft gibt es hier verschiedene Lösungen. Bei uns als Altlast noch häufig verbreitet: man löst es halt für jeden Layer separat in der Objektabfrage. Das heisst, dass mit einem Mischmasch aus einer Skriptsprache (PHP…) und SQL was zusammengebastelt wird, so dass die Objektabfrage etwa das liefert, was man sich vorstellt. Vorteil: man kann sich selber verwirklichen. Nachteil: man verwirklicht sich selber.

Da wir die Daten sowieso praktisch immer von einem Erfassungsmodell in ein Publikationsmodell umbauen, kann man hier das flachwalzen durchführen. Wie walze ich aber eine 1:n-Beziehung flach? Ich kann die Links zu einem String aggregieren und mit einem Komma oder, falls es der Klient richtig rendern kann, mit einem HTML-Break trennen. Das ist dann einerseits auch nur halb-schön und funktioniert nur solange es sich bei flachzuwalzenden Daten um ein einzelnes Attribut handelt (eben ein Link zu einem Foto) und nicht komplette Objekte. Klar kann man jedes Attribut des Objektes genaus so behandeln aber das führt dann wirklich ins Nirwana.

Und hier kommt JSON ins Spiel. Beim Datenumbau aggregiere ich die Objekte zu einem JSON-Array. Am einfachsten kann man das an einem konkreten Beispiel erläutern: Unser kantonales Nutzungsplanungsmodell orientiert sich am Bundesmodell. Dieses wiederum am ÖREB-Rahmenmodell. Jeder Geometrie wird ein Zonentyp zugewiesen. Jedem Zonentyp können mehrere Dokumente zugewiesen sein. Und um es noch spannender zu machen, gibt es diese Selbsreferenzierung der Dokumente auf sich selber. Als Übergangslösung bis zur Einführung des ÖREB-Katasters möchte man mit einem Klick im Web GIS Client auf eine Geometrie die wichtigsten Informationen präsentiert bekommen, d.h. neben dem Zonentyp sicher sämtliche dazugehörigen Dokumente.

Die Tabelle im Publikationsmodell hat jetzt mindestens eine Geometriespalte, eine Spalte mit dem Zonentyp und eben eine Spalte vom Typ JSON. In dieser Spalte sind sämtliche Dokumente, die für diesen Typ gültig sind als JSON-Array kodiert (Attribut «dokumente»):

Wenn man nun ein GetFeatureInfo auf diesen Layer absetzt, muss man sich zuerst entscheiden, was man vom WMS-Server retourniert haben will. Ob die Spezifikation überhaupt ein zwingendes Outputformat vorgibt, entzieht sich meiner Kenntnis, kann aber hier oder hier nachgelesen werden. Typischer Vertreter der Outputformate sind GML, HTML oder Text. Für jedes dieser Formate wird das JSON-Attribut standardmässig von GeoServer als String ausgeliefert. Somit hätte man noch nicht viel gewonnen. In QGIS sieht das so aus:

Entscheidet man sich, dass das Rendering des GetFeatureInfo-Requests auf dem Server und nicht auf dem Client geschehen soll, kann man HTML als Outputformat wählen. Standardmässig kommt hier in GeoServer eine relativ hässliche Tabelle. Aber jetzt kommt eben die Magie: Mit Freemarker-Templates kann ich was Schönes selber zusammenbasteln. Der Fokus liegt aber in meinem Fall weniger in «schön», sondern dass ich eben das JSON-Array selber prozessieren kann.

Freemarker ist eine Template Engine, um Text-Output zu generieren. Für die GetFeatureInfo-Templates werden ein Header-, ein Content- und ein Footer-Template benötigt. «Nomen est Omen» in diesem Fall. Da man in unserem Fall HTML generieren will, steht im Header hauptsächlich CSS und der Beginn eines HTML-Dokumentes usw. Der Footer schliesst das sauber ab. Im Content-Template kann man das eigentliche Präsentieren des Features abhandeln:

<table class="featureInfo">
  <caption class="featureInfo">Zonenplan: Grundnutzungen</caption>
  <col style="width:30%">
  <col style="width:70%">
  <#list features as feature>
    <#assign attrs = feature.attributes >
    <tr>
      <td><strong>Typ-Bezeichnung:</strong></td>
      <td>${attrs.typ_bezeichnung.value}</td>
    </tr>
    <tr>
      <td><strong>Kantonaler Typ:</strong></td>
      <td>${attrs.typ_kt.value}</td>
    </tr>
    <tr>
      <td><strong>Kommunaler Typ:</strong></td>
      <td>${attrs.typ_code_kommunal.value}</td>
    </tr>
    <tr>
      <td><strong>Verbindlichkeit:</strong></td>
      <td>${attrs.typ_verbindlichkeit.value}</td>
    </tr>
    <tr>
      <td><strong>Rechtsstatus:</strong></td>
      <td>${attrs.rechtsstatus.value}</td>
    </tr>
    <tr>
      <td><strong>Publiziert ab:</strong></td>
      <td>${attrs.publiziertab.value?date('MM/dd/yy')?string["dd. MMMM yyyy"]}</td>
    </tr>
    <tr>
      <td colspan="2"><strong>Dokumente:</strong></td>
    </tr>
        <#if "${attrs.dokumente.value}" != "">
          <#assign documents = "${attrs.dokumente.value}"?eval>
          <#list documents as document>
              <tr>
                <td style="font-weight:500;padding-left:2em;padding-top:0em;">Titel:</td>
                <td style="padding-top:0em;">${document.titel}</td>
              </tr>
              <tr>
                <td style="font-weight:500;padding-left:2em;padding-top:0em;">Offizieller Titel:</td>
                <td style="padding-top:0em;">${document.offiziellertitel}</td>
              </tr>
              <tr>
                <td style="font-weight:500;padding-left:2em;padding-top:0em;">Nummer:</td>
                <td style="padding-top:0em;">${document.offiziellenr}</td>
              </tr>
              <tr>
                <td style="font-weight:500;padding-left:2em;padding-top:0em;">Rechtsstatus:</td>
                <td style="padding-top:0em;">${document.rechtsstatus}</td>
              </tr>
              <tr>
                <td style="font-weight:500;padding-left:2em;padding-top:0em;">Publiziert ab:</td>
                <td style="padding-top:0em;">${document.publiziertab?date('yyyy-MM-dd')?string["dd. MMMM yyyy"]}</td>
              </tr>
              <tr>
                <td style="font-weight:500;padding-left:2em;padding-top:0em;">Link:</td>
                <td style="padding-top:0em;"><a href="${document.textimweb_absolut}" target="_blank">${document.textimweb_absolut}</a></td>
              </tr>
              <tr>
                <td>&nbsp;</td>
                <td></td>
              </tr>
          </#list>
        <#else>
          &nbsp;
        </#if>
  </#list>
</table>
<br/>

(Sorry für das hässliche HTML.)

Das Meiste ist ziemlich vorhersehbar. Wichtig ist die Zeile 35, wo mit <#assign documents = "${attrs.dokumente.value}"?eval> aus dem JSON-Array-String für Freemarker eine Liste gemacht wird, die man iterieren kann. Heikel resp. wohl ein Bug ist der Umstand, dass JSON-null-Werte zu einer Exception führen. Hier kann man als Workaround beim Datenumbau in PostgreSQL die Funktion json_strip_nulls() verwenden, die Attribute mit null-Werten wegputzt.

Das Resultat kann sich meines Erachtes sehen lassen:

In QGIS funktioniert es auch:

Da wir auch unsere Publikationsmodelle mit INTERLIS modellieren, haben wir das Dokumente-Attribut als reinen Text modelliert. In Zukunft kann man das dank einer Erweiterung von ili2db sauberer machen. Die Dokumente werden als BAG OF STRUCTURES modelliert und mit einem Meta-Attribut versehen. Dann weiss ili2db, dass es diese BAG OF STRUCTURES als JSON-Attribut in der relationalen Datenbank abbilden muss. Diese Erweiterung wird Ende 2018 verfügbar sein.

INTERLIS leicht gemacht #18 - Shapefiles validieren

Mon, 19 Feb 2018 00:00:00 +0000

Im letzten Beitrag habe ich kurz erwähnt, dass wir für GRETL einen Shapefile-Validator-Task entwickeln liessen. Hier nun kurz eine Einführung/Erläuterung dazu.

Shapefiles sind leider nicht wirklich aus der Welt zu schaffen. Auch wir importieren immer noch Shapefiles von externen Dienstleistern in unsere GDI. Jedenfalls bleibt der gute Vorsatz in unseren zukünftigen Datenabgabe keine Shapefiles mehr anzubieten, sondern als besserer Ersatz GeoPackage.

Was wir aber nicht wollen, ist treudoof die fremden Shapefiles in unsere Datenbank importieren. Ein Minimum an - nennen wir es mal - Schemaprüfung wollen wir trotzdem. Analog der Modellprüfung von INTERLIS-Transferdateien. Jetzt könnte man auf die Idee kommen irgendwas mit YAML o.ä. zu frickeln, um zu definieren was in einer Spalte erlaubt ist. Aber es geht viel besser: Schreiben wir doch lieber ein INTERLIS-Modell und definieren dort, was erlaubt ist und was nicht. Dann passt es tiptop zum ilivalidator, der ebenfalls via INTERLIS gesteuert und erweitert werden kann.

Am einfachsten kann man die Shapefile-Prüfung anhand eines GRETL-Jobs zeigen. Dazu müssen wir zuerst GRETL installieren. Leider ist das Docker-Image noch nicht wirklich production-ready. GRETL lässt sich aber ganz einfach aus dem Quellcode kompilieren und installieren (Java und Gradle müssen bereits installiert sein):

git clone https://github.com/sogis/gretl

Im gretl-Verzeichnis:

./gradlew clean build install

Dieser Befehl erstellt das Binary und installiert es in das lokale Maven-Repository.

Als Beispiel-Shapefile verwende ich unsere Grundwasserschutzzonen:

Als nächstes brauchen wir ein INTERLIS-Modell. Der Shapefile-Validator funktioniert so, dass er im Modell eine Klasse sucht, deren Attribute genau den Spaltennamen (Super: endlich wieder unlesbare Attributnamen schreiben im Modell) in der Shapedatei entsprechen (Gross- und Kleinschreibung wird ignoriert). Die gesamte Dokumentation dazu gibt es hier. Ein erster Wurf kann so aussehen:

INTERLIS 2.3;

!!@ technicalContact=mailto:agi@bd.so.ch
MODEL SO_AFU_Grundwasserschutzzonen_20180213_ShpValidator_20180213 (de)
AT "http://geo.so.ch/models/AFU"
VERSION "2018-02-13"  =
  IMPORTS GeometryCHLV95_V1;

  TOPIC ShpValidatorTopic =

    CLASS ShpValidatorClass =
      ogc_fid : MANDATORY 0 .. 10000000;
      zone : MANDATORY TEXT*20;
      archive : MANDATORY 0 .. 1;
      rrbnr : MANDATORY 1 .. 9999;
      rrb_date : MANDATORY INTERLIS.XMLDate;
      the_geom : MANDATORY GeometryCHLV95_V1.SurfaceWithOverlaps2mm;
    END ShpValidatorClass;

  END ShpValidatorTopic;

END SO_AFU_Grundwasserschutzzonen_20180213_ShpValidator_20180213.

Ich erwarte für jedes Attribut einen Wert. Ansonsten ist es noch ziemlich ungeschliffen. Als nächstes brauche ich den GRETL-Job:

import ch.so.agi.gretl.api.*
import ch.so.agi.gretl.tasks.*

buildscript {
    repositories {
        mavenLocal()
        maven {
            url "http://jars.interlis.ch"
        }
        maven {
            url "http://download.osgeo.org/webdav/geotools/"
        }
        mavenCentral()
    }
    dependencies {
        classpath group: 'ch.so.agi', name: 'gretl',  version: '1.0.4-SNAPSHOT'
    }
}

apply plugin: 'ch.so.agi.gretl'

task validateGrundwasserschutzzonenShapefile(type: ShpValidator){
    models = "SO_AFU_Grundwasserschutzzonen_20180213_ShpValidator_20180213"
    dataFiles = ["grundwasserschutzzonen.shp"]
}

Von Interesse sind eigentlich nur die Zeilen 22 bis 24. Hier wird der Validierungstask definiert. Zwingend ist soweit ich es verstehe nur der Dateinamen. Standardmässig wird als Modellnamen der Name der Shapedatei angenommen. Die Prüfung startet man mit:

gradle validateGrundwasserschutzzonenShapefile

Die Daten sollten «modellkonform» sein:

> Task :validateGrundwasserschutzzonenShapefile
Info: ilivalidator-1.6.0-5e18cf6587dae29c6452544e5667a1a2edc36574
Info: ili2c-4.7.8-20180208
Info: iox-ili-1.20.3-SNAPSHOT-85c29d5be771feeddc2dc74c1f5a1def73877570
Info: maxMemory 932352 KB
Info: dataFile </Users/stefan/Downloads/shpvalidator/grundwasserschutzzonen.shp>
Info: modelNames <SO_AFU_Grundwasserschutzzonen_20180213_ShpValidator_20180213>
Info: ilidirs <%ITF_DIR;http://models.interlis.ch/;%JAR_DIR/ilimodels>
Info: lookup model <SO_AFU_Grundwasserschutzzonen_20180213_ShpValidator_20180213> in repository </Users/stefan/Downloads/shpvalidator>
Info: lookup model <GeometryCHLV95_V1> 2.3 in repository </Users/stefan/Downloads/shpvalidator>
Info: lookup model <GeometryCHLV95_V1> 2.3 in repository <http://models.interlis.ch/>
Info: lookup model <GeometryCHLV95_V1> 2.3 in repository </Users/stefan/Downloads/shpvalidator/%JAR_DIR/ilimodels>
Info: Folder /Users/stefan/Downloads/shpvalidator/%JAR_DIR/ilimodels doesn't exist; ignored
Info: lookup model <GeometryCHLV95_V1> 2.3 in repository <http://models.geo.admin.ch>
Info: lookup model <CoordSys> 2.3 in repository </Users/stefan/Downloads/shpvalidator>
Info: lookup model <CoordSys> 2.3 in repository <http://models.interlis.ch/>
Info: lookup model <Units> 2.3 in repository </Users/stefan/Downloads/shpvalidator>
Info: lookup model <Units> 2.3 in repository <http://models.interlis.ch/>
Info: ilifile </Users/stefan/.ilicache/models.interlis.ch/refhb23/CoordSys-20151124.ili>
Info: ilifile </Users/stefan/.ilicache/models.interlis.ch/refhb23/Units-20120220.ili>
Info: ilifile </Users/stefan/.ilicache/models.geo.admin.ch/CH/CHBase_Part1_GEOMETRY_20110830.ili>
Info: ilifile </Users/stefan/Downloads/shpvalidator/SO_AFU_Grundwasserschutzzonen_20180213_ShpValidator_20180213.ili>
Info: validate data...
Info: assume unknown/external objects
Info: first validation pass...
Info: second validation pass...
Info: /Users/stefan/Downloads/shpvalidator/grundwasserschutzzonen.shp: SO_AFU_Grundwasserschutzzonen_20180213_ShpValidator_20180213.ShpValidatorTopic BID=b1
Info:     664 objects in CLASS SO_AFU_Grundwasserschutzzonen_20180213_ShpValidator_20180213.ShpValidatorTopic.ShpValidatorClass
Info: ...validation done


BUILD SUCCESSFUL in 1s
1 actionable task: 1 executed

Um zu prüfen, ob der Task auch Fehler findet, verändere ich das Modell leicht. Erlaubt sind nun nur noch RRB-Nummer kleiner 7200:

> Task :validateGrundwasserschutzzonenShapefile FAILED
Info: ilivalidator-1.6.0-5e18cf6587dae29c6452544e5667a1a2edc36574
Info: ili2c-4.7.8-20180208
Info: iox-ili-1.20.3-SNAPSHOT-85c29d5be771feeddc2dc74c1f5a1def73877570
Info: maxMemory 932352 KB
Info: dataFile </Users/stefan/Downloads/shpvalidator/grundwasserschutzzonen.shp>
Info: modelNames <SO_AFU_Grundwasserschutzzonen_20180213_ShpValidator_20180213>
Info: ilidirs <%ITF_DIR;http://models.interlis.ch/;%JAR_DIR/ilimodels>
Info: lookup model <SO_AFU_Grundwasserschutzzonen_20180213_ShpValidator_20180213> in repository </Users/stefan/Downloads/shpvalidator>
Info: lookup model <GeometryCHLV95_V1> 2.3 in repository </Users/stefan/Downloads/shpvalidator>
Info: lookup model <GeometryCHLV95_V1> 2.3 in repository <http://models.interlis.ch/>
Info: lookup model <GeometryCHLV95_V1> 2.3 in repository </Users/stefan/Downloads/shpvalidator/%JAR_DIR/ilimodels>
Info: Folder /Users/stefan/Downloads/shpvalidator/%JAR_DIR/ilimodels doesn't exist; ignored
Info: lookup model <GeometryCHLV95_V1> 2.3 in repository <http://models.geo.admin.ch>
Info: lookup model <CoordSys> 2.3 in repository </Users/stefan/Downloads/shpvalidator>
Info: lookup model <CoordSys> 2.3 in repository <http://models.interlis.ch/>
Info: lookup model <Units> 2.3 in repository </Users/stefan/Downloads/shpvalidator>
Info: lookup model <Units> 2.3 in repository <http://models.interlis.ch/>
Info: ilifile </Users/stefan/.ilicache/models.interlis.ch/refhb23/CoordSys-20151124.ili>
Info: ilifile </Users/stefan/.ilicache/models.interlis.ch/refhb23/Units-20120220.ili>
Info: ilifile </Users/stefan/.ilicache/models.geo.admin.ch/CH/CHBase_Part1_GEOMETRY_20110830.ili>
Info: ilifile </Users/stefan/Downloads/shpvalidator/SO_AFU_Grundwasserschutzzonen_20180213_ShpValidator_20180213.ili>
Info: validate data...
Info: assume unknown/external objects
Info: first validation pass...
value 7273 is out of range
line 0: SO_AFU_Grundwasserschutzzonen_20180213_ShpValidator_20180213.ShpValidatorTopic.ShpValidatorClass: tid o116: value 7273 is out of range
value 7273 is out of range
line 0: SO_AFU_Grundwasserschutzzonen_20180213_ShpValidator_20180213.ShpValidatorTopic.ShpValidatorClass: tid o219: value 7273 is out of range
value 7273 is out of range
line 0: SO_AFU_Grundwasserschutzzonen_20180213_ShpValidator_20180213.ShpValidatorTopic.ShpValidatorClass: tid o604: value 7273 is out of range
Info: second validation pass...
Info: /Users/stefan/Downloads/shpvalidator/grundwasserschutzzonen.shp: SO_AFU_Grundwasserschutzzonen_20180213_ShpValidator_20180213.ShpValidatorTopic BID=b1
Info:     664 objects in CLASS SO_AFU_Grundwasserschutzzonen_20180213_ShpValidator_20180213.ShpValidatorTopic.ShpValidatorClass
Info: ...validation failed


FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':validateGrundwasserschutzzonenShapefile'.
> validation failed

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 1s

Mission Accomplished. Fehler gefunden. Man kann das Modell jetzt natürlich noch ein wenig elaborieren:

Das Attribut zone dürte ein Aufzähltyp sein.
Das Datum des RRB rrb_date kann man eingrenzen.

Gesagt getan. Das gepimpte Modell gibt es als ILI resp. UML.

Da wir uns ja im ilivalidator-Universum befinden, kann man das Modell mit Constraints erweitern oder die Prüfungen mittels weiterem Modell (und INTERLIS-Views) und/oder eigenen Java-Prüfmethoden erweitern. In diesem Fall ist das wohl nicht ganz so zwingend, da wir ja in den meisten Fällen das Shapedatei-Validierungsmodell selber schreiben.

Ansonsten gibt es nicht mehr viel zu sagen. Das Modell kann selbstverständlich in eine INTERLIS-Modellablage kopiert werden und wird auch dort gefunden. Dokumentation ist schnell erledigt und dort wo sie hingehört, wenn man ein paar Kommentare ins Modell schreibt. CSV-Dateien können dank des CsvValidators auf die gleiche Art und Weise geprüft werden.

Datenflüsse mit Gradle #3 - GRETL

Sun, 11 Feb 2018 00:00:00 +0000

Vor etwas mehr als einem Jahr habe in zwei Beiträgen erläutert, wie wir in Zukunft die Datenflüsse rund um unsere GDI gestalten wollen. Im vergangenen Jahr haben wir das nun mit externer Hilfe umgesetzt resp. einen ersten Wurf mit den - für uns - wichtigsten Funktionalitäten. Der Name für unser neues Lieblingsspielzeug ist GRETL: Gradle ETL.

Rekapitulation: Seit Anbeginn der (GIS-)Zeit dreht sich bei uns viel oder fast alles um die Datenbank («Datenbank-zentrisches Amt»). Fast alles wurde von irgendwo her in die Datenbank importiert, vieles wurde auch darin berechnet und sämtliche Daten wurden in irgendeiner Form auch wieder exportiert. So weit, so gut. Die Schnittstellen wie die Daten in die Datenbank reinkommen oder wieder rauskommen oder wie die Berechnung durchgeführt wird, ist unendlich heterogen gelöst. Zuerst good old PHP4, später dann Python-Skripte («Yeah, wir sind modern.») und auch mal Java hier und dort. Import, Datenumbau und Berechnung im Skript wild durcheinander. Und immer wieder Probleme mit Fremddatenbanken (Oracle, SQL-Server), da keine passenden Treiber im Haus. Wir haben festgestellt, dass sich die einzelnen Schritte eines solchen Prozesses leicht identifizieren lassen und auch kapseln lassen und diese eben auch immer etwa gleich aussehen. Die einzelnen Schritte werden als Gradle-Tasks erstellt und anschliessend zu einem Job aneinandergereit. Gradle haben wir gewählt, weil es bereits viel von unseren Anforderungen out-of-the-box oder durch Plugins abdecken kann:

Herunterladen, Entzippen und Kopieren von Daten
Logging
Abhängigkeiten zwischen den einzelnen Tasks (tasks ordering)
Via SSH Befehle auf externen Servern ausführen.
Flyway
Deployments auf AWS etc.
Dokumentation mit Asciidoctor
etc. etc.

Für die fehlenden zusätzlichen Tasks ist Gradle relativ einfach mit Java (oder Groovy) erweiterbar.

Der Quellcode befindet sich im dazugehörigen Github-Repository. Die ganze Geschichte ist momentan noch klein wenig unübersichtlich strukturiert. Neben den ganzen Funktionalitäten, gibt es im Repository noch viel anderen Code: CI/CD-Pipeline inkl. Deployment in einer OpenShift-Umgebung als Docker-Container und viel Code für die Abhängigkeiten der Integrationstests etc. Der eigentliche Quellcode liegt im Unterordner gretl. Eine umfangreiche User-Dokumentation im Ordner docs/user inkl. einem minimalen Beispiel.

Zum jetzigen Zeitpunkt gibt es folgende zusätzlichen Tasks:

SQLExecutor: Dieser Task führt beliebige parametrisierbare SQL-Befehle in einer Datenbank aus.
Db2Db: Kopiert Tabellen aus einer Datenbank in einer andere. Einfache, parametrisierbare Datenumbauten sind möglich. Dank JDBC wird (theoretisch) jede Datenbank unterstützt für die ein JDBC-Treiber verfügbar ist.
CsvImport / CsvExport: Import und Export von CSV-Dateien in resp. aus einer Datenbank.
ShpImport / ShpExport: Import und Export von Shapedateien. (Traurig aber wahr: Sogar noch vor GeoPackage realisiert…)
CsvValidator / ShpValidator: Prüft den Inhalt der CSV- resp. Shapedateien gegenüber einer vorgegebenen Struktur. Die umgesetzte Lösung ist schlicht genial. Dazu in einem anderen Beitrag mehr.
Ili2pg: Für den Umgang mit INTERLIS wurden mit ili2pg verschiedene Tasks gebaut (Import, Export, Replace, Schema-Import)
Ilivalidator: Zum Prüfen für die INTERLIS-Transferdateien wurde ein ilivalidator-Task programmiert.

Mit diesen funktional atomaren Tasks (und den in Gradle vorhandenen Funktionalitäten) kommt man bereits jetzt ziemlich weit.

Builden und installieren funktioniert wie man es von Gradle kennt:

./gradlew clean build install

Das erstellte Produkt ist ein Gradle-Plugin, das im lokalen Maven-Respository installiert wird und anschliessend in den Jobs (= build.gradle) angesprochen werden kann.

Herausfordernd ist die Testerei: Will man möglichst Nahe an der Realität testen, kommt man nicht um eine PostgreSQL-/PostGIS-Datenbank herum. Viel JDBC-mässiger Code lässt sich zwar auch mit einer Derby-Datenbank testen, aber wenn es um «Geo» geht, muss PostgreSQL/PostGIS her. Momentan ist das so gelöst, dass der Entwickler manuell eine dockerisierte PostgreSQL/PostGIS-Datenbank hochfährt und anschliessend die Tests einer bestimmten Kategorie durchführen kann. Denkbar wäre auch, dass man in Gradle verschiedene TestSets einführt und so eine bessere Steuerbarkeit der Tests herbeiführt. Anstatt die dockerisierte Datenbank manuell hochzufahren, fände ich z.B. TestContainers eine sehr elegante Lösung. «Passt scho.»

Wir werden bei uns in der Produktion nicht das pure Plugin verwenden, sondern möchten eine GRETL-Runtime als Docker-Image in Betrieb nehmen. Im Image sind sämtliche benötigten Abhängigkeiten (im Sinne von Bibliotheken etc.). Gradles Dependency Management ist ja schön und gut, im produktiven Betrieb will man aber nicht zu viel Feenstaub, sondern exakt wissen welche Version welcher Bibliothek in Betrieb ist oder zumindest sicher sein, dass heute nicht eine andere in Betrieb ist als gestern. Ebenso werden die benötigten INTERLIS-Modellablagen mit ili2c geklont, um komplett offline agieren zu können.

Ganz abgefahren wird es bei der Orchestrierung der Jobs. Wir gehen davon aus, dass wir circa 100 bis 200 einzelne Jobs haben werden. Der grösste Teil sind Datenumbauten in der Datenbank resp. von einer Erfassungsdatenbank in eine Publikationsdatenbank. Bei dieser Anzahl von Jobs will man in keiner Software selber gross konfigurieren. Sei es erstmalig oder bei Änderungen, die sämtliche Jobs betreffen. Als Fundament für diese Orchestrierung setzen wir Jenkins ein. Für die Konfiguration der Jobs wird es einen «Seeder-Job» geben, der sämtliche anderen Jobs aufgrund eines Jenkinsfiles in Jenkins definiert. Diese Jobs können anschliessend cronjob-mässig automatisch ausgeführt werden oder auch on-demand durch einen Benutzer. Und wenn das alles so klappt wie gewünscht, habe ich ein paar graue Haare mehr und mache drei Kreuze an die Decke… Jedenfalls ist es «Spatial Is Not Special» ziemlich auf die Spitze getrieben.

Der Appetit kommt wie so oft mit dem Essen. Folgende zusätzlichen Tasks oder Funktionalitäten stehen auf dem Wunschzettel:

Unterstützung von GeoPackage
Bei den Export-Prozessen sollen auch SQL-Queries als Input möglich sein und nicht bloss Tabellen oder Views.
Die Geometrie (in einer noch zu bestimmenden Form) soll beim CSV-Export unterstützt werden.
Unterstützung für JasperResports
Upload-Funktionalität in die Aggregationsinfrastruktur der Kantone
Vielleicht ein wenig unorthodox: Ein Kettle-PDI-Ausführ-Task.
???

INTERLIS leicht gemacht #17: Polymorphes Schreiben

Mon, 6 Nov 2017 00:00:00 +0000

Für einige der Datensätze, die gemäss GeoIG / GeoIV als INTERLIS-Datensatz geliefert werden müssen, gibt es bereits in irgendeiner Struktur Daten in der kantonalen Geodateninfrastruktur. Dass gar keine Daten vorhanden sind, dürfte wohl eher die Ausnahme sein. In beiden Fällen dürfte die Umsetzung eine Themas aber die passende Gelegenheit sein, um sich Gedanken über die zukünftige Datenstruktur in der KGDI zu machen.

Wäre es nicht schön, wenn man das minimale Geodatenmodell nach seinen Wünschen erweitern könnte, dieses bei sich in der KGDI implementieren könnte und dann trotzdem automatisch das Bundes-MGDM exportieren und der Aggregationsinfrastruktur liefern könnte? Ja. Und seit kurzem geht das mit ili2pg (und Variationen).

Nehmen wir mal an, dass wir nicht ein eigenes Datenmodell für die Nutzungplanung geschrieben hätten, sondern wir erweitern einfach das Bundesmodell: Wir möchten ein zusätzliches Attribut Baumassenziffer in der Klasse Typ und eine zusätzliche Klasse Grundnutzung_Zonenflaeche_Pos, um die Zonentypen anschreiben zu können (Wer will das heute noch?).

INTERLIS 2.3;

MODEL SO_ARP_Nutzungsplanung_20171106 (en)
AT "http://www.agi.so.ch"
VERSION "2017-11-06"  =
  IMPORTS Nutzungsplanung_LV95_V1_1,GeometryCHLV95_V1;

  TOPIC Geobasisdaten
  EXTENDS Nutzungsplanung_LV95_V1_1.Geobasisdaten =

    CLASS Grundnutzung_Zonenflaeche_Pos =
      Ori : MANDATORY 0.0 .. 399.9;
      HAli : MANDATORY INTERLIS.HALIGNMENT;
      VAli : MANDATORY INTERLIS.VALIGNMENT;
      Pos : MANDATORY GeometryCHLV95_V1.Coord2;
    END Grundnutzung_Zonenflaeche_Pos;

    CLASS Typ (EXTENDED) =
      Baumassenziffer : 0.00 .. 9.00;
    END Typ;

    ASSOCIATION Grundnutzung_Grundnutzung_Pos =
      Grundnutzung -<> {1} Nutzungsplanung_LV95_V1_1.Geobasisdaten.Grundnutzung_Zonenflaeche;
      Grundnutzung_Pos -- {0..*} Grundnutzung_Zonenflaeche_Pos;
    END Grundnutzung_Grundnutzung_Pos;

  END Geobasisdaten;

END SO_ARP_Nutzungsplanung_20171106.

Das Erstellen der leeren Tabellen in der Datenbank geht wie bis anhin:

java -jar ili2pg.jar --dbhost geodb-dev.eu-central-1.rds.amazonaws.com --dbdatabase xanadu2 --dbusr YYYYYY --dbpwd XXXXXX --nameByTopic --disableValidation --defaultSrsCode 2056 --expandMultilingual --strokeArcs --createGeomIdx --createFkIdx --createEnumTabs --beautifyEnumDispName  --modeldir "http://models.geo.admin.ch;." --models "Nutzungsplanung_Hauptnutzung_V1_1;SO_ARP_Nutzungsplanung_20171106" --dbschema npl_polymorph --schemaimport

Anschliessend importiere ich noch die Hauptnutzungen:

java -jar ili2pg.jar --dbhost geodb-dev.eu-central-1.rds.amazonaws.com --dbdatabase xanadu2 --dbusr YYYYYY --dbpwd XXXXXX --nameByTopic --disableValidation --defaultSrsCode 2056 --expandMultilingual --strokeArcs --createGeomIdx --createFkIdx --createEnumTabs --beautifyEnumDispName  --modeldir "http://models.geo.admin.ch;." --models Nutzungsplanung_Hauptnutzung_V1_1 --dbschema npl_polymorph --import Hauptnutzung_CH_V1_1.xml

Aufgrund der Vererbung erhält die Tabelle geobasisdaten_typ in der Datenbank das zusätzliche Attribut t_type. Das Attribut enthält den konkreten Klassennamen resp. den SQL-Namen des qualifizierten INTERLIS-Klassennamens. Zu finden in der Tabelle t_ili2db_classname. Wenn ich jetzt in der Datenbank einen Record erfasse, der zur meiner erweiterten Typ-Klasse gehört, muss ich so_rp_n0171106geobasisdaten_typ reinschreiben. Ich kann nun munter darauflos digitalisieren oder wie in meinem Fall von meinem richtigen kantonalen Nutzungsplanungsmodell in das Fantasiemodell Daten mittels SQL rüberschaufeln.

Die Magie und das Besondere beginnt erst beim Export. Wenn ich die Daten in meinem erweiterten kantonalen Modell exportieren will, reicht immer noch:

java -jar ili2pg.jar --dbhost geodb-dev.eu-central-1.rds.amazonaws.com --dbdatabase xanadu2 --dbusr XXXXXX --dbpwd YYYYYY --nameByTopic --disableValidation --defaultSrsCode 2056 --expandMultilingual --strokeArcs --createGeomIdx --createFkIdx --createEnumTabs --beautifyEnumDispName  --modeldir "http://models.geo.admin.ch;." --models SO_ARP_Nutzungsplanung_20171106 --dbschema npl_polymorph --export npl_so.xtf

Will ich nun direkt das Bundesmodell exportieren, muss ich ili2pg die neue Option --exportModels mitgeben:

java -jar ili2pg.jar --dbhost geodb-dev.eu-central-1.rds.amazonaws.com --dbdatabase xanadu2 --dbusr XXXXXX --dbpwd YYYYYY --nameByTopic --disableValidation --defaultSrsCode 2056 --expandMultilingual --strokeArcs --createGeomIdx --createFkIdx --createEnumTabs --beautifyEnumDispName  --modeldir "http://models.geo.admin.ch;." --models SO_ARP_Nutzungsplanung_20171106 --exportModels Nutzungsplanung_LV95_V1_1 --dbschema npl_polymorph --export npl_ch.xtf

Mit --exportModels Nutzungsplanung_LV95_V1_1 wird die Transformation in das Basismodell gesteuert. Mit --models SO_ARP_Nutzungsplanung_20171106 wird der Dateninhalt des Exportes definiert. In meinem konkreten Fall bedeutet das, dass beim Export in das Bundesmodell (= Basismodell) die zusätzliche Klasse und das zusätzliche Attribut verloren gehen.

KGDI - The next generation #6: Datenvalidierung mit INTERLIS

Sun, 22 Oct 2017 00:00:00 +0000

Unser Projekt mit Gradle Datenflüsse durchzuführen, schreitet prächtig voran. Vieles bekommen wir mit Gradle geschenkt, ein paar geo-spezifische Tasks programmieren wir selber resp. lassen wir programmieren. Diese sogenannten Custom Tasks lassen sich in einem Plugin bündeln: GRETL.

Seit circa 1.5 Jahren (versuchen) wir die model-driven GDI zu leben. Das bedeutet für die Datenerfassung, dass wir INTERLIS-Modelle schreiben und diese mit ili2pg in der Datenbank abbilden. Der Benutzer verwendet anschliessend QGIS für die Erfassung/Manipulation der Daten. Nun, wo Menschen arbeiten, passieren Fehler. So möchte man sicherstellen, dass die erfassten Daten in der Datenbank dem Modell entsprechen. Ili2pg bildet heute bereits wichtige Constraints in der Datenbank ab, z.B. Länge von Texten, Ranges von numerischen Attributen, Fremdschlüssel etc. Somit hilft uns bei der Datenerfassung die Datenbank, weil fehlerhafte Daten schon gar nicht gespeichert werden können. Meines Erachtens die Achillesferse im Ganzen QGIS-PostgreSQL-Zusammenspiel sind die Geometrien. Da ist es anscheinend schnell möglich Fehler zu speichern. Auch ohne die «Geometrie-Schwäche» bin ich der Meinung, dass eine unabhängige Datenprüfung gut tut. Und weil wir ja INTERLIS verwenden, kann uns das bei der Datenprüfung helfen.

Die Idee ist so einfach wie genial: Wir exportieren die erfassten Daten einfach mit ili2pg und weil ili2pg die Validierungsbibliothek ilivalidator eingebaut hat, wird beim Export auch gleich die Modellkonformatität geprüft. Das exportierte XTF interessiert uns gar nicht, sondern eben nur das Validierungsresultat. Und weil für zukünftig nicht für jede Aufgabe ein Skript von Null an schreiben wollen, können wir für diesen Anwendungsfall Gradle resp. GRETL einsetzen. GRETL hat bereits einige INTERLIS-spezifische Custom Tasks implementiert, so wie den Ili2pgExport-Task.

Die daraus resultierende build.gradle-Datei kann so aussehen:

import java.nio.file.Paths
import ch.so.agi.gretl.tasks.*
import ch.so.agi.gretl.steps.*

buildscript {
    repositories {
        mavenCentral()
        jcenter()
        maven { url 'http://sogeo.services:8081/artifactory/libs-snapshot' }
        maven { url 'http://jars.interlis.ch' }
    }
    dependencies {
        classpath 'ch.so.agi:gretl:1.0.+'
        classpath 'de.undercouch:gradle-download-task:3.3.0'
    }
}

apply plugin: 'ch.so.agi.gretl'

ext {
    sourceDbUrl = "jdbc:postgresql://geodb-t.verw.rootso.org:5432/sogis"
    sourceDbUser = System.env.sourceDbUser
    sourceDbPass = System.env.sourceDbPass

    outputDir = rootProject.projectDir

    todaysDate = new Date().format('yyyy-MM-dd')
    models = []
    models.add(["SO_Agglomerationsprogramme_20170512", "arp_aggloprogramme", "arp_aggloprogramme_" + todaysDate ])
    models.add(["SO_ARP_Nutzungsvereinbarung_20170512", "arp_nutzungsvereinbarung", "arp_nutzungsvereinbarung_" + todaysDate ])
    models.add(["SO_Forstreviere_20170512", "awjf_forstreviere", "awjf_forstreviere_" + todaysDate ])
    models.add(["SO_Hoheitsgrenzen_20170623", "agi_hoheitsgrenzen", "agi_hoheitsgrenzen_" + todaysDate ])
    models.add(["SO_AWJF_Wegsanierungen_20170629", "awjf_wegsanierungen", "awjf_wegsanierungen_" + todaysDate ])
}

// Create a dynamic task for every model we
// want to validate and for cleaning up if
// validaton was successful.
models.each { model ->
    def modelName = model.getAt(0)
    def dbSchema = model.getAt(1)

    task "checkModel_$modelName"(type: Ili2pgExport) {
        description = "INTERLIS validation against database schema: $dbSchema ($modelName)"
        database = [sourceDbUrl, sourceDbUser, sourceDbPass]
        dbschema = dbSchema
        models = modelName
        disableValidation = false
        logFile = file(Paths.get(outputDir.toString(), dbSchema+".log"))
        dataFile = file(Paths.get(outputDir.toString(), dbSchema+".xtf"))

        finalizedBy "removeFiles_$modelName"
    }

    task "removeFiles_$modelName"(type: Delete) {
        description = "Remove files from model export: $modelName"

        onlyIf {
            project.getTasksByName("checkModel_$modelName", false).getAt(0).state.failure == null
        }

        delete file(Paths.get(outputDir.toString(), dbSchema+".log")), file(Paths.get(outputDir.toString(), dbSchema+".xtf"))
    }
}

// This is kinda dummy task. The magic is the 'dependsOn' logic.
task checkAllModels() {
    description = "Validate all models."
}

checkAllModels.dependsOn {
    tasks.findAll { task -> task.name.startsWith('checkModel_') }
}

In der Liste models sind die benötigten Informationen zu den INTERLIS-Modellen, die in der Datenbank abgebildet sind, gespeichert. Also Modellname, Schemaname und für den Export die Basis der Dateinamen von Logfile und XTF-Transferdatei.

Gradles Magie startet in Zeile 39: Anstatt für jedes zu prüfende Modell einen Task zu definieren, werden sogenannte dynamische Tasks definiert indem einfach über die models-Liste interiert wird. Dabei werden pro Modell zwei Tasks erstellt. Einen Export-Task und einen Lösch-Task für die erstellten Dateien (Log- und Transferfile), wobei nur gelöscht wird, falls der Export erfolgreich war (onlyIf). Gab es Fehler, will man wahrscheinlich wissen, was das Problem ist, darum werden die Dateien nicht gelöscht.

Mit gradle tasks --all erscheinen alle Tasks in der Konsole:

Other tasks
-----------
checkAllModels - Validate all models.
checkModel_SO_Agglomerationsprogramme_20170512 - INTERLIS validation against database schema: arp_aggloprogramme (SO_Agglomerationsprogramme_20170512)
checkModel_SO_ARP_Nutzungsvereinbarung_20170512 - INTERLIS validation against database schema: arp_nutzungsvereinbarung (SO_ARP_Nutzungsvereinbarung_20170512)
checkModel_SO_AWJF_Wegsanierungen_20170629 - INTERLIS validation against database schema: awjf_wegsanierungen (SO_AWJF_Wegsanierungen_20170629)
checkModel_SO_Forstreviere_20170512 - INTERLIS validation against database schema: awjf_forstreviere (SO_Forstreviere_20170512)
checkModel_SO_Hoheitsgrenzen_20170623 - INTERLIS validation against database schema: agi_hoheitsgrenzen (SO_Hoheitsgrenzen_20170623)
removeFiles_SO_Agglomerationsprogramme_20170512 - Remove files from model export: SO_Agglomerationsprogramme_20170512
removeFiles_SO_ARP_Nutzungsvereinbarung_20170512 - Remove files from model export: SO_ARP_Nutzungsvereinbarung_20170512
removeFiles_SO_AWJF_Wegsanierungen_20170629 - Remove files from model export: SO_AWJF_Wegsanierungen_20170629
removeFiles_SO_Forstreviere_20170512 - Remove files from model export: SO_Forstreviere_20170512
removeFiles_SO_Hoheitsgrenzen_20170623 - Remove files from model export: SO_Hoheitsgrenzen_20170623

Jeder Task kann einzeln aufgerufen werden, wobei aufgrund der finalizedBy-Bedingung (Zeile 52) die removeFiles-Tasks jeweils automatisch nach den checkModel-Tasks ausgeführt werden.

Wenn wir alle Modelle prüfen wollen, müssen wir nicht jeden Task auflisten, sondern es gibt einen checkAllModels-Task, der alle Modell prüft. Der einzige Sinn dieses Tasks ist, dass er abhängig von allen Tasks, die mit checkModel_ beginnen, ist. Somit müssen sämtlicher dieser Tasks ausgeführt werden, bevor der checkAllModels-Task ausgeführt wird (der aber nichts macht).

Normalerweise bricht Gradle den Prozess ab, falls in einem einzelnen Task Fehler auftreten. Der Ili2pgExport-Task ist genau so designt, dass er eine Exception wirft, wenn beim Export (resp. bei der Validierung während des Exports) ein Fehler auftritt. Das heisst, wir müssen dafür sorgen, dass der Gradle-Prozess nach einem Auftreten eines Fehler nicht abbricht, sondern weiterläuft. Dies erreicht man mit der --continue Option:

gradle checkAllModells --continue

Das Gute daran ist, dass der Gradle Build zwar durchläuft aber trotzdem am Ende den Status «failed» erhält. Dieser Validierungs-Job wird wie unsere anderen Datenflüsse in Zukunft mit Jenkins orchestriert werden. Damit können auf einfachste Weise E-Mails beim Auftreten von Fehler verschickt werden oder der Prozess kann ins kantonale Nagios eingebunden werden. Auch bei der Wahl des Orchestrierungstool gilt «Spatial Is Not Special».

KGDI - The next generation #5: CI/CD mit AWS

Tue, 12 Sep 2017 00:00:00 +0000

Seit einiger Zeit habe hier einen INTERLIS-Checkservice auf Basis von ilivalidator am Laufen. Der Webservice-Teil ist mit Spring Boot umgesetzt. Spring Boot macht das Entwickeln von Spring- und Webanwendungen sehr einfach. Insbesondere das Endprodukt ist ganz praktisch: eine einzige ausführbare JAR-Datei inkl. Servlet-Container. Den ganzen Service in einer einzigen Datei macht das Deployment natürlich auch einiges einfacher. Trotzdem muss ich die JAR-Datei zuerst herstellen, dann auf meinen Server hochladen und den Dienst neu starten.

Schöner wäre es, wenn jeder Commit automatisch dazu führt, dass die Anwendung kompiliert wird, getestet wird und falls alle Tests durchlaufen, in einer Testumgebung installiert wird. Weil wir zudem momentan total auf Docker abfahren, soll das Ganze als Docker-Image deployed werden.

Umgesetzt werden kann so ein Prozess natürlich auf ganz unterschiedliche Weise mit verschiedensten Werkzeugen. Ich habe mich für AWS CodePipeline entschieden. So muss ich überhaupt nichts installieren, sondern nur ein paar AWS-Dienste zusammenstöpseln.

In meinem sehr einfachen Fall einer Pipeline, gibt es ingesamt nur drei Schritte:

Source: Download des Quellcodes von Github.
Build: Kompilieren und Testen der Anwendung mittels AWS CodeBuild. Und anschliessendes Herstellen des Docker-Images.
Staging: Deployment des Docker-Images auf AWS Elastic Beanstalk.

Grafisch sieht das so aus:

Ich habe gute Erfahrung gemacht mit dem - für mich - kompliziertesten Schritt zu beginnen: Build. AWS CodeBuild kann man dazu verwenden sein Projekt (das auf Github o.ä. liegt) auf einer von AWS automatisch bereitgestellten Umgebung zu kompilieren und zu testen. Konkret heisst das, AWS fährt eine EC2-Instanz hoch und installiert die Programme, die man zum Builden seines Projektes braucht, automatisch. AWS stellt sogenannte Umgebungen als Docker-Image bereit. Diese Umgebungen sind ganz spezifisch für unterschiedliche Programmiersprachen ausgelegt. Man wählt dann das passende Docker-Image für sein Projekt aus (z.B. Java, Android etc.). Oder baut sich selber ein Docker-Image zusammenbauen, falls man spezielle Anforderungen an seine Build-Umgebung hat.

In meinen Fall brauche ich in meiner Build-Umgebung Java und Docker, da ich ja eine Java-Anwendung kompilieren will und anschliessend ein Docker-Image herstellen will. In dieser Kombiniation gibt es das aber nicht. Was aber relativ einfach geht, ist vor dem eigentlichen Builden des Codes noch Software nachzuinstallieren. Dh. ich kann die Docker-Umgebung verwenden und noch zusätzlich Java installieren.

Steuern lässt sich das Ganze über eine einzige Datei buildspec.yml, die im Code-Repository liegen muss:

version: 0.2

env:
  variables:
    JAVA_HOME: "/usr/lib/jvm/java-8-openjdk-amd64"

phases:
  install:
    commands:
      - apt-get update -y
      - apt-get install -y software-properties-common
      - add-apt-repository ppa:openjdk-r/ppa
      - apt-get update -y
      - apt-get install -y openjdk-8-jdk
  pre_build:
    commands:
      - echo Logging in to Docker Hub...
      - docker login -u $DOCKER_HUB_USERNAME -p $DOCKER_HUB_PASSWORD
  build:
    commands:
      - echo Starting build `date`
      - chmod +rx -R *
      - ./gradlew clean build
      # git metadata is not available yet when using
      # codepipeline. At the moment we just use a
      # date string.
      - APP_VERSION=$(./gradlew -q getVersion | tail -1)
      - docker build -t sogis/ilivalidator-web-service:$APP_VERSION -t sogis/ilivalidator-web-service:latest .
  post_build:
    commands:
      - echo Build completed on `date`
      - echo Pushing the Docker image...
      - docker push sogis/ilivalidator-web-service:$APP_VERSION
      - docker push sogis/ilivalidator-web-service:latest
      - echo Deleting Dockerfile
      - rm Dockerfile
      - sed -i -e "s/IMAGE_TAG/$APP_VERSION/" Dockerrun.aws.json
artifacts:
  files:
    - '**/*'

Vieles daran ist selbsterklärend. Der Build-Prozess ist unterteilt in Phasen. In jeder Phase kann man mehr oder weniger beliebige Shell-Kommandos ausführen lassen. In der install-Phase installiere ich noch zusätzliche Software. In der pre-build-Phase logge ich mich auf hub.docker.com ein, damit ich anschliessend mein Image hochladen kann. $DOCKER_HUB_USERNAME und $DOCKER_HUB_PASSWORD sind Umgebungsvariablen, die z.B. via WebGUI definiert werden können.

Das Kompilieren, Testen (./gradlew clean build) und Herstellen des Docker-Images (docker build …) geschieht in der build-Phase. Weil mein AWS CodeBuild-Projekt später ein Teil einer Codepipeline wird, muss man ein paar Sachen leider noch frickelig lösen. Beim Kopieren vom Stage- in den Build-Schritt der Codepipeline werden die git-Metadaten nicht mitkopiert, somit kann man leider das Docker-Image nicht mit einem git-sha versehen, sondern nur z.B. mit einem Timestamp. Wenn man das CodeBuild-Projekt autark verwenden würde, wäre das nicht der Fall und die git-Sachen wären vorhanden. Zum Builden des Docker-Images braucht es auch ein Dockerfile, das ebenfalls Bestandteil des Codes ist.

In der post-build-Phase lade das Docker-Image auf hub.docker.com hoch. Interessanterweise hat es bei mir ohne Löschen des Dockerfiles nicht funktioniert (was aber noch nichts heissen muss). Als letztes muss man in dieser Phase die Dockerrun.aws.json-Datei so bearbeiten, dass der richtige Tag des Docker-Images drin steht, welches man im nächsten Schritt der Codepipeline auf AWS Elastic Beanstalk deployen will. Im meinem Fall ein simples sed-Kommando.

Unter artifacts werden sämtliche Dateien wegkopiert. Wenn CodeBuild Bestandteil einer Codepipeline ist, ist mir noch nicht ganz klar, wohin das kopiert wird. Normalerweise irgendwo in einen S3-Bucket. Zum Zwischenlagern quasi.

Läuft das CodeBuild-Projekt durch (Succeeded), kann man sich noch an den Staging-Schritt der Codepipeline machen:

Hier mache ich es wieder gleich wie beim Build-Schritt. Ich erstelle mir zuerst eine AWS Elastic Beanstalk-Anwendung alleine, dh. eine Anwendung, die noch nicht Bestandteil der Codepipeline ist. Das geht via Browser sehr schnell. Eine Beanstalk-Anwendung kann mehrere Environments haben, was z.B. sehr praktisch für Blue/Green-Deployment ist. In einem solchen Fall kann man ganz einfach die Environments auf Knopfdruck tauschen und fertig.

Zuerst muss man beim Erstellen eines Environments wählen, ob es sich um ein Webserver-Environment oder um ein Worker-Environment handelt. Der INTERLIS-Checkservice ist - nomen est omen - ein Webserver-Environment. Anschliessend wählt man noch die Plattform aus. In meinem Fall Docker, weil ich ja ein Docker-Image deployen will. Zu guter Letzt muss man nur noch die Dockerrun.aws.json-Datei hochladen und die Magie beginnt. Nun wird eine EC2-Instanz hochgefahren und noch vieles mehr, was mich aber nicht kümmern muss, da alles sauber automatisch abläuft. Hat das funktioniert, sollte das Environment grün erscheinen und der Service erreichbar sein:

AWS Elastic Beanstalk bietet noch einiges mehr. So kann man z.B. auf Knopfdruck ein Load Balancing und Auto Scaling einrichten.

Hat man den Staging-Schritt und Build-Schritt als «Einzelanwendung» zum Laufen gebracht, kann man an die Codepipeline gehen. Dort kann man sich durch den Wizard klicken und eigentlich nicht mehr viel falsch machen, da man nur noch bestehende Build- resp. Staging-Schritte auswählen muss und ganz zu Beginn beim Source-Schritt das Github-Repository mit seinem Projekt angeben. Nach dem Speichern der Konfiguration, wird die Pipeline ein erstes Mal ausgeführt.

Benachrichtigungen kann man mittels AWS CloudWatch sehr detailliert konfigurieren. Und zwar so detailliert, dass ich es momentan doch eher unübersichtlich und nicht intuitiv finde.

Fazit: Mit AWS CodePipeline und weiteren Diensten kann man sich sehr einfach eine saubere CI/CD-Pipeline zusammenklicken, die dazu führt, dass jeder Commit nach erfolgreichen Tests auf einer (Test-)Umgebung zum Laufen kommt.

KGDI - The next generation #4: AWSome

Sun, 27 Aug 2017 00:00:00 +0000

Im Rahmen unseres Infrastrukturprojektes SO!GIS 2.0 bekommen wir einen neuen WebGIS Client. Das ist der passende Zeitpunkt sich um die in die Jahre gekommene Hintergrundkarte zu kümmern. Circa 10-jährig (gefühlte 50) hat sie eine Ablösung verdient. Entstanden ist sie damals mit dem Aufkommen von Google Maps und dem Umstand, dass das Publizieren der Landeskarten im Internet (uns zu) teuer war. Mit dem Vertrag «Geodatenaustausch unter Behörden» ist das aber kein Thema mehr und wir müssen uns nicht selber eine neue landeskarten-lose Hintergrundkarte zusammenschustern, sondern können die schönen Landeskarten der swisstopo als Basis verwenden.

Das ganze Vorhaben hat ja etwas von Rumspielen. Ich muss ein paar Varianten (in welcher Zoomstufe welche Landeskarte, wann kommt die amtliche Vermessung, was ist mit Maskierungen etc.) zusammenstellen und diese dann dem Publikum zeigen und Feedback abholen und teilweise wieder einfliessen lassen. Am einfachsten ist es, wenn die neuen Hintergrundkartenvarianten nicht nur im Intranet zur Verfügung stehen, sondern gleich im Internet. Auch macht das die Entwicklung einfacher: einfach schnell etwas von zu Hause ändern ist nicht, wenn man sich noch zweimal einloggen muss und sich dann trotzdem alles nicht super schnell anfühlt durch das mehrfache tunneln etc. Zudem bin ich während des Entwickelns definitiv gerne mein eigener Herr und Meister und will nicht auf einen Root/Admin warten, damit ich eine neue Variante deployen kann. Für das alles gibt es ja «die Cloud».

Ich brauche also etwas, wo ich ein paar Gigabyte Rasterdaten speichern kann und diese per WMS zur Verfügung stellen kann. Dh. es ist die Zeit gekommen, die nicht gerade wenigen Dienste von Amazon Web Services kennen zu lernen. Viel brauche ich für meine Bedürfnisse zuerst einmal nicht: Plattenplatz und einen Server auf dem ich den WMS-Server (QGIS-Server in meinem Fall) installieren kann. Weil ich den Server nicht 24/7 laufen lassen will und mich sowieso nicht ständig durch das Webinterface von AWS klicken will, brauche ich etwas damit ich meine Server- und Storagedefinitionen maschinell verwalten und ausführen kann. Aus Transparenz- und Dokumentationsgründen sowieso. Dazu dient mir Terraform: «Write, Plan, and Create Infrastructure as Code».

Als erstes erstelle ich ein Volume, um darauf die Landeskarten zu speichern. Das Volume soll dann bei Bedarf in meinen virtuellen Server eingehängt werden, damit der WMS-Server Zugriff auf die Karten hat. Für Terraform reicht es, wenn ich eine einzelne volume.tf-Datei schreibe. Terraform ist so gestrickt, dass es sämtliche *.tf-Dateien in einem Verzeichnis ausführt.

provider "aws" {
  region = "eu-central-1"
}

resource "aws_ebs_volume" "lk" {
  availability_zone = "eu-central-1a"
  size = 50
  type = "gp2"
  tags {
    Name = "ch.swisstopo.landeskarten"
  }
}

Die Authentifizerung findet via Access-Keys statt. Da genügt es beide Keys in einem File credentials im Ordner $HOME/.aws/ zu speichern. Ein wichtiges Konzept von Terraform sind die Resourcen. In meinem Fall möchte ich eine Elastic Block Storage-Resource in der Zone eu-central-1a. Das Volume soll 50 GB gross und vom Typ gp2 (08/15-SSD) sein. Mit Terraform beschreibe ich was das Ziel sein soll und nicht wie ich an das Ziel gelange (also nicht eine Abfolge von Befehlen).

Mit einem einfachen terraform apply führt es alle notwendigen Befehle aus und das Resultat ist ein verfügbares Volume, das ich beliebigen virtuellen Servern anhängen kann.

Als nächstes erstelle ich händisch (also im Webinterface) einmalig eine EC2-Instanz, um anschliessend das gerade vorher erstellte Volume einzuhängen und die Landeskarten darauf zu speichern. Ist die EC2-Instanz gestartet, kann ich ebenfalls im Webinterface das Volume einhängen. Zusätzlich zum Einhängen muss ich aber einmalig ein Filesystem auf dem Volume erstellen (mkfs -t ext4 /dev/xvdg) und es mounten (mkdir /opt/geodata && mount -o noacl /dev/xvdg /opt/geodata). Hat das alles funktioniert, kann ich alle benötigten Rasterdaten auf das Volume kopieren. Zu guter Letzt wird das Volume wieder «unmounted» und von der EC2-Instanz «detached» und diese terminiert.

Der nächste Schritt ist das automatische Hochfahren eines virtuellen Servers und das Installieren sämtlich benötigter Software, wie z.B QGIS und QGIS-Server aber auch x2go-Server, um auf dem Server selber mit QGIS arbeiten zu können und allenfalls Anpassungen an der Definition der Hintergrundkarte vorzunehmen.

Das automatische Hochfahren mache ich natürlich wieder mit einer Terraform-Datei:

provider "aws" {
  region = "eu-central-1"
}

resource "aws_security_group" "allow_all" {
  name        = "allow_all"
  description = "Allow all inbound traffic"

  ingress {
    from_port = 0
    to_port = 65535
    protocol = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

   egress {
    from_port = 0
    to_port = 0
    protocol = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags {
    Name = "allow_all"
  }
}

# EBS volume must exist.
resource "aws_volume_attachment" "ebs_att" {
  device_name = "/dev/sdg"
  volume_id   = "vol-01a63e9115f061d94"
}

resource "aws_instance" "qgis-gis-server" {
  availability_zone = "eu-central-1a"
  ami = "ami-1e339e71"
  instance_type = "t2.xlarge"
  key_name = "aws-demo"
  vpc_security_group_ids = ["${aws_security_group.allow_all.id}"]
  user_data = "${file("qgis-gis-server.conf")}"

  root_block_device {
    volume_type           = "gp2"
    volume_size           = 12
    delete_on_termination = true
  }

  tags {
    Name = "qgis-gis-server"
  }
}

output "public_ip" {
  value = "${aws_instance.qgis-gis-server.public_ip}"
}

Ich benötige drei Resourcen: eine zum Definieren einer Security Group, eine zum Einhängen des Volumes und natürlich noch eine zum Definieren meiner EC2-Instanz.

Die Security Group ist in meinem Fall sehr offen, da sie so ziemlich alles durchlässt (sowohl Ports wie auch IPs).

Die Volume-Einhäng-Resource muss auf ein bestehendes Volume verweisen. Hier mittels volume_id.

Die aws_instance-Resource definiert mir meinen virtuellen Server. Wichtig ist das Attribut key_name, welches das Key-Pair definiert, das zum Einloggen via SSH verwendet werden soll. Da die Security Group ja ebenfalls erst erstellt wird, kann ich darauf mit einer Variablen zugreifen: ${aws_security_group.allow_all.id}.

Die benötigte Software wird unter user_data installiert. Das kann entweder ein simples Shell-Skript sein oder ein cloud init-Skript:

#cloud-config
package_update: true
package_upgrade: true

apt_sources:
 - source: "ppa:x2go/stable"

packages:
 - xfce4
 - xfce4-whiskermenu-plugin
 - xfce4-terminal
 - thunar-archive-plugin
 - x2goserver
 - x2goserver-xsession
 - apache2
 - libapache2-mod-fcgid
 - firefox
 - gedit
 - filezilla

runcmd:
 # Install QGIS and other gis stuff.
 - 'echo "deb http://qgis.org/ubuntugis xenial main" >> /etc/apt/sources.list'
 - 'echo "deb-src http://qgis.org/ubuntugis xenial main" >> /etc/apt/sources.list'
 - 'echo "deb http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu xenial main" >> /etc/apt/sources.list'
 - 'echo "deb-src http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu xenial main" >> /etc/apt/sources.list'
 - apt-key adv --keyserver keyserver.ubuntu.com --recv-key 073D307A618E5811 # qgis
 - apt-key adv --keyserver keyserver.ubuntu.com --recv-key 089EBE08314DF160 # ubuntugis-(un)stable
 - apt-get update
 - apt-get --yes --allow-unauthenticated install qgis python-qgis qgis-plugin-grass qgis-server
 - apt-get --yes install mapcache-tools libapache2-mod-mapcache libmapcache1-dev
 # Copy apache conf file w/ qgis server stuff (fcgi...).
 - git clone https://github.com/edigonzales/somap20-hintergrundkarte.git /tmp/somap20-hintergrundkarte
 - cp /tmp/somap20-hintergrundkarte/terraform/create-gis-ec2-instance/apache/000-default.conf /etc/apache2/sites-available/000-default.conf
 - chown -R ubuntu:ubuntu /tmp/somap20-hintergrundkarte/
 - service apache2 restart
 # Mount EBS volume.
 # Filesystem already exists (mkfs -t ext4 /dev/xvdg).
 - mkdir /opt/geodata
 - mount -o noacl /dev/xvdg /opt/geodata
 - 'echo /dev/xvdg  /opt/geodata ext4 defaults,nofail,rw,user,exec,umask=000 0 0 >> /etc/fstab'

Wie man sieht, ist es schlussendlich - oder so wie ich es verwende - auch nicht gross etwas Anderes als ein abstrahiertes Shell-Skript. Viele der runcmd-Aufrufe waren notwendig, weil ich es nicht schaffte nicht-ppa-Repositories einfach hinzuzufügen.

Das cloud init-Skript wird jetzt einmalig beim Erstellen des virtuellen Servers ausgeführt. Weil ich den virtuellen Server nach getaner Arbeit immer terminiere, ist das ok. Wenn ich ihn aber nur herunterfahren würde, müsste man sicherstellen, dass das Volume beim Hochfahren gemountet wird.

In der Terraform-Datei kann mit output ein beliebiger Output in der Konsole erzeugt werden. Für mich ist natürlich die IP interessant, da ich ja mit x2go darauf zugreifen und arbeiten will.

Mit terraform plan kann ich mir anzeigen lassen, was ein allfälliger apply-Befehl alles machen würde:

+ aws_instance.qgis-gis-server
    ami:                                       "ami-1e339e71"
    associate_public_ip_address:               "<computed>"
    availability_zone:                         "eu-central-1a"
    ebs_block_device.#:                        "<computed>"
    ephemeral_block_device.#:                  "<computed>"
    instance_state:                            "<computed>"
    instance_type:                             "t2.xlarge"
    ipv6_address_count:                        "<computed>"
    ipv6_addresses.#:                          "<computed>"
    key_name:                                  "aws-demo"
    network_interface.#:                       "<computed>"
    network_interface_id:                      "<computed>"
    placement_group:                           "<computed>"
    primary_network_interface_id:              "<computed>"
    private_dns:                               "<computed>"
    private_ip:                                "<computed>"
    public_dns:                                "<computed>"
    public_ip:                                 "<computed>"
    root_block_device.#:                       "1"
    root_block_device.0.delete_on_termination: "true"
    root_block_device.0.iops:                  "<computed>"
    root_block_device.0.volume_size:           "12"
    root_block_device.0.volume_type:           "gp2"
    security_groups.#:                         "<computed>"
    source_dest_check:                         "true"
    subnet_id:                                 "<computed>"
    tags.%:                                    "1"
    tags.Name:                                 "qgis-gis-server"
    tenancy:                                   "<computed>"
    user_data:                                 "f61a6ca2bf27043bc9a74c638f0211cf5d7c8e15"
    volume_tags.%:                             "<computed>"
    vpc_security_group_ids.#:                  "<computed>"

+ aws_security_group.allow_all
    description:                           "Allow all inbound traffic"
    egress.#:                              "1"
    egress.482069346.cidr_blocks.#:        "1"
    egress.482069346.cidr_blocks.0:        "0.0.0.0/0"
    egress.482069346.from_port:            "0"
    egress.482069346.ipv6_cidr_blocks.#:   "0"
    egress.482069346.prefix_list_ids.#:    "0"
    egress.482069346.protocol:             "-1"
    egress.482069346.security_groups.#:    "0"
    egress.482069346.self:                 "false"
    egress.482069346.to_port:              "0"
    ingress.#:                             "1"
    ingress.1403647648.cidr_blocks.#:      "1"
    ingress.1403647648.cidr_blocks.0:      "0.0.0.0/0"
    ingress.1403647648.from_port:          "0"
    ingress.1403647648.ipv6_cidr_blocks.#: "0"
    ingress.1403647648.protocol:           "tcp"
    ingress.1403647648.security_groups.#:  "0"
    ingress.1403647648.self:               "false"
    ingress.1403647648.to_port:            "65535"
    name:                                  "allow_all"
    owner_id:                              "<computed>"
    tags.%:                                "1"
    tags.Name:                             "allow_all"
    vpc_id:                                "<computed>"

+ aws_volume_attachment.ebs_att
    device_name:  "/dev/sdg"
    force_detach: "<computed>"
    instance_id:  "${aws_instance.qgis-gis-server.id}"
    skip_destroy: "<computed>"
    volume_id:    "vol-01a63e9115f061d94"

Gefällt mir das, reicht ein terraform apply und nach ein paar Minuten habe ich meinen WMS-Server mit den Hintergrundkartenvarianten. Will ich etwas anpassen, kann ich mich mittels x2go auf Server einloggen und gleich dort mit QGIS die Kartendefinitionen ändern. Sind alle Arbeiten erledigt, kann man alles mit einem terraform destroy terminieren. Damit das erfolgreich ist, muss ich aber vorher das Volume unmounten, sonst erschienen Fehlermeldungen.

Damit nach all der trockenen Theorie noch etwas gezeigt wird, hier eine Variante mit Orthofoto (Landsat) und grauer Hintergrundkarte (die Farben für die Maskierung der grauen Variante stammen von hier):

Gorbatschow hat ja bekanntlich (nicht) gesagt: «Wer zu spät kommt, den bestraft das Leben.» Ich wünschte mir im Umgang mit den ganzen IaaS-, PaaS-, SaaS- etc. pp. -Anbietern etwas mehr Mut und Unverkrampfheit. Es kann helfen effizient und sauber strukturiert Aufgaben zu erledigen. Spass macht es allemal. Mit einer totalen Verweigerungshaltung ist man halt irgendeinmal zu spät.

Github-Repo mit allen Skripts: somap20-hintergrundkarte.

Interlis leicht gemacht #16

Mon, 24 Apr 2017 00:00:00 +0000

Zum Wochenstart ein klein wenig ilivalidator-Magie. Im vorangegangen Beitrag habe ich gezeigt, wie man sogenannte Custom Functions in Java programmiert, um beliebige Validierungen zu implementieren. Die dabei resultierende INTERLIS-Funktion war nicht viel mehr als eine Substring-Funktion. Also nichts Besonderes. Häufig will man aber seine Daten mit Referenzdaten, die irgendwo anders gespeichert sind, vergleichen.

In diesem Beispiel - auch weil es momentan so richtig trendy ist - vergleiche ich Daten der amtlichen Vermessung mit dem GWR. Genauer: Ist der EGID aus den Daten der amtlichen Vermessung im GWR enthalten. Für die Daten der amtlichen Vermessung verwende ich das MOpublic-Datenmodell. Hauptgrund ist, dass Custom Functions resp. die Definition von eigenen Constraints mit INTERLIS 1 mit ilivalidator nicht funktionieren. Für die GWR-Referenz verwende ich den «find»-Restservice der BGDI. Es ist kein spezifischer Suchdienst für EGID/EDID im GWR, sondern ein Suchdienst für Datensätze, die in der BGDI publiziert sind. Praktischerweise gibt es ein contains-Parameter. Mittels diesem Parameter lässt sich steuern, ob eine exakte Suche durchgeführt werden soll oder nicht. In unserem Fall sind wir an einer exakten Suche interessiert. Falls die Suche in unserem Fall also genau ein Resultat liefert, gibt es den EGID aus den Daten der amtlichen Vermessung im GWR. Soviel zur Logik der Custom Function.

Zuerst definieren müssen wir das Check-Modell mit den Views erstellen:

INTERLIS 2.3;

CONTRACTED MODEL MOpublic95_ili2_v13_Check (en) AT "http://sogeo.services"
  VERSION "2017-04-14" =
  IMPORTS MOpublic95_ili2_v13;
  IMPORTS SO_FunctionsExt;

  VIEW TOPIC Land_cover =
  DEPENDS ON MOpublic95_ili2_v13.Land_cover;

  	VIEW v_LCSurface
    	PROJECTION OF MOpublic95_ili2_v13.Land_cover.LCSurface;
    =
      ALL OF LCSurface;

      !!@ name = LCSurface_Egid
      !!@ ilivalid.msg = "EGID {RegBL_EGID} wurde im GWR nicht gefunden."
      MANDATORY CONSTRAINT SO_FunctionsExt.check4GWR(RegBL_EGID);

    END v_LCSurface;

END Land_cover;

END MOpublic95_ili2_v13_Check.

Die Funktion SO_FunctionsExt.check4GWR muss in unserem Funktions-Modell deklariert werden:

INTERLIS 2.3;

CONTRACTED MODEL SO_FunctionsExt (en) AT "http://sogeo.services"
  VERSION "2017-04-14" =

  FUNCTION check4GWR (egid: NUMERIC): BOOLEAN;

END SO_FunctionsExt.

Zu guter Letzt ist die Custom Function in Java zu implementieren:

package org.catais.ilivalidator.ext;

import ch.ehi.basics.logging.EhiLogger;
import ch.ehi.basics.settings.Settings;
import ch.interlis.ili2c.metamodel.NumericType;
import ch.interlis.ili2c.metamodel.TransferDescription;
import ch.interlis.iom.IomObject;
import ch.interlis.iox.IoxValidationConfig;
import ch.interlis.iox_j.logging.LogEventFactory;
import ch.interlis.iox_j.validator.InterlisFunction;
import ch.interlis.iox_j.validator.ObjectPool;
import ch.interlis.iox_j.validator.Value;
import org.apache.http.HttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;

import org.json.JSONArray;
import org.json.JSONObject;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class Check4GWRIoxPlugin implements InterlisFunction {
    @Override
    public void init(TransferDescription td, Settings settings, IoxValidationConfig validationConfig, ObjectPool objectPool, LogEventFactory logEventFactory) {
            logger = logEventFactory;
    }

    @Override
    public Value evaluate(String validationKind, String usageScope, IomObject mainObj, Value[] args) {
        if (args[0].skipEvaluation()) {
            return args[0];
        }
        if (args[0].isUndefined()) {
            return Value.createSkipEvaluation();
        }
        String egidString = args[0].getValue();

        // OMG: SSLHandshakeExceptions all over.
        // Do not use HTTPS!
        CloseableHttpClient httpClient = HttpClients.createDefault();

        try {
            HttpGet getRequest = new HttpGet(
                    "http://api3.geo.admin.ch/rest/services/api/MapServer/find?layer=ch.bfs.gebaeude_wohnungs_register&searchText="
                            + egidString +"&searchField=egid&returnGeometry=false&contains=false");
            getRequest.addHeader("accept", "application/json");

            HttpResponse response = httpClient.execute(getRequest);

            if (response.getStatusLine().getStatusCode() != 200) {
                throw new RuntimeException("Failed : HTTP error code : "
                        + response.getStatusLine().getStatusCode());
            }

            BufferedReader br = new BufferedReader(
                    new InputStreamReader((response.getEntity().getContent())));

            String output;
            String jsonString = "";
            while ((output = br.readLine()) != null) {
                jsonString += output;
            }

            JSONObject jsonObject = new JSONObject(jsonString);
            JSONArray resultsArray = jsonObject.getJSONArray("results");

            if (resultsArray.length() == 1) {
                return new Value(true);
            } else {
                return new Value(false);
            }

        } catch (IOException e) {
            logger.addEvent(logger.logErrorMsg(e.getMessage()));
            return new Value(false);
        }
    }

    @Override
    public String getQualifiedIliName() {
        return "SO_FunctionsExt.check4GWR";
    }
}

Keine Rocket Science. Das Interessante passiert in den Zeilen 43 bis circa 68. Für jeden EGID aus der Klasse LCSurface wird ein GET-Request gemacht. Wird der EGID im Datensatz der BGDI / des GWR gefunden, wird true zurückgeliefert. Und funktionieren tut es tadellos. Vielleicht aber nicht nicht die performanteste Art den EGID in den Daten der amtlichen Vermessung zu validieren.

Weil wir in diesem Fall nicht nur Standard-Java-Bibliotheken verwenden (json und http) müssen diese auch beim Validieren in ilivalidator verfügbar sein. Momentan kopiere ich diese in ein Verzeichnis von ilivalidator (z.B. libs-ext/). Der Aufruf ist in nun klein wenig komplizierter:

java -cp  '../apps/ilivalidator/ilivalidator.jar:../apps/ilivalidator/libs/*:../apps/ilivalidator/plugins/*' org.interlis2.validator.Main --config ../examples/06/mopublic.toml  ../examples/06/mopublic_errors.xtf

Die gefundenen Fehler können z.B. zusätzlich in eine XTF-Errordatei geschrieben werden und anschliessend mit ili2pg in die Datenbank importiert und auf map.geo.admin.ch visualisiert werden. Einfacher geht es nicht.

Das Beispiel ist eines von vielen eines vor kurzem gehaltenen ilivalidator-Workshops.

Interlis leicht gemacht #15

Mon, 10 Apr 2017 00:00:00 +0000

Im letzten Beitrag zeigte ich wie man in ilivalidator eigene, zusätzliche Constraints definieren kann und eigene Java-Funktionen schreiben kann. Beides hat zum Ziel, dass man neben der eigentlichen Modellprüfung zusätzliche Prüfungen durchführen kann. Von der Version 0.10.0 zur Version 1.0.0 hat sich da noch einiges getan. Und eines vorweg: es ist ziemlich genial geworden.

Ich habe den fast gleichen Test-Rumspiel-Datensatz wie beim letzten Mal verwendet (ein paar Fixpunkte). Einzig den Modellnamen habe ich leicht angepasst: AVLight. Das Modell sieht jetzt so aus:

INTERLIS 2.3;

MODEL AVLight (en) AT "http://sogeo.services"
  VERSION "2017-02-11" =

  IMPORTS UNQUALIFIED INTERLIS;
  IMPORTS UNQUALIFIED GeometryCHLV95_V1;

    UNIT
      Grads = 200.0 / PI [rad];
      SquareMeters [m2] = (m * m);

    DOMAIN

      Altitude = -200.000 .. 5000.000 [m];
      Rotation = 0.0 .. 399.9 [Grads];
      Accuracy = 0.0 .. 700.0;

   TOPIC Control_points =
      OID AS INTERLIS.UUIDOID;

      CLASS Control_point =
        Category : MANDATORY 0..5;
        IdentND : MANDATORY TEXT*12;
        Number : MANDATORY TEXT*12;
        Geometry : MANDATORY Coord2;
        Plan_accuracy : Accuracy;
        Geom_alt : Altitude;
        Alt_accuracy : Accuracy;
        Mark : MANDATORY 0..8;
        State_of : XMLDateTime;
        FOSNr : 0 .. 9999;
      UNIQUE IdentND, Number;
      END Control_point;

    END Control_points;

  END AVLight.

Wenn ich jetzt einen «no-frills» ilivalidator-Aufruf mache, meldet es mir bereits einen Fehler. Eine Höhe ist viel zu gross und entspricht nicht den Vorgaben des Modelles.

Wenn ich nun weiss, dass die Nummern der Fixpunkte bei uns immer nur acht Zeichen lang sind, kann/muss ich einen zusätzlichen Contraint definieren. Beim letzten Mal habe ich diesen Contraint mit der vordefinierten INTERLIS-Funktion INTERLIS.len() direkt in das Original-Modell geschrieben. Das geht natürlich, ist aber nicht sonderlich elegant und man müsste immer so etwas wie eine Schattenkopie des wirklichen Originals vorliegen haben.

Eleganter geht es mit Views. INTERLIS-Views sind mir soweit gänzlich unbekannt und die Syntax auch nicht nicht wirklich geläuft, aber für etwas gibt es ja das Referenzhandbuch und die ilivalidator-Dokumentation. Man schreibt sich jetzt also ein AVLight_Check-Modell und definiert dort die Views mit den zusätzlichen Constraints:

INTERLIS 2.3;

CONTRACTED MODEL AVLight_Check (en) AT "http://sogeo.services"
  VERSION "2017-04-07" =
  IMPORTS AVLight;

  VIEW TOPIC Control_points_Check =
  DEPENDS ON AVLight.Control_points;

    VIEW v_Control_point
    	PROJECTION OF AVLight.Control_points.Control_point;
    =
      ALL OF Control_point;
      MANDATORY CONSTRAINT (INTERLIS.len (Number)) == 8;
    END v_Control_point;

  END Control_points_Check;

END AVLight_Check.

Um die Prüfung mit dem zusätzlichen Constraint durchzuführen, braucht es einzig noch einen Eintrag in der Konfigurationsdatei AVLight.toml:

["PARAMETER"]
additionalModels="AVLight_Check"

So wird ilivalidator mitgeteilt, dass es ein weiteres zu berücksichtigendes Modell gibt. Der Aufruf erfolgt mit dem --config-Parameter und liefert folgenden zusätzlichen Fehler:

Info: second validation pass...
Info: validate role references of AVLight.Control_points.Control_point...
Error: line 65: AVLight.Control_points.Control_point: tid a01868e1-11fd-4c7c-a109-341b778b4d44: Mandatory Constraint AVLight_Check.Control_points_Check.v_Control_point.Constraint1 is not true.
Info: ...validation failed

Schön. Nur nicht sonderlich leserlich. Mit Metattributen !!@… (Zeilen 14 und 15) kann man nun einerseits den Constraint mit einem Namen versehen und auch eine für den Menschen lesbare Fehlermeldung ausgeben:

INTERLIS 2.3;

CONTRACTED MODEL AVLight_Check (en) AT "http://sogeo.services"
  VERSION "2017-04-07" =
  IMPORTS AVLight;

  VIEW TOPIC Control_points_Check =
  DEPENDS ON AVLight.Control_points;

    VIEW v_Control_point
    	PROJECTION OF AVLight.Control_points.Control_point;
    =
      ALL OF Control_point;
      !!@ name = Punktnummer_Laenge
      !!@ ilivalid.msg = "Laenge der Punktenummer {Number} ist falsch. Erwartet wird 8."
      MANDATORY CONSTRAINT (INTERLIS.len (Number)) == 8;
    END v_Control_point;

  END Control_points_Check;

END AVLight_Check.

Die Metattribute müssen vor den betroffenen Constraint platziert werden. Das Ergebnis ist definitiv informativer:

Info: second validation pass...
Info: validate role references of AVLight.Control_points.Control_point...
Error: line 65: AVLight.Control_points.Control_point: tid a01868e1-11fd-4c7c-a109-341b778b4d44: Laenge der Punktenummer 1066703099 ist falsch. Erwartet wird 8.
Info: ...validation failed

Wenn ich jetzt Dinge prüfen will, die ich nicht mehr mit den INTERLIS-Standardfunktion umsetzen kann, muss ich selber in die Java-Tasten hauen. Grundsätzlich gilt weiterhin, dass man ein Java-Interface implementieren muss. Bei uns beginnen alle BfS-Nummern mit einer «2». Jetzt kann ich also eine «SubText»-Funktion schreiben, die von einem String einen Teil extrahiert und mit einer «2» vergleicht und das Ganze in einen MandatoryConstraint packen:

MANDATORY CONSTRAINT SubText(FOSNr,"0","1") == "2";

Disclamer: Die Methode habe ich gewählt, weil sie bereits aus Testzwecken im iox-ili-Code vorhanden ist.

Neu müssen die - nennen wir sie mal - Custom Functions eine Methode getQualifiedIliName() implementieren. Der Rückgabewert ist ein qualifizierter Name, wie man die Methode in Modellen ansprechen kann. Dafür fällt in der Deklaration im Modell das Metaattribut weg. Zuerst sah ich die Eleganz nicht und dachte, dass man ja jetzt gleiche Methoden für verschiedene Modelle schreiben muss. Aber weit gefehlt. Als man es mir dann erklärte, dämmerte es: Man (z.B. eine Organisation, ein Checkservice-Anbieter) erstellt für die Deklaration der Methoden ein eigenes INTERLIS-Modell, das man - analog wie das AVLight-Modell - jeweils in das Check-Modell importiert. Daher ist der qualifizierte Name meiner Implementierung der SubText-Methode SO_FunctionsExt.mySubText. SO_FunctionsExt ist das Modell in dem einzig meine Funktion deklariert wird.

Die Methode wird jetzt kompiliert und als JAR-Datei in einen Ordner kopiert. Standardmässig lädt ilivalidator seit Version 1.0.0 die Custom Functions aus dem plugins-Verzeichnis (muss erstellt werden) innerhalb der Applikation. Dies kann aber mit dem Parameter --plugins übersteuert werden. Bei mir hat das Laden meiner SubText-Funktion nicht auf Anhieb funktioniert. Ich habe das Gefühl, dass im iox-ili-Code noch ein Fehler versteckt ist. Erst eine zusätzliche Zeile und das anschliessende Kompilieren von iox-ili und kopieren der Bibliothek in das libs-Verzeichnis von ilivalidator hat die Custom Functions gefunden (resp. eben die Klasse geladen).

Anschliessend muss ich das erwähnte SO_FunctionsExt-Modell erstellen:

INTERLIS 2.3;

CONTRACTED MODEL SO_FunctionsExt (en) AT "http://sogeo.services"
  VERSION "2017-04-09" =

  FUNCTION mySubText (text: TEXT; from: NUMERIC; to: NUMERIC): TEXT;

END SO_FunctionsExt.

Ebenfalls leicht anpassen muss ich das AVLight_Check-Modell:

INTERLIS 2.3;

CONTRACTED MODEL AVLight_Check (en) AT "http://sogeo.services"
  VERSION "2017-04-07" =
  IMPORTS AVLight;
  IMPORTS SO_FunctionsExt;

  VIEW TOPIC Control_points_Check =
  DEPENDS ON AVLight.Control_points;

    VIEW v_Control_point
    	PROJECTION OF AVLight.Control_points.Control_point;
    =
      ALL OF Control_point;
      !! Constraint name will not be shown if ilivalid.msg is defined!?
      !!@ name = Punktnummer_Laenge
      !!@ ilivalid.msg = "Laenge der Punktenummer {Number} ist falsch. Erwartet wird 8."
      MANDATORY CONSTRAINT (INTERLIS.len (Number)) == 8;
      !!@ name = BfS_Nummer_erste_Ziffer
      !!@ ilivalid.msg = "Erste Ziffer der BfS-Nummer {FOSNr} ist falsch. Erwartet wird 2."
      MANDATORY CONSTRAINT SO_FunctionsExt.mySubText(FOSNr,"0","1") == "2";
    END v_Control_point;

  END Control_points_Check;

END AVLight_Check.

In Zeile 6 wird das «Funktions-Deklarations-Modell» importiert. Damit hat sich es erledigt. Natürlich muss man noch den Constraint selber ausformulieren und falls gewünscht die passende Fehlermeldung dazu (Zeilen 19 - 21).

Der ilivalidator-Aufruf liefert korrekterweise einen Fehler:

Info: second validation pass...
Info: validate role references of AVLight.Control_points.Control_point...
Error: line 65: AVLight.Control_points.Control_point: tid a01868e1-11fd-4c7c-a109-341b778b4d44: Laenge der Punktenummer 1066703099 ist falsch. Erwartet wird 8.
Error: line 82: AVLight.Control_points.Control_point: tid 2d8fef45-cc65-4305-a59a-5e046afd2fcb: Erste Ziffer der BfS-Nummer 4479 ist falsch. Erwartet wird 2.
Info: ...validation failed

Um eigene Bedingungen zu formulieren mit oder ohne eigenen Tests muss ich in erster Linie nichts Anderes verstehen als INTERLIS. Keine zusätzliche INTERLIS-Validierungssyntax oder ähnliches. Ich brauche keinen neuen Skriptsyntaxparser/-validator, denn den gibt es ja bereits: den INTERLIS-Compiler. Klar, will ich eigene Funktionen schreiben, muss man ein wenig Java beherrschen. Aber that’s it. Die Verwaltung der zusätzlichen Check-Modelle? Gelöst, nennt sich INTERLIS-Modellablage und hat sich etabliert.

Sämtliche Daten finden sich hier. Das Git-Repo mit meiner Custom Function gibt es hier.

Interlis leicht gemacht #14

Mon, 13 Feb 2017 00:00:00 +0000

Letzte Woche wurde von ilivalidator die Version 0.10.0 veröffentlicht. Diese Version beinhaltet ein neues, cooles Feature. Nämlich die Erweiterung der INTERLIS-Prüfung mit eigenen Tests. Hier eine Sneak Preview was schon geht (resp. was ich rausgefunden habe, was geht):

Gemäss Auftragsspezifikation dürfte das R2.6 und R2.7 sein. Das will heissen, dass jetzt einerseits die INTERLIS-Standardfunktionen (kannte ich nicht, siehe Kapitel 2.14 des INTERLIS-Referenzhandbuches) vorhanden sind und andererseits lassen sich eigene Funktionen für die Validierung definieren.

Definiert werden diese zum Ausgangsmodell zusätzlichen Prüfungen wiederum mit INTERLIS. Nämlich mit CONSTRAINTS. Gegenwärtig muss man es noch direkt im Ausgangsmodell machen, was natürlich unschön ist. Soweit ich mich noch erinnere, soll das zukünftig aber über VIEWS in einem abgeleiteten Modell passieren. Dann hätte man das «Original»-Ausgangsmodell und ein Modell mit den zusätzlich definierten Checks.

Die Definition mit INTERLIS in einem Modell mag auf den ersten Blick exotisch wirken. Wahrscheinlich weil man eher etwas wie eine «Check-Definitions-Sprache» erwartet. Aber eben, diese braucht es gar nicht, weil man das genau so gut mit INTERLIS machen kann. Zudem kann ich diese zusätzlichen Modelle wiederum in einer INTERLIS-Modellablage verwalten und zur Verfügung stellen.

Zurück zum eigentlichen Validieren: Zum Rumspielen habe ich mir ein Test-Modell (angelehnt an das MOpublic) für Fixpunkte gebastelt und dazu ein paar Daten in eine XTF-Datei gespielt. Will ich jetzt z.B. die Länge der Fixpunktnummer auf acht Zeichen beschränken (erlaubt sind gemäss Modell zwölf), kann ich mit einer Standardfunktion einen zusätzlichen CONSTRAINT definieren:

CLASS Control_point =
  Category : MANDATORY 0..5;
  IdentND : MANDATORY TEXT*12;
  Number : MANDATORY TEXT*12;
  Geometry : MANDATORY Coord2;
  Plan_accuracy : Accuracy;
  Geom_alt : Altitude;
  Alt_accuracy : Accuracy;
  Mark : MANDATORY 0..8;
  State_of : XMLDateTime;
  FOSNr : 0 .. 9999;
  UNIQUE IdentND, Number;
  MANDATORY CONSTRAINT (INTERLIS.len (Number)) == 8;
END Control_point;

Sollte soweit selbsterklärend sein. Wenn ich jetzt bewusst einen Fehler - also eine Nummer eines Fixpunktes länger als acht Zeichen - einbaue, erscheint auf der Konsole folgende Fehlermeldung:

Error: line 68: FunctionTests.Control_points.Control_point: tid a01868e1-11fd-4c7c-a109-341b778b4d44: Mandatory Constraint FunctionTests.Control_points.Control_point.Constraint2 is not true.

Das ist natürlich noch nicht das Gelbe vom Ei. Immerhin stehen TID und die Zeilennummer in der Meldung. Aber wichtig wären selber definierbare Fehlermeldungen.

Wenn ich jetzt die absolute Validierungsfreiheit will, kann ich meine Funktion in Java selber schreiben. Dazu muss man bloss ein Interface implementieren. Als Beispiel diente mir eine Klasse, die ich unter den Tests gefunden haben. Ich bin dann so vorgegangen, dass ich mir die benötigten Bibliotheken aus der Fatjar-Ilivalidator-Bibliothek, die ich mir mit jedem neuen Release generiere, aus meinem quick 'n' dirty Maven-Repository hole. Programmieren kann man mit der IDE seiner Wahl.

Als zusätzliche Validierung möchte ich prüfen, ob die ersten vier Zeichen der LFP2-Fixpunktnummer mit einem Prefix zusammen dem Attribut IdentND (= NBIdent) entspricht. Da bin ich eigentlich davon ausgegangen, dass das immer so sein sollte. Die ersten vier Zeichen der LFP2-Punkte entsprechen der 1:25'000-Landeskartenblattnummer und der Prefix (= CH030000) ist für LFP2 ebenfalls fix definiert. Die Kombination sollte dem NBIdent entsprechen.

Im Gegensatz zu den Standardfunktionen, muss ich im INTERLIS-Modell die Funktion zuerst deklarieren und mit einem INTELRIS-Metaattribut versehen, damit ilivalidator weiss, in welcher Java-Klasse diese Funktion steckt:

!!@ilivalid.impl.java=org.catais.ilivalidator.ext.IdentND
FUNCTION identND (number: TEXT): TEXT;

Hier steckt die Funktion also in der Klasse org.catais.ilivalidator.ext.IdentND. Die Funktion erwartet einen Parameter vom Typ TEXT und gibt ebenfalls wieder einen Wert vom Typ TEXT zurück.

Die Defintion des CONSTRAINTS ist genau gleich wie bei den Standardfunktionen:

MANDATORY CONSTRAINT identND(Number) == IdentND;

Ich übergebe der Funktion also die Fixpunktnummer und die Funktion bastelt mir daraus den «theoretischen» NBIdent. Diesen vergleicht der CONSTRAINT mit dem NBIdent aus dem Datensatz. Der Java-Code ist keine Rocket-Science:

package org.catais.ilivalidator.ext;

import ch.ehi.basics.settings.Settings;
import ch.interlis.ili2c.metamodel.FunctionCall;
import ch.interlis.ili2c.metamodel.TextType;
import ch.interlis.ili2c.metamodel.TransferDescription;
import ch.interlis.iom.IomObject;
import ch.interlis.iox.IoxValidationConfig;
import ch.interlis.iox_j.validator.InterlisFunction;
import ch.interlis.iox_j.validator.Value;

public class IdentND implements InterlisFunction {
    private IomObject mainObj;
    private Value[] actualArguments;

    private String prefix = "CH030000";

    @Override
    public void init(TransferDescription td, FunctionCall func,Settings settings,IoxValidationConfig validationConfig) {
    }

    @Override
    public void addObject(IomObject mainObj, Value[] actualArguments) {
        this.setMainObj(mainObj);
        this.setActualArguments(actualArguments);
    }

    @Override
    public Value evaluate() {
        Value[] args = getActualArguments();

        if (args[0].skipEvaluation()) {
            return args[0];
        }
        if (args[0].isUndefined()) {
            return Value.createSkipEvaluation();
        }
        String number = args[0].getValue();

        String identnd = prefix + number.substring(0,4);
        TextType text = new TextType();
        return new Value(text, identnd);
    }

    private IomObject getMainObj() {
        return mainObj;
    }

    private void setMainObj(IomObject mainObj) {
        this.mainObj = mainObj;
    }

    private Value[] getActualArguments() {
        return actualArguments;
    }

    private void setActualArguments(Value[] actualArguments) {
        this.actualArguments = actualArguments;
    }

In der Methode evaluate() findet das Zusammenbasteln des NBIdents statt. Grundsätzlich stehen verschiedene Objekte und Werte in der Klasse zur Verfügung. So z.B. auch das komplette INTERLIS-Objekt (mainObj) bei dem der CONSTRAINT definiert ist.

Ist man damit fertig, muss man ilivalidator nur noch davon in Kenntnis setzen, dass es jetzt eine zusätzlich Klasse gibt, der er bitteschön berücksichtigen soll. Leicht naiv dachte ich, dass es reicht, wenn man die generierte Jar-Datei einfach in das libs-Verzeichnis von ilivalidator kopiert. Aber er wollte und wollte die Funktion nicht finden:

Error: line 3972: FunctionTests.Control_points.Control_point: tid 90379a91-29e2-4960-a88f-822c16b8ef3b: Function is not yet implemented.

Auch das explizite Setzen des Classpaths beim Java-Aufruf brachte nichts:

java -cp 'libs/ilivalidator-extensions-0.0.1-SNAPSHOT.jar' -jar ilivalidator.jar --modeldir "http://models.geo.admin.ch;." control_points.xtf

Profis schütteln den Kopf: Anscheinend kann man -cp und -jar nicht kombinieren:

java -cp '/Users/stefan/Apps/ilivalidator-0.10.0/ilivalidator.jar:/Users/stefan/Apps/ilivalidator-0.10.0/libs/*' org.interlis2.validator.Main --modeldir "http://models.geo.admin.ch;." control_points.xtf

Sieht doof aus, ist aber egal. In Production kann man das sicher übersichtlicher lösen. Jedenfalls hat die Prüfung mit meiner Klasse ergeben, dass bei einem Fixpunkt die Nummer nicht stimmt. Oder das Abweichen von der definierten Logik wurde bewusst in Kauf genommen, da der Punkt ein Teil einer Punktgruppe ist und nur wenige Meter im anderen Kartenblatt liegt.

Mit der Möglichkeit eigener Validierungsfunktionen öffnen sich nun viele Türen: So können Webservice oder Datenbanken angezapft werden, um die zu prüfenden Daten mit Referenz- oder Drittdaten (z.B. GWR) zu vergleichen.

Auf die Schnelle konnte ich zwei Dinge nicht umsetzen, die ich gerne wollte. Da ist der Vergleich eines Attributes mit einem Teil des Transferdateinamens. So wie ich den Code verstehe, ist der Transferdateiname unbekannt, da pro IoxEvent geprüft wird. Eventuell könnte man ihn in den Settings unterbringen. Die Settings stehen im InterlisFunction-Interface zur Verfügung. Vielleicht auch super unelegant…

Das zweite Problem ist das Prüfen von LIST und BAG OF Geschichten. Da weiss ich sowieso noch nicht, ob ich die Syntax richtig verstanden habe und ich wünschte mir, dass man mit einem CONSTRAINT alle Elemente (in meinem Fall STRUCTURE) der BAG/LIST prüfen kann.

Eine Demo mit einer eigenen Funktion findet sich hier. Das dazugehörige Java-Gefrickel gibt es hier.

Datenflüsse mit Gradle #2

Wed, 8 Feb 2017 00:00:00 +0000

Der Beitrag dürfte auch den Namen «INTERLIS leicht gemacht #14» erhalten, da er sehr schön die Vorzüge einer model-driven GDI mit INTERLIS zeigt.

Die Idee mit Gradle Datenflüsse zu orchestrieren resp. aus einzelnen immer wiederkehrenden Schritten verschiedene Jobs zusammenstöpseln, wurde in diesem Beitrag erläutert. Eine Herausforderung, die auftritt, ist der Umgang mit Wiederholungen. Wenn es nun häufig darum gehen soll, Daten von A nach B zu kopieren und diese in eine Datenbank zu importieren, merkt man sofort, dass auf dem fremden Server ja nicht nur eine Datei liegt, die es zu importieren gilt, sondern viele. Jetzt könnte man natürlich das build-File einfach mehrfach kopieren. Bei zwei Dateien geht das ja vielleicht noch, aber bei 109 Gemeinden mit je einem AV-Datensatz will man mit diesem Ansatz nie mehr was verändern. Oder die einzelnen Schritte sind so ausgelegt, dass sie nicht nur mit einer Datei umgehen können, sondern mit einer beliebigen Anzahl. Das ist wahrscheinlich komplizierter zu programmieren und ich finde es «schöner», wenn die einzelnen Steps möglichst atomar sind. Vor allem möchte ich aber die Ressource kennen, mit der ich mich während des Jobs beschäftigen muss. Was wenn z.B. auf dem FTP-Server eine unbekannte 10GB-Datei liegt und einfach alles vom FTP-Server herunterladen wird und versucht wird zu importieren? Uncool. Also muss was her, dass zwar tendenziell auf die einzelne Datei zielt aber es soll so etwas geben wie eine Forschleife für die Wiederverwendbarkeit von Jobs (mit anderen Parameter).

Gradle kennt Multiprojekte. Es gibt ein Root-Projekt und Subprojekte. Das Root-Projekt soll in unserem Fall dazu dienen die 1 bis n (identischen) Subprojekte zu konfigurieren und auszuführen.

Für die Probe aufs Exempel will ich Daten, die in unserer model-driven GDI, erfasst werden täglich prüfen. Dazu muss ich die Daten aus der PostgreSQL-Datenbank nach INTERLIS mit ili2pg exportieren und anschliessend mit ilivalidator auf ihre Modellkonformität prüfen. Genau genommen reicht der Export mit ili2pg, da die ilivalidator-Prüfbibliotheken bequemerweise bereits eingebaut sind. Trotz den praktischen QGIS-Editier-Widgets und -Formularen sind Fehler bei der Erfassung schnell passiert. Vor allem wenn der Benutzer Beziehungen manuell korrigiert und erfasst. Darum lohnt sich dieses tägliche Validieren. Insbesondere können so auch Geometriefehler gefunden werden.

Zum Testen stehen zwei kleinere Modelle zur Verfügung: Hoheitsgrenzen und die Nachführungskreise der amtlichen Vermessung.

Die einzelnen Subprojekte müssen in Gradle in der Datei settings.gradle definiert werden:

include ':av_hoheitsgrenzen'
include ':av_nachfuehrungskreise'

Die Namen der Subprojekte sind frei wählbar. Weil aber diese Namen über ein Property im build-File ansprechbar sind, wählt man sinnigerweise etwas aus, das man im weiteren Verlauf noch verwenden kann. Diese Subprojekte befinden sich «eigentlich» in Unterordnern. Weil wir aber sowieso keinen Code in diesen Unterordnern resp. Subprojekten haben, müssen diese Ordner auch nicht existieren.

Nun kommt das erste Mal die Magie zum Vorschein. Im Haupt-Build-File build.gradle können den Subprojekten Properties mitgegeben werden. Wir müssen ja z.B. wissen in welchem Datenbankschema die Daten liegen und welches INTERLIS-Datenmodell verwendet werden muss.

project(':av_hoheitsgrenzen') {
    ext.dbschema = "av_hoheitsgrenzen"
    ext.ilimodels = "SO_Hoheitsgrenzen_20170203"
}

project(':av_nachfuehrungskreise') {
    ext.dbschema = "av_nachfuehrungskreise"
    ext.ilimodels = "SO_AV_Nachfuehrungskreise_20161126"
}

Wo werden die Daten jetzt aber exportiert und geprüft? Gleich nachfolgend, hier:

subprojects {
    apply from: "${rootDir}/validation.gradle"
}

Das bedeutet, dass für jedes Subprojekt das Build-Skript validation.gradle ausgeführt wird. Und in genau diesem validation.gradle findet der eigentliche Validierungs-Job statt:

import ch.so.agi.gdi.tasks.io.InterlisExportTask

ext {
    exportDir = "/opt/tmp/validation/"
}

task validateData(type: InterlisExportTask) {
    host = db_host
    port = db_port
    database = db_database
    usr = db_usr
    pwd = db_pwd

    schema = dbschema
    models = ilimodels

    xtfFileName = exportDir + project.name + ".xtf"
    logfile = exportDir + project.name + ".log"
}

task cleanUp(type: Delete) {
    outputs.upToDateWhen {false}

    onlyIf {
        validateData.state.failure == null
    }

    delete fileTree(dir: exportDir, include: "**/${project.name}.*")
}

validateData.finalizedBy('cleanUp')

Zuerst wird der selber geschriebene - auf ili2pg basierende - InterlisExportTask importiert. Anschliessend wird das Exportverzeichnis definiert. Der Task validateData ist vom Typ InterlisExportTask und prüft gleich während des Exportierens die Daten. Falls sie fehlerhaft sind, ist der Build nicht erfolgreich. Nach dem Validieren werden die exportierten Daten wieder gelöscht. Dies macht der cleanUp-Task vom Typ Delete. Dieser Typ ist bereits Bestandteil von Gradle und musste nicht selber geschrieben werden. Gelöscht werden die Daten aber nur, falls die Validierung erfolgreich war: onlyIf in Verbindung mit validateData.state.failure == null.

Zu guter Letzt möchten wir mit einer E-Mail benachrichtigt werden, falls etwas schief lief. Dies können wir im Root-Build-File mit dem buildFinished-Hook erledigen. Das ist dann kein Task, denn wir aufrufen, sondern ein paar Zeilen selbst erklärendes Groovy pur.

import org.apache.commons.mail.DefaultAuthenticator
import org.apache.commons.mail.Email
import org.apache.commons.mail.SimpleEmail

gradle.buildFinished { buildResult ->
    println "\nBUILD FINISHED"

    if (buildResult.failure) {
        logger.error("build failure - " + buildResult.failure)
    }

    if (buildResult.failure) {
        def message = buildResult.failure.getMessage()

        Email email = new SimpleEmail()
        email.setHostName(email_host)
        email.setSmtpPort(Integer.parseInt(email_port))
        email.setAuthenticator(new DefaultAuthenticator(email_login, email_password))
        email.setSSLOnConnect(true)
        email.setFrom(email_from)
        email.setSubject(project.name)
        email.setMsg(message)
        email.addTo(email_receiver)
        email.send()
    }
}

Will man einzelne Subprojekte ausführen, muss man den vollständigen Pfad (mit Doppelpunkt getrennt) zum Task angeben. In unserem Fall für die Hoheitsgrenzen: gradle :av_hoheitsgrenzen:validateData. Oder aber wenn wir alle Subprojekte am Stück ausführen lassen wollen: gradle validateData. Falls jetzt das erste Subprojekt einen Fehler wirft, wird das zweite nicht mehr ausgeführt. Dieses Verhalten können wir mit der Option --continue ändern.

Ein weiteres kleines Goodie ist die Option --profile. Das liefert eine nette HTML-Seite mit Informationen zum Build.

Interessanter ist so eine Auswertung aber für ein anderes Projekt: Von map.geo.admin.ch werden sämtliche 230 frei verfügbaren AV-Datensätze herunterladen und mit ilivalidator geprüft. Da gibt der Report schon ein bisschen mehr her. Mit der Performanz von ilivalidator darf man schon mal ganz zufrieden sein. 230 AV-Datensätze in 1:11h. Die grafische Aufbereitung der Resultate gibt es hier, die natürlich täglich mittels cronjob und Gradle-Build-File nachgeführt werden.

Datenflüsse mit Gradle #1

Thu, 19 Jan 2017 00:00:00 +0000

Datenflüsse sind ja momentan bei uns ein wichtiges Thema. Bereits heute schieben wir tagein tagaus viele Daten umher. Importieren sie und unsere Datenbank, bauen sie um und exportieren sie auch wieder. Und in Zukunft werden Datenflüsse für uns noch zentraler werden. Aus diesem Grund wollen und brauchen wir etwas Generisches und Rock-solides.

Schaut man sich unsere heutigen Anwendungsfälle an, sieht man viele Gemeinsamkeiten:

Herunterladen / Umherkopieren von Dateien (INTERLIS, Shapefiles, CSV)
Import der Dateien in die PostgreSQL-Datenbank
Umbauen der Daten mit einer SQL-Query in der Datenbank
Daten aus - juhee - einer Oracle-Datenbank in unsere PostgreSQL-Datenbank importieren.

Das heisst, wir brauchen nicht die eierlegende Wollmilchsau, sondern können uns beschränken auf:

eine geringe Anzahl an zu unterstützenden Datenformaten.
einen Datenumbau in der Datenbank (SQL to the rescue).

Weil wir in Zukunft verschiedene Datenbanken für die verschiedenen Zwecke verwenden wollen, kann der Datenumbau zwar mit SQL in der Quell-Datenbank stattfinden, trotzdem müssen anschliessend die Daten in die Ziel-Datenbank transportiert werden.

An einer höchst konstruktiven Brainstormingsitzung mit Claude Eisenhut haben wir über diese ganze generische Datenfluss/-integrationsgeschichte noch weiter räsoniert und versucht solche Prozesse weiter «auseinanderzubeinlen»:

Der ganze Prozess ist ein Job. Ein Job kann aus mehreren Steps bestehen. Ein Step ist z.B. das Herunterladen von Dateien oder das Importieren einer Datei in die Datenbank etc. Ziel sollte es sein, möglichst wiederverwendbare Steps zu haben, die man nur noch aneinanderzureihen hat, um eine zuverlässige Datenintegration inkl. Datenumbau zu erhalten. Der AGI-Mitarbeiter muss also nicht mehr das hundertste Individualskript mit php4 oder Python schreiben, sondern muss nur noch Steps zusammenstöpseln und die gewünschten Parameter eintragen.

Für den Datenimport bräuchten wir als Steps ein paar robuste 1:1-Transformatoren, wie z.B. CSV in die Datenbank oder INTERLIS in die Datenbank. Für den Datenumbau braucht es einen DB2DB-Step, dem man einfach SQL übergeben kann und anschliessend das Resultat der Query in die Ziel-Datenbank schreibt.

Es war schon Aufbruchstimmung als die Diskussion auf das Thema «Ausführen eines Jobs» kam. Und da fiel das Zauberwort von Claude: «Ihr könnt auch ant verwenden.» Ein Build-Tool. Das macht ja genau das, was wir wollen. Es hat (voneinander abhängige) einzelne Schritte, die ausgeführt werden, z.B.:

Quellcode kompilieren
Kompilierte Klassen zu einem Paket/Programm schnüren.
Das Programm irgendwo hinkopieren.

Falls das Kompilieren Fehler wirft, wird das Paketieren und Kopieren gar nicht erst ausgeführt. Analog dazu soll bei uns der Importschritt nicht stattfinden, falls beim Herunterladen der Datei ein Fehler auftaucht ist.

Anstelle von ant habe ich mich zum Ausprobieren aber für Gradle entschieden. Was bekommt sonst noch «gratis»:

Steps (Tasks in Gradle) können einzeln angestossen werden.
Ein Job (Project) - also ein Build - kann auch innerhalb eines Groovy-Skript ausgeführt werden und nicht nur auf der Konsole.
Eigene Tasks sind einfach selber in Groovy oder Java programmierbar.

Als kleiner Teaser hier ein Build-Skript, das eine INTERLIS-Datei kopiert und anschliessend mit ilivalidator prüft:

import ch.ehi.basics.settings.Settings
import org.interlis2.validator.Validator
import ch.ehi.basics.logging.EhiLogger

buildscript {
    repositories {
        mavenCentral()
        maven {
            url "http://www.catais.org/maven/repository/release/"
        }
    }
    dependencies {
        classpath group: 'org.interlis2', name: 'ilivalidator', version: '0.9.0'
    }
}

// Copy file
task copyFile(type: Copy) {
    from("/Users/stefan/Projekte/agi-data-integrator/data/ch_254900.itf")
    into("/opt/tmp/")
}

// Validate INTERLIS file
task validate(type: IlivalidatorTask, dependsOn: 'copyFile') {
    fileName = "/opt/tmp/ch_254900.itf"
}

// Custom Task
class IlivalidatorTask extends DefaultTask {
    @Input String fileName

    Boolean success

    @TaskAction
    def validate() {
        def settings = new ch.ehi.basics.settings.Settings()
        settings.setValue(Validator.SETTING_ILIDIRS, Validator.SETTING_DEFAULT_ILIDIRS)
        success = Validator.runValidation(fileName, settings)
        if (!success) {
            throw new GradleException("INTERLIS validation failed.")
        }
    }
}

Das Beispiel ist natürlich nicht sonderlich sinnvoll, aber es zeigt ein paar Grundprinzipien ganz gut. Ausführen muss man den Build auf der Konsole mit gradle validate, um das ITF zuerst zu kopieren und anschliessend zu validieren. Will man nur validieren ohne vorgänging zu kopieren, kann man den copy-Task auch ausschliessen: gradle validate -x copyFile.

Falls die INTERLIS-Datei fehlerfrei ist, wird der Build erfolgreich beendet: BUILD SUCCESSFUL. Falls sich Fehler in der INTERLIS-Datei eingeschlichen haben, wird der Build mit BUILD FAILED und weiteren Fehlermeldungen beendet:

Die selber geschriebenen Tasks (hier IlivalidatorTask) kann man natürlich noch auf verschiedene Weisen auslagern und so wiederverwenden. So würden dann auch noch ein Zeilen zu Beginn des Skripts wegfallen und es blieben die beiden Tasks übrig (7 Zeilen).

Das Ganze ist momentan noch nicht mehr als eine Spielerei. Ob weitere unserer Anforderungen so einfach abgedeckt werden können, muss sich noch zeigen.

Stay tuned for more gradle data integration magic.

KGDI - The next generation #3

Mon, 2 Jan 2017 00:00:00 +0000

«Model-driven GDI» klingt ja schon mal cool. Von wem genau der Begriff stammt, weiss ich leider nicht mehr. Es kann gut sein, dass er sich nach einem Vortrag von Peter Staub bei uns herauskristallisiert hat oder vielleicht auch während des Vortrages bereits gefallen ist. Was verstehe ich darunter?

Grundsätzlich dazu gehört der modellbasierte Ansatz mit INTERLIS. Beschrieben wird er, wie auch die Vorzüge von Datenmodellen, im Dokument Allgemeine Empfehlungen zur Methodik der Definition «minimaler Geodatenmodelle», das hier zu finden ist. Diese Gedanken sind ja nicht nur richtig wenn es um minimale Geodatenmodelle des Bundes oder der Kantone geht, sondern sie passen auch wenn es ganz allgemein um Geodatenmodellierung geht (und wenn kein Gesetz es verlangt). Dieser modellbasierte Ansatz soll dann integraler Bestandteil der GDI werden. Da müssen Prozesse und Technik sauber darauf abgestimmt werden. Vor allem braucht es auch ein Ökosystem, damit überhaupt damit gearbeit werden kann.

Früher begann ein Projekt oder ein Erfassung von Daten häufig mit einem Anruf beim AGI mit der Bitte um die Erstellung von ein paar Datenbanktabellen. Gesagt getan: CREATE TABLE …. Es folgte anschliessend ein weiterer Anruf, weil dieses und jenes Attribut in den Tabellen fehlte.

Oftmals stand auch das Tool im Vordergrund. Es ging fast weniger um die Erfassung von Daten, als um die Entwicklung eines coolen neuen Tools (was für den Entwickler verständlicherweise spannender ist).

Mit der «model-driven GDI» sollen jetzt wieder die Daten und die Datenerfassung ins Zentrum gerückt werden. Damit gewinnen wir eine bessere Dokumentation, eine sauberere Strukturierung der einzelnen Teile und ein nachhaltigeres «Ganzes». Klar braucht es dazu auch Tools aber in den allermeisten Fällen geht es zuerst einmal um die Daten und die Strukturierung dieser Daten.

Die Überlegungen wie die Daten strukturiert werden sollen, muss man sich ja sowieso machen. Auch wenn das vielleicht häufig nicht formalisiert stattfindet. Weil man sich die Arbeiten ja eben sowieso machen muss, kann man das daraus folgende Resultat gleich im UML/INTERLIS-Editor erfassen. Hier ein Beispiel eines Datenmodelles für Nutzungsvereinbarungen des Amtes für Raumplanung:

Wichtig bereits bei diesem Schritt ist das Beschreiben der Attribute und Klassen:

Das vom UML/INTERLIS-Editor erzeugte INTERLIS-Modell kann noch mit weiteren Kommentaren in einem beliebigen Texteditor (hier jEdit) ergänzt werden:

Eine Frage, die schnell auftaucht, ist der Umgang mit benötigten Fremddaten. Häufig braucht man ja Daten, wo der «Master» in einem anderen Modell (resp. Schema/Tabelle in der DB) verwaltet werden, z.B. Gemeindegrenzen, Grundstücke etc. Soll man diese jetzt nochmals im eigenen Modell verwalten? Diese Fragestellung ist ein Teil des Modellierungsprozesses und muss dort beantwortet werden. Häufig reicht wahrscheinlich ein Fremdschlüssel. Der Fremdschlüssel kann in diesem Fall entweder ein Sachattribut (amtliche Gemeindenummer) oder die Geometrie selber sein.

Es lohnt sich auch bereits zu diesem Zeitpunkt Gedanken über die Publikation der Daten zu machen. In erster Linie geht es zwar um die Datenerfassung und diese geschieht tendenziell in einem normalisierten Datenmodell. In den meisten Fällen will man die Daten aber in einer einfacheren, flachgedrückten Form publizieren. Unter Publikation kann das Bereitstellen für anderen Dienststellen verstanden werden (read-only, als Hintergrundlayer in QGIS), die Bereitstellung im WMS / WebGIS oder die Datenabgabe (GeoPackage, DXF etc.). Wenn sich Erfassung und Publikation nicht viel nehmen, darf man wahrscheinlich auch beim (Erfassungs-)Modell Kompromisse eingehen, um sich ein eigenes Publikationsmodell zu sparen. Klare Vorstellungen was publiziert werden soll, dient auch dem Aufdecken allfälliger Fehler in einem Erfassungsmodell.

Ob für das allfällig benötigte, separate Publikationsmodell immer auch mit INTERLIS modelliert werden muss, bedarf noch ein paar weiterführenden Diskussionen und Gedanken. Tendenziell bin ich Freund dieses Ansatzes. Im ersten Blick wirkt es ein wenig übertrieben, wenn man an kleine Modelle denkt, aus denen eine flachgedrückte Tabelle für die Publikation entstehen. Andererseits kann man alles über einen Kamm scheren. Damit entsteht auch kein Wildwuchs. Und wie gesagt, Gedanken wie ich was publizieren will, muss man ja sowieso machen. Sowie auch die Dokumentation. Es ist also nicht so, dass ohne INTERLIS-Publikationsmodell alles 10x mal schneller geht.

Aus dem INTERLIS-Modell erstelle ich mit einem Einzeiler und ili2pg die leeren Datenbanktabellen:

java -jar /Users/stefan/Apps/ili2pg-3.5.1/ili2pg.jar --dbhost 192.168.50.4 --dbdatabase xanadu2 --dbusr stefan --dbpwd ziegler12 --dbschema arp_nutzungsvereinbarungen --disableValidation --nameByTopic --sqlEnableNull --createGeomIdx --createFkIdx --strokeArcs --models SO_ARP_Nutzungsvereinbarung_20160726 --modeldir "http://models.geo.admin.ch/;." --defaultSrsCode 2056 --schemaimport

Ein absolutes Goodie ist das Handling von Kommentaren in diesem Ökosystem. Die Kommentare, die man mühelos im GUI des UML/INTERLIS-Editors erfasst hat, werden in der Datenbank abgebildet:

QGIS passt da wunderprächtig in das gesamte Ökosystem. Dank den sehr mächtigen Formularfunktionen, kann man auch in normalisierten Datenmodellen direkt und bequem Daten erfassen:

Bei kleineren Modellen geht das Zusammenstöpseln der Beziehungen und der richtigen Widget-Typen schnell. Bei grösseren Modellen ist es dann schon brutale Fleissarbeit. Vor allem wenn das Modell nach einer Testphase wieder ändert. Dann muss unter Umständen das gesamte QGIS-Projekt neu erstellt werden. Aus diesem Grund ist eine Arbeitsgruppe zur Zeit an der Entwicklung eines QGIS-Projektgenerators, der dem Menschen bei dieser doch eher mühseligen Arbeiten helfen soll.

Was wir in QGIS wieder entdecken, sind die Kommentare zu den einzelnen Attributen:

Will man die Daten in dieser Form bereitstellen (oder eben dann das Publikationsmodell), lässt sich die erstellte INTERLIS-Transferdatei einfach mit dem ilivalidator prüfen.

Für eine «model-driven GDI» steht heute ein sich stetig weiterentwickelndes Ökosystem zur Verfügung. Gedankliche und konzeptionelle Ansätze sind auch vorhanden. Sicher müssen Details noch geklärt werden. Meines Erachtens ist der vermeintliche Mehraufwand mehr als gerechtfertig. Die Qualität und Zuverlässigkeit des gesamten Systems wird besser. Ebenso bekommen die Daten, als teuerstes und wertvollstes Gut in der GDI, einen grösseren Stellenwert.

Zu guter Letzt: Löst das Datenmodell (resp. das Transferformat dazu) jetzt das Shapefile ab? Nein. Wenn überhaupt löst GeoPackage das Shapefile ab. Für mich sind INTERLIS-Transferformate und Shapefiles et al. immer noch zwei paar Schuhe…

REST-Service mit Spring Boot

Sun, 1 Jan 2017 00:00:00 +0000

Frameworks, Bibliotheken und dergleichen für REST-Service gibt es wie Sand am Meer. Für SO!GIS 2.0 werden wir sicher etwas Anständiges erhalten. Programmiersprachlich wollen wir uns in der möglichen Auswahl aber auf Java und Python beschränken. Als Freund von Java und weil ich die Webdienste für ili2gpkg, Freeframe und ilivalidator mit Spring Boot gemacht habe, wollte ich ausprobieren, wie weit und wie gut man im Spring-Universum einen REST-Service zusammenbasteln kann.

Das soll kein Technologie-Vorentscheid sein, sondern mir das Gefühl geben, was geht, wo kann es klemmen, was sind mögliche Stolperfallen etc.

Etwas was mir an Spring Boot gefällt, ist wie schnell man wie sehr wenig Code sehr weit kommt. Praktikabel finde ich ebenfalls, dass man die ganze Anwendung kapseln kann. Ob das genau einem «Self-Contained-System» entspricht, weiss ich zwar nicht, jedoch passt es für mich. Anstelle einer WAR-Datei, die man in einem Servlet-Container deployen muss, kann die Spring Boot-Anwendung mit einem embedded Container ausgeliefert werden.

Ebenfalls interessant ist die Tatsache, dass man ein halbwegs «production ready deployment» ziemlich einfach hinbekommt. Zumindest auf Linux-Maschinen. Viele Fragestellungen (Logging, Service) kann man elegant konfigurieren.

Für die Umsetzung eines REST-Services mit Spring Boot braucht es je nach Anforderung und Wünschen ein paar weitere Abhängigkeiten. Entweder von Spring selbst oder dann halt Klassiker wir z.B. JDBC-Treiber. Erwähnenswert sind Hibernate Spatial und für das Serialisieren resp. Deserialisieren von Geometrien eine weitere Bibliothek.

Als Beispieldatensatz verwende ich die Bienenstandorte des Kantons. Die Datenbanktabelle habe ich in eine Shapedatei gedumped und das Ganze anschliessend in ein kleines INTERLIS-Modell gequetscht. Ganz simpel, nur eine Klasse:

Für den Demodatensatz ist das unnötig, aber wenn man das Ganze - auch nur aufgrund von Testzwecken - auf verschiedenen Systemen ein paar Mal aufsetzen will/muss, lernt man es zu schätzen, wenn man plattformunabhängige Werkzeuge hat, die den Datenimport/-export immer gleich machen:

java -jar /Users/stefan/Apps/ili2pg-3.5.1/ili2pg.jar --dbhost 192.168.50.4 --dbdatabase xanadu2 --dbusr stefan --dbpwd ziegler12 --dbschema alw_bienenstandorte --disableValidation --nameByTopic --sqlEnableNull --createGeomIdx --createFkIdx --strokeArcs --models SO_Bienenstandorte_20161227 --modeldir "http://models.geo.admin.ch/;." --defaultSrsCode 2056 --import alw_bienenstandorte_20161225.xtf

Und schon sind die Bienenstandorte (893 Standorte) in der Datenbank:

Alles was es jetzt für einen funktionierende REST-Service braucht sind mindestens eine Klasse und ein Interface (natürlich neben den üblichen Spring Boot-Klassen etc.). Als erstes braucht es eine «resource representation class». Nomen est omen: diese Klasse repräsentiert die REST-Ressource. In unserem Fall müssen wir noch ein paar Annotations anbringen, damit Spring Boot weiss, dass es sich um eine Datenbank-Tabelle handelt und wie das Schema und die Tabelle heisst. Schlussendlich ist es aber nicht Anderes als ein POJO. Das Beispiel gibt es hier.

Nun müssen wir ein Repository erstellen indem wir ein Interface erweitern. Interessanterweise müssen wir das Interface selber nicht implementieren. Auch die out-of-the-box Queries müssen wir nicht implementieren. Hier kommt der Spring-Feenstaub zum Zug. Diese «findByXXX»-Abfragen gibt es in Verbindung mit einer Datenbank gratis. Im Interface können wir auch noch den Namen wählen, wie die Ressource angesprochen werden soll. In unserem Fall: ch.so.alw.bienenstandort.

Mit der Klasse und dem Inteface bekommt man bereits einen funktionierenden REST-Service. Als Zugabe ist dieser REST-Service bereits «Hypermedia-Driven» mit dem HAL-Ausgabeformat. So in der Gänze verstanden, habe ich diese HATEOAS-Sache jedenfalls noch nicht. Erster Eindruck: da wird dem REST-Service noch bisschen «Intelligenz» eingehaucht. Und ebenfalls sind die Resultate gepaged (resp. wurde so definiert im Repository), dh. es werden nicht alle 893 Bienenstandorte auf einmal zurückgeliefert, sondern nur immer 20 Stück und der Client muss die weiteren Pages anfordern:

{
  "_embedded" : {
    "/ch.so.alw.bienenstandort" : [ {
      "bstnr" : "102920",
      "jahr" : 2017,
      "pid_2015" : 207814,
      "pid_2011" : 9209,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2612608.4948999994, 1250397.3973999992 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/4"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/4"
        }
      }
    }, {
      "bstnr" : "48016",
      "jahr" : 2017,
      "pid_2015" : 604435,
      "pid_2011" : 131414,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2601152.9639, 1258610.9426999986 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/5"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/5"
        }
      }
    }, {
      "bstnr" : "72184",
      "jahr" : 2017,
      "pid_2015" : 601831,
      "pid_2011" : 128795,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2597261.348700002, 1228547.4364 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/6"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/6"
        }
      }
    }, {
      "bstnr" : "102924",
      "jahr" : 2017,
      "pid_2015" : 207788,
      "pid_2011" : 9182,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2613244.4734000005, 1248688.3872000016 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/7"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/7"
        }
      }
    }, {
      "bstnr" : "102806",
      "jahr" : 2017,
      "pid_2015" : 207826,
      "pid_2011" : 9222,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2608493.4569999985, 1247794.4199 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/8"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/8"
        }
      }
    }, {
      "bstnr" : "82568",
      "jahr" : 2017,
      "pid_2015" : 205965,
      "pid_2011" : 7008,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2631996.5089999996, 1240138.5654999986 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/9"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/9"
        }
      }
    }, {
      "bstnr" : "72272",
      "jahr" : 2017,
      "pid_2015" : 473947,
      "pid_2011" : 103687,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2597749.344300002, 1227845.4373999983 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/10"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/10"
        }
      }
    }, {
      "bstnr" : "41612",
      "jahr" : 2017,
      "pid_2015" : 201334,
      "pid_2011" : 1346,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2616852.5084999986, 1258628.4717999995 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/11"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/11"
        }
      }
    }, {
      "bstnr" : "62016",
      "jahr" : 2017,
      "pid_2015" : 605250,
      "pid_2011" : 132231,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2609550.3222999983, 1225258.332800001 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/12"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/12"
        }
      }
    }, {
      "bstnr" : "62140",
      "jahr" : 2017,
      "pid_2015" : 207633,
      "pid_2011" : 9020,
      "status_bst" : "Aktiv",
      "saisonal" : "1",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2609506.3486, 1229524.3418000005 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/13"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/13"
        }
      }
    }, {
      "bstnr" : "102732",
      "jahr" : 2017,
      "pid_2015" : 203788,
      "pid_2011" : 3813,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2608305.4657000005, 1250274.4360999987 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/14"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/14"
        }
      }
    }, {
      "bstnr" : "62004",
      "jahr" : 2017,
      "pid_2015" : 602420,
      "pid_2011" : 129390,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2604411.054299999, 1223172.8467000015 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/15"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/15"
        }
      }
    }, {
      "bstnr" : "31484",
      "jahr" : 2017,
      "pid_2015" : 602532,
      "pid_2011" : 129502,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2604137.3066000007, 1225322.382199999 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/16"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/16"
        }
      }
    }, {
      "bstnr" : "41668",
      "jahr" : 2017,
      "pid_2015" : 207610,
      "pid_2011" : 8995,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2601171.401799999, 1256667.4970000014 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/17"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/17"
        }
      }
    }, {
      "bstnr" : "58006",
      "jahr" : 2017,
      "pid_2015" : 605293,
      "pid_2011" : 132274,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2639746.5154, 1254536.799800001 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/18"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/18"
        }
      }
    }, {
      "bstnr" : "72284",
      "jahr" : 2017,
      "pid_2015" : 605172,
      "pid_2011" : 132151,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2610135.3605000004, 1234627.3381999992 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/19"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/19"
        }
      }
    }, {
      "bstnr" : "31520",
      "jahr" : 2017,
      "pid_2015" : 201191,
      "pid_2011" : 1202,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2603626.3046000004, 1221320.3414999992 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/20"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/20"
        }
      }
    }, {
      "bstnr" : "18006",
      "jahr" : 2017,
      "pid_2015" : 605255,
      "pid_2011" : 132236,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2628381.2760000005, 1235816.4164999984 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/21"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/21"
        }
      }
    }, {
      "bstnr" : "102936",
      "jahr" : 2017,
      "pid_2015" : 604431,
      "pid_2011" : 131410,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2605077.9497000016, 1248073.3953999989 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/22"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/22"
        }
      }
    }, {
      "bstnr" : "41736",
      "jahr" : 2017,
      "pid_2015" : 207669,
      "pid_2011" : 9058,
      "status_bst" : "Aktiv",
      "saisonal" : "0",
      "status_btr" : "Aktiv",
      "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)",
      "standort" : {
        "type" : "Point",
        "coordinates" : [ 2616021.4771, 1252594.4061999992 ]
      },
      "_links" : {
        "self" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/23"
        },
        "bienenstandort" : {
          "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/23"
        }
      }
    } ]
  },
  "_links" : {
    "first" : {
      "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort?page=0&size=20"
    },
    "self" : {
      "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort"
    },
    "next" : {
      "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort?page=1&size=20"
    },
    "last" : {
      "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort?page=44&size=20"
    },
    "profile" : {
      "href" : "http://localhost:8884/v1/rest/layer/profile/ch.so.alw.bienenstandort"
    },
    "search" : {
      "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/search"
    }
  },
  "page" : {
    "size" : 20,
    "totalElements" : 893,
    "totalPages" : 45,
    "number" : 0
  }
}

Diese «Intelligenz» macht sich vor allem in der Verlinkung bemerkbar. So werden z.B. die Links auf die nächste und vorherige Page angezeigt oder ein Link auf die vorhandenen Suchanfragen:

{
  "_links" : {
    "findByBstnr" : {
      "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/search/findByBstnr{?bstnr,page,size,sort}",
      "templated" : true
    },
    "self" : {
      "href" : "http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/search"
    }
  }
}

Nachdem man sich die Zusatzfunktionalitäten ein wenig zu Gemüte geführt hat, kann man mit den bekannten vier Verben Daten abfragen, erfassen, ändern und löschen.

Daten abfragen / GET:

curl -X GET http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/search/findByBstnr?bstnr=102920

Daten erfassen / POST:

curl -H "Content-Type: application/json" -X POST -d '{"bstnr" : "1", "jahr" : 2017, "pid_2015" : 207669, "pid_2011" : 9058, "status_bst" : "Aktiv", "saisonal" : "0", "status_btr" : "Aktiv", "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)", "standort" : {"type" : "Point", "coordinates" : [ 2600000.123, 1200000.456 ]}}' http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort

Daten löschen / PUT:

curl -H "Content-Type: application/json" -X PUT -d '{"bstnr" : "1", "jahr" : 2525, "pid_2015" : 207669, "pid_2011" : 9058, "status_bst" : "Aktiv", "saisonal" : "0", "status_btr" : "Aktiv", "kommentar" : "Export Gelan-2015;(19.12.2016; 22:31)","standort" : {"type" : "Point", "coordinates" : [ 2600000.123, 1200000.456 ]}}' http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/4

Daten löschen / DELETE:

curl -X DELETE http://localhost:8884/v1/rest/layer/ch.so.alw.bienenstandort/4

Etwas was mir momentan noch nicht klar ist, ist der Umgang mit verschiedenen Koordinatensystemen. Verwendet man als Codierung für die Geometrien GeoJSON gibt keine Möglichkeit mehr das Koordinatensystem anzugeben. In der ersten Spezifikation gab es die Möglichkeit, nur hat man das in freier Wildbahn auch nie wirklich gesehen. Wahrscheinlich läuft es darauf hinaus, dass der REST-Service pro Ressource konsquenterweise nur ein Koordinatensystem unterstützen kann. Lieber in sauber nur ein Koordinatensystem als mit viel Geknorze was reinbasteln…

Eine andere Frage ist eher Spring-bezogen. Nämlich der Umgang mit räumlichen Abfragen. Grundsätzlich ist dank Hibernate Spatial und der Jackson-Erweiterung für das De-/Serialisieren der Geometrien der Umgang mit Geodaten soweit schmerzlos. Ganz so out-of-the-box scheinen die räumlichen Abfragen nicht zu gehen. Für einen anderen Testdatensatz (die Nachführungskreise der amtlichen Vermessung) habe ich weitere Queries im Repository-Interface definiert:

{
  "_links" : {
    "findByKreisname" : {
      "href" : "http://localhost:8884/v1/rest/layer/nf_kreis/search/findByKreisname{?kreisname,page,size,sort}",
      "templated" : true
    },
    "findByPerimeter" : {
      "href" : "http://localhost:8884/v1/rest/layer/nf_kreis/search/findByPerimeter{?x,y}",
      "templated" : true
    },
    "findByKreisnameLike" : {
      "href" : "http://localhost:8884/v1/rest/layer/nf_kreis/search/findByKreisnameLike{?kreisname,page,size,sort}",
      "templated" : true
    },
    "self" : {
      "href" : "http://localhost:8884/v1/rest/layer/nf_kreis/search"
    }
  }
}

Neben der schicken «findByKreisnameLike»-Query, mit der man genau wie bei Datenbanken «Like»-Abfragen durchführen kann, habe ich natürlich auch etwas Räumliches definiert. Hier im konkreten Fall etwas Ähnliches wie eine WMS-GetFeatureInfo-Abfrage. Um das mit möglichst wenig Aufwand hinzukriegen, habe ich eine native PostgreSQL/PostGIS-Query im Repository definiert, was jetzt natürlich sehr, sehr, seeeeehr unschön ist. Eine bessere und nachhaltigere Alternative ist das Schreiben von «Custom Queries» in dem man ein eigenes Repository-Interface implementiert (was man anscheinend sowieso für read-only Repositories machen muss). Da bin ich mir aber nicht mehr sicher, ob diese Queries noch im search-Link auftauchen, was wiederum sehr schade wäre.

Fazit: Das Spring-Universum liefert schon sehr viel, um effizient REST-Service anbieten zu können. Hier gilt auch ausnahmsweise einmal «Spatial is (ganz klein wenig) special», da man sicher noch für räumliche Abfragen klären muss, wie gut sich das umsetzen liesse. Die interessantere Frage ist aber unabhängig vom eingesetzten Produkt und betrifft den Betrieb/Konfiguration des REST-Services: Welche Tabellen / Views als REST-Service mit welchen Alias-Namen der Attribute angeboten werden, steht in Zukunft in unserem Metamodell. Was man wahrscheinlich nicht möchte, ist das manuelle Erstellen der benötigten Klassen, Interfaces, Rechte etc. im REST-Service. Entweder könnte sich der REST-Service direkt aus dem Metamodell bedienen. Da ist mir jedoch gar nichts bekannt. Oder aber es wird etwas Ähnliches wie einen Code-Generator für diese Objekte geben. Da müssen die Profis ran. TBD.

KGDI - The next generation #2

Thu, 29 Dec 2016 00:00:00 +0000

Ein Thema, das uns im Kontext von SO!GIS 2.0 beschäftigt, sind Datenflüsse. Datenflüsse jeglicher Art. Also sowohl von aussen nach innen, von innen nach aussen und wie auch innerhalb unserer GDI selbst. Irgendwie müssen die Daten ja in unsere GDI kommen und oftmals müssen sich auch noch umgebaut werden. Darum sind es eigentlich zwei Aspekte:

Datenintegration: Nennen wir es einfach mal so, obwohl damit nicht nur die Integration von Daten in unsere GDI gemeint ist, sondern eben auch Daten aus unserer GDI exportieren.
Datenumbau: Wenn Daten hin- und hergeschoben werden, müssen sie garantiert noch in irgendeiner Form - sei es auch nur minimal - umgebaut werden.

Obschon es ja zwei paar Schuhe sind, gehören die beiden Prozesse irgendwie zusammen. Denn auch beim Datenumbau fliessen die Daten von A nach B.

Warum beschäftigt dieses Thema uns jetzt konkret? Dazu muss man ein wenig ausholen: Ein absolutes Fundament unserer KGDI ist die zentrale Datenhaltung. Das bedeutet, dass die kantonalen Geodaten in unserem Amt (resp. in unserer Infrastruktur) liegen. Das Amt A hat - falls gewünscht - einfachen Zugriff auf Daten des Amtes B. Unser Amt koordiniert alles und kümmert sich auch um die Datenbereitstellung gegenüber internen und externen Kunden. Seien es blosse WebGIS-Kärtchen oder die Abgabe der Rohdaten. Die Ämter müssen/dürfen keine eigene GIS-Infrastruktur aufbauen.

Vielleicht wurde dieser Grundsatz der zentralen Datenhaltung über die Jahre etwas überinterpretiert: Zentrale Datenhaltung hiess dann auch, dass jede GIS-Applikation direkt mit unserer einzigen Datenbank arbeiten muss. Und über die Jahre hinweg haben sich in den Ämtern etliche Applikationen angesammelt, die zwar einen kleinen Raumbezug haben und dementsprechend geografische Daten speichern müssen aber nicht von uns programmiert wurden. Oftmals wissen wir nicht genau, was diese Fremdapplikationen genau machen, geschweige denn wie sie funktionieren. Eine Art Blackbox also.

Schematisch sieht die Architektur somit so aus:

Die blauen Anwendungen sind unsere Kernkomponenten (Desktop- und WebGIS) und selber programmierte Tools. Diese Anwendungen haben wir im Griff und wir kennen die Anforderungen und Problemchen relativ gut. Die grünen Anwendungen sind die Fremdapplikationen, die ebenfalls direkten Lese- und Schreibzugriff auf unsere einzige Datenbank haben. Der rote Kasten symbolisiert die exportierten Daten aus der Datenbank.

Diese zentrale Datenbank führte dann beispielhaft zu folgenden Problemfällen:

(1) Die Fremd-Webapplikation läuft nicht auf unseren Servern, sondern auf den Servern des Informatikamtes (AIO). Die Applikation greift aber auf unsere Datenbank zu (lesend und schreibend). Weil wir relativ (seeeeehr) lange mit dem Datenbankupdate zugewartet haben, konnte auch der Hersteller der Fremdapplikation seine Software nie updaten und die Userexperience war nicht sonderlich gut, da kein Bugfixing-Release etc. eingespielt werden konnte. Schlussendlich war niemand mit der Situation zufrieden (Hersteller, AIO, Anwender und wir).

(2) Die Fremd-Webapplikation macht bei jeder Abfrage in unserer Datenbank dutzende (temporäre) Tabellen und löscht sie wieder. Wegen den vielen Vacuum-Prozessen in unserer Datenbank füllte es die Festplatte.

(3) Ein Hersteller einer Fremdapplikation wurde verknurrt seine Applikation von Oracle nach PostgreSQL umzuschreiben, damit die Daten bei uns gespeichert werden können. Leider hat der Hersteller mit PostgreSQL nicht viel Erfahrung und so schlichen sich unnötig viele Bugs in die Software. Ein grausiger Bug war das Verbrauchen von DB-Connections ohne sie wieder freizugeben. Das führte dazu, dass ein sämtliche QGIS-Benutzer keine Tabellen in QGIS mehr laden konnten, weil eben alle Verbindungen aufgebraucht waren.

Für mich absolut entscheidend ist die Tatsache, dass Fremdapplikationen keinen negativen Impact auf unsere Datenbank im engeren Sinne und auf unsere Infrastruktur im weiteren Sinne haben dürfen. Konsequenterweise bedeutet das, dass viele oder alle dieser Fremdapplikationen ihre eigene Datenhaltung mitbringen müssen. Was bei den meisten bereits der Standardfall ist. Viele der Daten dieser Anwendungen sollen trotzdem noch in unsere GDI integriert werden (Interesse anderer Ämter, Webkarten, Publikation als WMS etc.). Jedoch bestimmen wir den Zeitpunkt und das Bereitstellen von Ressourcen (CPU, DB-Connections etc.) für die Integration und verlassen uns nicht auf das Prinzip Hoffnung, das schon nichts Schlimmes passiert.

Was wir also brauchen, ist eine rock-solide und generische Lösung für die Integration von Daten, die in einem Fremdsystem liegen. Bereits heute importieren wir viele Daten aus verschiedenen Systemen. Jedoch wird dazu immer und immer wieder ein neues Skript geschrieben. Dieses quick 'n' dirty Skript verleitet leider auch häufig dazu die Trennung von Integration und Datenumbau nicht einzuhalten, was dann wiederum den Betrieb und Unterhalt dieses Importprozesses erschwert. Vielmehr schwebt uns etwas vor, dass man konfigurien kann und nicht neu programmieren muss. Super viele Formate müssen nicht unterstützt werden: am Ehesten wohl CSV, Oracle-DB, PostGIS-DB, INTERLIS, Shapefiles, GeoPackage. Zudem sollte der Integrationsprozess sowohl manuell wie auch mittels Scheduler ausführbar sein.

Konzeptionell haben sich da z.B. die Spring-Leute mit Spring Batch schon mal ein paar gute Gedanken gemacht (resp. JSR-352).

Zusätzlich zu diesem «Datenintegrator» braucht es noch eine lightweight REST-Schnittstelle. Damit können Anwendungen schnell und schmerzlos an Daten kommen, die in unserer Datenbank liegen und falls die Berechtigung vorhanden ist auch verändern und zurückschreiben. Die REST-Schnittstelle ist nicht dazu gedacht Terabyte an Daten zu lesen und zu schreiben, sondern vielmehr für einzelne, wenige Erfassungen von z.B. Neophyten, Unfällen und dergleichen. Oftmals tuen sich ja Nicht-GIS-Softwarehersteller relativ schwer mit einer «GIS-Schnittstelle». Damit man solche Fragestellungen nicht mit dem GIS-Schlachtrosse WFS beantworten muss, ist neu die REST-Schnittstelle da. JSON versteht ja wirklich jeder Webentwickler. Und auch mit einem GET / POST / PUT und DELETE kann man umgehen. Wie im Metamodell vorgesehen, wird man bei jedem registrierten Datensatz wählen können, ob dieser als REST-Schnittstelle exponiert werden soll.

In Zukunft möchten wir auch unsere eigene Datenbank funktional trennen: Es wird eine Erfassungs-Datenbank, eine Publikations-Datenbank und eine Archiv-Datenbank geben. Heute passiert das alles in einer Datenbank in der gleichen Tabelle. Das ist zu starr, zu unflexibel und zu fehleranfällig. Zudem passt die angedachte Architektur besser zum Ansatz der model driven GDI (dazu in einem späteren Beitrag mehr). Für das Überführen der Daten von der Erfassungsdatenbank in die Publikationsdatenbank ist ein Datenumbau notwendig. Dieser Datenumbau geht einher mit einer Datenintegration. Nur halt innerhalb unserer eigenen Infrastruktur. Aufgrund der Tatsache, dass entweder das Ziel- oder Quellsystem in unserem Fall eine relationale Datenbank ist, kann man sich überlegen, ob der Datenumbau nicht auf Funktionen eben dieser Systeme zu beschränken ist resp. in diesen Systemen passieren soll. Damit ist auch die Lingua Franca für den Datenumbau klar: SQL. Für die Umsetzung kann man sich verschiedene Varianten vorstellen: Views, selber geschriebene DB-Funktionen oder pures SQL, das abgesetzt wird. Zum jetzigen Zeitpunkt ist mir die «pure-SQL»-Lösung am Liebsten.

Die Idee eines solchen Werkzeuges scheint jedenfalls nicht super originär zu sein: batyr.

In Zukunft dürfte es bei uns also circa so aussehen:

Das wahrscheinlich Wichtigste bei diesem Umkrempeln ist aber, dass wir die Softwarehersteller gut informieren, gut dokumentieren und eine gewisse Strenge an den Tag legen. Es bringt nichts, wenn wir bei jeder neuen Herausforderung gleich wieder in alte Verhaltensmuster zurückfallen und das Rad neu erfinden wollen, nur damit es kurzfristig schneller funktioniert.

KGDI - The next generation #1

Sat, 24 Dec 2016 00:00:00 +0000

Unsere Geodateninfrastruktur ist circa 16-jährig. So weit, so gut. Das heisst aber auch, dass viele der Komponenten und Prozesse ebenfalls etliche Jahre auf dem Buckel haben. Zu viele Jahre. Die Bedürfnisse und Anforderungen an eine GDI haben sich in diesen 16 Jahren stark verändert. Ein WebGIS-Client sieht heute anders aus und hat andere Funktionen und die Leute sind es sich gewohnt mit solchen exotischen Tools umzugehen. Auch die GIS-Kenntnisse in den Dienststellen ausserhalb einer GIS-Fachstelle sind gewachsen. Und zu guter Letzt darf man langsam zur Einsicht kommen, dass viele Herausforderungen in einer GDI nichts mit «GIS» zu tun haben, sondern pure IT ist und dementsprechend nicht durch den GIS-Spezialisten/-Informatiker/-Projektleiter (whatever…) gelöst werden müssen.

Wenn im Kontext der GDI der Bezugsrahmenwechsel etwas gebracht hat, dann die Einsicht, dass sich in diesen 16 Jahren sehr viel angesammelt. Bei dieser Ansammlung von selbst geschriebener Software, Schnittstellen, Daten etc. fehlt uns oft die Übersicht. Wer braucht noch was? Warum liegt diese Datei hier? Bei vielen eingesetzten Tools, Skripts und dergleichen darf oder muss man getrost sagen: «End of Life».

Während dieser GIS-Pionierzeit endeten viele Entwicklungen (gefühlt einmal mit jeder Programmiersprache, die es gibt) als Individualkomponente. Das Rad wurde immer und immer wieder neu erfunden. Das macht als Entwickler natürlich Spass, ist aber für den Betrieb so ziemlich unangenehm. Oder wenn für den Bezugsrahmenwechsel jede dieser Individualkomponente geprüft und allenfalls angepasst werden muss. Zudem müssen mit diesem Approach immer mehr Ressourcen in die Aufrechterhaltung des Betriebes gesteckt werden. Interessanterweise wurde auch nie irgendetwas abgekündigt. Es läuft und läuft und läuft. Und es kam/kommt immer mehr.

Mit ein paar kleinen kosmetischen Anpassungen kommt man da nicht mehr raus. Das «Übel» muss an der Wurzel gepackt werden. Aus diesem Grund haben wir das Projekt SO!GIS 2.0 gestartet.

Es hat unter anderem zum Ziel:

Reduktion der Anzahl und der Heterogenität der GDI-Komponenten
Erneuerung der veralteten GDI-Komponenten
Schaffung der Prozesse zur nachhaltigen Weiterentwicklung der GDI
Definition der konzeptionellen Systemarchitektur für die anschliessenden Umsetzungsprojekte

Einige Fragestellungen werden bereits kräftig bearbeitet oder aber sind zumindest gedanklich ziemlich gediehen. Ein paar Kernideen werden in loser Folge hier beschrieben.

Ein grosses Thema, das uns absolut beschäftigt, kann man in drei Wörtern zusammenfassen: «Know your GDI». Uns ist zwar seit geraumer Zeit bekannt, dass wir die GDI eben nicht genau kennen, aber das Maximum der Unkenntnis wurde - wie erwähnt - beim Bezugsrahmenwechsel erreicht.

Da liegen auf einem Server ein paar Dutzend MapServer-Mapfiles herum aber niemand weiss, ob es die noch braucht und falls ja, für was genau. Oder der gern gesehene Klassiker: «Wie schreibt jetzt die Fremdapplikation in unserer Datenbank?». Bis heute haben wir das nicht herausgefunden. Fairerweise muss man dazu sagen, dass der Softwarehersteller der Fremdapplikation auch nicht mehr weiss, wie seine Software in unsere Datenbank schreibt… WMS-/WFS-Dienste gibt es en masse. Weil wir aber nicht wissen, wer die intern noch braucht, können wir die massig vorhandenen Redundanzen nicht abbauen. Das zieht dann Fäden: Tabellen und Views, die in den Mapfiles referenziert werden, können auch nicht bearbeitet oder gelöscht werden, weil irgend eine asbach-uralt Software diesen bestimmten WMS-Layer verwendet. Individualkomponente lässt grüssen.

Im Rahmen des Ablösungsprojektes unseres WebGIS-Clients (inkl. Backend) haben wir ein Metamodell entwickelt:

Aus dem Teilmodell GDI-Knoten wird es eine Implementierung in Form einer Webanwendung geben. In dieser Webanwendung wird man Tabellen, Views, Dateien, Dienste etc. erfassen müssen. Einerseits damit sie überhaupt z.B im WMS-Dienst erscheinen und andererseits damit wir wissen wie/was/wo verwendet wird. Kurz zusammengefasst: Was im Metamodell nicht registriert wird, existiert nicht in unserer GDI (und kann gelöscht werden). Detailliertere Informationen gibt es hoffentlich an der nächsten FOSSGIS-Konferenz. Oliver Jeker (als eigentlicher Vater des Metamodelles) hat einen Abstract eingereicht.

Das Metamodell ist also ein erster, unverzichtbarer Schritt, um die GDI zu kennen und zu beherrschen.

Interlis leicht gemacht #14

Wed, 9 Nov 2016 00:00:00 +0000

Um mit JavaServer Faces «rumzupröbeln», habe ich vor geraumer Zeit kurzerhand einen kleinen Checkerservice mit den ilivalidator-Bibliotheken gemacht. Weil ich auch noch etwas Einfacheres haben wollte, habe ich mit Spring Boot einen «no-frills» Webdienst auf die Beine gestellt:

Die Funktionalität ist eingeschränkt: Das Ein- und Ausschalten von Checks wird nicht unterstützt. Wäre aber z.B. machbar, wenn man ZIP-Dateien mit einer TOML-Datei hochladen könnte.

Im Fokus stand bei dieser Umsetzung weniger das GUI, sondern vielmehr die Webwendung ohne GUI. Mit curl und Konsorten geht das Prüfen von INTERLIS-Dateien so jetzt wunderbar:

Die Syntax ist simpel:

-v: curl erzeugt möglichst viel Output.
-XPOST: Es wird ein POST-Request durchgeführt.
-F file=@ch_254900_error.itf: Mit diesem Parameter werden die Daten auf den Server hochgeladen. Dabei entspricht file dem Namen des HTML-Input-Elementes vom Typ file der HTML-Webseite.

Es folgt die URL des Webdienstes (Achtung: Slash am Ende der URL). Wie einfach, effizient und im Prinzip elegant so ein Dienst geschrieben werden kann, sieht man im Quellcode. Es wird zweimal auf die gleiche URL gemappt. Der einzige Unterschied ist die Request-Methode. Einmal GET und einmal POST. Je nach Request-Methode erscheint entweder die HTML-Webseite oder es wird die Prüfung der hochgeladenen Datei durchgeführt.

In die zu prüfendene INTERLIS-Datei habe ich absichtlich einen Fehler eingepflanzt. Der Output der INTERLIS-Prüfung ist ziemlich unübersichtlich. Vor allem auch wegen des Outputs von curl selbst:

Auf der viertletzten Zeile ist der Fehler ersichtlich: Ein LFP3 ohne Nummer. Um das Ganze übersichtlicher zu machen, lassen wir beim nächsten Aufruf den -v-Parameter und den Parameter -XPOST. -XPOST hat zwar keinen Einfluss auf den Output, ist aber überflüssig, da curl standardmässig einen POST-Request ausführt. Ist schon übersichtlicher geworden:

Jetzt ist nur noch Output von ilivalidator sichtbar. Was mich aber in den allermeisten Fällen überhaupt nicht interessiert, sind die Information zu den Repositories und Programmversionen etc. etc. Oder anders formuliert: Ich will nur die Fehler sehen. Für diesen Usecase reicht ein wenig «Pipe-und-Grep-Zauber»:

Der Pipe-Operator | leitet die Ausgabe des Befehls (hier curl) direkt an einen anderen Befehl. In unserem Fall ist dieser andere Befehl grep. Mit grep lassen Dateien etc. nach Texten durchsuchen. Weil wir eben nur an Fehlern interessiert sind, suchen wir nach «Error». Eine Unschönheit gibt es noch: diese Datei-Hochlade-Information. Warum die jetzt plötzlich erscheint, ist mir schleierhaft. Mit einem simplen zusätzlichen -s beim curl-Befehl verschwindet diese auch noch:

Bei macOS und Linux ist curl natürlich mit dabei oder zumindest sofort installiert. Unter Windows ist curl jedenfalls auch verfügbar. Eventuell reicht unter Windows 10 schon die Linux Bash Shell.

Interlis leicht gemacht #13

Sun, 23 Oct 2016 00:00:00 +0000

Von den letzten Wochen sind mir zwei frustrierende INTERLIS-Erlebnisse in Erinnerung geblieben. Nicht wegen INTERLIS selbst, nicht wegen der investierten Zeit, sondern viel mehr wegen der mangelnden Datenhygienie resp. der mangelnde technischen Datenqualität. INTERLIS = gute Datenqualität. Stimmt so nicht. Und das ist dann doch erstaunlich nach über 20 Jahren INTERLIS…

Wenn man versucht mit ili2pg diese Daten in die Datenbank zu importieren, kommt es zu Fehlermeldungen. Schlimmstenfalls gibt es eine java.lang.NullPointException, was so nicht wirklich aussagekräftig ist und definitiv nicht der Weisheit letzter Schluss ist. Das Verhalten der Software in diesen Situationen resp. die Fehlermeldung werden in Zukunft sicher noch besser werden (müssen).

Das Tüpfelchen auf dem Frustrations-i war aber die Aussage (wobei ich die Aussage voll und ganz nachvollziehen kann):

«I’m a bit puzzled…I spent quite some time on trying a new procedure to integrate cadastral data. I wanted to use interlis, but it seems not possible at the moment, what a pity.»

Nun denn, um nicht nur rumzufrustrieren, im Folgenden ein paar konstruktive Tipps und Tricks zur Fehlersuche in den Daten.

Fehlermeldung lesen

Klingt blöd, ist aber so. Unter Umständen ist die Fehlermeldung relativ lang und der interessante Teil steht ganz zu Beginn:

Error: Object 12216773 at (line 6751147,col 0)
Error:   ERROR: duplicate key value violates unique constraint "pipelines_linear_element_posname_pkey"
  Detail: Key (t_id)=(1100350) already exists.
Error: Object 12216773 at (line 6751148,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751149,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751150,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751151,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751152,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751153,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751154,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751155,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751156,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751157,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751158,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751159,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751160,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751161,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751162,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751163,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751164,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751165,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751166,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751167,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751168,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751169,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751170,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751171,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751172,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751173,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751174,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751175,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751176,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: Object 12216773 at (line 6751177,col 0)
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: failed to query av_mopublic.t_ili2db_seq
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block
Error: org.postgresql.util.PSQLException: ERROR: current transaction is aborted, commands ignored until end of transaction block
Error:   ERROR: current transaction is aborted, commands ignored until end of transaction block

Die zweite Zeile sagt bereits alles aus: irgendetwas mit einem duplicate key. In der ersten Zeile schreibt ili2pg netterweise sogar die Transfer-ID und die Zeile dieses Objektes in der Transferdatei. Schaut man sich diese Zeile an, wird sofort ersichtlich, was das Problem ist:

TABL Linear_element_PosName
OBJE 12216771 8294270 IWB 2614693.048 1268727.154 186.0 1 2 2703
OBJE 12216772 8294270 IWB 2614676.986 1268794.383 175.7 1 2 2703
OBJE 12216773 8294324 IWB 2616025.963 1270865.401 28.1 1 2 2703
OBJE 12216773 8294359 IWB 2616025.963 1270865.401 28.1 1 2 2703
OBJE 12216773 8294390 IWB 2616025.963 1270865.401 28.1 1 2 2703
OBJE 12216773 8294397 IWB 2616025.963 1270865.401 28.1 1 2 2703
...

Ein bestimmtes Objekt ist mehrfach in der Transferdatei vorhanden. Was aber das Hauptproblem ist, ist die mehrfach verwendete Transfer-ID (12216773). Das kann so natürlich nicht funktionieren. Da es sich um das MOpublic-Datenmodell handelt, liegt der Verdacht nahe, dass es sich um einen Fehler beim Datenumbau handelt. Insbesondere wenn man sich vergegenwärtigt, wie diese Tabelle entsteht und aus welchen Tabellen des DM01-Datenmodells zusammengebastelt wird.

ili2pg-Optionen

ili2pg hat die Option --trace, die während des Imports zusätzliche Informationen in die Konsole schreibt. In Kombination mit der Option --log fubar.log, die diese Meldungen in eine Datei schreibt, hat man eine gute Ausgangslage für die Fehlersuche. Ohne --trace meldet ili2pg folgendes:

Info: ilifile <./NG_NaturgefahrenLV95.ili>
Info: create table structure...
Info: process data file...
Info: data <naturgefahren.itf>
Info: Basket NG_NaturgefahrenLV95.Gefahrengebiet(oid itf0)...
java.lang.NullPointerException

Mit --trace erfolgt dieser Output:

Info: buildSurfaces(): build surfaces..._itf_geom_Gefahrengebiet, maxOverlaps 0.0 (ItfSurfaceLinetable2Polygon.java:217)
Error: java.lang.NullPointerException
Error:     ch.interlis.iom_j.itf.impl.ItfSurfaceLinetable2Polygon.removeValidSelfIntersections(ItfSurfaceLinetable2Polygon.java:392)
Error:     ch.interlis.iom_j.itf.impl.ItfSurfaceLinetable2Polygon.buildSurfaces(ItfSurfaceLinetable2Polygon.java:230)
Error:     ch.interlis.iom_j.itf.ItfReader2.read(ItfReader2.java:313)
Error:     ch.ehi.ili2db.fromxtf.TransferFromXtf.doit(TransferFromXtf.java:389)
Error:     ch.ehi.ili2db.base.Ili2db.transferFromXtf(Ili2db.java:1786)
Error:     ch.ehi.ili2db.base.Ili2db.runUpdate(Ili2db.java:598)
Error:     ch.ehi.ili2db.base.Ili2db.runImport(Ili2db.java:195)
Error:     ch.ehi.ili2db.base.Ili2db.run(Ili2db.java:175)
Error:     ch.ehi.ili2db.AbstractMain.domain(AbstractMain.java:367)
Error:     ch.ehi.ili2pg.PgMain.main(PgMain.java:71)

Immerhin weiss ich jetzt, dass es beim Prozess der Flächenbildung und beim Löschen der validen Self-Intersections Probleme gab. Diese validen Self-Intersections sind wahrscheinlich die Nemesis eines jeden Programmierers: INTERLIS lässt ja bekanntlich unter gewissen Voraussetzungen Self-Intersections zu. In der Datenbank möchte man aber keine nicht-konformen Simple-Feature-Geometrien. Das unter einen Hut zu bringen ist schwierig.

Falls es sich wirklich um ein Problem bei der Flächenbildung / Self-Intersections-Bereinigung handelt, weiss ich aber immer noch nicht wo (also geografisch) das Problem liegt. In diesem Moment hilft mir die Option --skipPolygonBuilding. Sie verhindert die Flächenbildung und importiert somit nur die Linien, wie sie in der ITF-Datei kodiert sind. Somit kann ich die Daten immerhin in die Datenbank importieren und in einem Desktop-GIS anschauen und prüfen. In QGIS gibt es dafür das Geometry Checker Plugin:

Im Moment bin ich nur an den Self-Intersections interessiert. Sämtliche anderen Prüfungen lasse ich links liegen. Das Resultat liefert mir dann die Liniengeometrien mit Self-Intersections. Sind diese zu gross, kann ili2pg nicht mehr damit umgehen und auch kein Polygon daraus bilden. Einer der Fehler, die das Plugin aufgedeckt hat:

Ein weiterer häufig auftretender Fehler in (INTERLIS-)Daten sind doppelte Stützpunkte. Auch diese lassen sich im Geometry Checker Plugin entdecken.

Selber coden

Bei anderen Daten wurde der Import mit dieser Fehlermeldung verweigert:

Info: Basket MD01MOCH24MN95F.Points_fixesCategorie1(oid itf0)...
Info: Basket MD01MOCH24MN95F.Points_fixesCategorie2(oid itf1)...
Info: Basket MD01MOCH24MN95F.Points_fixesCategorie3(oid itf2)...
Error: failed to build polygons of MD01MOCH24MN95F.Points_fixesCategorie3.Mise_a_jourPFP3.Perimetre
Error:   no polygon
Info: Basket MD01MOCH24MN95F.Couverture_du_sol(oid itf3)...
java.lang.NullPointerException

Mit --trace sieht die Fehlermeldung so aus:

Info: buildSurfaces(): build surfaces..._itf_geom_Mise_a_jourCS, maxOverlaps 0.05 (ItfSurfaceLinetable2Polygon.java:217)
Info: removeValidSelfIntersections(): valoverlap Intersection overlap 8.527947694197402E-4, coord1 (2559588.499, 1144173.854, NaN), coord2 (2559591.1405376485, 1144172.0968293739, NaN), tid1 4955, tid2 4955, idx1 0, idx2 1, seg1 CIRCULARSTRING (2559591.251 1144171.994, 2559589.951 1144173.036, 2559588.499 1144173.854), seg2 CIRCULARSTRING (2559588.499 1144173.854, 2559589.948 1144173.037, 2559591.247 1144171.998) (ItfSurfaceLinetable2Polygon.java:397)
Info: removeValidSelfIntersections(): valoverlap Intersection overlap 3.728486693480781E-4, coord1 (2556237.844, 1145424.429, NaN), coord2 (2556240.125186811, 1145424.724616642, NaN), tid1 7439, tid2 7439, idx1 2, idx2 0, seg1 CIRCULARSTRING (2556240.715 1145424.465, 2556239.274 1145424.847, 2556237.844 1145424.429), seg2 CIRCULARSTRING (2556237.844 1145424.429, 2556239.38 1145424.846, 2556240.893 1145424.352) (ItfSurfaceLinetable2Polygon.java:397)
Info: removeValidSelfIntersections(): valoverlap Intersection overlap 8.527947694197402E-4, coord1 (2559588.499, 1144173.854, NaN), coord2 (2559591.1405376485, 1144172.0968293739, NaN), tid1 4199, tid2 4199, idx1 0, idx2 1, seg1 CIRCULARSTRING (2559591.251 1144171.994, 2559589.951 1144173.036, 2559588.499 1144173.854), seg2 CIRCULARSTRING (2559588.499 1144173.854, 2559589.948 1144173.037, 2559591.247 1144171.998) (ItfSurfaceLinetable2Polygon.java:397)
java.lang.NullPointerException
    ch.interlis.iom_j.itf.impl.LineSet.buildBoundaries(LineSet.java:51)
    ch.interlis.iom_j.itf.impl.ItfSurfaceLinetable2Polygon.buildSurfaces(ItfSurfaceLinetable2Polygon.java:228)
    ch.interlis.iom_j.itf.ItfReader2.read(ItfReader2.java:313)
    ch.ehi.ili2db.fromxtf.TransferFromXtf.doit(TransferFromXtf.java:389)
    ch.ehi.ili2db.base.Ili2db.transferFromXtf(Ili2db.java:1786)
    ch.ehi.ili2db.base.Ili2db.runUpdate(Ili2db.java:598)
    ch.ehi.ili2db.base.Ili2db.runImport(Ili2db.java:195)
    ch.ehi.ili2db.base.Ili2db.run(Ili2db.java:175)
    ch.ehi.ili2db.AbstractMain.domain(AbstractMain.java:367)
    ch.ehi.ili2pg.PgMain.main(PgMain.java:71)

Also irgendwie wieder bei der Flächenbildung aber nicht mehr beim Löschen der Overlaps, sondern beim «Erstellen der Grenze/Kanten.» (buildBoundaries) in der Klasse LineSet. Der Trick mit --skipPolygonBuilding funktioniert hier leider nicht, da weitere Fehler auftauchen und kein Import möglich ist. Was machen? Weil der Quellcode ja öffentlich und frei verfügbar ist, kann ich mir den Code anschauen und vielleicht eine zusätzliche Meldung reinbasteln, die mir sagt, bei welchem Objekt genau das Problem auftaucht.

Besagte Klasse ist nicht im Code von ili2pg, sondern sie ist Bestandteil der Bibliothek iox-ili. ili2pg wiederum verwendet diese Bibliothek. Das geklonte Projekt ist ruckzuck in Eclipse importiert. Falls ich was ändere, kann ich die notwendige Jar-Datei mit ant jar neu erzeugen und in das libs-Verzeichnis von ili2pg kopieren.

Dank der Fehlermeldung weiss man, dass bei Zeile 51 der Hund begraben sein muss. In Zeile 51 wird die Methode getattrobj aufgerufen. Das Problem liegt also wahrscheinlich beim Objekt polyline. Dieses wiederum entsteht ein paar Zeilen weiter oben auf Zeile 48. Mit ein paar sinnvollen Debugmeldungen vor- und nachher ist man um einiges schlauer:

EhiLogger.debug("t_id: " + line_tid);
IomObject polyline=lines.get(line_tid).getattrobj(helperTableGeomAttrName, 0);
EhiLogger.debug("IomObject (polyline): " + polyline);

Ein erneuter Aufruf von ili2pg liefert neu zusätzlichen Output:

Info: buildBoundaries(): t_id: 98624113 (LineSet.java:49)
Info: buildBoundaries(): IomObject (polyline): null (LineSet.java:51)
java.lang.NullPointerException
    ch.interlis.iom_j.itf.impl.LineSet.buildBoundaries(LineSet.java:55)
    ch.interlis.iom_j.itf.impl.ItfSurfaceLinetable2Polygon.buildSurfaces(ItfSurfaceLinetable2Polygon.java:228)
    ch.interlis.iom_j.itf.ItfReader2.read(ItfReader2.java:313)
    ch.ehi.ili2db.fromxtf.TransferFromXtf.doit(TransferFromXtf.java:389)
    ch.ehi.ili2db.base.Ili2db.transferFromXtf(Ili2db.java:1786)
    ch.ehi.ili2db.base.Ili2db.runUpdate(Ili2db.java:598)
    ch.ehi.ili2db.base.Ili2db.runImport(Ili2db.java:195)
    ch.ehi.ili2db.base.Ili2db.run(Ili2db.java:175)
    ch.ehi.ili2db.AbstractMain.domain(AbstractMain.java:367)
    ch.ehi.ili2pg.PgMain.main(PgMain.java:71)

Wie vermutet, ist das polyline-Objekt null. In der Transferdatei muss man sich jetzt nur das Objekt mit der t_id 98624113 anschauen:

OBJE 98624113 98624113
ELIN

Eine Linie ohne Stützpunkte. Mit dem kann ili2pg nicht umgehen und wirft daher eine java.lang.NullPointerException. Auch nach dem Löschen dieser leeren Linie hat der Import leider nicht funktioniert. Zu viele andere Modellfehler.

Was ich mir wünsche

Bessere Datenqualität
Bessere Fehlermeldungen und besserer Umgang mit Fehlern. Das heisst nicht, dass jeder Mumpitz importiert werden soll. Aber diese NullPointerException sind unschön.
In Zukunft vor einer Datenabgabe die Daten z.B. mit ilivalidator prüfen und anschliessend bereinigen.

Interlis leicht gemacht #12

Sun, 11 Sep 2016 00:00:00 +0000

Der Open Source INTERLIS-Checker ilivalidator entwickelt sich prächtig. Mittlerweile kann man bereits die Version 0.3.0 herunterladen. Ganz neu ist, dass die Methode runValidation() einen Rückgabewert besitzt. Der Rückgabewert ist true, falls die Prüfung erfolgreich war resp. false, falls nicht. Somit wird es einfacher, wenn man ilivalidator als Programmbibliothek einsetzen will und verschiedene weitere Schritte vom Resultat der Prüfung abhängig machen will. Diese neue Funktion wird in der nächsten Version verfügbar sein.

Will nicht «bloss» eine INTERLIS-Transferdatei prüfen (z.B. mit einem simplen Webservice), sondern eine ganzes Verzeichnis mit Daten prüfen und Logdateien von nicht bestandenen Prüfungen mit einer E-Mail verschicken, schreibt man entweder ein kleines Skript oder aber man verwendet spezielle Software dazu. Kettle ist so eine typische ETL-Software. Daten rumkopieren, Verzeichnisse auslesen und E-Mails verschicken gehören zum Standard eines solchen Werkzeuges. Es fehlt bloss die INTERLIS-Prüfung. Weil sich Kettle einfach erweitern lässt und dazu noch mit Java geschrieben ist, passt das alles sehr gut zusammen.

Eine Erweiterungsmöglichkeit von Kettle ist die «User Definied Java Class» (UDJC). Damit lässt sich ein Transformation-Step mit Java-Code relativ einfach und effizient selber schreiben:

import org.interlis2.validator.Validator;
import ch.ehi.basics.settings.Settings;

private FieldHelper inputField = null;
private Settings settings = null;

public boolean processRow(StepMetaInterface smi, StepDataInterface sdi) throws KettleException
{
	Object[] r = getRow();

	if (r == null) {
		setOutputDone();
		return false;
	}

	if (first) {
		first = false;
		// get the input and output fields
		inputField = get(Fields.In, "filename");

		// Default settings for ilivalidator.
		settings = new Settings();
		settings.setValue(Validator.SETTING_ILIDIRS, Validator.SETTING_DEFAULT_ILIDIRS);
	}

	String value = inputField.getString(r);
	logBasic("INTERLIS transfer file: " + value);

	boolean ret = Validator.runValidation(value, settings);
	logBasic("Validation successful? " + ret);

	return true;
}

Einzig die Java-Bibliotheken von ilivalidator muss man in das lib/-Verzeichnis von Kettle kopieren. Als Proof-Of-Concept ist das ideal und funktioniert einwandfrei. Wenn man aber mehr Steuerungsmöglichkeiten will oder aber den Transformation-Step einfacher verfügbar machen will, dient sich die zweite Erweiterungsmöglichkeit an: ein Plugin.

Für den Bezugsrahmenwechsel habe ich für GeoKettle vor längerer Zeit ein Plugin geschrieben. Der Nachteil von Plugins ist, dass man sich da ein wenig reinkämpfen muss und unter anderem in die SWT-Hölle abtauchen muss. Mit viel Copy/Paste vom Bezugsrahmenwechsel-Plugin habe ich einen ersten Wurf eines ilivalidator-Plugins geschrieben. Dieses lässt sich jetzt sehr bequem wie alle anderen Transformation-Steps in Kettle nutzen. Als Input erwartet das Plugin den Namen einer INTERLIS-Transferdatei. Und es kann mittels Checkbox gewählt werden, ob ein Logfile erzeugt werden soll:

Das Plugin fügt dem Datenstrom ein Attribut valid hinzu. Je nach Resultat der Prüfung ist der Wert dieses Attributes true oder false (also der Rückgabewert der Methode runValidation()). Zusätzlich wird auch das Attribut logfile hinzugefügt. Der Wert ist der Name der erzeugten Logdatei. Schöner wäre es natürlich, wenn man die Namen dieser neuen Attribute selber wählen könnte. Zudem fehlen noch weitere Optionen von ilivalidator, wie z.B. der XTF-Logfile-Output oder ein sauberer Umgang mit den INTERLIS-Modelablagen. Momentan wird einfach die INTERLIS-Compiler-Standard-Variante verwendet.

Als Beispiel-Workflow will ich ein ganzes Verzeichnis mit INTERLIS-Dateien prüfen und die Logdateien, der nicht erfolgreichen Prüfugen per E-Mail verschicken. Sämtliche Prüfungen sollen in eine Excel-Datei geloggt:

Diesen Workflow kann man sich jetzt einfach in Kettle zusammenklicken. Tricky war noch das Verschicken der E-Mails. Zuerst müssen E-Mail-Credentials dem Datenstrom hinzugefügt werden. Das geht mit dem Add constants-Step. Im Mail-Step muss man dann für seinen E-Mail-Provider die richtigen Parameter finden. Für GMail ist das der Port 465 für SSL. Als Authentification user muss nicht die ganze E-Mail-Adresse angegeben werden, sondern nur das vor dem at-Zeichen. Um die Logfiles als Attachement zu verschicken, muss man Dynamic filenames anwählen und das Feld mit dem Logfile-Namen auswählen. Eventuell muss man in den GMail-Einstellungen die Option «Access for less secure apps» einschalten.

Abgesehen von der normalen Frickelei mit Kettle (die Doku ist aber sehr informativ), lässt sich mit wenig Aufwand eine ganze Prozesskette zum Prüfen von INTERLIS-Dateien auf die Beine stellen. Vorausgesetzt natürlich das ilivalidator-Plugin hält, was es verspricht.

Ein erster Wurf des Plugins kann man hier herunterladen. Den Quellcode gibt es hier. Die Zip-Datei enthält sowohl das Plugin selbst wie auch die benötigten ilivalidator-Bibliotheken. Die Zip-Datei kopiert man entpackt im plugins/-Ordner von Kettle und schon sollte der ilivalidator-Step in der Kategorie Validation von Kettle sichtbar sein. Die antlr-Bibliothek von ilivalidator ist nicht in der Zip-Datei enthalten. Mit dieser gibt es ein Problem, da in Kettle selbst bereits eine andere Version vorhanden ist.

Leider habe erst nach der Copy/Paste-Orgie festgestellt, dass die Plugin-Dokumention (seit kurzem?) von Kettle gar nicht so übel ist. Es gibt sogar eine Richtlinie, wie man die Icons designen soll. Das Template-Plugin findet sich im Github-Repository. Ich muss da definitiv nochmals über die Bücher, da mein Copy/Paste-Plugin auf einer sehr alten Kettle-Version basiert.

Interlis leicht gemacht #11

Mon, 18 Jul 2016 00:00:00 +0000

Getreu dem Motto «Release early, release often» gibt es jetzt bereits die zweite Version von ilivalidator - dem OpenSource INTERLIS-Checker - zum Ausprobieren.

Um nicht immer die amtliche Vermessung als Testbeispiel zu verwenden, bastle ich mir zuerst ein paar Daten zusammen. Dazu baue ich vorhandene Daten des Kantons Solothurn in das Modell «Planerischer Gewässerschutz» des BAFU um.

Als erstes mache ich mit ili2pg einen Schemaimport und lege leere Tabellen an, die ich später mit QGIS-Forms-and-Relations-Magie abfüllen werde. Ein Datenumbau mit SQL reicht leider nicht, da ich - zum Testen von ilivalidator - zusätzliche Daten erfassen will, die in den vorhandenen Daten des Kantons noch nicht vorhanden sind.

java -jar ili2pg.jar --dbhost localhost --dbdatabase rosebud2 --dbport 5432 --dbusr stefan --dbpwd ziegler12 --defaultSrsAuth EPSG --defaultSrsCode 21781 --modeldir http://models.geo.admin.ch --models PlanerischerGewaesserschutz_V1 --smart1Inheritance --expandMultilingual --createGeomIdx --createEnumTabs --nameByTopic --strokeArcs --createFkIdx --schemaimport --dbschema plan_gewaesserschutz

Abfüllen werde ich nicht das ganze Modell, sondern nur das Topic «GWSZonen». Und auch nur die Zonen der «Stöckli- und Wasserbergquelle» in der Gemeinde Bärschwil. Betroffen sind die Klassen «GWSZone», «Status» und «Dokument». Zusätzlich müssen einige Assoziationen erfasst werden. Mit QGIS geht das sehr elegant. Neu werden MANDATORY resp. NOT NULL Attribute farblich hervorgehoben:

Für meinen Geschmack schon sehr viel Farbe. Aber wenigstens fällt es auf…

Die vier erfassten Zonen der Quelle sehen so aus:

Mit ili2pg können die erfassten Daten in eine INTERLIS/XTF-Datei exportiert werden:

java -jar ili2pg.jar --dbhost localhost --dbdatabase rosebud2 --dbport 5432 --dbusr stefan --dbpwd ziegler12  --modeldir http://models.geo.admin.ch --models PlanerischerGewaesserschutz_V1 --disableValidation --export --dbschema plan_gewaesserschutz gewaesserschutz.xtf

Mit xmllint kann die XML-Datei noch für das/mein Auge schöner formatiert werden:

xmllint --format gewaesserschutz.xtf -o gewaesserschutz.xtf

Die daraus resultierende INTERLIS/XTF-Datei kann mit ilivalidator mit einem einfachen Befehl in der Konsole gegenüber dem konzeptionellen INTERLIS-Modell geprüft werden:

java -jar ilivalidator.jar gewaesserschutz.xtf

Wurden keine Fehler gefunden, erscheinen folgende Zeilen in der Konsole:

In die INTERLIS/XTF-Datei baue ich nun bewusst vier Fehler ein. Und zwar vier Fehler, die ilivalidator bereits jetzt schon finden sollte:

Fehlendes MANDATORY-Attribut «Titel» in der Klasse «Dokument».
Zu langes Text-Attribut «OffizielleNr» in der Klasse «Dokument». Erlaubt sind nur 20 Zeichen.
Falscher numerischer Wert für das Attribut «Gemeinde» in der Klasse «Dokument». Erlaubt ist eine Zahl zwischen 0 und 9999.
Falscher Aufzähltyp für das Attribut «Art» in der Klasse «GWSZone».

Ein erneuter Aufruf von ilivalidator liefert in der Konsole folgendes Resultat:

Es sollten mindestens zwei Dinge auffallen:

Es gibt neu in der Konsole vier Zeilen, die mit Error beginnen.
Die letzte Zeile endet mit Info: …validation failed Anstelle von Info: …validation done

Die vier Error-Zeilen geben auch Auskunft über die Art des Fehler und bei welchem Objekt (tid) der Fehler auftritt. Ebenfalls liefert ilivalidator die Zeilenummer. Bei XML ist diese aber oftmals nicht wahnsinnig hilfreich. Die Fehlermeldungen sind soweit sehr verständlich.

Die Meldungen auf der Konsole können auch in eine Logdatei geschrieben werden:

java -jar ilivalidator.jar --log result.log gewaesserschutz.xtf

Es besteht zudem die Möglichkeit die Meldungen in ein bewusst sehr einfach gehaltenes INTERLIS-Modell zu schreiben. Das Modell ist auf «Shapefile-Niveau», dh. der Benutzer muss nicht mühsam Daten umbauen, um sie visualisieren zu können.

java -jar ilivalidator.jar --xtflog result.xtf gewaesserschutz.xtf

Mit ili2gpkg könnte jetzt die resultierende Log-XTF-Datei in eine GeoPackage-Datei umgewandelt werden, um die Fehler und Warnungen in QGIS anzeigen zu lassen.

Manchmal möchte man aber Fehler in der Transfer-Datei tolerieren oder sogar ignorieren. Dazu gibt es bereits jetzt schon die Möglichkeit dies über eine TOML-Datei zu steuern. In meiner TOML-Konfiguration schalte ich die type-Prüfung des Attributes «Art» in der Klasse «GWSZone» aus. Dh. es wird nicht mehr geprüft, ob der Wert des Attributes im Aufzähltyp vorkommt. Zudem stufe ich die MANDATORY-Prüfung des Attributes «Titel» in der Klasse «Dokument» zu einer Warnung herunter. Der Aufruf mit einer TOML-Konfiguration ist wie folgt:

java -jar ilivalidator.jar --config gewaesserschutz.toml gewaesserschutz.xtf

Neu werden nur noch drei Fehler gefunden, wobei ein Fehler nur als Warnung attribuiert ist:

Die Steuerung kann auch direkt im Datenmodell mit Metaattributen vorgenommen werden.

In der Anleitung zu ilivalidator gibt es noch mehr Tipps & Tricks und ein kleines Beispiel-Datenmodell mit Datensatz.

So geht INTERLIS-Datenprüfung im 21. Jahrhundert.

MapCache: Disk vs. SQLite

Fri, 1 Jul 2016 00:00:00 +0000

Historisch betrachtet sind wir ein «Ein-Request-ein-Bild-WebGIS-Kanton». Was heisst das? Bei all unseren eingesetzten WebGIS-Klienten wurde nach einer Benutzer-Interaktion (also Zoomen, Pannen etc.) ein einziges Bild vom Server zurückgeliefert. Auch wenn das Bild aus mehreren Kartenlayern zusammengesetzt ist. Wie so alles im Leben hat das Vor- und Nachteile. State-of-the-art ist es gefühlt heute nicht mehr. Will man z.B. die Transparenz eines Kartenlayers ändern, löst das einen neuen Request aus und der Server muss ein neues Bild rendern. Er übernimmt eine Aufgabe, die heute locker ein Browser schafft.

Beim Einsatz von QGIS-Webclient kamen dann auch noch Performance-Probleme hinzu. Aus diesem Grund haben wir begonnen die Hintergrundkarten (wie Orthofoto, Basisplan, etc.) zu kacheln und diese Kacheln vorzuhalten (aka WMTS). Als WMTS-Server verwenden wir MapCache. MapCache unterstützt verschiedene Cache Types. Ohne gross zu studieren, haben wir dann das vermeintlich Einfachste gewählt: Disk caches. Dabei werden einfach alle Kacheln direkt auf dem Filesystem gespeichert. Die Projektdokumentation macht da eine relativ klare Ansage:

«The disk based cache is the simplest cache to configure, and the one with the the fastest access to existing tiles. It is ideal for small tile repositories, but will often cause trouble for sites hosting millions of tiles, as the number of files or directories may rapidly overcome the capabilities of the underlying filesystem.»

Und so ist es dann natürlich auch gekommen. Welches ist das sinnvollste Filesystem? Ok, Rücksprache mit der Informatik-Abteilung und speziell ein Laufwerk erstellen, formatieren und mounten…

Als weiterer Cache type gibt es auch SQLite caches. Bei dieser Variante werden sämtliche Kacheln in einer SQLite-Datenbank gespeichert. Was jetzt natürlich auf einen Schlag die ganze Filesystem-Diskussion beendet plus das Deployment vereinfacht: Einfach irgendwo seeden und die SQLite-Datei an den passenden Ort kopieren. Die Kachel wird als Blob in der Datenbank-Tabelle gespeichert. Nachteilig sind gemäss Dokumentation:

«The SQLite based caches are a bit slower than the disk based caches, and may have write-locking issues at seed time if a high number of threads all try to insert new tiles concurrently.»

Nicht ganz klar sind mir die «write-locking issues at seed time». Heisst das, dass - falls sie auftreten - Kacheln «verloren» gehen oder die Seeding-Performance zusammenbricht? Um das zu klären, müsste man auf der Mailingliste nachfragen.

In erster Linie geht es mir um die Frage wie gross der Performance-Unterschied der beiden Cache types ist. Sind Disk caches so massiv schneller, dass SQLite caches ein No-go sind? Um diese Frage zu beantworten, habe ich auf meinen Testsystem eine WMS-Karte je einmal mit Disk caches und SQLite caches geseedet und anschliessend mit jmeter die Performance gemessen. Dabei habe ich wiederum WMS-Requests gemacht, die MapCache aber aus den vorher geseedeten Kacheln zusammensetzt. Das ist zwar ein Zusatzaufwand, der eigentlich nichts mit den Cache types zu tun hat, aber ich denke, das ist für unsere Anforderungen vernachlässigbar (und an absoluten Zahlen sind wir weniger interessiert).

Das Seeding selbst scheint bei beiden Typen gleich schnell zu sein.

Für die WMS-Requests gibt es wieder altbackene Charts:

Interessanterweise sind bei mir die SQLite caches sogar klein wenig schneller. Faszinierend ist der Vergleich zu den nicht-aus-geseedeten-Kacheln-zusammengesetzten Live-WMS-Requests. Als Vergleich habe ich neben dem wirklich direkten Zugriff auf den WMS-Server auch noch MapCache als Proxy (<full_wms>forward</full_wms>) dazwischengeschaltet:

QGIS Server vs. MapServer - Revisited

Tue, 21 Jun 2016 00:00:00 +0000

Auf vielfachen Wunsch hier noch die Resultate mit MapServer als FCGI. AVWMS und Orthofoto («nearest neighbour») sind dann schon eine andere Hausnummer. Jedoch zeigt sich dann bei den maximalen Antwortzeiten ein ähnliches Verhalten wie bei QGIS Server. Der FCGI-Experte würde wahrscheinlich (?) sagen: «Logisch!».

AVWMS:

Orthofoto («nearest neighbour»):

Orthofoto («average»):

QGIS Server vs. MapServer

Mon, 20 Jun 2016 00:00:00 +0000

Bei uns steht ein grösser Umbau der GIS-Infrastruktur im Web an. Da darf natürlich auch die Diskussion über den zukünftigen Kartenserver nicht fehlen. Zurzeit - «historisch gewachsen» - setzen wir drei (3) WMS-Server ein: MapServer, GeoServer und QGIS Server. Nach dem Umbau soll es nur einer sein. GeoServer scheidet als erstes aus. Wir haben damit einfach am wenigsten Erfahrung. Bleiben noch MapServer und QGIS Server. MapServer setzen wir seit Tag 1 ein, haben also reichlich Erfahrung. Bei QGIS Server schätzen wir z.B. die umfangreichen Funktionen in verschiedenen Bereichen, die allesamt direkt auch im Web verwendbar und vor allem sichtbar werden.

Als eine kleine Hilfe bei der Entscheidungsfindung habe ich kurzerhand ein WMS-Shootout gemacht.

Disclaimer: Bis vor vier Tagen habe ich noch nie irgendetwas mit MapServer gemacht. QGIS verwende ich seit circa Version 0.7.

Das Benchmarking-Setup sah wie folgt aus:

Server bei server4you.de (i5-4xxx irgendwas) mit SSD.
Daten und WMS-Server auf dem gleichen Server.
Benchmarking-Tool: jmeter.
Drei Benchmarks:
- AVWMS (bestehend aus Bodenbedeckung, Liegenschaften und Liegenschaftsnummern).
- Orthofoto (Kantone BL, BS und nördlicher Teil von Kanton SO). Resampling «nearest neighbour».
- Orthofoto (dito). Resampling «average».
Pro Benchmarks jeweils 1, 2, 4, 8, 16, 32 und 64 parallele Requests.
Bei allen Tests jeweils drei Durchgänge.
MapServer (7.0.1) bewusst nur als CGI.
QGIS Server (master) als FCGI (FcgidMaxProcesses 10, FcgidMaxProcessesPerClass 10).
Alle Einstellungen möglichst out-of-the-box.

Die Resultate habe ich jeweils in zwei Charts gepackt: Einmal den Throughput (Requests pro Sekunde) und einmal die maximale Antwortzeit.

AVWMS:

QGIS Server ist in diesem Vergleich schneller. Auffallend ist aber das Hochschnellen der maximalen Antwortzeit wenn mehr als zehn gleichzeitige Requests gemacht werden. Als FCGI-Laie klingt das jetzt noch plausibel, da wir ja in den FCGI-Einstellungen eben nur maximal zehn Prozesse zulassen.

Orthofoto («nearest neighbour»):

MapServer ist hier deutlich vor QGIS Server. Und auch hier wieder die relativ hohen maximalen Antwortzeiten von QGIS Server.

Orthofoto («average»):

Überraschung, Überraschung: QGIS Server liegt hier plötzlich vor MapServer. Diesen Sachverhalt haben wir früher bereits mal - ohne Benchmarking - festgestellt. Ebenso hat MapServer hier auch Probleme mit langen Antwortzeiten.

Einen klaren Gewinner gibt es mit diesem eher simplen Benchmarking nicht. Neben der puren Geschwindigkeit ist für uns auch wichtig, wie pflegeleicht die Software ist. Und da ist (für uns jedenfalls) MapServer, der auch als purer CGI-Prozess gute Performance liefert, einfacher zu handhaben («fire and forget»). Bei QGIS Server haben wir bezüglich FCGI unsere Bedenken. Nicht, dass das per se schlecht wäre, nur haben wir da weniger (= kein) Know-How.

Weitere Faktoren sind z.B. die kartografischen Möglichkeiten. Da hinkt MapServer gefühlt Lichtjahre hinterher. Einfache Sachen sind anscheinend nicht möglich. Dass QGIS nativ auch die Ankerpunkte gemäss INTERLIS («hali» und «vali») unterstützt und MapServer nicht, ist nur noch ein kleines Detail. Handkehrum kann man mit MapServer garantiert 99% sämtlicher Kartendarstellungen mehr als befriedigend lösen.

Entscheide sind noch keine gefallen. Sollten aber bald.

Interlis leicht gemacht #10

Mon, 13 Jun 2016 00:00:00 +0000

Ili2pg unterstützt neu drei Vererbungsstrategien. Vererbungsstrategien sind keine Erfindung von INTERLIS oder dergleichen, sondern so alt wie das O/R-Mapping selbst. Im Internet gibt es tonnenweise Material zum Nachlesen. Wie so oft, kann Wikipedia die erste Anlaufstelle sein.

Seit der Version 2.5.0 unterstützt ili2pg zwei Vererbungsstrategien. Vorher kannte ili2pg «nur» die sogenannte NewClass-Strategie. Dabei wird für jede Klasse (abstrakt und konkret) eine Tabelle in der Datenbank angelegt. Die zweite Vererbungsstrategie ist die sogenannte «smarte» Vererbung. Sie ist eine Mischung aus verschiedenen Strategien. Ganz neu in der Version 3.1.0 ist eine weitere smarte Vererbungsstrategie hinzugekommen.

In der Dokumentation von ili2db sind die Strategien erläutert. Anhand eines Beispieles zeige ich wie das konkret in der Datenbank aussieht. Als Beispiel-Modell verwende ich das gleiche Modell (uml, ili), das bereits im ili2pg-Workshop verwendet wurde:

Bei der Klasse Building handelt es sich um eine abstrakte Klasse. Die beiden Klassen Apartments_building und Administrative_building sind daraus spezialisierte Klassen.

Zuerst wird das INTERLIS-Modell mit der NewClass-Strategie in der Datenbank abgebildet:

java -jar ili2pg.jar --dbhost 10.0.1.10 --dbdatabase rosebud2 --dbusr stefan --dbpwd ziegler12 --noSmartMapping --dbschema buildings_v1_nosmart --schemaimport --modeldir . --models Buildings_V1

Die Option --noSmartMapping ist notwendig, weil ili2pg standardmässig eine smarte Vererbungsstrategie wählt. In der Datenbank wird nun für jede Klasse (sei sie abstrakt oder nicht) eine Tabelle angelegt:

In der Tabelle apartments_building ist neben dem Primärschlüssel einzig das zusätzliche Attribut apartments vorhanden:

Die Verknüpfung zwischen der Tabelle building und apartments_building wird anhand des gleichen Primärschlüsselwertes gemacht. Mit der NewClass-Strategie verteilt sich ein INTERLIS-Objekt auf verschiedene Datenbank-Tabellen.

Wenn man jetzt die smarte Vererbung mit folgendem Befehl anwendet:

java -jar ili2pg.jar --dbhost 10.0.1.10 --dbdatabase rosebud2 --dbusr stefan --dbpwd ziegler12 --smart1Inheritance --dbschema buildings_v1_smart1 --schemaimport --modeldir . --models Buildings_V1

werden die Klassen wie folgt abgebildet:

Die abstrakte Klasse building wird nicht mehr in der Datenbank als Tabelle abgebildet. Sämtliche Eigenschaften der abstrakten Klassen sind jetzt als Attribute der spezialisierten Klassen resp. der Tabellen vorhanden.

Das Beispiel-Modell wird nun um eine weitere Klasse erweitert (uml, ili). Jedes Haus braucht einen oder mehrere Hausmeister:

Die abstrakte Klasse building wird in diesem Fall von einer anderen Klasse referenziert. Wird das Modell mit der gleichen Option --smart1Inheritance abgebildet, ergibt sich folgendes Bild:

Die «Gebäude»-Klassen werden jetzt mit einer SuperClass-Strategie abgebildet: sämtliche Informationen sind in einer einzigen building-Tabelle vorhanden resp. müssen dort erfasst werden.

Mit der neusten Variante der Vererbung --smart2Inheritance kann man aber wieder eine SubClass-Strategie fahren:

Warum das jetzt alles? Warum diese verschiedenen Varianten? Der Benutzer soll eben wählen können, welche Strategie er für die Abbildung seines INTERLIS-Modells in der relationalen Datenbank wählt. Geht es um Datenerfassung in einer GIS-Anwendung, wählt er unter Umständen eine andere Variante als jemand, der bestehende Daten in ein anderes INTERLIS-Modell umbauen muss. Ein Anderer wiederum muss möglichst schnell Daten exportieren können. Für diesen Einsatzzweck sollte man wahrscheinlich die Variante mit möglichst wenig teuren Datenbankoperationen wählen.

Wichtig ist vorallem, dass der Anwender weiss, wie die Strategien funktionieren und wie ili2pg die INTERLIS-Modelle in der Datenbank abgebildet.

Interlis leicht gemacht #9

Mon, 30 May 2016 00:00:00 +0000

Wie oft haben wir uns bereits einen Open-Source-INTERLIS-Checker gewünscht? Jahre darüber diskutiert wie es doch schön wäre einen mehr oder weniger plattformunabhängigen Checker zu haben, der auch noch frei verfügbar ist. Reichen würde uns zuerst auch ein «no-frills» Checker. Also keine Mega-Super-Zusatzfunktionen, sondern in erster Priorität die Prüfung einer INTERLIS-Transferdatei (.xtf / .itf) gegenüber dem INTERLIS-Modell (.ili).

Solche Prüfungen werden bei uns vermehrt eingesetzt und sind für die Qualitätsprüfung schlicht unverzichtbar. Eingesetzt werden solche Prüfungen z.B. bei:

den wöchenlichen Datenlieferungen der amtlichen Vermessung der Nachführungsgeometer an den Kanton.
den AVGBS-Lieferungen der Nachführungsgeometer an das Grundbuch.
der Erfassung der Nutzungsplanung durch die Planungs- und Ingenieurbüros.

Neben der Plattformunabhängigkeit und freien Verfügbarkeit wünschten wir auch Folgendes:

Einbindung als Programmbibliothek soll möglich sein.
Export der gefundenen Fehler in eine INTERLIS-Error-Datei und Log-Datei.
Einfaches GUI
lokalisierbar (im Sinne einer Mehrsprachigkeit)
Erweiterbar um zusätzliche, eigene Tests / Bedingungen

Mit den Grundanforderungen (Programmbibliothek, plattformunabhängig, Open Source) ist auch die Trennung zwischen (Weiter-)Entwicklung der eigentlichen Prüfsoftware und eines Check-Services einfach möglich. Mit der rosaroten Brille sehe ich z.B. bereits eine moderne M2M-Schnittstelle und eine saubere Benutzerverwaltung.

Die pure Prüfung einer Transferdatei auf der Kommandozeile wäre circa so:

java -jar ilichecker.jar --errXtf error.xtf --models SO_Nutzungsplanung_2016-02-03 2601_nplso.xtf

Wie wenig es braucht, um einen kleinen Web-Service auf die Beine zu stellen, habe ich bereits hier gezeigt. Ändern würde sich für den Checker nicht viel: einzig ein paar Zeilen Code und eine andere Klasse verwenden.

Soviel zum Wunschkonzert. Manchmal geht es dann aber schneller als gedacht und was lange währt wird hoffentlich auch gut. Mit ili2pg und ili2gpkg haben der Kanton Glarus und der Kanton Solothurn in den letzten Jahren INTERLIS-Werkzeuge weiterentwickeln lassen, die sich hervorragend für den Formatumbau von/nach INTERLIS eignen (Stichwort «generisches Schnittstellenwerkzeug»). Diesen Schwung wollten wir mitnehmen und im Bereich der Datenprüfung etwas auf die Beine stellen. Dazu haben wir ein Konzept mit Spezifikation einer möglichen Prüfsoftware geschrieben.

Die Spezifikation kann am Besten mit einem Beispiel-Modell illustriert werden (resp. das Beispiel-Modell ist die Spezifikation):

INTERLIS 2.3;

CONTRACTED MODEL Beispiel1
  AT "mailto:ceis@localhost"
  VERSION "2016-03-29" =

  DOMAIN
    LKoord = COORD 2480000.00 .. 2850000.00, 1060000.00 .. 1320000.00,
      ROTATION 2 -> 1;


  TOPIC Bodenbedeckung =

    CLASS GebaeudeArt =
      Art : MANDATORY TEXT*6; !! R2.1, R2.2
    END GebaeudeArt;

    CLASS BoFlaechen =
      Art : MANDATORY ( !! R2.1, R2.2
        Gebaeude,
        befestigt,
        humusiert,
        Gewaesser,
        bestockt,
        vegetationslos);
      Form : MANDATORY AREA WITH (STRAIGHTS, ARCS) VERTEX LKoord
        WITHOUT OVERLAPS > 0.10; !! R2.1, R2.2
    END BoFlaechen;

    FUNCTION checkGebaeudeVersicherungsSystem(str : TEXT):BOOLEAN;

    CLASS Gebaeude =
      Art : MANDATORY (
        Wohn,
        Industrie,
        andere); !! R2.1, R2.2
      AndereArt : TEXT*6; !! R2.1, R2.2
      AssNr : MANDATORY TEXT*6; !! R2.1, R2.2
      UNIQUE AssNr;                                    !! R2.3
      EXISTENCE CONSTRAINT AndereArt REQUIRED IN GebaeudeArt:Art;    !! R2.4
      MANDATORY CONSTRAINT Art!=#andere OR DEFINED(AndereArt);       !! R2.5
      MANDATORY CONSTRAINT INTERLIS.len(AssNr)>=4;     !! R2.6
      MANDATORY CONSTRAINT checkGebaeudeVersicherungsSystem(AssNr);  !! R2.7
    END Gebaeude;

    ASSOCIATION GebaeudeFlaeche =
      Gebaeude -- {0..*} Gebaeude;                     !! R2.8, R2.9
      Flaeche -- {1} BoFlaechen;
    END GebaeudeFlaeche;

    VIEW IndustrieGebaeude                             !! R2.10
    	PROJECTION OF Gebaeude;
    	WHERE Gebaeude->Art==#Industrie;
    =
      ALL OF Gebaeude;
      MANDATORY CONSTRAINT INTERLIS.len(AssNr)==6;
    END IndustrieGebaeude;

  END Bodenbedeckung;

END Beispiel1.

R1.1 / API: Es stehen JAVA-Klassen und -Methoden zur Verfügung, welche die Prüfung der einzelnen INTERLIS-Objekte ermlicht.

R1.2 / error.xtf: Das Prüfresultat wird in eine error.xtf-Datei geschrieben. Die Datei entspricht einem durch den Checker fixen, definierten INTERLIS-Modell.

R1.3 /Kommandozeile: Es steht auf der Kommandozeile ein Standalone-Programm zur Verfügung: java -jar ilichecker.jar …

R1.4 / GUI: Einfaches GUI mit allen Möglichkeiten, die die Kommandozeile bietet (aber ohne Editor für Konfigurationsdateien).

R1.5 / Warnings per Checks: Einzelne Checks (Attributekardinalität R2.1) lassen sich ausschalten und erscheinen dann als Warnings oder gar nicht im error.xtf.

R1.6 / Warnings per Constraints: Einzelne Constraints lassen sich ausschalten und erscheinen dann als Warnings oder gar nicht im error.xtf.

R1.7 / eigene Fehlermeldungen: Es lassen sich spezifische Fehlermeldungen zu einzelnen Constraints definieren.

R1.8 / Zusätzliche Constraints: Zu einem bestehenden Modell lassen sich zusätzliche Constraints definieren (ausserhalb des Modells; via einfache VIEWs oder eigene Syntax; wird während der Realisierung definiert).

R1.9 / GUI und Fehlermeldungen lokalisierbar: Die Fehlermeldungen und das GUI sind lokallisierbar.

R1.10 / Daten lesen via IoxReader: Der Checker soll zum Lesen der Daten ausschliesslich das Interface IoxReader benutzen, so dass andere Formate einfach ergänzt werden können.

R1.11 /ILIGML, XTF, ITF: Der Checker soll die aktuellen INTERLIS-Formate ITF, XTF und ILIGML unterstützen.

R2.1 / Kardinalitaet von Attributen: Die Kardinalität von Attributen (MANDATORY, OPTIONAL, {0..*} bei BAG/LIST) wird geprüft.

R2.2 / Datentyp von Attributen: Der Datentyp von Attributen wird geprüft (z.B. 0.0 .. 10.0) aber ohne die Zielklasse bei Referenzattributen (Teil von R2.8)

R2.3 / UniquenessConstraint: Eindeutigkeitsbedingung gemäss INTERLIS-Referenzhandbuch werden geprüft

R2.4 / ExistenceConstraint: Existenzbedingung gemäss INTERLIS-Referenzhandbuch werden geprüft

R2.5 / MandatoryConstraint, PlausibilityConstraint und SetContraint (ohne Funktionen): inkl. DEFINED, AND, OR, NOT, (), aber ohne Funktionen gemäss Modell INTERLIS (Anhang A des Referenzhandbuches)

R2.6 / Constraint mit Funktionen gemäss Anhang des INTERLIS Referenzhandbuchs: Funktionen gemäss Modell INTERLIS (Anhang A des Referenzhandbuches) werden geprüft

R2.7 / Constraint mit eigenen Funktionen: Eigene INTERLIS-Funktionen können via einen einfachen Plugin-Mechanismus (die Funktion selbst muss in JAVA implementiert sein und kann via Checker-API auf die Daten zugreifen) hinzugefügt werden

R2.8 / Zielklasse in ASSOCATION und in Referenzattributen: Es wird geprüft, ob das Zielobjekt existiert, und ob die Klasse des Objekts der Zielklasse gemäss Rolle oder Referenzattribut entspricht.

R2.9 / Kardinalität in ASSOCIATION: Es wird geprüft, ob die Anzahl der in Beziehung stehenden Objekte den Rollendefinitionen entsprechen.

R2.10 / VIEWs: Als Basis für komplexe Constraints lassen sich VIEWs definieren. Diese werden durch den Checker auch ausgewertet.

Und nun zum wirklich guten Teil: Aufgrund einer glücklichen Fügung ist die Finanzierung des grössten Teils gesichert. Neben den Kantonen Glarus und Solothurn wird ein signifikanter Teil der Entwicklungskosten durch ein privates Ingenieurbüro übernommen. Einzig der ILIGML-Reader und R2.10 (VIEWs) können zum jetzigen Zeitpunkt noch nicht realisiert werden. Wer noch etwas beisteuern will, ist also gerne willkommen (auch in Zukunft). Ende Jahr sollte eine erste Version vollständig (bis auf ILIGML und VIEWs) vorhanden sein. Im September ist ein Zwischenrelease mit abgespecktem Funktionsumfang vorgesehen.

Ich denke, dass der Open-Source-INTERLIS-Checker viele Anwender finden und begeistern wird. Schon allein aufgrund des sehr interessanten Ansatzes wie eigene Tests / Prüfungen umgesetzt werden können (Plugin-Mechanismus und VIEWs) sowie der einfachen Einsetzbarkeit der Prüfsoftware (JAVA-Klasse).

Interlis leicht gemacht #8

Sun, 29 May 2016 00:00:00 +0000

Für PostGIS-Anwender, die den Bezugsrahmenwechsel noch durchführen müssen, steht ja eine geniale Datenbankfunktion zur Verfügung, um die Daten wirklich innerhalb der Datenbank transfomieren zu können und nicht ein Drittwerkzeug bemühen zu müssen.

Als Transformationsgrundlage zwischen den beiden Bezugsrahmen dient die nationale Dreiecksvermaschung CHENyx06. Swisstopo stellt dafür eine DLL zur Verfügung. Die PostGIS-Funktion kann aber nichts mit dieser DLL anfangen, sondern erfordert die Dreiecksdefinitionen in beiden Bezugsrahmen als Polygon in einer einzigen Datenbanktabelle (was nebenbei bemerkt die Funktion enorm flexibel macht). Leider ist die Definition dieser Dreiecksvermaschung nirgends auffindbar. Ich habe einzig eine Spatialite-Datenbank, die ich aus Shape-Dateien zusammengeschustert habe, die ich vor Jahren bei swisstopo bestellt habe. Wäre die Definition nicht sogar ein Geobasisdatensatz?

Egal. Um aber die Dreiecksdefinition vom Spatialite-Joch zu befreien und den Import in die PostGIS-Datenbank vermeintlich einfacher zu gestalten, habe ich mir kurzerhand ein klitzekleines INTERLIS-Datenmodell zusammengebaut:

Der Datenumbau von der bereits bestehenden Datenbanktabelle (resultierend aus einem ogr2ogr-Import der Spatialite-Datenbank nach PostGIS) in die leere mit ili2pg angelegten Datenbanktabelle ist simpel:

INSERT INTO av_chenyx06.chenyx06_chenyx06 (nummer, nom, jahr_definiert, jahr_eliminiert, geom_lv03, geom_lv95)
SELECT num, nom, to_date(jahr_def::varchar, 'YYYY'), NULL::date AS jahr_elim,
       ST_SnapToGrid(the_geom_lv03, 0.001),
       ST_SnapToGrid(the_geom_lv95, 0.001)
FROM av_chenyx06.chenyx06_triangles;

Die UML-Datei gibt es hier, das INTERLIS-Modell hier und die exportierte INTERLIS-Transferdatei hier. Es wurde bewusst nur eine Tabelle mit zwei Geometriespalten modelliert, da ja genau diese Konstellation von der ST_Fineltra-Funktion erwartet wird.

Ohne gross zu überlegen, kann man jetzt mit ili2pg die INTERLIS-Datei in die PostgreSQL-Datenbank importieren:

java -jar ili2pg.jar --dbhost localhost --dbport 5432 --dbdatabase rosebud2 --dbusr stefan --dbpwd ziegler12 --defaultSrsAuth EPSG --defaultSrsCode  21781 --createGeomIdx --strokeArcs --createUnique --nameByTopic --dbschema av_chenyx06 --modeldir "http://models.geo.admin.ch;." --models SO_CHENyx06_20160527 --import SO_CHENyx06.xtf

Da sollten jetzt zwei Optionen ins Auge stechen: --defaultSrsAuth resp. --defaultSrsCode. Damit geben wir der Datenbank an, um welches Bezugssystem es sich handelt. In unserem Fall haben wir nun das Problem, das wir zwei unterschiedliche Bezugssysteme in einer einzigen Tabelle im INTERLIS-Modell haben. Dh. ili2pg importiert beiden Geometrien als LV03:

Auch die einzelnen Geometrien selbst sind als LV03 codiert. Folgende Abfrage

SELECT ST_AsEWK(geom_lv95) FROM av_chenyx06.chenyx06_chenyx06 LIMIT 1;

ergibt:

"SRID=21781;POLYGON((2619108.994 1266953.473,2624004.381 1265802.492,2619830.525 1263811.084,2619108.994 1266953.473))"

PostgreSQL/PostGIS wäre nicht PostgreSQL/PostGIS wenn die Rettung nicht bloss ein Einzeiler wäre:

ALTER TABLE av_chenyx06.chenyx06_chenyx06
  ALTER COLUMN geom_lv95 TYPE geometry(Polygon, 2056)
    USING ST_SetSRID(geom_lv95, 2056);

Dieser Einzeiler setzt einerseits die korrekte SRID für die Tabelle als auch für jedes einzelne Feature ohne irgendetwas zu transformieren. Das Resultat der vorherigen Query ist:

"SRID=2056;POLYGON((2619108.994 1266953.473,2624004.381 1265802.492,2619830.525 1263811.084,2619108.994 1266953.473))"

Und die Definition der Tabelle sieht jetzt wie gewünscht aus:

Das Problem mit den unterschiedlichen Bezugssystemen tauchte natürlich bereits beim Herstellen der INTERLIS-Transferdatei auf. Dabei wurde die leere Tabelle mit --schemaimport angelegt. Das Vorgehen war anschliessend identisch.

Interlis leicht gemacht #7

Thu, 11 Feb 2016 00:00:00 +0000

Seit kurzem gibt es neu auch ili2gpkg. Damit kann aus einer INTERLIS-Transferdatei schnell und ohne eine PostgreSQL-Datenbank am Laufen zu haben eine GeoPackage-Datei erstellt werden. Diese kann dann in QGIS oder ArcGIS visualisert und bearbeitet werden. Der Befehl zum Erstellen des GeoPackages ist praktisch identisch dem Befehl zum Importieren in eine PostGIS-Datenbank:

java -jar ili2gpkg.jar --import --nameByTopic --modeldir http://models.geo.admin.ch --models DM01AVCH24D --dbfile av_solothurn.gpkg ch_260100.itf

Im Prinzip stehen die gleichen Optionen wie bei ili2pg zur Verfügung. Einige gibt es natürlich nicht, z.B. die DB-Connection-Parameter. Die werden einfach durch den Filenamen-Parameter ersetzt: --dbfile. Natürlich ist man dabei nicht nur auf das Erstellen (= Lesen von INTERLIS) von GeoPackage-Dateien beschränkt. Man kann ebenso aus GeoPackage-Dateien INTERLIS-Transfer-Dateien erstellen. Dazu in einem späteren Beitrag mehr.

Eine Anwendungsmöglichkeit unter vielen ist z.B. ein kleiner Webdienst, wo man eine INTERLIS-Transferdatei hochladen kann und als Antwort die GeoPackage-Datei bekommt. Klassischerweise würde man hier ein Java-Servlet schreiben. Fürs Prototyping erstelle ich aber ein Groovlet. Man kann sich das auf dem Web/Servlet-Container so einrichten, dass alle in einem Ordner liegende *.groovy-Dateien als Servlet resp. eben als Groovlet ausgeführt werden. Zum Rumspielen noch ganz praktisch.

Als erstes brauchen wir das Upload-Formular. Dazu reichen ein paar Zeichen Groovy, das uns das benötigte HTML erstellt:

html.html {
    head {
        meta(charset:'utf-8')
        meta(name:'viewport', content:'width=device-width, initial-scale=1')
        meta('http-equiv':'x-ua-compatible', content:'ie=edge')

        title 'ili2gpkg online converter'
        style '''
            label { display: block; padding: 0.2em; }
        '''
    }
    body {
        h1 'INTERLIS (ITF/XTF) to GeoPackage Converter'
        form action: 'do_ili2gpkg.groovy', method: 'post', enctype: 'multipart/form-data', {
            label 'Reference frame: ', {
                select name: 'reference_frame', {
                    option 'LV03'
                    option 'LV95'
                }
            }
            label "--strokeArcs", {
                input type: 'checkbox', checked: 'checked', name: 'strokeArcs', id: 'strokeArcs'
            }
            label "--skipPolygonBuilding", {
                input type: 'checkbox', name: 'skipPolygonBuilding', id: 'skipPolygonBuilding'
            }
            label "--nameByTopic", {
                input type: 'checkbox', checked: 'checked', name: 'nameByTopic', id: 'nameByTopic'
            }
            label 'File: ', {
                input type: 'file', name: 'file'
            }
            input type: 'submit', name: 'submit', value: 'Send to server'
        }
    }
}

Das sind ganz schön nach 90er-Jahre aus, aber es fehlt schliesslich auch jegliches Styling:

Von den unzähligen Programmoptionen lassen wir nur vier zu, die der Anwender via Webformular auswählen kann:

--defaultSrsCode: Entweder LV03 oder LV95.
--skipPolygonBuilding: Falls gewünscht, wird die Flächenbildung für Polygone nicht gemacht und es bleiben «Spaghetti»-Daten. Dies kann sehr praktisch für die Verifikation von Datenlieferungen sein. Bei der Flächenbildung bereinigt ili2gpkg zulässige Overlaps, um OGC-konforme Geometrien zu erhalten. Um jedoch wirklich die Original-Geometrien zu erhalten und diese bei Grenzfällen besser beurteilen zu können, lohnt es sich manchmal nur die Linien zu betrachten.
--strokeArcs: Kreisbogen werden segmentiert.
--nameByTopic: Die Tabellen in der GeoPackage-Datenbank werden nach dem Muster Topicname_Classname benannt.

Wie man dem Groovy-Skript resp. der HTML-Datei entnehmen kann, ist do_ili2gpkg.groovy das Groovy-Skript, das beim Senden aufgerufen wird. Dieses übernimmt die eigentliche Umwandlung INTERLIS → GeoPackage:

@Grapes([
   @GrabResolver(name='catais.org', root='http://www.catais.org/maven/repository/release/', m2Compatible='true'),
   @Grab(group='commons-fileupload', module='commons-fileupload', version='1.3.1'),
   @Grab(group='commons-io', module='commons-io', version='2.4'),
   @Grab(group='org.xerial', module='sqlite-jdbc', version='3.8.11.2'),
   @Grab('ch.interlis:ili2c:4.5.21'),
   @Grab('ch.interlis:ili2gpkg:3.0.0'),
   //@GrabConfig(systemClassLoader = true)
])

import javax.servlet.http.HttpServletResponse
import javax.servlet.ServletOutputStream
import java.util.logging.Logger
import java.nio.file.Path
import java.nio.file.Files
import org.apache.commons.io.IOUtils
import org.apache.commons.io.FilenameUtils
import org.apache.commons.io.FileUtils
import org.apache.commons.fileupload.FileItem
import org.apache.commons.fileupload.util.Streams
import org.apache.commons.fileupload.servlet.ServletFileUpload
import org.apache.commons.fileupload.disk.DiskFileItemFactory
import org.apache.commons.fileupload.FileUploadException
import ch.ehi.ili2db.base.Ili2db
import ch.ehi.ili2db.base.Ili2dbException
import ch.ehi.ili2db.gui.Config
import ch.ehi.ili2db.mapping.NameMapping
import ch.ehi.basics.logging.EhiLogger

Logger logger = Logger.getLogger("do_ili2gpkg.groovy")
logger.setUseParentHandlers(true)
logger.info ("Starts at: " + new Date())

if (ServletFileUpload.isMultipartContent(request)) {
    ServletFileUpload upload = new ServletFileUpload(new DiskFileItemFactory())
    //upload.setSizeMax(52428800) // 50MB
    upload.setSizeMax(2*5242880) // 2*5MB

    List<FileItem> items = null

    try {
        items = upload.parseRequest(request);
    } catch (FileUploadException e) {
        logger.severe e.getMessage()
        response.sendError(HttpServletResponse.SC_FORBIDDEN, e.getMessage())
        return
    }

    for (item in items) {
        if (item.isFormField()) { // 'normal' form fields
            String fieldName = item.getFieldName()
            String value = item.getString()

            params[fieldName] = value
            logger.info fieldName.toString()
            logger.info value.toString()
            logger.info item.getClass().toString()

        } else { // files
            String fieldName = item.getFieldName()
            String fileName = FilenameUtils.getName(item.getName())

            if (fileName.equalsIgnoreCase("")) {
                // return 'bad request' (400) if no file was sent
                String errorMessage = "No file chosen."
                logger.severe errorMessage
                response.sendError(HttpServletResponse.SC_BAD_REQUEST, errorMessage)
                return
            }

            // get the file as input stream
            InputStream fileContent = item.getInputStream()

            // create random temporary directory
            String tmpDirPrefix = "ili2gpkg_";
            Path tmpDir = Files.createTempDirectory(tmpDirPrefix);

            // copy input stream into target file
            String targetFileName = fileName
            File targetFile = new File(tmpDir.toString() + File.separator + targetFileName)

            try {
                FileUtils.copyInputStreamToFile(fileContent, targetFile)
                logger.info "Uploaded file: " + targetFile.toString()
                logger.info "Uploaded file size [KB]: " + (int) (targetFile.length() / 1024)
            } catch (java.io.IOException e) {
                FileUtils.deleteDirectory(tmpDir.toFile())

                logger.severe e.getMessage()
                response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR, e.getMessage())
                return
            }

            // create configuration for ili2gpkg
            def config = initConfig(params)

            // Set the name of the geopackage.
            // Same name as input file but with *.gpkg extension instead.
            String gpkgFileName = FilenameUtils.removeExtension(targetFileName) + ".gpkg"
            gpkgFullFileName = tmpDir.toString() + File.separator + gpkgFileName
            config.setDbfile(gpkgFullFileName)
            config.setDburl("jdbc:sqlite:"+config.getDbfile())
            config.setXtffile(targetFile.toString())

            String fileExtension = FilenameUtils.getExtension(targetFileName)
            System.out.println(fileExtension)
            if (fileExtension.equalsIgnoreCase("itf")) {
                config.setItfTranferfile(true)
            }

            // Now create the GeoPackage.
            try {
                //EhiLogger.getInstance().setTraceFilter(false)
                Ili2db.runImport(config, "")
            } catch (Ili2dbException e) {
                logger.severe e.getMessage()
                response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR, e.getMessage())
                return
            }

            // Send GeoPackage to browser.
            response.setContentType("application/x-sqlite3")
            response.setHeader("Content-Disposition", "attachment; filename=" + gpkgFileName);
            ServletOutputStream os = response.getOutputStream();
            FileInputStream fis = new FileInputStream(gpkgFullFileName);
            try {
                int buffSize = 1024
                byte[] buffer = new byte[buffSize]
                int len
                while ((len = fis.read(buffer)) != -1) {
                    os.write(buffer, 0, len)
                    os.flush()
                    response.flushBuffer()
                }
            } catch (Exception e) {
                logger.severe e.getMessage()
            }
            finally {
                FileUtils.deleteDirectory(tmpDir.toFile())
            }
        }
    }
}

def initConfig(params) {
    def config = new Config()
    config.setModeldir("http://models.geo.admin.ch/;http://models.geo.gl.ch/;http://www.catais.org/models")
    config.setModels(Ili2db.XTF)
    config.setSqlNull("enable");
    config.setDefaultSrsAuthority("EPSG");
    config.setDefaultSrsCode("21781");
    config.setMaxSqlNameLength(Integer.toString(NameMapping.DEFAULT_NAME_LENGTH));
    config.setIdGenerator(ch.ehi.ili2db.base.TableBasedIdGen.class.getName());
    config.setInheritanceTrafo(config.INHERITANCE_TRAFO_SMART1);
    config.setCatalogueRefTrafo(Config.CATALOGUE_REF_TRAFO_COALESCE);
    config.setMultiSurfaceTrafo(Config.MULTISURFACE_TRAFO_COALESCE);
    config.setMultilingualTrafo(Config.MULTILINGUAL_TRAFO_EXPAND);

    config.setGeometryConverter(ch.ehi.ili2gpkg.GpkgColumnConverter.class.getName());
    config.setDdlGenerator(ch.ehi.sqlgen.generator_impl.jdbc.GeneratorGeoPackage.class.getName());
    config.setJdbcDriver("org.sqlite.JDBC");
    config.setIdGenerator(ch.ehi.ili2db.base.TableBasedIdGen.class.getName());
    config.setIli2dbCustomStrategy(ch.ehi.ili2gpkg.GpkgMapping.class.getName());
    config.setOneGeomPerTable(true);

    for (param in params) {
        def key = param.key

        if (key.equalsIgnoreCase("strokeArcs")) {
            config.setStrokeArcs(config.STROKE_ARCS_ENABLE)
        }

        if (key.equalsIgnoreCase("nameByTopic")) {
            config.setNameOptimization(config.NAME_OPTIMIZATION_TOPIC)
        }

        if (key.equalsIgnoreCase("skipPolygonBuilding")) {
            config.setDoItfLineTables(true);
            config.setAreaRef(config.AREA_REF_KEEP);
        }

        if (key.equalsIgnoreCase("reference_frame")) {
            if (param.value.equalsIgnoreCase("LV95")) {
                config.setDefaultSrsCode("2056");
            }
        }
    }
    return config
}

logger.info ("Stops at: " + new Date())

Zeilen 1 - 9: Die notwendigen Bibliotheken werden mittels Grape einmalig heruntergeladen. Die *.jar-Dateien landen dann im .groovy/grapes/-Verzeichnis des Apache-Tomcat-Users und nicht etwa im lib-Verzeichnis von Apache-Tomcat selbst. Der Befehl @GrabConfig(systemClassLoader = true) scheint nicht notwendig zu sein, wenn das Skript als Groovlet in Apache Tomcat läuft.

Zeilen 11 - 28: Notwendige Imports werden gemacht. Für den File-Upload verwenden wir die Apache-Commons-Bibliotheken. Ab Servlet-Spezifikation 3.0 gibt es dafür native Unterstützung. Heruntergebrochen auf ein Groovlet habe ich das aber nicht zum Laufen gebracht. Daher wird hier wieder die old-school-Methode verwendet.

Zeile 37: Die maximale Grösse der Upload-Datei ist auf 10MB beschränkt.

Zeilen 49 - 58: «Normale» Parameter aus dem HTML-Formular werden in einer Map gespeichert. Sie werden später für die Konfiguration von ili2gpkg verwendet.

Zeilen 59 - 92: Die gelieferte Datei wird entgegengenommen und in einem temporären Verzeichnis gespeichert.

Zeilen 99 - 119: Hier findet die eigentliche Umwandlung der INTERLIS-Transferdatei in die GeoPackage-Datei statt. Die Config-Klasse wird mit den übermittelten Parameter aus dem HTML-Formular in einer separaten Methode konfiguriert. Ein INTERLIS-Modell oder ein -Repository kann nicht übermittelt werden. Das Modell wird aus der Transferdatei selber ermittelt (Zeile 148) und in den drei hardcodierten Repositories gesucht.

Zeilen 121 - 140: Zu guter Letzt wird die GeoPackage-Datei an den Browser zurückgesendet. Der Benutzer muss sie nur noch speichern.

Das Resultat sieht genauso aus wie wir es von ili2pg gewohnt sind. Nur halt in einer GeoPackage-Datei:

Anschauen kann man sich das Resultat anschliessend in QGIS:

Achtung: ili2gpkg setzt den Layer-Extent gemäss dem INTERLIS-Modell. Beim CH-Modell der amtlichen Vermessung entspricht das der Bounding-Box der gesamten Schweiz. Wenn man in QGIS «Zoom to Layer Extent» wählt, zoomt QGIS auf die gesamte Schweiz. Einerseits verwirrend, andererseits eigentlich korrekt. Aber darüber kann man sich sicher lange unterhalten.

In Apache Tomcat sind drei Anpassungen vorzunehmen. Einerseits muss konfiguriert werden, dass alle *.groovy-Dateien eines Verzeichnisses als Groovlet ausgeführt werden. Dies wird in der web.xml-Datei gemacht (im Root-Element):

<servlet>
    <servlet-name>Groovy</servlet-name>
    <servlet-class>groovy.servlet.GroovyServlet</servlet-class>
</servlet>

<servlet-mapping>
    <servlet-name>Groovy</servlet-name>
    <url-pattern>*.groovy</url-pattern>
</servlet-mapping>

Zudem wollen wir dieses Verzeichnis an einem beliebigen Ort im Filesystem haben und nicht unterhalb des Tomcat-Installationsverzeichnisses. Dazu setzen wir einen «Context Path» in der Datei server.xml unter <Host>:

<Host name="localhost"  appBase="webapps"
      unpackWARs="true" autoDeploy="true">

  <!-- SingleSignOn valve, share authentication between web applications
       Documentation at: /docs/config/valve.html -->
  <!--
  <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
  -->

  <!-- Access log processes all example.
       Documentation at: /docs/config/valve.html
       Note: The pattern used is equivalent to using pattern="common" -->
  <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
         prefix="localhost_access_log" suffix=".txt"
         pattern="%h %l %u %t &quot;%r&quot; %s %b" />

 <!-- Groovlets -->
 <Context path="/groovy/ili2gpkg" docBase="/home/stefan/Projekte/ili2gpkg_service/scripts" reloadable="true"/>

</Host>

Einzig die Zeilen 17 und 18 stammen von mir, alles Andere sind Default-Einstellungen. Der Eintrag bewirkt jetzt, dass der Request http://…/groovy/ili2gpkg/mein_skript.groovy (Attribut path) im Verzeichnis gemäss dem Attribut docBase das Groovy-Skript mein_skript.groovy sucht und, sofern vorhanden, ausführt.

Als letztes muss noch die groovy-all-x.y.z.jar in das lib-Verzeichnis von Apache Tomcat kopiert werden. Dieses Groovy-«Sorglos»-Paket liegt dem Download bei.

~~Ein Live-Beispiel gibt es hier(mspublic / mspublic).~~ Ein erweitertes Beispiel findet sich hier.

Interlis leicht gemacht #6

Sat, 28 Nov 2015 00:00:00 +0000

Die Eidgenössische Vermessungsdirektion aggregiert verschiedene Metadaten der amtlichen Vermessung. Dazu zähle ich:

Die Daten werden von den Kantonen an die V+D geliefert und anschliessend werden sie publiziert:

Der «Stand der amtlichen Vermessung» war der erste Metadatensatz, den die Kantone liefern mussten. Das dazugehörige INTERLIS-Modell ist einfach und besteht aus zwei Tabellen: Actual_Status und Actual_Status_Geometry. Die Herausforderung zu diesem Zeitpunkt war aber: Wie kriege ich meine Daten in eine INTERLIS-Transferdatei? Die Lösung war dann nicht so prickelnd: Ich schrieb einen 1:1-Prozessor, der mir die Transferdatei erstellt. Ein Geknorze sondergleichen.

Heute geht das mit ili2pg und QGIS viel leichter und eleganter:

Schema mit Tabellen in PostgreSQL/Postgis anlegen
Daten erfassen
Daten exportieren

Die Schritte (1) und (3) übernimmt ili2pg für uns. Die Daten erfassen müssen wir schon noch selber. Mit QGIS macht aber auch diese Arbeit Spass und geht leicht von der Hand. QGIS hat sehr mächtige Formularfunktionen und man kann sich damit so etwas wie eine «Fachschale» zusammenklicken.

Für den Datensatz «Stand der Periodischen Nachführung» soll nun der ganze Prozess exemplarisch durchgespielt werden. Zuerst legen wir mit ili2pg die leeren Tabellen in der Datenbank an:

java -jar ili2pg.jar --schemaimport --dbhost localhost --dbport 5432 --dbdatabase rosebud2 --dbusr stefan --dbpwd ziegler12 --defaultSrsAuth EPSG --defaultSrsCode 2056 --createGeomIdx --createEnumTabs --nameByTopic --strokeArcs --dbschema av_pnf_stand_amo --modeldir http://models.geo.admin.ch --models AMO_Grafik_LV95_PNF

Mit den Optionen --defaultSrsAuth EPSG und --defaultSrsCode 2056 wird ili2pg mitgeteilt, dass die Geometrie-Tabellen in der Datenbank im Bezugsrahmen LV95 angelegt werden sollen. --createEnumTabs erstellt für Aufzähltypen eine eigene Tabelle. Diese Aufzähltyp-Tabellen sind später wichtig für die Arbeit mit QGIS.

Das Resultat sieht relativ unspektakulär aus:

Es gibt zwei Tabellen im Modell resp. in der Datenbank: pnf_pnf und pnf_pnf_geometry. Die erste Tabelle beinhaltet alle Sachattribute, die zweite die Geometrie dazu. Zusätzlich wird in der Datenbank für jeden Aufzähltyp eine Tabelle angelegt. Der Inhalt der Tabelle amo_grafik_lv95_pnf_cantons sieht - wenig überraschend - so aus:

Das Gute an ili2pg ist, dass man nachträglich auch ein paar Veränderungen/Verfeinerungen in den Datenbanktabellen vornehmen darf, die dem Datenerfasser das Leben erleichtern:

Das Modell gibt vor, dass die Kombination der Attribute canton und id eindeutig sein muss. In der Datenbanktabelle fügen wir einen UNIQUE-Constraint hinzu:

ALTER TABLE av_pnf_stand_amo.pnf_pnf ADD CONSTRAINT pnf_pnf_ili_unique UNIQUE (canton, id);

Des Weiteren erstellen wir zwei Sequenzen, damit der Primary Key in den Tabellen automatisch nachführt wird:

-- sequence for t_id "pnf_pnf"
CREATE SEQUENCE av_pnf_stand_amo.pnf_t_id_seq;
ALTER TABLE av_pnf_stand_amo.pnf_pnf ALTER COLUMN t_id SET DEFAULT nextval('av_pnf_stand_amo.pnf_t_id_seq');
ALTER TABLE av_pnf_stand_amo.pnf_pnf ALTER COLUMN t_id SET NOT NULL;
ALTER SEQUENCE av_pnf_stand_amo.pnf_t_id_seq OWNED BY av_pnf_stand_amo.pnf_pnf.t_id;

-- sequence for t_id "pnf_pnf_geometry"
CREATE SEQUENCE av_pnf_stand_amo.pnf_geometry_t_id_seq;
ALTER TABLE av_pnf_stand_amo.pnf_pnf_geometry ALTER COLUMN t_id SET DEFAULT nextval('av_pnf_stand_amo.pnf_geometry_t_id_seq');
ALTER TABLE av_pnf_stand_amo.pnf_pnf_geometry ALTER COLUMN t_id SET NOT NULL;
ALTER SEQUENCE av_pnf_stand_amo.pnf_geometry_t_id_seq OWNED BY av_pnf_stand_amo.pnf_pnf_geometry.t_id;

Somit wäre Schritt (1) erledigt und wir können die Daten in QGIS erfassen. Für die Datenerfassung in QGIS werden die Tabellen der Aufzähltypen, die eigentlichen Datentabellen sowie ein Datensatz der Gemeindegrenzen benötigt:

Zuallererst muss die Relation zwischen dem Layer pnf_pnf und pnf_pnf_geometry hergestellt werden. Somit weiss QGIS, dass die beiden Tabellen mit einer 1:n-Relation verknüpft sind:

Anschliessend basteln wir uns mit den verschiedenen Editwidgets ein schönes Formular für die effiziente Datenerfassung:

Für die Attribute canton, practice und reference_frame ist das Editwidget vom Typ «Value Relation» zu wählen. Als Inputlayer wählen wir die jeweilige Aufzähltyp-Tabelle, z.B. bei cantons ist der Layer amo_grafik_lv95_pnf_cantons zu wählen. Für das Attribut year wählen wir den Typ «Range» und wählen den Bereich gemäss INTERLIS-Modell (2000 bis 2100).

Anstelle der automatisch generierten Eingabemake, kann man sich mit Drag 'n' Drop seine eigene Maske zusammenstöpseln. Wir verwenden diese Möglichkeit, um die 1:n-Relation in dieser Eingabemaske nicht darzustellen:

Wenn wir anschliessend ein Feature im Layer pnf_pnf erfassen, sieht das Formular wie folgt aus:

Beim Attribut cantons haben wir den Typ «Value Relation» gewählt. Standardmässig erscheint bei diesem Typ eine Combobox. Wählt man jedoch die Option «Use Completer» erscheint keine Combobox, sondern es werden mögliche Werte aus der Aufzähltyp-Tabelle live vorgeschlagen. Dank den Editwidget-Typen wie «Value Relation» oder «Range» können so unnötige Tippfehler bei der Datenerfassung vermieden werden resp. es können gar keine nicht vorhandene Werte eingetippt werden.

Eine vollständig ausgefüllte Eingabemaske:

Als nächstes müssen wir zu diesem PNF-Objekt den dazugehörigen Perimeter erfassen. Als Vorarbeit haben wir in QGIS die Relation definiert: Jedes PNF-Objekt kann gemäss INTERLIS-Modell mehrere Perimeter aufweisen. Also eine klassische 1:n-Beziehung. Interessant ist aber die Frage: wie kann ich einen Perimeter (den ich der Tabelle pnf_pnf_geometry erfassen muss) korrekt einem Objekt der Tabelle pnf_pnf zuweisen?

Dazu wählen wir für den Layer pnf_pnf_geometry beim Attribut afrom (entspricht dem Fremdschlüssel) den Widgettyp «Relation Reference»:

Die Datenerfassung läuft dann wie folgt ab: Wir kopieren eine oder mehrere Gemeindegrenzen aus dem Layer mit den Gemeindengrenzen in den Layer pnf_pnf_geometry. Anschliessend erfassen wir dazu die Daten. In diesem Fall ist das nur der Primary Key t_id (interessiert uns ja nicht, da dieser automatisch vergeben wird) und das «Beziehungsattribut» (aka Fremdschlüssel) afrom. Mit einer Combobox kann man das Objekt des Layers pnf_pnf auswählen, dem man die Geometrie zuweisen will.

Blöd nur, dass da bloss der Primary Key steht. Damit kann man meistens nichts anfangen. Viel besser wäre es, wenn man ein anderes Attribut darstellen könnte. Kann man. Ändern kann man das bei den Einstellungen im «Relation Reference»-Widget bei «Display expression». Standardmässig steht da COALESCE("t_id", '<NULL>'). Anstelle von t_id schreibt man das gewünschte Attribut hin. In unserem Fall description:

Möglich sind auch Kombinationen der Attribute resp. alles was QGIS Expressions hergibt. Die Zuweisung der Geometrie zu einem Objekt ist jetzt viel einfacher:

Die Geometrien möchte ich pro Jahr anders einfärben. Dazu müsste das Attribut year im Layer pnf_pnf_geometry vorhanden sein. Dieses Attribut ist aber im «Parent»-Layer pnf_pnf vorhanden. Früher hat man sich dann mit einer View o.ä. geholfen. Das ist nicht mehr nötig. Mit der Kombination aus Feldrechner und QGIS Expressions kann man virtuelle Felder mit Attributwerten aus anderen Layern erstellen. Die dazu benötige Expression: attribute(get_feature('pnf_pnf','t_id',afrom),'year'). Die Syntax ist unter Umständen ein klein wenig gewöhnungsbedürftig:

Die erste Funktion get_feature holt sich ein Feature aus einem anderen Layer (hier: pnf_pnf). Der zweite und dritte Funktionsparameter beschreiben die jeweiligen Attribute der beiden Layer über die gejoined werden soll. Achtung: beim layereigenen Attribut sind keine Quotes notwendig. Die zweite Funktion attribute extrahiert aus dem gefundenen «Fremd»-Feature ein Attribut. Der Parameter ist der Attributsname.

Das Ergebnis dieser Expression in Kombination mit dem Feldrechner ist ein virtuelles Feld im Layer pnf_pnf_geometry, das ich zum Einfärben oder Beschriften verwenden kann:

Sind alle PNF-Objekte und die dazugehörigen Perimeter erfasst, kann mit ili2pg die INTERLIS-Transferdatei erzeugt werden:

java -jar ili2pg.jar --export --dbhost localhost --dbport 5432 --dbdatabase rosebud2 --dbusr stefan --dbpwd ziegler12 --defaultSrsAuth EPSG --defaultSrsCode 2056 --createGeomIdx --createEnumTabs --nameByTopic --strokeArcs --dbschema av_pnf_stand_amo --modeldir http://models.geo.admin.ch --models AMO_Grafik_LV95_PNF stand_pnf_20151118.itf

Das Resultat ist eine modellkonforme INTERLIS1-Transferdatei:

Es hat sich dann leider herausgestellt, dass die Lieferung aber pro PNF-Jahr erfolgen muss, dh. in jedem ITF dürfen nur PNF-Objekte resp. -Perimeter eines Jahres vorhanden sein. Und zusätzlich verwirrend: Das Attribut reference_frame beschreibt den Bezugsrahmen der erfassten Geometrien und nicht den Bezugsrahmen in dem die Periodische Nachführung durchgeführt worden ist. Nun gut. Was ich definitiv nicht will, ist pro Jahr ein DB-Schema. Aus diesem Grund erstelle ich ein «export»-Schema, das ich mit ein paar simplen SQL-Befehlen für jeweils ein Jahr abfülle und anschliessend mit ili2pg exportiere:

DELETE FROM av_pnf_stand_amo_export.pnf_pnf_geometry;
DELETE FROM av_pnf_stand_amo_export.pnf_pnf;

INSERT INTO av_pnf_stand_amo_export.pnf_pnf (t_id, canton, id, description, practice, reference_frame, year)
SELECT t_id, canton, id, description, practice, reference_frame, year
FROM av_pnf_stand_amo.pnf_pnf
WHERE year = 2015;

INSERT INTO av_pnf_stand_amo_export.pnf_pnf_geometry (t_id, afrom, perimeter)
SELECT g.t_id as t_id, g.afrom, g.perimeter
FROM av_pnf_stand_amo.pnf_pnf as p, av_pnf_stand_amo.pnf_pnf_geometry as g
WHERE p.t_id = g.afrom
AND p.year = 2015;

Fazit: Was früher knorzig und mühsam war, geht heute mit den richtigen Werkzeugen ruckzuck und entspannt vonstatten.

State of WFS

Sun, 18 Oct 2015 00:00:00 +0000

Oder wie soll man WFS «richtig» nutzen? Eines vorweg: ich weiss es nicht. Ein Direktzugriffsverfahren auf Daten mit Filterfunktionen ist toll und sinnvoll. Aber für mich stellen sich einige Fragen in zwei Themenfeldern:

Interaktion zwischen Benutzer und Service
Umgang mit grossen Datenmengen
Und irgendwie eine Kombination von beidem.

Die ganze Thematik mit Anwendungsschemen und komplexen Feature lassen wir mal beiseite und gehen von good old OGC SF-0 aus. Das heisst eine Tabelle aus der Datenbank wird zu einem WFS-Layer, der mit einem GetFeature-Request heruntergeladen werden kann. Solche WFS-Server gibt es wie Sand am Mehr (GeoServer, QGIS Server, MapServer/TinyOWS, deegree).

Die Unterstützung in den Desktop-GIS wie z.B. QGIS ist auf den ersten Blick nicht allzu übel. Unterstützt wird die Version 1.0.0. Das Einbinden von WFS-Layer ist einfach und ähnlich dem eines Postgis-Layers:

Im Video wird gezeigt, wie die Hoheitsgrenzen des Kantons Solothurn in QGIS geladen werden. «In QGIS geladen» bedeutet, dass die Vektordaten komplett vom WFS-Server heruntergeladen werden und in QGIS in einem Memory-Layer gespeichert werden. Wird QGIS geschlossen, werden die Daten nirgends auf dem Computer gespeichert und beim Öffnen des QGIS-Projektes werden die Daten vom WFS-Server erneut heruntergeladen.

Soweit so gut. Die Hoheitsgrenzen werden zügig geladen. Es sind ja auch nur 110 Polygone. Auch das Nicht-Offline-Speichern und erneute Laden beim Öffnen des QGIS-Projektes hat was: So sind die Daten garantiert immer aktuell resp. entsprechen der Aktualität wie sie der Serviceprovider anbietet.

Schauen wir uns die Bodenbedeckung der amtlichen Vermessung an. Das sind im Kanton Solothurn knapp 280'000 Polygone:

Wird der WFS-Layer genau gleich geladen wie die Hoheitsgrenzen wartet der Benutzer 1.5 Minuten auf die Antwort. Das QGIS Fenster ist blockiert und auf dem Server läuft in diesem Zeitraum ein Prozess mit 100% CPU-Auslastung. Wird z.B. QGIS-Server verwendet, läuft neben der eigentlichen Verarbeitung des WFS-Request (als FCGI-Prozess) auch noch Apache mit 20% CPU-Auslastung. Speichert man das QGIS-Projekt und öffnet es wieder, wird dieser Request wiederholt. Der Benutzer wartet also bei jedem Öffnen des Projektes einige Minuten. Mir noch nicht klar warum das Abfragen von einzelnen Features (mit dem Identify Features Tool) so lange dauert. Eventuell wird beim Memory-Layer kein Spatial-Index erzeugt und daher wirkt die Feature-Abfrage so käsig.

Mit den Filterfunktionen kann der Problematik der langen Downloadzeit entgegen gewirkt werden. Einerseits kann nach Sachattributen (z.B. Gemeindenummer) gefiltert werden:

Man darf aber nicht vergessen, dass man ja nur nach Attributen filtern kann, die auch da sind. Fehlt im WFS-Layer das Attribute bfsnr kann nicht nach einer Gemeinde gefiltert werden.

Anderseits kann man geografisch filtern:

Auch das geht nicht immer: WFS-Layer ohne Geometrien können nicht geografisch gefiltert werden. An den Haaren herbeigezogen? Ich denke nicht. Denkbar sind Strassennamen oder ähnliches.

QGIS hat beim Hinzufügen von WFS-Layer eine interessante Option, die sich «Cache Features» nennt. Leider funktioniert sie mit der aktuellen QGIS-Version (2.10) nicht mehr. Im GUI ist die Option noch vorhanden aber die Funktion wurde im Quellcode bewusst auskommentiert. Äh..? Irgendwie ist da sowieso der Wurm drin. Die Idee hinter «Cache Features» ist eben das oben beschriebene Verhalten, dh. alle Features des WFS-Layer werden in QGIS «gecached»/heruntergeladen. Wählt man jetzt diese Option ab (in QGIS 1.8 funktioniert das noch), werden die Features nicht mehr in QGIS gecached, sondern es werden nur die Features heruntergeladen, die dem aktuellen Kartenausschnitt entsprechen. Der Funktion ist sogar ein Mindestmass an Intelligenz eingepflanzt. So werden die Features nicht erneut geladen, wenn der neue Kartenausschnitt (nach Zoomen) komplett innerhalb des vorangegangenen Kartenausschnittes ist. Auf den ersten Blick ist das genau das Verhalten, das man sich eigentlich wünscht. Die Probleme beginnen aber beim Herauszoomen und am Schluss lädt es bei jedem Verschieben der Karte sehr lange, sehr viele Features herunter:

Wie man aber auch sieht, funktioniert dieser uncached WFS-Layer bei grossen Massstäben (und dementensprechend wenig Feature, die nachgeladen werden müssen) ziemlich gut. Bei genügend schneller Internetverbindung merkt man das Nachladen praktisch gar nicht.

Nach all den Beispielen bleiben bei mir immer noch Fragen in den eingangs erwähnten Themenfeldern:

Darf das Herunterladen der Daten länger dauern oder soll der Benutzer die gleiche User Experience wie bei WMS haben? Bei kleinen Datenmengen scheint das ziemlich gut zu funktionieren. Bei grösseren überhaupt nicht mehr. Oder macht es eben nichts, wenn die Daten nicht mehr instant erscheinen, sondern es etliche Sekunden oder Minuten geht bis man wieder weiterarbeiten kann? Darf es Ziel der ganzen Übung sein die Daten einmalig herunterzuladen und dann lokal physisch zu speichern (als Shapefile o.ä.)? Ganz quer ist dieser Gedanke nicht: GML ist ja kein Produktionsformat, sondern ein Datenaustauschformat. Aber dann verliert man die Vorteile eines Direktzugriffsverfahrens.

Klar, es gibt Filter. Darf man aber erwarten, dass der Benutzer immer vorgängig die richtigen Filter kennt und auch einstellt? Zudem kann nur nach etwas gefiltert werden, was auch in den Daten vorhanden ist («Ich will Daten der Gemeinde XY, kann aber keine Gemeindenummer beim Filter auswählen.«). Einmal Filter nicht gesetzt und schon dauert ein Download sehr lange und generiert Last.

Last: Die grossen WFS-Requests erzeugen eine hohe Last auf dem Server. Ich bin zwar keine Server-Admin-Guru aber ich glaube nicht, dass man von externen und unter Umständen unbekannten Leuten den Server unbewusst (Filter vergessen?) so einfach unter Volllast gesetzt bekommen will. Für GeoServer gibt es ein Control Flow Modul, das die OWS-Requests detailliert kontrollieren kann. Bei QGIS-Server (FCGI-Process) kann/man/will man das wahrscheinlich teilweise direkt in den FCGI-Einstellungen regeln. Häufig gibt es auch die Möglichkeit auf der Serverseite die maximale Anzahl der Features zu limitieren, die auf eine Anfrage eines Klienten zurückgeschickt werden. Bis zur WFS-Version 2.0.0 wurde diese Anzahl dem Klienten nicht bekannt gegeben. Der Klient wusste also nicht, ob er alle angeforderten Features bekommen hat oder ob der Server die maximale Anzahl der auszuliefernden Features bereits erreicht hat. In WFS 2.0.0 wird diese Anzahl als CountDefault im GetCapabilities-Dokument stehen. In Kombinination mit Paging wären so zumindest sehr grosse Downloads möglich mit der Sicherheit wirklich auch alle Features zu bekommen.

Ist WFS also nur etwas für kleine Datenmengen? Oder aber hat jemand Antworten auf die Frage: Wie soll man WFS «richtig» nutzen?

Bezugsrahmenwechsel: ST_Fineltra in Action

Sun, 4 Oct 2015 00:00:00 +0000

Sandro Santilli hat eine erste Version der ST_Fineltra Funktion für PostGIS zum Testen freigegeben. Um die Funktion verwenden zu können, sind zwei Schritte notwendig:

Installieren der neuen Funktion
Importieren der Dreiecksvermaschung in die Datenbank

Das Installieren der Funktion funktioniert unter Ubuntu 14.04 problemlos. Hat man sowieso bereits die üblichen «GIS-Tools» (PostgreSQL/Postgis, gdal/ogr etc.) installiert, fehlt anscheinend nur das dev-Paket von liblwgeom:

sudo apt-get install liblwgeom-dev

Anschliessend kann gemäss der Installationsanleitung im README vorgegangen werden:

git clone https://github.com/strk/fineltra.git
cd fineltra
./autogen.sh
./configure
make
sudo make install

Die Funktion ist eine PostgreSQL-Extension und kann für die gewünschte Datenbank aktiviert werden:

sudo -u postgres psql -d xanadu2 -c "CREATE EXTENSION fineltra;"

Der zweite Schritt ist der Import der Dreiecksvermaschung. Eine Spatialite-Datei mit einer Tabelle mit sämtlichen Dreiecken in beiden Bezugsrahmen gibts hier. Vor Jahren habe ich diese aus den Shapedateien von Swisstopo erstellt. Der Import in die Datenbank ist ein einfacher ogr2ogr-Befehl. Leider scheint das mit einer Version kleiner 2.0 nicht wirklich gut zu funktionieren, weil die Tabelle zwei Geometriespalten aufweist. Bei mir werden nur die Sachattribute importiert. Mit ogr2ogr >= 2.0 reicht aber folgender Befehl:

ogr2ogr -f "PostgreSQL" PG:"dbname='xanadu2' host='localhost' port='5432' user='stefan' password='ziegler12'" chenyx06.sqlite chenyx06 -lco SCHEMA=av_chenyx06 -nln chenyx06_triangles

Die Tabelle mit den Dreiecken muss beide Bezugsrahmen beinhalten. Es ist nicht möglich die Funktion ST_Fineltra mit Dreiecksgeometrien aus verschiedenen Tabelle zu bedienen.

Das Schema av_chenyx06 muss bereits existieren. Ansonsten muss es manuell angelegt werden:

sudo -u postgres psql -d xanadu2 -c "CREATE SCHEMA av_chenyx06 AUTHORIZATION stefan;"

Es ist unbedingt darauf zu achten, dass die Geometrietabellen einen Geometrieindex aufweisen. Bei mir werden diese beim Import mit ogr2ogr automatisch erzeugt. Falls dies nicht der Fall ist:

sudo -u postgres psql -d xanadu2 -c "CREATE INDEX ON av_chenyx06.chenyx06_triangles USING GiST (the_geom_lv03);"

Hat das geklappt, kann es ans Testen gehen. Die Syntax ist sowohl im README wie auch im vorangegangen Beitrag erläutert.

Ok, das ist jetzt noch keine Wissenschaft. Aber es scheint zu funktionieren. Die erste Frage muss aber sein: «Stimmt die Transformation überhaupt?» Um dies zu beantworten, vergleichen wir die Resultate aus zwei unabhängigen Transformationen. Einmal transformieren wir einen Testdatensatz mit der neuen ST_Fineltra-Funktion und einmal mit einem offiziellen Transformationsdienst der Swisstopo.

Diesen Vergleich können wir auch innerhalb der Datenbank machen. Dazu verwenden wir die PostgreSQL-Extension http. Mit dieser Extension wird PostgreSQL zu einem HTTP-Client. Bevor man das jetzt produktiv wirklich nutzen will, sollte man unbedingt das Kapitel «Why This is a Bad Idea» im README lesen.

Die Installation ist simpel:

git clone https://github.com/pramsey/pgsql-http.git
cd pgsql-http
make
sudo make install

Und anschliessend:

sudo -u postgres psql -d xanadu2 -c "CREATE EXTENSION http;"

Ein Testaufruf zeigt folgendes:

Mit den JSON-Funktionen von PostgreSQL kann man einfach auf die einzelnen Rückgabewerte zugreifen. Als Testdatensatz wählen wir die Fixpunkte aus der amtlichen Vermessung. Weil jetzt für jeden Fixpunkt ein HTTP-GET-Request gemacht wird, dauert das ein Weilchen:

WITH fineltra AS (
  SELECT nummer, nbident,
    ST_X(wkb_geometry) as x_lv03, ST_Y(wkb_geometry) as y_lv03,
    ST_X((ST_Fineltra(wkb_geometry, 'av_chenyx06.chenyx06_triangles', 'the_geom_lv03', 'the_geom_lv95'))) as x_lv95_pg,
    ST_Y((ST_Fineltra(wkb_geometry, 'av_chenyx06.chenyx06_triangles', 'the_geom_lv03', 'the_geom_lv95'))) as y_lv95_pg
  FROM av_avdpool_test.fixpunktekategorie__lfp
  --WHERE fid = 3515717
  LIMIT 100
),
swisstopo AS (
  SELECT nummer, nbident, x_lv95_pg, y_lv95_pg,
   cast(content::json->>'easting' as double precision) as x_lv95_lt,
   cast(content::json->>'northing' as double precision) as y_lv95_lt
  FROM fineltra as f, http_get('http://geodesy.geo.admin.ch/reframe/lv03tolv95?easting=' || f.x_lv03 || '&northing=' || f.y_lv03 || '&format=json')
)
SELECT nummer, nbident, (x_lv95_pg - x_lv95_lt)*1000 as x_diff_mm, (y_lv95_pg - y_lv95_lt)*1000 as y_diff_mm
FROM swisstopo;

Das Resultat sieht vielversprechend aus:

Die Differenzen bewegen sich also in einem völlig irrelevanten Bereich. Um sicher zu sein, müssen auch noch weitere Geometrietypen (Linien und Polygone) überprüft werden.

Zu guter Letzt soll die Performanz getestet werden. Dazu werden alle Tabellen der amtlichen Vermessung des Kantons Solothurn in einem MOpublic-ähnlichen Datenmodell in die Datenbank importiert. Eine GeoPackage-Datei des gesamten Kantons kann hier heruntergeladen und mit folgendem ogr2ogr-Befehl in die Datenbank importiert werden:

ogr2ogr -f "PostgreSQL" PG:"dbname='xanadu2' host='localhost' port='5432' user='stefan' password='ziegler12'" -lco SCHEMA=av_avdpool_test kanton.gpkg

In das Schema av_avdpool_test wurden 33 Tabellen importiert. Alle im Bezugrahmen LV03:

In einem Groovy-Skript reicht jetzt eigentlich eine einzige For-Schleife. Aus der View geometry_columns werden alle zu transformierenden Tabellen identifiziert und diese transformiert:

@Grapes([
   @Grab('org.postgresql:postgresql:9.4-1201-jdbc41'),
   @GrabConfig(systemClassLoader = true)
])

import groovy.sql.*

def dbhost = "localhost"
def dbport = "5432"
def dbdatabase = "xanadu2"
def dbusr = "stefan"
def dbpwd = "ziegler12"
def dbschema = "av_avdpool_test"

def dburl = "jdbc:postgresql://${dbhost}:${dbport}/${dbdatabase}?user=${dbusr}&password=${dbpwd}"

def query = "SELECT f_table_schema, f_table_name, f_geometry_column, coord_dimension, srid, type " +
  " FROM geometry_columns " +
  " WHERE f_table_schema = '$dbschema'" +
  " AND srid = 21781;"

def sql = Sql.newInstance(dburl)

def startTime = Calendar.instance.time
def endTime
println "Start: ${startTime}."

sql.withTransaction {
  sql.eachRow(query) {row ->
    def tableName = row.f_table_name
    def geomColumn = row.f_geometry_column

    def geomType = row.type
    if (row.coord_dimension == 3) {
      geomType += 'Z'
    }

    def alterQuery = "ALTER TABLE ${Sql.expand(dbschema)}.${Sql.expand(tableName)}" +
      " ALTER COLUMN ${Sql.expand(geomColumn)} TYPE geometry(${Sql.expand(geomType)},2056)" +
      " USING ST_Fineltra(${Sql.expand(geomColumn)}, 'av_chenyx06.chenyx06_triangles', 'the_geom_lv03', 'the_geom_lv95');"

    println "--- $dbschema.$tableName ---"
    sql.execute(alterQuery)

    endTime = Calendar.instance.time
    println "Elapsed time: ${(endTime.time - startTime.time)} ms"

  }
}

endTime = Calendar.instance.time
println "End: ${endTime}."
println "Total elapsed time: ${(endTime.time - startTime.time)} ms"

sql.connection.close()
sql.close()

Die Transformation einer Datenbanktabelle ist die Query in den Zeilen 38 - 40. Dies ist der einfachst mögliche Fall. Gibt es aber Rules und/oder Triggers etc. in der Tabelle, müssen diese wahrscheinlich vorher ausgeschaltet und nach der Transformation eingeschaltet werden. Das genaue Vorgehen muss geprüft werden.

Die gleichen 33 Tabellen liegen nun im Bezugsrahmen LV95 vor:

Die Geschwindigkeit ist verblüffend: Für sämtliche Tabellen braucht das Skript bloss circa 140 Sekunden. Die Transformation der Bodenbedeckung mit circa 280'000 Polygonen dauert nur 25 Sekunden (Ubuntu 14.04 in einer VirtualBox auf einem 2jährigen iMac mit SSD).

Interlis leicht gemacht #5

Sat, 3 Oct 2015 00:00:00 +0000

Overlaps in INTERLIS. Eine leidige Geschichte. Im Referenzhandbuch ist auf den Seiten 49 und 50 beschrieben was erlaubt ist. Fairerweise muss man erwähnen, dass das Verbieten von Overlaps im INTERLIS-Modell das Problem aber trotzdem nicht lösen würde. Möglich blieben Overlaps (aka Self-Intersections) aus rein numerischen Gründen. Hier die erläuternde Skizze aus dem Handbuch ((c) by KOGIS, CH-3084-Wabern, www.kogis.ch):

Das Problem mit Overlaps ist, dass Geometrien mit solchen im OGC Simple Feature Universum nicht gültig sind und beim Prozessieren für nicht zuverlässige Resultate sorgen oder auch zu gar keinen.

Solche Overlaps sind unter anderem häufig in der amtlichen Vermessung bei Einlenkern anzutreffen:

Soweit sieht das ganz gut aus. Um das Ganze übersichtlicher zu gestalten, lassen wir alles weg, was nicht Liegenchaften sind und markieren die Stützpunkte. Die grünen Quadrate kennzeichnen die Linienstützpunkte LIPT und die blauen Kreise die Bogenstützpunkte ARCP:

Sieht eigentlich immer noch gut aus. Zoomt man jetzt aber beim rechten Einlenker (roter Kreis) stark rein, wird die Self-Intersection sichtbar. Eine der beiden Linien ist rot eingefärbt, um das Kreuzen (= Self-Intersection = Overlap) der Linien besser sichtbar zu machen:

Wie ging man bis anhin mit diesem Problem um? Eine Variante ist die einzelnen Linienstücke während des INTERLIS-Importes neu zu verknoten. Dort wo sich die Linien kreuzen wird ein neuer Stützpunkt gerechnet und anschliessend wird polygoniert. Dabei entsteht ein klitzekleines Polygon. Für den Umgang mit diesem Polygon gibts wiederum ein paar Varianten:

Es wird gelöscht. Unschön, da jetzt eine Lücke im Datensatz entsteht (bei Areas).
Es wird dem «Ursprungs»-Polygon zugewiesen. Unschön, da jetzt ein Multipolygon entsteht resp. entstehen muss. Das INTERLIS-Datenmodell sieht aber unter Umständen keine Multipolygone vor (Constraints in der Datenbank lassen grüssen).
Es wird dem Nachbarpolygon mit der längsten gemeinsamen Kanten zugewiesen. Unschön, da jetzt der Endpunkt des «Ursprungs»-Polygons nicht mehr am «Ursprungs»-Endpunkt zu liegen kommt. In der amtlichen Vermessung würde das bedeuten, dass auf diesem Stützpunkt des Polygons kein Grenzpunkt liegt obwohl doch eigentlich einer da sein sollte.

In der neusten Version von ili2pg wurde eine bessere Variante implementiert. Um die Topologie (wenn man das so nennen darf) resp. die Nachbarschaftsbeziehungen zwischen den Polygonen besser einzuhalten wird auf dem Kreisbogen in genügend grossem Abstand (abhängig vom erlaubten OVERLAP-Wert im INTERLIS-Datenmodell) von der tangential zulaufenden Gerade ein neuer Stützpunkt gerechnet. Von diesem neuen Stützpunkt wird anschliessend ein kleines Geradenstück bis zum Endpunkt gezogen. Vielleicht sagt ein Bild mehr als 1'000 komplizierte Worte:

Rausgezoomt wird die neue Situation nochmals deutlicher sichtbar:

Teil dieses Weiterentwicklungspaketes von ili2pg war ebenfalls die Unterstützung der Flächenbildung unter Beibehaltung der Kreisbogengeometrien. Diese werden neu nicht mehr segmentiert, sondern das Resultat eines INTERLIS1-Importes in die Postgis-Datenbank sind Geometrien vom Typ COMPOUNDCURVE und CURVEPOLYGON. Mit dem Programmparameter --strokeArcs können Kreisbogen weiterhin segmentiert werden.

Diese Weiterentwicklungen wurden finanziell unterstützt durch die Kantone Bern, Glarus und Solothurn und durch die Firma Eisenhut Informatik AG ausgeführt. Besten Dank!

Bezugsrahmenwechsel: PostGIS to the rescue

Thu, 17 Sep 2015 00:00:00 +0000

Gute Mitarbeiter mit guten Ideen. Was dabei rauskommt? Die PostgreSQL-Funktion ST_Fineltra.

Wie wahrscheinlich viele andere Kantone auch wollten wir mit FME und dem REFRAME-Plugin die Daten in unserer PostgreSQL-Datenbank transformieren. Das funktioniert und ist genügend schnell. So richtig glücklich wurden wir aber nicht damit:

Warum sollen wir Daten mit einer Drittapplikation ausserhalb der Datenbank transformieren, um sie dann wieder in der Datenbank zu speichern? Wenn ich mit ST_Transform Daten in ein anderes Koordinatensystem transformiere, muss ich das ja auch nicht machen.
In einer Übergangsphase müssen wir wohl oder über die Flexibilität und Fähigkeit besitzen Daten in beiden Bezugsrahmen anbieten und verwalten zu können. Für diese Aufgaben will/kann ich nicht immer gleich FME anschmeissen.
Wir hatten mit FME Probleme bei Tabellen, die mehrere Geometrieattribute aufweisen. War alles machbar, wirkte aber hakelig.

Warum also nicht ein Funktion à la ST_Transform, die es ermöglicht die Daten mit der offiziellen Dreiecksvermaschung zu transformieren? ST_Fineltra war geboren. Ende Oktober sollte die Funktion als PostgreSQL-Extension verfügbar sein.

Die Bodenbedeckung der amtlichen Vermessung mit ST_Fineltra transformieren?

UPDATE bodenbedeckung_boflaeche
  SET geometrie_lv95 = ST_Fineltra(geometrie_lv03, 'chenyx06', 'geom_lv03', 'geom_lv95');

geometrie: Die zu transformierende Geometrie.

chenyx06: Der Namen der Tabelle mit der Dreiecksvermaschung. Es wird also möglich sein die Funktion mit eigenen Dreiecksvermaschungen (z.B. für lokale Entzerrungen) zu verwenden.

geom_lv03: Attributname der Dreiecksdefinitionen (in der Dreiecksvermaschungstabelle) im Ausgangsbezugsrahmen.

geom_lv95: Attributname der Dreiecksdefinitionen (in der Dreiecksvermaschungstabelle) im Zielbezugsrahmen.

Die UPDATE-Query hat den Schönheitsfehler, dass es jetzt zwei Geometrieattribute in der Tabelle gibt. Dies wollen wir vermeiden und die LV03-Geometrie in eine LV95-Geometrie transformieren. Mit folgender schicken Query ist das kein Problem:

ALTER TABLE bodenbedeckung_boflaeche
  ALTER COLUMN geometrie TYPE geometry(Polygon,2056)
    USING ST_Fineltra(geometrie, 'chenyx06', 'geom_lv03', 'geom_lv95');

In der Datenbanksicht geometry_columns sind alle notwendigen Informationen dazu vorhanden. Mit einem kleinen Skript und einer For-Schleife lassen sich jetzt alle Tabellen transformieren. In PostGIS < 2.0 ist geometry_columns keine Sicht, sondern eine Tabelle, die manuell nachgeführt werden muss. Entweder ist die sauber und vollständig nachführt oder man muss sich die Informationen aus den verschiedenen pg_*-Tabellen zusammen suchen, was die Komplexität des Skriptes natürlich erhöht. Ebenfalls muss an anfällige Triggers und Rules gedacht werden. Diese sollten vor der Transformation ausgeschaltet und anschliessend wieder eingeschaltet werden. Informationen dazu können ebenfalls aus den pg_*-Tabellen geholt werden.

Interlis leicht gemacht #4

Sun, 30 Aug 2015 00:00:00 +0000

Wir sind momentan dabei im Kanton Solothurn die AVGBS einzuführen. In einem Pilotprojekt sollen verschiedene Geschäftsfälle durchgespielt werden. Dafür müssen in der amtlichen Vermessung die Grundstücke das Attribut «EGRIS_EGRID» führen. Im Grundbuch wird der EGRID bereits geführt. Eine Liste aller Grundstücke (inkl. EGRID) kann vom Grundbuch als CSV-Datei exportiert werden. Die Frage lautet also nun: Wie kommen die EGRID aus dem Grundbuch in die amtliche Vermessung beim Nachführungsgeometer?

Eine Variante ist das manuelle Abfüllen des EGRID im AV-Erfassungssystem. Bei fast 2000 Grundstücken in der Pilotgemeinde macht das wenig Spass, ist fehleranfällig und wird ewig dauern. Mmmmh, es geht hier doch um AVGBS. Warum erstellen wir nicht eine AVGBS-Datei, die der Nachführungsgeometer in seinem System einlesen kann? Gesagt, getan. Mit einem kleinen Groovy-Skript und ili2pg wird das TOPIC Eigentumsverhaeltnis mit der CLASS Grundstueck erstellt, abgefüllt und anschliessend in einer INTERLIS-Datei dem Nachführungsgeometer zur Verfügung gestellt. Dieser kann die INTERLIS-Datei einlesen und der EGRID wird den Grundstücken in seinem System zugewiesen.

Der komplette Prozess kann in vier Schritte unterteilt werden:

Erstellen der INTERLIS-Modellstruktur in der Datenbank
Importieren der CSV-Datei mit den EGRID in die Datenbank
Abfüllen der in Schritt (1) erstellten Tabellen mit den benötigten Informationen
Exportieren der INTERLIS-Datei

@Grapes([
   @GrabResolver(name='catais.org', root='http://www.catais.org/maven/repository/release/', m2Compatible='true'),
   @Grab('org.postgresql:postgresql:9.4-1201-jdbc41'),
   @Grab('ch.interlis:ili2c:4.5.12'),
   @Grab('ch.interlis:ili2pg:2.1.4'),
   @GrabConfig(systemClassLoader = true)
])

import ch.ehi.ili2db.base.Ili2db
import ch.ehi.ili2db.base.Ili2dbException
import ch.ehi.ili2db.gui.Config
import ch.ehi.ili2pg.converter.PostgisGeometryConverter
import ch.ehi.sqlgen.generator_impl.jdbc.GeneratorPostgresql
import groovy.sql.*

def csv = "/Users/stefan/tmp/gb_egridexport150730_2407.csv"
def numberOfCsvRows = 3717
def municipality = "oensingen"
def fosnr = 2407

def dbhost = "localhost"
def dbport = "5432"
def dbdatabase = "xanadu2"
def dbusr = "stefan"
def dbpwd = "ziegler12"
def dbschema = "av_egrid"
def modelName = "GB2AV"

def dburl = "jdbc:postgresql://${dbhost}:${dbport}/${dbdatabase}?user=${dbusr}&password=${dbpwd}"

/*
* 1. Create empty database tables with ili2db.
*/
def query = "DROP SCHEMA IF EXISTS ${Sql.expand(dbschema)} CASCADE;"
def sql = Sql.newInstance(dburl)
sql.execute(query)

def config = new Config()
config.setDbhost(dbhost)
config.setDbdatabase(dbdatabase)
config.setDbport(dbport)
config.setDbusr(dbusr)
config.setDbpwd(dbpwd)
config.setDbschema(dbschema)
config.setDburl(dburl)

config.setModels(modelName);
config.setModeldir("http://models.geo.admin.ch/");

config.setGeometryConverter(PostgisGeometryConverter.class.getName())
config.setDdlGenerator(GeneratorPostgresql.class.getName())
config.setJdbcDriver("org.postgresql.Driver")

config.setNameOptimization("topic")
config.setMaxSqlNameLength("60")
config.setSqlNull("enable");

config.setDefaultSrsAuthority("EPSG")
config.setDefaultSrsCode("21781")

Ili2db.runSchemaImport(config, "")

/*
* 2. Create foreign table from CSV.
*/
query = """\
DROP FOREIGN TABLE IF EXISTS ${Sql.expand(dbschema)}.${Sql.expand(municipality)};

CREATE FOREIGN TABLE ${Sql.expand(dbschema)}.${Sql.expand(municipality)}  (
 bfsnr integer,
 kreisnr integer,
 grundstuecknummer varchar,
 grundstuecknummerzusatz varchar,
 grundstuecknummer3 varchar,
 grundstuecknummer4 varchar,
 egrid varchar(14)
) SERVER file_fdw_server
OPTIONS (format 'csv', header 'true',
         filename '${Sql.expand(csv)}',
         delimiter ',', null '');
"""
sql.execute(query)

// Check number of rows in foreign table.
query = "SELECT count(*) FROM ${Sql.expand(dbschema)}.${Sql.expand(municipality)};"
assert sql.firstRow(query).count == numberOfCsvRows

/*
* 3. Assign EGRID values to cadastral data and insert data into ili2db tables.
*/
query = """\
DELETE FROM ${Sql.expand(dbschema)}.eigentumsverhaeltnis_grundstueck;
DELETE FROM ${Sql.expand(dbschema)}.gb2av_grundstuecknummer;

WITH av AS (
 SELECT g.ogc_fid as av_id, g.nbident, g.nummer as av_nummer, l.flaechenmass, l.geometrie, l.gem_bfs, l.lieferdatum
 FROM av_avdpool_ch.liegenschaften_grundstueck as g, av_avdpool_ch.liegenschaften_liegenschaft as l
 WHERE g.gem_bfs = ${Sql.expand(fosnr)}
 AND l.gem_bfs = ${Sql.expand(fosnr)}
 AND g.tid = l.liegenschaft_von
),
gb AS (
 SELECT row_number() OVER () as gb_id, bfsnr, grundstuecknummer as gb_nummer, egrid
 FROM ${Sql.expand(dbschema)}.${Sql.expand(municipality)}
 WHERE grundstuecknummerzusatz IS NULL
),
eigentumsverhaeltnis_grundstueck AS (
 INSERT INTO ${Sql.expand(dbschema)}.eigentumsverhaeltnis_grundstueck (t_id, art)
 SELECT gb_id, 0::integer as art
 FROM av, gb
 WHERE av.av_nummer = gb.gb_nummer
)
INSERT INTO ${Sql.expand(dbschema)}.gb2av_grundstuecknummer(t_id, t_seq, egrid, nummer, gb2aveigntmsvrhltnis_grundstueck_nummer)
SELECT (gb_id+1000000) as t_id, 0::integer as t_seq, gb.egrid, gb.gb_nummer, gb_id
FROM av, gb
WHERE av.av_nummer = gb.gb_nummer;
"""
sql.execute(query)

// Check if we were able to assign an EGRID to all Liegenschaften from cadastral
// survyeing. If this is true the number of objects in all three tables is equal.
query = "SELECT count(*) FROM av_avdpool_ch.liegenschaften_liegenschaft WHERE gem_bfs = ${Sql.expand(fosnr)};"
def numberOfLiegenschaften = sql.firstRow(query).count

query = "SELECT count(*) FROM ${Sql.expand(dbschema)}.eigentumsverhaeltnis_grundstueck;"
def numberOfEigentumsverhaeltnisGrundstueck = sql.firstRow(query).count

query = "SELECT count(*) FROM ${Sql.expand(dbschema)}.gb2av_grundstuecknummer;"
def numberOfGrundstuecknummer = sql.firstRow(query).count

assert numberOfLiegenschaften == numberOfEigentumsverhaeltnisGrundstueck
assert numberOfLiegenschaften == numberOfGrundstuecknummer

// Close database connection.
sql.connection.close()
sql.close()

/*
* 4. Export data to an INTERLIS/XTF file.
*/
config.setXtffile("/Users/stefan/tmp/egrid_${municipality}.xtf")
Ili2db.runExport(config, "")

Zeilen 34 - 61: Im ersten Schritt wird das Schema, in dem die INTERLIS-Modellstruktur angelegt wird, gelöscht (falls es existiert). Anschliessend werden mit ili2pg die leeren Tabellen in der Datenbank angelegt. Mehr Informationen zu den Konfigurationsparametern gibts hier.

Zeilen 66 - 86: Die Daten aus der CSV-Datei müssen in die Datenbank importiert werden, um anschliessend Abfragen durchführen zu können. Ein eleganter Weg die Daten zu importieren, ist die Verwendung eines Foreign Data Wrappers für Textdateien. Die Kenntnis über die Struktur (also die Spalten der CSV-Datei und das verwendete Trennzeichen) reicht, um mit einem CREATE FOREIGN TABLE die Daten zu "importieren". Mit assert wird geprüft, ob auch wirklich alles importiert wurde.

Zeilen 91 - 136: Anschliessend können mit SQL-Befehlen die AV-Daten mit den importierten Grundbuchdaten verknüpft werden und das gewünschte Ergebnis in die passenden Tabellen (aus Schritt 1) gespeichert werden. Verwendet werden Common Table Expressions. Somit fallen die x-fach verschachtelten Subqueries weg.

Aus dem TOPIC Eigentumsverhaeltnis interessiert eigentlich nur die CLASS Grundstueck. Die Klasse verwendet jedoch eine STRUCTURE, die in der relationalen Datenbank in einer weiteren Tabelle abgebildet wird. So müssen Daten in zwei Tabellen geschrieben werden.

Auch hier überprüfen wir wieder auf Vollständigkeit: In beiden Tabellen, in die wir Daten geschrieben haben, müssen genau gleich viele Objekte vorhanden sein, wie in der Ausgangstabelle (Liegenschaften der amtlichen Vermessung).

Die selbständigen und dauerenden Rechte fehlen in der Abfrage, können aber genau gleich behandelt werden.

Zeilen 141 - 142: Zu guter Letzt exportieren wird unsere Arbeit in eine INTERLIS/XTF-Datei.

Die Log-Informationen des Exportprozesses sehen schon mal gut aus:

Ein kurzer Blick in die INTERLIS/XTF-Datei zeigt das gewünschte Resultat:

Interlis leicht gemacht #3

Sun, 9 Aug 2015 00:00:00 +0000

Das GeoIG resp. die GeoIV sieht Downloaddienste für Geobasisdaten vor. Kurzum heisst das, dass diese Geobasisdaten dienstebasiert und modellkonform zum Download bereitgestellt werden. Modellkonform bedeutet - sehr einfach ausgedrückt - entweder INTERLIS/XTF oder INTERLIS/GML. INTERLIS/GML hat den Vorteil, dass man es, im Gegensatz zu INTERLIS/XTF, sinnvoll mittels WFS bereitstellen kann. Dienstebasiert bedeutet, dass nicht bloss ein einfacher Downloadlink publiziert wird, sondern dass zusätzlich zum Link eine Serviceschicht darüber gestülpt wird.

Gedanken über das modellkonforme Bereitstellen von Geodaten hat sich INSPIRE auch schon gemacht. Als Lösungen für Downloaddienste werden zwei Alternativen vorgeschlagen: WFS und Atom + OpenSearch (AtOS). Informationen zu Atom + OpenSearch findet man vor allem in zwei Masterarbeiten. Bei Atom + OpenSearch können die (Geo)daten dateibasiert und vordefiniert heruntergeladen werden. Um dem Servicegedanken gerecht zu werden und nicht bloss stupide HTTP-Links zu publizieren, muss noch eine Schicht drüber gelegt werden. Diese pflanzt dem Ganzen ein wenig Intelligenz ein.

Setzt man sich mit der modellkonformen Bereitstellung von Geodaten auseinander, darf man zum Schluss kommen, dass die Atom + OpenSearch Lösung einfacher und effizienter für eine GDI umsetzbar ist. Zudem schlägt man zwei Fliegen mit einer Klappe: neben modellkonformen Daten können ebenfalls nicht-modellkonforme Daten und Rasterdaten mittels Atom + OpenSearch bereitgestellt werden können. WFS kann natürlich trotzdem eingesetzt werden. In diesem Fall aber nicht für die modellkonforme Bereitstellung. Die gerade eben diskutierten Datenflüsse lassen sich grob wie folgt darstellen:

Das Schema zeigt die beiden Schritte (1) Datenumbau und (2) Formatumbau. Der Datenumbau kann z.B. mit einem ETL-Werkzeug oder auch mit SQL-Befehlen durchgeführt werden. Für den Formatumbau eignet sich ja hervorragend ili2pg. Der Formatumbau bei der Variante WFS übernimmt der WFS-Server selbst. Nun könnte man zum Schluss kommen, dass die Variante AtOS weniger aktuell als die WFS-Variante ist: Der WFS greift live auf die Daten des MGDM-Topfs zu wohingegen bei AtOS die Datei z.B. einmal pro Tag mit ili2pg physisch produziert wird. Nun, dem ist nicht so. Eine elegante Lösung ist der Einsatz der ili2pg-Bibliotheken als Servlet. Damit kann der Formatumbau erst beim Aufruf der URL, z.B. http://www.example.com/2583_schoenenwerd.xtf, ausgeführt werden. Als Proof of Concept soll die amtliche Vermessung der Gemeinde Schönenwerd im Datenmodell MOpublic mittels Servlet erzeugt werden.

Als erstes brauchen wir einen Servlet-Container. Anstelle von Java kann man auch - um ein paar Zeichen zu sparen - Groovy einsetzen und sich mit Jetty was zusammenbasteln:

#!/usr/bin/env groovy

import org.eclipse.jetty.server.Server
import org.eclipse.jetty.servlet.*
import groovy.servlet.*

@Grab(group='org.eclipse.jetty.aggregate', module='jetty-all', version='9.2.10.v20150310')
def startJetty() {
    def server = new Server(8080)
    def handler = new ServletContextHandler(ServletContextHandler.SESSIONS)
    handler.contextPath = '/'
    handler.resourceBase = '.'
    handler.addServlet(IliExport, '/*')

    server.handler = handler
    server.start()
    server.join()
}

println "Starting Jetty, press Ctrl+C to stop."
startJetty()

Interessant sind wahrscheinlich folgende Zeilen:

Zeile 7: Groovy hat mit Grape ein effizientes Dependency Management. Fehlt die gewünschte Bibliothek auf dem System, wird sie einmalig heruntergeladen und gespeichert.

Zeile 13: Hier teilen wir dem Server mit, dass bei allen Requests das Servlet IliExport aufgerufen werden soll.

Das Formatumbau/Export-Servlet sieht dann wie folgt aus:

@GrabConfig(systemClassLoader=true)
@GrabResolver(name='catais.org', root='http://www.catais.org/maven/repository/release/', m2Compatible='true')
@Grab(group='org.postgresql', module='postgresql', version='9.4-1201-jdbc41')
@Grab(group='ch.interlis', module='ili2c', version='4.5.12')
@Grab(group='ch.interlis', module='ili2pg', version='2.1.4')

import javax.servlet.http.*
import javax.servlet.*
import groovy.servlet.ServletCategory

import ch.ehi.ili2db.base.Ili2db
import ch.ehi.ili2db.base.Ili2dbException
import ch.ehi.ili2db.gui.Config
import ch.ehi.ili2pg.converter.PostgisGeometryConverter
import ch.ehi.sqlgen.generator_impl.jdbc.GeneratorPostgresql

class IliExport extends HttpServlet {
    def application

    void init(ServletConfig config) {
        super.init(config)
        application = config.servletContext
    }

    void doGet(HttpServletRequest request, HttpServletResponse response) {
        def requestedFileName = request.getRequestURI() - '/'

        def mapping = [
        '2583_schoenenwerd.xtf': ['modelname':'MOpublic03_ili2_v13', 'dbschema':'av_mopublic_export'],
        '2583_schoenenwerd.gml': ['modelname':'MOpublic03_ili2_v13', 'dbschema':'av_mopublic_export']
        ]
        def params = mapping.get(requestedFileName)
        def modelName = params['modelname']
        def dbschema = params['dbschema']

        def config = new Config()
        config.setDbhost("localhost")
        config.setDbdatabase("xanadu2")
        config.setDbport("5432")
        config.setDbusr("stefan")
        config.setDbpwd("ziegler12")
        config.setDbschema(dbschema)
        config.setDburl("jdbc:postgresql://localhost:5432/xanadu2")

        config.setModels(modelName);
        config.setModeldir("http://models.geo.admin.ch/");

        config.setGeometryConverter(PostgisGeometryConverter.class.getName())
        config.setDdlGenerator(GeneratorPostgresql.class.getName())
        config.setJdbcDriver("org.postgresql.Driver")

        config.setNameOptimization("topic")
        config.setMaxSqlNameLength("60")
        config.setStrokeArcs("enable")
        config.setSqlNull("enable");
        config.setValue("ch.ehi.sqlgen.createGeomIndex", "True");

        config.setDefaultSrsAuthority("EPSG")
        config.setDefaultSrsCode("21781")

        def tmpDir = System.getProperty('java.io.tmpdir')
        def fileName = tmpDir + File.separator + requestedFileName

        config.setXtffile(fileName)

        Ili2db.runExport(config, "")

        ServletOutputStream os = response.getOutputStream();
        FileInputStream fis = new FileInputStream(fileName);
        try {
            int buffSize = 1024;
            byte[] buffer = new byte[buffSize];
            int len;
            while ((len = fis.read(buffer)) != -1) {
                os.write(buffer, 0, len);
                os.flush();
                response.flushBuffer();
            }
        } finally {
            os.close();
        }
    }
}

Zeilen 1 -2: Weil JDBC-Treiber anders geladen werden, müssen wir Grape speziell konfigurieren. Brauchen wir spezielle Mavenrepositories müssen wir diese ebenfalls angeben (Zeile 2).

Zeilen 26 - 34: Sämtliche Requests werden auf dieses Servlet umgeleitet (siehe oben). Der URL-Aufruf entspricht ja eigentlich einem Download einer statischen Datei (INTERLIS/XTF-Datei der Gemeinde Schönenwerd), dh. der Request sieht in unserem Fall wie folgt aus: http://localhost:8080/2583_schoenenwerd.xtf. Die dazugehörigen Daten liegen in der Datenbank in einem Schema. In welchem Schema steht aber nicht in der URL, sondern das müssen wir mittels Mapping herausfinden. In diesem einfachen Proof of Concept stehen die benötigten Informationen in einer Map. Anstelle der Map ist natürlich auch eine Meta-DB o.ä. vorstellbar. Neben des Speicherortes (Datenbankschema) müssen wir noch den Interlis-Modellnamen kennen.

Zeilen 36 - 66: Die INTERLIS/XTF-Datei wird erzeugt und in ein temporäres Verzeichnis geschrieben (= Formatumbau).

Zeilen 68 - 81: Die gerade eben erzeugte Datei wird an den Klienten gestreamt.

Um den Browser nicht zu arg zu belasten (bei 25 MB XML) verwenden wir cURL in der Konsole, um die Datei herunterzuladen:

curl http://localhost:8080/2583_schoenenwerd.xtf | xmllint --format -

Mit xmllint wird das heruntergeladene XML noch schön formatiert. Der Formatumbau dauert für die Gemeinde Schönenwerd circa fünf Sekunden und das Resultat kann sich sehen lassen:

Ein Vorteil von ili2pg ist, dass es neben INTERLIS/XTF auch INTERLIS/GML exportieren kann. Der Anwender muss nur drei Buchstaben ändern (.xtf → .gml):

curl http://localhost:8080/2583_schoenenwerd.gml | xmllint --format -

Wiederum fünf Sekunden später erfreuen wir uns über die GML-Datei:

Je nach Situation (Komplexität und Methode) könnte man auch den Datenumbau (1) gerade beim Aufruf erledigen. In unserem Fall wird der Datenumbau mit SQL-Befehlen gemacht und dauert weniger als eine Sekunde.

Eleganter wäre sicher auch wenn man auf das Zwischenspeichern in einer temporären Datei verzichten könnte und ili2pg direkt zum Klienten streamen könnte. Dann muss man auch nicht mehr den Knorz in den Zeilen 68 - 81 durchführen. Soweit ich das verstehe, dürfte das möglich sein, da die darunterliegende Klasse XtfWriter dies bereits unterstützt.

Und sollte aus ili2pg irgendwann einmal ein ili2GeoPackage werden, können auch Nicht-PostgreSQL-Anwender diese Bibliotheken verwenden. Man muss bloss den Datenumbau aus dem proprietären System nach GeoPackage machen und den Rest übernimmt ili2GeoPackage…

Bezugsrahmenwechsel: Transformation von Lidardaten

Wed, 24 Jun 2015 00:00:00 +0000

Im Frühjahr 2014 liess der Kanton Solothurn eine LiDAR-Befliegung über das gesamte Kantonsgebiet durchführen. Die Daten wurden, wie von uns gewünscht, im Bezugsrahmen LV03 geliefert. Nicht die sinnvollste Entscheidung… Der Bezugsrahmenwechsel steht definitiv vor der Tür und falls wir wollen, dass die Rohdaten in Zukunft noch verwendet werden, müssen wir wohl oder übel auch die 1'066 LAZ-Dateien transformieren.

Für die Transformation stehen - je nach Genauigkeit der Daten - verschiedene Transformationsmethoden zur Verfügung. Eine davon ist die Transformation mittels NTv2-Gitter. Anstelle der Dreiecke wird hier ein regelmässiges Gitter verwendet. Die Differenz zwischen der Transformation mittels Dreiecksvermaschung und NTv2-Gitter ist im Kanton Solothurn sehr klein:

Die Abbildung zeigt die Differenzen eines 100 m x 100 m Rasters. In drei sehr kleinen Gebieten wird die maximale Abweichung von 25 mm erreicht. Der Mittelwert ist 1.3 mm, der Median bloss 0.6 mm. Die Genauigkeit der LiDAR-Daten liegt im einstelligen bis tiefen zweistelligen Zentimeterbereich. Für die Transformation genügt das NTv2-Gitter also vollkommen.

Eine Bedingung an die transformierten Daten ist, dass sie ebenfalls wieder in Quadratkilometer-Kacheln mit «schönen» Boundingbox-Koordinaten vorliegen:

Das Bild zeigt exemplarisch vier Kacheln. Im linken Teil sind diese vier Kacheln im Bezugsrahmen LV03 gezeichnet. Im rechten Teil (Bezugsrahmen LV95) sind die transformierten Kacheln grau gezeichnet. Diese «hässlichen» Koordinaten sind aber für die Kacheleinteilung nicht erwünscht, sondern die «schönen» runden Koordinaten. Das bedeutet, dass die graue Kachel mit dem Gebäude neu in vier Kacheln zu liegen kommt. Anders formuliert: Das Gebäude liegt in einer neuen Kachel, die Daten aus vier alten Kacheln beinhaltet.

Die Software muss also etwas Ähnliches wie GDAL mit seinem vrt-Treiber anbieten. Dann kann man genau gleich vorgehen wie bereits mit den Orthofotos.

PDAL ist ein relativ neues Projekt. Es ist eine Bibliothek für "translating and manipulating point cloud data". Was GDAL für 2D-Pixel-Daten heute ist, will PDAL für multidimensionale Punkte werden.

Zuerst muss ein Tileindex für sämtliche Kacheln erzeugt werden:

find /home/stefan/mr_candie_nas/Geodaten/ch/so/agi/hoehen/2014/lidar/ -maxdepth 1 -iname "*.laz" | pdal tindex tileindex.gpkg -f "GPKG" --a_srs EPSG:21781 --t_srs EPSG:21781 --fast_boundary --stdin --lyr_name tileindex

Der Befehl sucht alle Dateien mit der Endung *.laz und schreibt die Boundingbox in eine GeoPackage-Datei. Mit der Option --a_srs EPSG:21781 wird den LiDAR-Daten ein Koordinatensystem zugewiesen. Ob die LiDAR-Daten bereits mit einem Koordinatensystem versehen sind, lässt sich mit dem pdal info-Befehl herausfinden:

pdal info --metadata LAS_592228.laz

liefert:

{
  "filename": "LAS_592228.laz",
  "metadata":
  {
    "comp_spatialreference": "",
    "compressed": true,
    "count": 14347366,
    "creation_doy": 312,
    "creation_year": 2014,
    "dataformat_id": 1,
    "dataoffset": 329,
    "filesource_id": 0,
    "global_encoding": "AAA=",
    "header_size": 227,
    "major_version": 1,
    "maxx": 592999.98999999999,
    "maxy": 228999.98999999999,
    "maxz": 2134.52,
    "minor_version": 2,
    "minx": 592000,
    "miny": 228000,
    "minz": 918.08000000000004,
    "offset_x": -0,
    "offset_y": -0,
    "offset_z": -0,
    "project_id": "00000000-0000-0000-0000-000000000000",
    "scale_x": 0.01,
    "scale_y": 0.01,
    "scale_z": 0.01,
    "software_id": "TerraScan",
    "spatialreference": "",
    "system_id": ""
  },
  "pdal_version": "1.0.0.b1 (git-version: 1dce22)"
}

Hat die Datei bereits ein Koordinatensystem, sieht der Output so aus:

{
  "filename": "LAS_592228.laz",
  "metadata":
  {
    "comp_spatialreference": "PROJCS[\"CH1903 / LV03\",GEOGCS[\"CH1903\",DATUM[\"CH1903\",SPHEROID[\"Bessel 1841\",6377397.155,299.1528128,AUTHORITY[\"EPSG\",\"7004\"]],TOWGS84[674.4,15.1,405.3,0,0,0,0],AUTHORITY[\"EPSG\",\"6149\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4149\"]],PROJECTION[\"Hotine_Oblique_Mercator_Azimuth_Center\"],PARAMETER[\"latitude_of_center\",46.95240555555556],PARAMETER[\"longitude_of_center\",7.439583333333333],PARAMETER[\"azimuth\",90],PARAMETER[\"rectified_grid_angle\",90],PARAMETER[\"scale_factor\",1],PARAMETER[\"false_easting\",600000],PARAMETER[\"false_northing\",200000],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],AXIS[\"Y\",EAST],AXIS[\"X\",NORTH],AUTHORITY[\"EPSG\",\"21781\"]]",
    "compressed": true,
    "count": 14347366,
    "creation_doy": 224,
    "creation_year": 2015,
    "dataformat_id": 3,
    "dataoffset": 2181,
    "filesource_id": 0,
    "global_encoding": "AAA=",
    "header_size": 227,
    "major_version": 1,
    "maxx": 592999.98999999999,
    "maxy": 228999.98999999999,
    "maxz": 2134.52,
    "minor_version": 2,
    "minx": 592000,
    "miny": 228000,
    "minz": 918.08000000000004,
    "offset_x": 0,
    "offset_y": 0,
    "offset_z": 0,
    "project_id": "00000000-0000-0000-0000-000000000000",
    "scale_x": 0.01,
    "scale_y": 0.01,
    "scale_z": 0.01,
    "software_id": "PDAL 1.0.0.b1 (e412bd)",
    "spatialreference": "PROJCS[\"CH1903 / LV03\",GEOGCS[\"CH1903\",DATUM[\"CH1903\",SPHEROID[\"Bessel 1841\",6377397.155,299.1528128,AUTHORITY[\"EPSG\",\"7004\"]],TOWGS84[674.4,15.1,405.3,0,0,0,0],AUTHORITY[\"EPSG\",\"6149\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4149\"]],PROJECTION[\"Hotine_Oblique_Mercator_Azimuth_Center\"],PARAMETER[\"latitude_of_center\",46.95240555555556],PARAMETER[\"longitude_of_center\",7.439583333333333],PARAMETER[\"azimuth\",90],PARAMETER[\"rectified_grid_angle\",90],PARAMETER[\"scale_factor\",1],PARAMETER[\"false_easting\",600000],PARAMETER[\"false_northing\",200000],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],AXIS[\"Y\",EAST],AXIS[\"X\",NORTH],AUTHORITY[\"EPSG\",\"21781\"]]",
    "system_id": "PDAL"
  },
  "pdal_version": "1.0.0.b1 (git-version: 1dce22)"
}

Die Option --t_srs beschreibt das Koordinatensystem des zu erzeugenden Tileindexes. Mit --fast_boundary wird die Boundingbox nicht aus den Daten selbst eruiert, sondern es werden die Koordinaten aus den Metadaten verwenden. Und ja, es ist massiv schneller.

Anschliessend an die Erstellung des Tileindexes, kann mittels Pythonskript, einer For-Schleife und dreier PDAL-Befehlen das gewünschte Resultat berechnet werden:

#!/usr/bin/python
# -*- coding: utf-8 -*-
import os.path

from osgeo import ogr, osr
import os
import sys

ogr.UseExceptions()

S_SRS = "+proj=somerc +lat_0=46.952405555555555N +lon_0=7.439583333333333E +ellps=bessel +x_0=600000 +y_0=200000 +towgs84=674.374,15.056,405.346 +units=m +units=m +k_0=1 +nadgrids=./chenyx06/chenyx06a.gsb"
T_SRS = "+proj=somerc +lat_0=46.952405555555555N +lon_0=7.439583333333333E +ellps=bessel +x_0=2600000 +y_0=1200000 +towgs84=674.374,15.056,405.346 +units=m +k_0=1 +nadgrids=@null"

LAYERNAME = "tileindex"
TEMPDIR = "/tmp/"

TILEINDEX = "/home/stefan/tmp/lidar/tileindex.gpkg"
OUTDIR = "/home/stefan/tmp/"

BUFFER = 2
SCALE = 0.01

gpkg = ogr.Open(TILEINDEX)
lyr = gpkg.GetLayerByName(LAYERNAME)

for feat in lyr:
    cmd = "rm " + os.path.join(TEMPDIR, "*.las")
    os.system(cmd)

    cmd = "rm " + os.path.join(TEMPDIR, "*.laz")
    os.system(cmd)

    filename = feat.GetField("location")
    print "*** " + os.path.basename(filename) + " ***"

    env = feat.GetGeometryRef().GetEnvelope()
    min_x = int(env[0] + 0.001)
    min_y = int(env[2] + 0.001)
    max_x = int(env[1] + 0.001)
    max_y = int(env[3] + 0.001)

    # Create new file name.
    filename_lv95 = "LAS_" + str(min_x/1000 + 2000) + "_" + str(min_y/1000 + 1000) + ".laz"
    filename_lv95 = os.path.join(OUTDIR, filename_lv95)

    # Get a slightly larger tile. Two meters buffer is enough. We crop afterwards.
    # Reason: 620'000 -> 2'620'000.65
    bounds = "(["+str(min_x-BUFFER)+", "+str(max_x+BUFFER)+"], ["+str(min_y-BUFFER)+", "+str(max_y+BUFFER)+"])"
    cmd = 'pdal tindex --merge ' + TILEINDEX + ' --lyr_name tileindex --bounds "' + str(bounds) + '" --t_srs EPSG:21781 ' + os.path.join(TEMPDIR, 'tmp.las')
    os.system(cmd)

    # Now change reference frame with ntv2.
    cmd = 'pdal translate --a_srs "'+S_SRS+'" --t_srs "'+T_SRS+'" -i ' + os.path.join(TEMPDIR, 'tmp.las') + ' -o ' + os.path.join(TEMPDIR, 'tmp_lv95.las')
    os.system(cmd)

    # Set better/nicer EPSG:2056. The ntv2 transformation lacks of datum name.
    # Crop to nice bbbox.
    bounds = "(["+str(min_x+2000000)+", "+str(max_x+2000000)+"], ["+str(min_y+1000000)+", "+str(max_y+1000000)+"])"
    cmd = 'pdal translate --a_srs EPSG:2056 --t_srs EPSG:2056 --writers.las.format="1" --bounds "' + bounds + '" -z -i ' + os.path.join(TEMPDIR, 'tmp_lv95.las') + ' -o ' + os.path.join(OUTDIR, filename_lv95)
    os.system(cmd)

Das Grundprinzip resp. -vorgehen steht bereits hier. Interessant sind bloss die drei PDAL-Aufrufe:

Zeilen 48 - 50: Es wird aus dem Tileindex eine etwas (BUFFER = 2 Meter) grössere Kachel ausgeschnitten. Es muss nur soviel mehr sein, dass wir anschliessend an die Transformation garantiert «schöne» LV95-Koordinaten ausschneiden können. Mit pdal tindex und der Option --merge können Daten, die in einem Tileindex vorliegen, zusammengefügt werden. Zusätzlich gibt es die Option --bounds mit der nur ein ganz bestimmtes Rechteck gemerged resp. ausgeschnitten werden kann. Leider - so wie ich es verstanden habe - werden jeweils zuerst sämtliche vom Rechteck betroffene Kacheln komplett zusammengefügt und erst anschliessend ausgeschnitten. Das schlägt sich einerseits in der Geschwindigkeit und andererseits im RAM-Verbrauch nieder. In Normalfall sind ja neun Kacheln betroffen, die zuerst zusammengefügt werden müssen. Das braucht circa 9 GB RAM.

Zeilen 53 - 54: Nach dem Zusammenfügen und Ausschneiden können die Daten mit dem NTv2-Grid transformiert werden. Dazu verwendet man den Befehl pdal translate.

Zeilen 58 - 59: Zu guter Letzt müssen die transformierten Daten auf die «schönen» Koordinaten zurechtgeschnitten werden. Zudem kann in diesem Schritt das Koordinatensystem in den Metadaten sauber gesetzt werden (--a_srs EPSG:2056 und --t_srs EPSG:2056). Sonst stehen da die hässlichen PROJ4-Strings der NTv2-Transformation drin. Für das Zuschneiden kann der Befehl pdal translate mit der Option --bounds verwendet werden.

Das Resultat sind jetzt 1'066 LiDAR-Kacheln mit «schönen» Boundingbox-Koordinaten in LV95.

Die ganze Rechnerei dauert aber ein wenig. Liegen die Daten lokal auf der SSD vor, dauert das Prozedere für eine Kachel circa 150 Sekunden. Mein Setup war aufgrund des Platzbedarfs leider ziemlich übel: Die Daten liegen auf einem NAS, das via WLAN an den Computer angebunden ist. Gerechnet wird in einer virtuellen Maschine, in der das NAS mit sshfs gemounted ist. So rechnete das fast 4 Tage vor sich hin. Also fast doppelt so lange.

Hätte man jedoch genügend RAM, könnte man den Prozess leicht parallelisieren. Man muss bloss das Skript x-mal anstossen und die For-Schleife dürfte nicht den gleichen Tileindex als Input haben.

Der Prozess selbst konnte leicht optimert werden, indem beim Zwischenschritt nicht mit der Option -c komprimiert wurde. Ebenfalls gewinnbringend wirkt sich der Einsatz von --bounds anstelle --polygon aus. Will man also bloss ein Rechteck ausscheiden und nicht ein beliebiges Polygon reicht --bounds allemal und pdal muss in diesem Fall keine teuren GEOS-Operationen verwenden.

Interlis leicht gemacht #2

Tue, 9 Jun 2015 00:00:00 +0000

Im letzten Beitrag habe ich gezeigt, wie man einfach und effizient mit einem Kommandozeilenbefehl und dem Java-Tool ili2pg aus INTERLIS-Modellen eine Datenbankstruktur anlegen kann.

Das Schöne an Java und an ili2pg ist, dass man diese Funktionalität jetzt auch in eigenen Java-Code und dementsprechend in einen eigenen Importprozess einbinden kann. Eventuell müssen ja vorgängig Daten bearbeiten werden oder nach dem Import müssen weitere Prozessierungen vorgenommen werden.

Wie das geht? Ganz einfach: Einzig die drei Jar-Dateien ili2c.jar, ili2pg.jar und postgresql-9.1-901.jdbc4.jar müssen im Klassenpfad sein. Mit einer IDE seiner/ihrer Wahl kein Problem. Das kann man sich sogar zusammenklicken.

Ein minimales Java-Programm zum Importieren einer ITF-Datei sieht wie folgt aus:

package org.catais.interlis;

import ch.ehi.ili2db.base.Ili2db;
import ch.ehi.ili2db.base.Ili2dbException;
import ch.ehi.ili2db.gui.Config;
import ch.ehi.ili2pg.converter.PostgisGeometryConverter;
import ch.ehi.sqlgen.generator_impl.jdbc.GeneratorPostgresql;


public class Ili2pgTest {

	public static void main(String[] args) {

        Config config = new Config();
        config.setDbdatabase("xanadu2");
        config.setDbhost("localhost");
        config.setDbport("5432");
        config.setDbusr("stefan");
        config.setDbpwd("ziegler12");
        config.setDbschema("test5");
        config.setModels("DM01AVCH24LV95D");
        config.setModeldir("/home/stefan/Downloads/");

        config.setGeometryConverter(PostgisGeometryConverter.class.getName());
        config.setDdlGenerator(GeneratorPostgresql.class.getName());
        config.setJdbcDriver("org.postgresql.Driver");

        config.setNameOptimization("topic");
        config.setMaxSqlNameLength("60");

        config.setDefaultSrsAuthority("EPSG");
        config.setDefaultSrsCode("2056");

        config.setXtffile("/home/stefan/Downloads/ch_lv95_254900.itf");

        String dburl = "jdbc:postgresql://" + config.getDbhost() + ":" + config.getDbport() + "/" + config.getDbdatabase();
        config.setDburl(dburl);

        try {
            Ili2db ili2pg = new Ili2db();
            ili2pg.runImport(config, "");
        } catch (Ili2dbException e) {
            e.printStackTrace();
        }
    }
}

Man benötigt lediglich zwei Klassen: eine Konfigurationsklasse Config und die eigentliche Importklasse Ili2db. Mittels der Konfigurationsklasse steuert man verschiedene Parameter und in welchen Datenbanktyp importiert werden soll. Dies ist nötig, um gewisse Unterschiede zwischen den Datenbanktypen abzufangen resp. anders zu behandeln.

Zeilen 1 - 22: Diese Zeilen sollten eigentlich selbsterklärend sein.

Zeilen 24 - 26: Hier wird der Konfigurationsklasse mitgeteilt, dass es sich bei der Datenbank um PostgreSQL/Postgis handelt. Dies hat Auswirkungen auf die Konvertierung der Geometrie und auf das Erstellen der SQL-Befehle.

Zeilen 28 - 29: Mit der Methode setNameOptimization("topic") werden die Datenbanktabellennamen zusammengesetzt aus Topic- und Klassennamen (verbunden mit einem Untertrich): topic_class. Mit der Methode setMaxSqlNameLength("60") wird die maximale Länge der SQL-Namen auf 60 Zeichen gesetzt. Das Setzen der maximalen Länge ist wichtig, da der Prozess sonst abbricht.

Zeilen 31 - 32: Wird was anderes als LV03 (EPSG:21781) importiert, muss das hier mittels EPSG-Code definiert werden.

Zeile 34: Hier wird die zu importierende Interlis-Datei angegeben.

Zeilen 36 - 37: ~~Warum das manuelle Zusammensetzen der Datenbankurl noch nötig ist, ist mir nicht ganz klar. Eigentlich kennt die Konfigurationsklasse bereits alle angaben, die dazu benötig werden.~~

Zeilen 40 - 41: Zu guter Letzt kann die Importklasse instanziiert werden und der Importprozess kann gestartet werden.

Falls keine Fehlermeldungen in der Konsole erscheinen, sollten die Daten erfolgreich importiert worden sein:

Interlis leicht gemacht #1

Sat, 9 May 2015 00:00:00 +0000

Im Kanton Solothurn wird gegenwärtig die AVGBS eingeführt. Die Gebäudeadressen sollen nicht von den einzelnen Nachführungsgeometern an das Grundbuch geliefert werden, sondern durch das Amt für Geoinformation. Die Daten der amtlichen Vermessung - aus denen die Lieferung erstellt wird - liegen wochenaktuell als Kopie zentral in einer PostgreSQL/PostGIS-Datenbank beim Amt für Geoinformation.

Das Datenmodell GB2AV (aka "Kleine Schnittstelle"), das die auszutauschenden Daten zwischen dem Grundbuch und der amtlichen Vermessung beschreibt, ist in INTERLIS 2.2 geschrieben. Uiuiui, INTERLIS 2… Vererbung und so. Noch nie wirklich was mit gemacht. Bisweilen immer nur INTERLIS 1. Anstatt nur Trockenübungen, ergibt sich hier und jetzt die Gelegenheit etwas Praktisches mit INTERLIS 2 zu machen. Wie kommen jetzt also die Gebäudeadressen aus unserer zentralen Datenbank ins Grundbuch? Oder anders gefragt: Wie erstelle ich diese INTERLIS 2-Transferdatei?

Das Erstellen der INTERLIS 2-Transferdatei besteht aus zwei wesentlichen Schritten: Datenumbau und Formatumbau. Zuerst müssen die Gebäudeadressen so umgebaut werden, damit sie dem AVGBS-Modell entsprechen. Das passiert in der Datenbank. Der zweite Schritt ist dann nur noch ein Export aus der Datenbank in die INTERLIS 2-Transferdatei. Also ein Formatumbau vom Datenbankformat in das INTERLIS 2 Austauschformat.

Der Datenumbau ist ein Umbau der Daten vom Modell der amtlichen Vermessung in das AVGBS-Modell in der Datenbank. Das leere AVGBS-Modell (also die verschiedenen Tabellen) in der Postgis-Datenbank erzeugt mir die Software ili2pg. Die Software wird zum jetzigen Zeitpunkt weiterentwickelt: Dokumentation (Programmoptionen, Abbildungsregeln von Klassen, Vererbungsstrategie), Umgang mit Kreisbogen.

Folgender Aufruf erzeugt ein Datenbankschema mit leeren Tabellen:

java -Xms128m -Xmx2048m -jar ili2pg.jar --schemaimport --dbhost localhost --dbport 5432 --dbdatabase xanadu --dbschema av_avgbs --dbusr stefan --dbpwd ziegler12 --models GB2AV --modeldir ./ --nameByTopic

--schemaimport: Es werden keine Daten importiert sondern lediglich leere Tabellen erzeugt.
--models: Das zu verwendende Interlismodell (oder mehrere Interlismodelle).
--modeldir: Verzeichnisse, wo die Interlismodelle liegen (oder Repository-URL).
--nameByTopic: Die Tabellen werden nach dem Schema Topicname_Klassenname erzeugt.

Aus dem objektorientierten Interlismodell wurden nach gewissen Regeln in der relationalen Datenbank Tabellen erzeugt. Das Verständnis für die Abbildung des Modelles in der Datenbank braucht vielleicht ein wenig Übung. Aber hat man das UML-Diagramm, das Interlismodell und die Tabellen in der Datenbank vor Augen, lernt man das relativ schnell.

Für den eigentlichen Datenumbau - also das Abfüllen der vorher erstellen, leeren Tabellen mit den in der Datenbank vorhandenen Daten der amtlichen Vermessung - verwende ich Kettle. Leider scheint das Projekt GeoKettle nicht mehr aktiv zu sein. Da bei diesem Datenumbau keine Geometrien umher geschoben werden müssen, kann man auch das "normale" Kettle verwenden. Exemplarisch eine Transformation:

In dieser Kettle-Transformation werden sämtliche Gebäude aus den Daten der amtlichen Vermessung in die Tabelle/Klasse Gebaeude des Topics Grundstuecksbeschrieb geschrieben. Der nötige Verschnitt "Gebäude - Liegenschaft" für die Association GrundstueckGebaeude (ebenfalls als Tabelle in der Datenbank abgebildet) wird in der Datenbank gerechnet. Analog wird der Datenumbau für die anderen Klassen und Strukturen gemacht.

Wenn jetzt alle benötigen Daten in die neuen Tabellen umgebaut wurden, kann der Formatumbau ausgelöst werden. Beim Formatumbau hilft mir wiederum die Software ili2pg:

java -jar ili2pg.jar --export --dbhost localhost --dbport 5432 --dbdatabase xanadu --dbschema av_avgbs --dbusr stefan --dbpwd ziegler12 --models GB2AV grundstuecksbeschrieb.xtf

Ein Verzeichnis, wo sich das Interlismodell befindet, muss man nicht mehr angeben, da das Modell in einer zusätzlichen Tabelle beim Schemaimport mit importiert wurde.

Das Ergebnis des Exportes ist eine INTERLIS 2-Transferdatei. Beim Überprüfen stellt man fest, dass die Daten aber zweimal vorhanden sind: einmal im Topic Grundstuecksbeschrieb und ein zweites Mal im Topic Mutationstabelle. Das Topic Mutationstabelle erbt sämtliche Klassen des Topics Grundstuecksbeschrieb. Beim Export weiss ili2pg nicht zu welchen Topic die Daten gehören und schreibt sie bei beiden. Dieses Verhalten muss in einer Weiterentwicklung geändert werden.

Dieses Vorgehen eignet sich auch hervorragend für die Umsetzung von minimalen Geodatenmodellen im Rahmen des GeoIG, wie Peter Staub in seinem Whitepaper eindrücklich zeigt.

QGIS Server: VRT vs. GeoPackage Raster

Thu, 25 Dec 2014 00:00:00 +0000

Seit kurzem unterstützt GDAL Geopackage Raster, was ziemlich cool ist. Jetzt man kann man z.B. sämtliche Orthofotos des Kantons Solothurn (1993 bis 2014) in eine 85 GB grosse SQLite-Datenbank packen.

Und weil mehr oder weniger gilt «Kann es GDAL, so kann es auch QGIS.», soll hier kurz die Performance von QGIS Server anhand eines Orthofoto-WMS verglichen werden. Momentan wird aus vielen einzelnen GeoTIFF-Dateien eine VRT-Datei erstellt und diese in QGIS geladen. Bis zum Massstab 1:20'000. Für kleinere Massstäbe wird ein 5m-Orthofoto verwendet. Ab diesem Massstab sieht man praktisch keinen Unterschied mehr zwischen Originalkacheln (12.5cm) und 5m-Orthofoto. Als Resampling-Methode wird «average» mit Faktor 2 verwendet. Insgesamt sind es drei VRT-Dateien sowie drei 5m-Orthofotos (für die Jahre 2012-2014).

Zum Vergleich werden zwei Varianten mit Geopackage herangezogen:

Pro Jahr eine Geopackage-Datei (zwischen 5 und 10 GB).
Eine einzige Geopackage-Datei mit sämtlichen Orthofotos (inkl. abgeleiteten Produkten, circa 85 GB)

Mit folgenden Befehlen und Parametern wurden die GPKG-Dateien erstellt:

gdal_translate --config OGR_SQLITE_SYNCHRONOUS OFF -co APPEND_SUBDATASET=YES -co RASTER_TABLE=ch.so.agi.orthofoto.2014.rgb -co TILE_FORMAT=PNG_JPEG -of GPKG /home/stefan/Geodaten/ch/so/kva/orthofoto/2014/rgb/12_5cm/ortho2014rgb.vrt /home/stefan/tmp/orthofoto.gpkg
gdaladdo --config OGR_SQLITE_SYNCHRONOUS OFF -oo TABLE=ch.so.agi.orthofoto.2014.rgb -r average /home/stefan/tmp/orthofoto.gpkg 2 4 8 16 32 64 128 256

Das Testsetup war gleich wie bei anderen QGIS Server Performance Tests.

Das Resultat sieht so aus:

Anscheinend ist es völlig egal, ob drei einzelne GPKG-Dateien oder eine sehr grosse GPKG-Datei verwendet wird. Der ganz leichte Geschwindigkeitsvorteil von VRT gegenüber GPKG lässt sich beliebig wiederholen. Interessant ist aber die Tatsache, dass bei den GPKG-Varianten beinahe kein average-Resampling notwendig ist/wäre (Geschwindigkeitsfaktor circa 2.5). Da sehen die gerenderten Bilder auch mit «nearest neighbour» ganz ordentlich aus. Ganz im Gegensatz dazu die VRT-Variante, die sichtbar an visueller Qualität verliert ohne average-Resampling.

Fun with GeoKettle Episode 2

Sat, 29 Nov 2014 00:00:00 +0000

Eigentlich geht es hier eher um PostGIS Raster als um GeoKettle. GeoKettle wird jedoch am Schluss noch für einen kleinen Arbeitsschritt verwendet. Darum sei der Titel erlaubt.

Der Kanton Solothurn hat dieses Jahr eine LiDAR-Befliegung über sein ganzes Kantonsgebiet durchführen lassen. Neben den Rohdaten wurden abgeleitete Produkte (z.B. DTM, DOM etc.) hergestellt. Als eine Plausibilitätskontrolle sollen die Fixpunkte der amtlichen Vermessung mit dem 50cm-DTM verglichen werden. Möglichkeiten wie man das machen kann, gibts viele. Ich habe mich für PostGIS Raster entschieden, um ein wenig Praxis darin zu bekommen.

Zuerst muss das DTM mit dem Befehl raster2pgsql in PostGIS importiert werden:

raster2pgsql -d -s 21781 -I -C -M -F -r /opt/Geodaten/ch/so/kva/hoehen/2014/dtm/*.tif -t 100x100 av_lidar_2014.dtm | psql -d rosebud2

Mit diesem Befehl werden sämtliche GeoTiff-Dateien im Verzeichnis /opt/Geodaten/ch/so/kva/hoehen/2014/dtm/ in die Tabelle dtm im Schema av_lidar_2014 importiert.

-d: Vorhandene Tabelle wird gelöscht und neu angelegt.
-s 21781: Den Daten wird das Koordinatensystem EPSG:21781 zugewiesen.
-I: Es wird ein Index für die Tabelle erzeugt.
-C: Verschiedene Constraints werden hinzugefügt.
-M: Nach dem Import wird ein vacuum analyze ausgeführt.
-F: Es wird eine Spalte mit dem Dateinamen in der Tabelle hinzugefügt.
-r: Weiterer Constraint.
-t: Die Grösse der Kacheln in welche die Ausgangsdaten geschnitten und in der Datenbank gespeichert werden. Die Grösse der Kacheln ist entscheidend für die Ausführungsdauer der Abfragen, die später gemacht werden. Für unseren Anwendungsfall ist es sinnvoll die Kachelgrösse eher klein zu wählen.

Das dauert je nach Datenmenge ein paar Minuten und braucht ordentlich Speicherplatz in der Datenbank (DTM und DOM, je 1066 km2):

Das wirklich Schöne an Postgis Raster ist, dass man völlig unkompliziert Vektor- und Rasterdaten gleichzeitig/gemeinsam abfragen kann. Uns interessiert die Höhe aus dem DTM an der Stelle wo ein Fixpunkt der amtlichen Vermessung vorhanden ist:

SELECT p.ogc_fid, p.nummer, p.kategorie, p.geometrie, ST_X(p.geometrie) as x, ST_Y(p.geometrie) as y,
   p.hoehe as h_lfp, ST_Value(r.rast, p.geometrie) as h_dtm,
   (ST_Value(r.rast, p.geometrie) - p.hoehe) as diff, p.bfsnr
FROM av_avwmsde_t.cppt as p, av_lidar_2014.dtm as r
WHERE ST_Intersects(r.rast, p.geometrie)
AND p.hoehe IS NOT NULL
AND p.kategorie IN ('LFP1', 'LFP2', 'LFP3');

Die ganze Magie besteht aus zwei Funktionen:

ST_Value(r.rast, p.geometrie): Diese Funktion liefert für eine Koordinate (p.geometrie) den Zellenwert des Rasters (r.rast) zurück.
ST_Intersects(r.rast, p.geometrie): Funktioniert grundsätzlich gleich wie das Vektorpendant.

Alles andere ist Beigemüse.

Das Resultat wird als Shapedatei und als Exceldatei abgespeichert. Dafür verwenden wir GeoKettle. Die GeoKettle-Transformation sieht dann völlig unspektakulär so aus:

Und das Resultat? Unter Berücksichtigung der Randbedingungen (50cm-DTM, Fixpunkt teilweise unter Schacht etc.) stimmen die resultierenden Differenzen positiv:

Klar gibt es grössere Differenzen (Fixpunkt auf Gebäude oder Kunstbaute, Kirchenspitze etc.). Diese sind aber praktisch alle erklärbar (und wären auch vorgängig filterbar). Ebenso konnten einige wenige Höhenfehler in den Daten der amtlichen Vermessung gefunden werden.

Bezugsrahmenwechsel: Transformation von Rasterdaten #1

Sat, 15 Nov 2014 00:00:00 +0000

Mit dem NTv2-CHENyx06-Datensatz lassen sich beliebige Datenformate (Vektor und Raster) transformieren. So unterstützt z.B. QGIS seit der Version 2.2 diese Möglichkeit der Datumstransformation. Die Genauigkeit dieser Methode ist im Kanton Solothurn nur marginal schlechter als die strenge Transformation mit dem FINELTRA-Algorithmus. Für die allermeisten Darstellungen am Bildschirm oder für die Transformation von Rasterdaten reicht die Genauigkeit völlig aus.

Ein NTv2-Datensatz kann in verschiedenen WMS-Servern auch dazu verwendet werden Transformationen on-the-fly durchzuführen (z.B. QGIS Server, GeoServer). Will man aber trotzdem die Rasterdaten nicht nur on-the-fly transformieren, sondern sie auch physisch vorliegen haben, kann man das mit einem kleinen Skript und GDAL machen. Oftmals reicht für nicht-hochauflösende Rasterdaten z.B. eine Translation um +2 Mio / +1 Mio. Eine andere Variante ist die strenge Transformation der Metadaten («Worldfile»). Für hochauflösende Rasterdaten funktioniert das nur noch bedingt.

Viele der Rasterdaten liegen in einem nahtlosen Mosaik vor (z.B. Orthofotos). Nach der Transformation sollen weiterhin keine Lücken und Überlappungen zwischen den einzelnen Kacheln sichtbar sein. Um das zu erreichen wird zuerst eine Shapedatei mit den einzelnen Kacheln als Polygon erstellt. Im Kanton Solothurn sind das 1km2-Kacheln:

Dieser sogenannte Tileindex wird mit gdaltindex erstellt:

gdaltindex -write_absolute_path ortho2014.shp *.tif

Dabei werden sämtliche Tiff-Dateien in dem Verzeichnis berücksichtigt. Mit der Option -write_absolute_path wird im Attribut location in der Shapedatei ortho2014.shp der absolute Pfad der Tiff-Dateien gespeichert.

Jetzt ist es Zeit für das kleine Pythonskript, dass schlussendlich nichts Anderes macht als für jede dieser Kacheln ein gdal_warp-Befehl mit passenden Parameter zusammenzustellen und auszuführen:

#!/usr/bin/python
# -*- coding: utf-8 -*-

from osgeo import ogr, osr
import os

S_SRS = "+proj=somerc +lat_0=46.952405555555555N +lon_0=7.439583333333333E +ellps=bessel +x_0=600000 +y_0=200000 +towgs84=674.374,15.056,405.346 +units=m +units=m +k_0=1 +nadgrids=./chenyx06/chenyx06a.gsb"
T_SRS = "+proj=somerc +lat_0=46.952405555555555N +lon_0=7.439583333333333E +ellps=bessel +x_0=2600000 +y_0=1200000 +towgs84=674.374,15.056,405.346 +units=m +k_0=1 +nadgrids=@null"

ogr.UseExceptions()

shp = ogr.Open("mosaic/ortho2014.shp")
layer = shp.GetLayer(0)

for feature in layer:
    infileName = feature.GetField('location')
    geom = feature.GetGeometryRef()
    env = geom.GetEnvelope()

    minX = int(env[0] + 0.001 + 2000000)
    minY = int(env[2] + 0.001 + 1000000)
    maxX = int(env[1] + 0.001 + 2000000)
    maxY = int(env[3] + 0.001 + 1000000)

    outfileName = str(minX)[0:4] + str(minY)[0:4] + "_12_5cm.tif"
    outfileName = os.path.join(os.path.dirname(infileName), "lv95", outfileName)

    cmd = "/usr/local/gdal/gdal-dev/bin/gdalwarp -s_srs \"" + S_SRS + "\" -t_srs \"" + T_SRS + "\" -te "  + str(minX) + " " +  str(minY) + " " +  str(maxX) + " " +  str(maxY)
    cmd += " -tr 0.125 0.125 -wo NUM_THREADS=ALL_CPUS -co 'PHOTOMETRIC=RGB' -co 'TILED=YES' -co 'PROFILE=GeoTIFF'"
    cmd += " -co 'INTERLEAVE=PIXEL' -co 'COMPRESS=DEFLATE' -co 'BLOCKXSIZE=512' -co 'BLOCKYSIZE=512'"
    vrt = "/opt/Geodaten/ch/so/kva/orthofoto/2014/rgb/12_5cm/ortho2014rgb.vrt"
    cmd += " -r bilinear " + vrt + " " + outfileName
    os.system(cmd)

    cmd = "/usr/local/gdal/gdal-dev/bin/gdal_edit.py -a_srs EPSG:2056 " + outfileName
    os.system(cmd)

    cmd = "/usr/local/gdal/gdal-dev/bin/gdaladdo -r nearest --config COMPRESS_OVERVIEW DEFLATE --config GDAL_TIFF_OVR_BLOCKSIZE 512 " + outfileName + " 2 4 8 16 32 64 128"
    os.system(cmd)

Zeilen 4 - 5: Benötigte Module werden geladen.

Zeilen 7 - 8: Es ist möglich neben EPSG-Codes für Transformation mit GDAL auch eigene proj4-Definitionen als Parameter zur übergeben. Bei der Verwendung von NTv2-Gittern ist das ein bisschen hakelig. Es gibt viele Varianten. Viele davon führen zu falschen Resultaten, zwei davon führen zu richtigen Resultaten. Abhängig davon welcher NTv2-Datensatz (chenyx06a.gsb oder chenyx06etrs.gsb) verwendet wird. Langer Rede kurzer Sinn: Das hier ist eine Kombination, die korrekt transformiert.

Zeile 12 - 13: Die Shapedatei mit der Kacheleinteilung wird geöffnet und ein Layer wird angelegt.

Zeilen 15 -16: Die For-Schleife bearbeitet jede Kachel einzeln. Zuerst wird das Attribut location ausgelesen. Es beinhaltet den kompletten absoluten Pfad der einzelnen Tiff-Datei. Davon verwenden wir aber später nur das Verzeichnis, da wir in ein Unterverzeichnis die resultierenden Tiff-Dateien speichern wollen.

Zeilen 17 - 18: Die Geometrie der Kachel wird ausgelesen und die Envelope (Tupel mit den min/max Koordinatenwerten) berechnet.

Zeilen 20 - 23: Aus der Envelope lesen wir die minimalen X- resp. Y-Werte. Die resultierenden Kacheln sollen wie die Ausgangskacheln «schöne» Kilometerkacheln sein. Dazu wird einfach 2 Mio. resp. 1 Mio dazugerechnet. Weil der int-Befehl abrundet (?), muss den Koordinatenwerten ein kleiner Wert dazu addiert werden, um keine falschen Ganzzahleswerte zu bekommen.

Zeilen 25 - 26: Aus den Koordinatenwerten wird der Dateinnamen der neuen Kacheln bestimmt.

Zeilen 28 - 33: Hier geschieht die Zauberei. Als Ausgangsdatei wird nicht die einzelne Kacheln verwendet sondern immer die vrt-Datei (Diese muss u.U. vorgängig noch erstellt werden). GDAL sieht jetzt nur eine einzelne, flächendeckende Rasterdatei. Somit muss nur noch der Ausschnitt gewählt werden, der aus dieser einzelnen Rasterdatei ausgeschnitten werden soll. Dieser Ausschnitt wurde ja bereits in den Zeilen 20 - 23 ermittelt. Das Resultat wird wiederum in einer Tiff-Datei gespeichert.

Zeilen 35 - 39: Anschliessend werden in der neuen GeoTiff-Datei noch korrekte Metadaten zum Koordinatensystem gespeichert und es werden interne Overview gerechnet.

Das Resultat sind einzelne Orthofotokacheln, die sich weder überlappen noch sind Lücken zwischen den Kacheln vorhanden. Die Übergänge sind wie im Ausgangsmaterial nicht sichtbar. Einzig am Perimeterrand sind kleine schwarze Ränder sichtbar. Diese entstehen weil im Ausgangsmaterial in diesem Bereich keine Daten vorhanden sind. Liegt das Ausgangsmaterial im Bezugsrahmen LV95 vor und wird in den Bezugsrahmen LV03 transformiert, dürfte dieses Phänomen nicht auftreten.

Der Transformationsprozess dauerte für 384 Kacheln circa 1h 45m. Ein Qualitätsverlust aufgrund des Resamplings ist nicht feststellbar.

Karten rendern mit PyQGIS

Sun, 19 Oct 2014 00:00:00 +0000

An der FOSSGIS 2013 wurde von Andreas Schmid gezeigt wie mit QGIS der Basisplan der amtlichen Vermessung erstellt werden kann. Der ganze Systemaufbau ist nicht gerade trivial weil für das Rendern des Kartenbildes QGIS Server eingesetzt wird. Dies setzt z.B. Apache 2 und ein FCGI-Modul voraus. Das eigentliche Ziel der Übung ist aber nicht einen WMS-Dienst anzubieten, sondern aus Vektordaten ein Rasterkartenwerk zu erstellen.

Weil bei Projektstart einige Funktionen in den Python-Bindings von QGIS (PyQGIS) fehlten, konnte nicht dieser Weg gewählt werden, sondern es wurde der Umweg über einen WMS-Dienst als Kartenrenderer gewählt. Die fehlenden Funktionen sind jetzt alle vorhanden und es steht einer Vereinfachung des Herstellungsprozesses nichts mehr im Wege.

Vieles zu PyQGIS steht im Kochbuch. Einige Details fehlen aber. Darum folgt nachstehend ein komplettes Beispiel, das zeigt wie man mit einem vorbereiteten QGIS-Projekt die Rasterkarten anhand einer Blatteinteilung erstellen kann ohne QGIS manuell starten zu müssen.

Das vorbereitete QGIS-Projekt ist simpel. Es besteht nur aus den Gemeindegrenzen des Kantons Solothurn:

Als erstes müssen zwei Dateien erstellt werden:

basisplan.sh
basisplan.py

basisplan.sh macht nichts weiter als den Pfad zu den QGIS-Bibliotheken zu setzen und anschliessend die Pythondatei basisplan.py aufzurufen:

#!/bin/bash
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/stefan/Apps/qgis_master/lib
export PYTHONPATH=$PYTHONPATH:/home/stefan/Apps/qgis_master/share/qgis/python

python basisplan.py

basisplan.py enthält den interessanteren Teil:

# -*- coding: utf-8 -*-
from PyQt4.QtCore import *
from PyQt4.QtGui import *
from qgis.core import *
from qgis.gui import *

import os
import sys

# Aktuelles Verzeichnis
current_dir = os.path.dirname(os.path.realpath(__file__))

# QGIS initialisieren
app = QApplication(sys.argv)
QgsApplication.setPrefixPath("/home/stefan/Apps/qgis_master", True)
QgsApplication.initQgis()

# QGIS-Projekt laden
QgsProject.instance().setFileName(os.path.join(current_dir,  "bpav5000sw.qgs"))
if not QgsProject.instance().read():
    sys.exit("QGIS-Projekt nicht gefunden.")

# List mit sämtlichen Layer im QGIS-Projekt
lst = []
layerTreeRoot = QgsProject.instance().layerTreeRoot()
for id in layerTreeRoot.findLayerIds():
    node = layerTreeRoot.findLayer(id)
    lst.append(id)

# Layer mit Blatteinteilung laden
layer_name =  "blatteinteilung"
vlayer = QgsVectorLayer(os.path.join(current_dir, "basisplan.gpkg") + "|layername=blatteinteilung", "Blatteinteilung", "ogr")
if not vlayer.isValid():
    sys.exit("Blatteinteilung konnte nicht geladen werden.")

# Rasterkarten erstellen
iter = vlayer.getFeatures()
for feature in iter:
    idx = vlayer.fieldNameIndex('nummer')
    nummer = feature.attributes()[idx].toString()

    # Ausschnitt und Grösse der Karte berechnen
    dpi = 508
    scale = 5000

    geom = feature.geometry()
    p1 = geom.vertexAt(0)
    p2 = geom.vertexAt(2)

    rect = QgsRectangle(p1, p2)

    dx = rect.width()
    dy = rect.height()

    width = (dx/scale) / 0.0254 * dpi
    height = (dy/scale) / 0.0254 * dpi

    # Einstellungen für Kartenrenderer
    mapSettings = QgsMapSettings()
    mapSettings.setMapUnits(0)
    mapSettings.setExtent(rect)
    mapSettings.setOutputDpi(dpi)
    mapSettings.setOutputSize(QSize(width, height))
    mapSettings.setLayers(lst)
    mapSettings.setFlags(QgsMapSettings.DrawLabeling)

    # Karte zeichnen
    img = QImage(QSize(width, height), QImage.Format_Mono)
    img.setDotsPerMeterX(dpi / 25.4 * 1000)
    img.setDotsPerMeterY(dpi / 25.4 * 1000)

    p = QPainter()
    p.begin(img)

    mapRenderer = QgsMapRendererCustomPainterJob(mapSettings, p)
    mapRenderer.start()
    mapRenderer.waitForFinished()

    p.end()

    img.save(os.path.join("/tmp", "bpav" + str(scale) + "_" + str(nummer) + str(".png")), "png")

# Layer mit Blatteinteilung löschen
del vlayer

# QGIS schliessen
QgsApplication.exitQgis()

Zeilen 2 - 8: Module werden geladen.

Zeile 11: Bei mir funktionieren verschiedene QGIS-Methoden nicht korrekt mit relativen Pfaden, wenn diese direkt reingeschrieben werden (z.B. "./bpav5000sw.qgs" für das zu ladende QGIS-Projekt). Wird aber zuerst das aktuelle Verzeichnis (in dem das Skript läuft) ermittelt und dieses für die relativen Pfade verwendet, funktionierts.

Zeilen 14 - 16: Zuerst wird eine Qt-Applikation und anschliessend QGIS initialisiert. Der Pfad in Zeile 15 zeigt auf die lokale QGIS-Installation.

Zeilen 19 - 21: Hier wird das vorbereitete QGIS-Projekt geladen. Falls es nicht gefunden wird, ist der Rückgabewert der Methode QgsProject.instance().read() False.

Zeilen 24 - 28: Für das Rendern der Karte müssen zuerst sämtliche Layer des QGIS-Projekts in eine Liste geschrieben werden. Sollen nur die sichtbaren Layer gerendert werden, kann man diese mit node.isVisible() ermitteln.

Zeilen 31 - 34: Die Blatteinteilung wird als QGIS-Layer zusätzlich geladen.

Zeilen 37ff: Für jedes Feature des vorhin geladenen Layers mit der Blatteinteilung wird nun die Rasterkarte erstellt.

Zeilen 42 - 56: Aufgrund des Massstabes, Auflösung (DPI) und Ausdehnung des Kartenblattes wird die Grösse (Pixelanzahl) und die Boundingbox der zu erstellenden Rasterkarte berechnet.

Zeilen 59 - 65: Die oben ermittelnden Werte werden in einer Settings-Klasse gespeichert, die später der Kartenrenderer verwenden wird. Interessant ist die Zeile 65. Hier können verschiedene Flags angegeben werden. Mit QgsMapSettings.DrawLabeling wird dem Renderer mitgeteilt, dass die Labels gezeichnet werden sollen. Ohne das Flag QgsMapSettings.Antialiasing werden die Karten ohne Antialiasing gezeichnet. Dies ist insbesondere für schwarz-weisse Rasterkarten sinnvoll, da dann 1-Bit-Karten möglich sind. Die Grösse ist um ein vielfaches kleiner als bei RGB-Bildern und die Karte lässt sich mit jeder beliebigen Farbe einfärben.

Mehrere Flags werden mittels Pipe-Zeichen aneinandergereiht, z.B. mit Antialiasing: mapSettings.setFlags(QgsMapSettings.Antialiasing | QgsMapSettings.DrawLabeling).

Zeilen 68 - 81: Als nächstes muss ein QImage-Objekt mit der passenden Grösse, Format und Auflösung erstellt werden. Für unseren Fall eignet sich das Format QImage.Format_Mono bestens, denn es erstellt das gewünschte 1-Bit-Rasterbild. Für Farbbilder eignet sich z.B. QImage.Format_RGB32. Alle möglichen Formate sind hier beschrieben.

Der Kartenrenderer wird auf Zeile 76 gestartet. Die darauffolgende Zeile ist wichtig, da sonst - ohne auf das Ende zu warten - das unfertige Bild physisch auf die Festplatte geschrieben wird.

Nachdem das Bild fertig gerendert ist, wird es an einem gewünschten Ort gespeichert.

Zeile 84: Ohne das explizite Löschen des zusätzlich geladenen Layers verabschiedet sich mein Skript mit einem Segmentation fault.

Zeile 87: QGIS wird geschlossen und alle verwendeten Layer werden gelöscht (siehe Kommentar zu Zeile 84).

Die Renderzeit eines Kartenblattes ist abhängig von der Anzahl der Layer, der Komplexität der Symbologie und der Grösse (Pixelanzahl). Am schnellsten sind schwarz-weisse Karten, die ohne Antialiasing gezeichnet werden. Farbige Karten sind ebenfalls schneller ohne als mit Antialiasing.

Die hier vorgestellte Lösung kann den Herstellungsprozess des Basisplanes der amtlichen Vermessung vereinfachen, da kein WMS-Dienst verwendet wird. Zudem eignet sich diese Lösung wegen der mächtigen Symbologiemöglichkeiten und Flexibilität von QGIS ebenfalls für das Herstellen von Rasterkarten jeglicher Art.

Das QGIS-Beispielprojekt inkl. Shell- und Pythonskript gibt es hier.

NDVI Orthofotos

Mon, 22 Sep 2014 00:00:00 +0000

Der Kanton Solothurn lässt jedes Jahr ein Drittel seiner Fläche neu befliegen und lässt daraus neue Orthofotos erstellen. Als Endprodukt werden GeoTIFF mit den vier Kanälen Rot, Grün, Blau und nahes Infrarot ausgeliefert. Daraus werden anschliessend zwei abgeleitete Produkte erstellt: ein RGB-Orthofoto und ein FCIR-Orthofoto. "FCIR" steht für "false-colour infrared" und besteht aus den Kanälen nahes Infrarot, Rot und Grün und sieht dann in etwa so aus:

Hilfreich kann diese Kombination zum Beispiel für Umweltanalysen sein. Unser Fokus lag jedoch in der besseren Identifizierbarkeit von Abgrenzungen zwischen Objekten unterschiedlicher Bodenbeschaffenheit (z.B. Wasser - nicht Wasser oder Strasse - Acker/Wiese).

Auf dem Mapbox-Blog sind verschiedene, interessante Beiträge was man mit Satellitenbildern und Orthofotos und den verschiedenen Kanälen anstellen kann. So auch ein Beitrag zu NDVI. Sieht cool aus, will ich auch. Netterweise stehen auch gleich die GDAL- und ImageMagick-Befehle im Blog. Daraus lässt sich leicht für unsere Daten ein Skript erstellen:

#!/bin/bash

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/gdal/gdal-dev/lib
export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.6/dist-packages/GDAL-2.0.0-py2.6-linux-x86_64.egg

for FILE in /opt/Geodaten/ch/so/kva/orthofoto/2014/cir/12_5cm/*.tif
do
  BASENAME=$(basename $FILE .tif)
  OUTFILE=/home/stefan/Geodaten/NDVI_2014/${BASENAME}.tif
  OUTFILE_PREP=/home/stefan/Geodaten/NDVI_2014/${BASENAME}_prep.tif
  OUTFILE_TMP=/home/stefan/Geodaten/NDVI_2014/${BASENAME}_tmp.tif

  echo "Processing: ${BASENAME}.tif"

  cp $FILE $OUTFILE
  listgeo -tfw $OUTFILE
  rm $OUTFILE

  convert $FILE $OUTFILE_PREP

  convert -monitor $OUTFILE_PREP -fx '(u.r - u.g) / (u.r + u.g + 0.001)' $OUTFILE_TMP

  /usr/local/gdal/gdal-dev/bin/gdal_edit.py -a_srs EPSG:21781 $OUTFILE_TMP
  /usr/local/gdal/gdal-dev/bin/gdal_translate -co TILED=YES -co COMPRESS=LZW $OUTFILE_TMP $OUTFILE
  /usr/local/gdal/gdal-dev/bin/gdaladdo -r cubic --config COMPRESS_OVERVIEW LZW $OUTFILE 2 4 8 16 32 64 128

  rm $OUTFILE_PREP
  rm $OUTFILE_TMP
done

Zeilen 3 - 4: Sind nicht relevant. Die Zeilen werden gebraucht, um dem Skript mitzuteilen, dass eine bestimmte GDAL-Version verwendet werden soll.

Zeile 6: Hier beginnt die for-Schleife, die jede einzelne Orthofoto-Kachel verarbeitet. Da schlussendlich nur die Kanäle Rot und nahes Infrarot interessieren, kann das FCIR-Orthofoto für die Berechnung verwendet werden.

Zeilen 8 - 11: Parameter für die verschiedenen (temporären) Dateien.

Zeilen 15 - 17: Quick 'n' Dirty wird hier ein World-File erstellt. Da mit den ImageMagick-Befehlen die Georeferenzierung verloren geht, muss diese zum Schluss wiederhergestellt werden. Dafür brauchts das World-File.

Zeile 19: Der später verwendetete -fx Operator funktioniert am besten mit Dateien, die von ImageMagick selbst erstellt wurden. Aus diesem Grund wird das GeoTIFF mit dem convert Befehl kopiert.

Zeile 21: Hier passiert die Magie: Mit dem -fx Operator wird der NDVI-Wert für jedes Pixel berechnet. Falls sowohl der nahe Infrarot (u.r) und rote (u.g) Kanal einen Pixelwert von 0 aufweisen, ist der Nenner ebenfalls 0 und damit der Bruch nicht mehr definiert. Aus diesem Grund wird ein kleiner Wert beim Nenner hinzuaddiert. Dies dürfte auf das Resultat keinen Einfluss haben. Schöner wäre es natürlich wenn man das ganze mit einem if-else-Konstrukt behandeln würde.

Zeilen 23 - 25: Anschliessend wird die Georeferenzierung wiederhergestellt und die internen Overviews gerechnet.

Zeilen 27 - 29: Zu guter Letzt werden noch die temporären Dateien, die nicht mehr benötigt werden, gelöscht.

Die ganze Berechnung dauert für circa 450 1km2 Kacheln (8000 x 8000 Pixel) rund 10 Stunden. Der Flaschenhals ist der -fx Operator obwohl dieser sämtliche Kerne des Prozessors verwendet:

Das Resultat dieser CPU-Orgie sieht dann wie folgt aus:

Soweit so gut. Nicht wirklich spektakulär aber in etwa das was man aufgrund des Beispiels im Mapbox-Blog erwarten durfte. Augenfällig ist aber die klare Unterscheidung zwischen Strassen (keine Vegetation) und der landwirtschaftlich genutzten Flächen oder des Waldes. Für gewisse Fragestellungen (z.B. Periodische Nachführung, Erfassung von Waldstrassen) in der amtlichen Vermessung kann man sich das jetzt zunutze machen. Unter gewissen Umständen ist im normalen RGB-Orthofoto und FCIR-Orthofoto kein Strassenverlauf mehr zu erkennen. Auf dem NDVI-Bild ist ein Verlauf aber immer noch (mehr oder weniger gut) sichtbar:

~~Die Beispiele zum Vergleichen gibts hier, hier und hier.~~

Pimp your Orthophoto

Mon, 22 Sep 2014 00:00:00 +0000

Werden Luftbilder zu unterschiedlichen Zeitpunkten geflogen, sind die daraus resultierenden Orthofotos farblich unterschiedlich. Was aber nicht mehr nachzuvollziehen ist, sind Unterschiede wie hier in den FCIR-Orthofotos der Jahre 2012 und 2013:

Die Orthofotos auf der linken Seite (2012) wurden zwar bei voller Belaubung geflogen jedoch sind die Farbunterschiede zu gross und die Orthofotos auf der rechten Seite (2013) scheinen einen Blaustich zu haben. Was machen?

Die Analyse der Bildhistogramme zeigt, dass insbesondere der rote Kanal (resp. das nahe Infrarot) sehr unterschiedlich ist und einen Shift zwischen den beiden Jahren aufweist.

Hat man nur ein Bild kann man mit Gimp (o.ä.) dran schrauben bis es passt. Hat man aber 467 Kacheln macht das weniger Spass. Mit ImageMagick geht das aber wunderbar:

convert -channel R -gamma 2 $INPUT $OUTPUT

Mit diesem Befehl wird eine Gammakorrektur im roten Kanal durchgeführt. Mit ein wenig probieren, findet man schnell einen passenden Wert. Das Resultat sieht so aus:

Der Blauschleier ist nicht mehr so extrem wie vorher. Trotzdem könnte man die Farben sicher noch besser anpassen. ~~Den WMS mit den angepassten Orthofotos gibts hier.~~

GeoAdmin API Plugin für QGIS

Sun, 24 Aug 2014 00:00:00 +0000

Swisstopo stellt eine Programmierschnittstelle (API) zur Verfügung mit der man Webseiten mit Swisstopo-Karten verschönern kann. Diese API ist sauber dokumentiert und neben der eigentlichen Javascript-API stehen ebenfalls auch REST-Schnittstellen online.

Interessant ist vor allem der Suchdienst, mit dem man neben Adressen und administrativen Einheiten (Kantone, Bezirke) auch Grundstücke suchen kann. Folgender Request liefert Informationen zum Grundstück Nr. 2585 in Solothurn:

http://api3.geo.admin.ch/rest/services/api/SearchServer?searchText=Solothurn%202585&origins=parcel&type=locations

Leider darf die Adresssuche nur von der Bundesverwaltung gebraucht werden. Sucht man nach einer bestimmten Adressen, wird zwar eine Antwort geliefert, diese beinhaltet aber keine Georeferenzierung (kein geom_st_box2d Attribut):

http://api3.geo.admin.ch/rest/services/api/SearchServer?searchText=Solothurn%20Werkhofstrasse%2017&origins=address&type=locations

Ebenfalls gesucht werden können Layer, die in der GeoAdmin API zur Verfügung stehen. Dieser Request liefert Layer zur Thematik Fixpunkte:

http://api3.geo.admin.ch/rest/services/api/SearchServer?searchText=Fixpunkte&type=layers

Zu guter Letzt lassen sich mit dem Suchdienst auch Features suchen, z.B. den Fixpunkt 11277510:

http://api3.geo.admin.ch/rest/services/api/SearchServer?features=ch.swisstopo.fixpunkte-lfp1&type=featuresearch&searchText=11277510

Nicht alle Layer der GeoAdmin API sind durchsuchbar.

Mit diesen REST-Schnittstellen kann ein QGIS-Plugin erstellt werden, das ähnliche Funktionen bietet, wie die Suchfunktion auf map.geo.admin.ch. Dh. Lokalisationen können gesucht werden und es kann an den ausgewählten Ort gezoomt werden. Angebotene Layer können gesucht und in QGIS hinzugefügt werden. Features von durchsuchbaren Layer können gesucht werden und ein Popup-Fenster erscheint, falls etwas ausgewählt wurde.

Screenshots:

Die Layersuche resp. das anschliessende Hinzufügen des Layers in QGIS ist noch unbefriedigend gelöst. In den Plugineinstellungen lässt sich wählen, ob der Layer als WMS oder WMTS hinzugefügt werden soll:

Einige der Layer sind nur als WMS, andere nur als WMTS vorhanden. So wird zuerst also versucht den Layer mit dem Provider hinzuzufügen, den man in den Einstellungen gewählt hat. Klappt das nicht, wird der andere Provider gewählt.

Das führt auch gleich zum Thema/Problem «Terms of use». Der WMTS-Dienst darf gemäss Webseite nicht in Desktop-Applikationen verwendet werden: "Nur für Websites, kein Desktop-Zugriff". Wird beim Anfordern der Kachel kein Referer mitgeschickt, verweigert der Server die Auslieferung der Kachel. Zwar kann man sich mit einer Domain gratis registrieren aber die Desktop-Applikation hat halt keine Domain.

Bleibt der WMS-Dienst: Gewisse Layer sind nicht frei verfügbar (z.B. Pixelkarten) und nicht im «normalen» BGDI-WMS enthalten. Für diese Dienste gibt es einen zweiten WMS-Dienst. 5000 Megapixel/Jahr sind gratis. Leider lässt sich mit keiner REST-Schnittstelle exakt eruieren, ob ein Layer als WMS und/oder als WMTS verfügbar ist. So meint das Plugin, dass das Orthofoto (SWISSIMAGE) nur als WMTS-Layer verfügbar ist, da in den Metainformation beim Layer ch.swisstopo.swissimage das Attribut wmsUrlResource fehlt. Login und Passwort für den geschützten WMS lassen sich in den Plugineinstellungen speichern. Es macht den Anschein, dass entweder mein Plugin, QGIS oder der passwortgeschützte WMS von Zeit zu Zeit Probleme beim Verbinden verursacht. Erscheint in QGIS die Fehlermeldung Error: Layer is not valid. lohnt sich ein erneuter Versuch (irgend ein «Redirect loop detected»-Problem).

Das Plugin GeoAdmin Search liegt im QGIS Plugin Repository. Quellcode gibts hier: https://bitbucket.org/edigonzales/qgis_geoadminsearch.

Vom Webdienst zum Bulkdownload

Sun, 8 Jun 2014 00:00:00 +0000

Chris Herwig erkennt drei Hauptgruppen von Open Government Daten Benutzer:

Gelegenheitsuser
Benutzer, die mittels einer API Zugriff auf die Daten wünschen.
«Bulk»-Datenuser: Diese User wollen grosse Datenmengen (und auch komplette Datensätze) herunterladen.

Ein möglicher technischer Umsetzungsansatz ist das Verbinden von Gruppe 2 und 3. Der Webdienst von Gruppe 2 wird verwendet, um die vorgefertigten Datensätze für Gruppe 3 herzustellen.

Anlass für das Rumspielen war ebenfalls das neue Geodatenformat Geopackage, das seit Version 1.11 in GDAL/OGR unterstützt wird. Da QGIS ebenfalls GDAL/OGR einsetzt, wird das Datenformat auch in QGIS unterstützt.

Als Webdienst wird der MOpublic-WFS verwendet. Das Herstellen der einzelnen Datensätze/Geopackages übernimmt ein kleines Pythonskript:

#!/usr/bin/env python
# -*- coding: UTF-8 -*-

import os
import osgeo.gdal
from osgeo import ogr


# VARS
GPKG_DIR = "/opt/Geodaten/ch/so/kva/av/mopublic/gpkg/lv03/d/"

# Enable exceptions
ogr.UseExceptions()

# Get all the layer names
layer_list = []
driver = ogr.GetDriverByName('WFS')
ds_mopublic = driver.Open("WFS:http://www.catais.org/wfs/mopublic?")

for i in range(0, ds_mopublic.GetLayerCount()):
    layer = ds_mopublic.GetLayerByIndex(i)
    layer_list.append(layer.GetName())

ds_mopublic.Destroy()

# Export new deliveries
ds_lieferungen = driver.Open("WFS:http://www.catais.org/wfs/av_lieferungen?")
layer_lieferungen = ds_lieferungen.GetLayerByName('lieferungen_heute')

for feature in layer_lieferungen:
    gem_bfs = feature.GetField('gem_bfs')

    out = os.path.join(GPKG_DIR, str(gem_bfs) + ".gpkg")
    out_driver = ogr.GetDriverByName("GPKG")

    if os.path.exists(out):
        out_driver.DeleteDataSource(out)

    out_datasource = out_driver.CreateDataSource(out)

    filter = "&FILTER=%3Cogc:Filter%20xmlns:ogc=%22http://www.opengis.net/ogc%22%3E%0A%20%3Cogc:PropertyIsEqualTo%3E%0A%20%20%3Cogc:PropertyName%3Ebfsnr%3C/ogc:PropertyName%3E%0A%20%20%3Cogc:Literal%3E" + str(gem_bfs) + "%3C/ogc:Literal%3E%0A%20%3C/ogc:PropertyIsEqualTo%3E%0A%3C/ogc:Filter%3E%0A"

    for i in range(len(layer_list)):
        wfs_string = "WFS:http://www.catais.org/wfs/mopublic?TYPENAME" + layer_list[i] + filter
        ds_mopublic = driver.Open(wfs_string)
        layer_mopublic = ds_mopublic.GetLayerByName(layer_list[i])
        out_layer = out_datasource.CopyLayer(layer_mopublic, layer_list[i])

        ds_mopublic.Destroy()

ds_lieferungen.Destroy()


# Export whole canton
ds_mopublic = driver.Open("WFS:http://www.catais.org/wfs/mopublic?")

out = os.path.join(GPKG_DIR,  "kanton.gpkg")
out_driver = ogr.GetDriverByName("GPKG")

if os.path.exists(out):
    out_driver.DeleteDataSource(out)

out_datasource = out_driver.CreateDataSource(out)

for i in range(len(layer_list)):
    layer_mopublic = ds_mopublic.GetLayerByName(layer_list[i])
    out_layer = out_datasource.CopyLayer(layer_mopublic, layer_list[i])

ds_mopublic.Destroy()

Zeile 16 - 24: Es werden zuerst alle Layernamen des WFS in eine Liste geschrieben. Diese Layer werden später gemeindeweise angefordert und als GeoPackage gespeichert.

Zeile 27 - 28: Ein weiterer WFS liefert die neuen Datenlieferungen (Gemeinden, die heute Nacht geliefert wurden).

Zeile 30 - 49: Die Layer werden nun gemeindeweise angefordert und pro Gemeinde in eine GeoPackage-Datei gespeichert.

OGR hat eine Methode layer.SetAttributeFilter("gem_bfs = 2549"), die Datensätze nach Attribute filtern kann. Dies funktioniert beim OGR-WFS-Treiber entweder auf der Serverseite (bevorzugt) oder auf der Klientenseite. Da QGIS-Server (hier als WFS-Server eingesetzt) in der GetCapabilities-Antwort die «LogicalOperators» nicht auflistet, sie aber versteht, verwendet OGR nur das klientenseitige Filtern. Das hat zur Folge, dass zuerst immer sämtliche Daten vom Server geholt werden müssen. Um dies zu verhindern, kann der Filter direkt in der URL angegeben werden (Zeile 41 und 44/45).

Zeile 55 - 69: Nach dem gemeindeweisen Erstellen der GeoPackages wird ein GeoPackage für den ganzen Kanton Solothurn erstellt.

Funktionierts?

Das Skript lokal ausgeführt braucht circa 1.5 Stunden für das Erstellen sämtlicher 109 Gemeinden. Das Skript auf dem gleichen Server ausgeführt, auf dem der WFS läuft, dauert länger (circa 2.5 Stunden). Der lokale Rechner hat im Gegensatz zum Server eine SSD. Eventuell kann das ein Flaschenhals sein. Interessanterweise macht die kürzere Downloadzeit das nicht wett.

Laden, Zoomen und Pannen funktioniert in QGIS 2.3 (kompiliert mit GDAL/OGR 2.0.0dev) tadellos und sehr schnell. Einzig das Scrollen in der Attributtabelle ist einiges zäher und käsiger als mit Postgis.

Die Daten können hier heruntergeladen werden.

Fun with GeoKettle Episode 1

Sun, 9 Feb 2014 00:00:00 +0000

Der Bezugsrahmenwechsel steht vor der Tür und viele Geodaten müssen früher oder später transformiert werden. Swisstopo bietet einen Webdienst und ein FME-Plugin für diese Transformation an.

Für das ETL-Tool GeoKettle habe ich ein Plugin geschrieben, das diese Transformation für Vektordaten als «Transform-Step» anbietet. Das Plugin kann auf Github heruntergeladen werden: FreeFrame.zip. Die Zip-Datei muss entpackt und in den Ordner plugins/steps von GeoKettle kopiert werden. Hat die Installation geklappt, erscheint unter Design - Transform ein neuer Step: «FreeFrame Plugin» Eine (marginal) ausführlichere Installationsanleitung findet sich hier. Zum Ausprobieren habe ich ein Sorglos-Paket zusammengestellt, das aus GeoKettle und dem Plugin selbst besteht. Es wird nicht mit jeder neuen Plugin-Version aktualisiert.

Die Anwendung ist einfach: Der Transformationsschritt kann innerhalb GeoKettle zu einem beliebigen Zeitpunkt angewendet werden, z.B. vor dem Export einer Datenbanktabelle in eine Shapedatei:

Viel einstellen muss/kann man nicht:

Apply transformation on: Die gewünschte Geometriespalte, die transformiert werden soll.
Source reference frame: Quell-Referenzrahmen (LV03 oder LV95)
Target reference frame: Ziel-Referenzrahmen (LV03 oder LV95)
Triangular transformation network: Dreiecksvermaschungsdatensatz (CHENyx06)

Das Plugin prüft nicht, ob die Geometrien im richtigen Koordinatensystem vorliegen. Wählt man also z.B. als Quell-Referenzrahmen «LV03» aus und die Input-Geometrien sind in einem anderen Koordinatensystem (also nicht EPSG:21781) erhält man keine befriedigenden und sinnvollen Resultate. Für vorgängige Koordinatentransformationen kann der «SRS Transformation»-Schritt verwendet werden.

Liegen die zu transformierenden Koordinaten nicht innerhalb der Dreiecksvermaschung wird keine Transformation durchgeführt und die Koordinaten werden unverändert weitergeleitet.

Stimmt die Transformation auch? Als kleine GeoKettle-Übung habe ich Punktkoordinaten verglichen, die ich mit dem swissopo-Dienst und mit GeoKettle transformiert habe:

Die Resultate zeigen, dass es ausser Kleinstdifferenzen aus (wahrscheinlich?) nummerischen Gründen keine Unterschiede gibt.

Der Transformationsschritt ist vernünftig schnell: Für das Exportieren der gesamten Bodenbedeckung des Kantons Solothurn (circa 270'000 Polygone) aus einer PostgreSQL/Postgis-Datenbank in eine Shape-Datei benötigt GeoKettle ohne Transformation circa 40 Sekunden; mit Transformation werden knapp 100 Sekunden benötigt. Das Transformieren der gleichen Datenbanktabelle inkl. Speichern in einer neuen Datenbanktabelle benötigt circa 130 Sekunden. Für den Test wurde ein Hetzner-Server (Intel i7-3770, HDD im Software-Raid 1, Ubuntu 10.04) verwendet.

Was bringt die Zukunft:

Einbinden von kantonalen Dreiecksvermaschungen, z.B. BEENyx15.
Automatische Detektierung der Geometriespalte(n). So wird es möglich sein alle Tabellen einer Datenbank oder eines Datenbankschemas in einem Rutsch zu transformieren.

Der Quellcode des Plugins befindet sich auf Github.

QGIS server vs. QGIS server

Wed, 29 Jan 2014 00:00:00 +0000

QGIS Server ist schnell. Das zeigt die Präsentation an der FOSSGIS 2013. Ich wurde aber das Gefühl nie los, dass sich die Performance verschlechtert, falls Layer kaskadiert werden. Was verstehe ich unter «kaskadiert»?

Häufig benutzte Grundlagen- resp. Hintergrundkarten werden einmalig erstellt und über eine Schnittstelle (WMS) zur Verfügung gestellt. Dies ist vor allem praktisch, falls die Grundlagenkarte aus vielen einzelnen Layern und Datensätzen besteht.

Für insgesamt fünf Hintergrundkarten habe ich mit JMeter Lasttests durchgeführt:

AV-WMS
Plan für das Grundbuch
Basisplan
Orthofoto
Kombination aus Orthofoto und Basisplan resp. Plan für das Grundbuch

Dabei wurden drei Ansätze (= drei QGIS-Projekte = drei WMS-Dienste) verfolgt:

direkt: Layer werden in QGIS direkt geladen, z.B. VRT-Layer für Orthofotos, Postgis für Vektordaten.
embedded: Layer werden via QGIS-Projekt (Variante 1) geladen («Embed Layers and Groups…»).
wms: Layer wird von Variante 1 als WMS in QGIS-Projekt geladen (= Kaskadieren).

Die Testbedingungen sind wie folgt:

Hetzner-Server:
- Intel i7-3770 (4 Cores, 8 Threads, 3.4 - 3.9 GHz)
- 16 GB RAM
- 2 x 3 TB HDD (7200 rpm, Software-RAID 1)
Ubuntu 10.04
PostgreSQL 8.4 / Postgis 2.0
QGIS enterprise 13.03b
JMeter, Datenbank und QGIS auf dem gleichen Server

Exemplarisch das Resultat des AV-WMS:

Embedded Layer und Gruppen sind gleichauf mit direkt geladenen Datensätzen. Massiv hingegen ist der Einbruch unter Last bei kaskadierten Layern. Warum der Einbruch so massiv ist, entzieht sich meiner Kenntnis. Zu empfehlen sind daher kaskadierende Layer nur beschränkt. Die bessere Lösung ist das direkte Einbinden der Datensätze oder «eingebettete» Datensätze.

Für alle anderen Hintergrundkarten zeigt sich exakt das gleiche Bild. Sämtliche Resultate und einige Beispielbilder gibts hier.

Smoothe Höhenkurven

Fri, 3 Jan 2014 00:00:00 +0000

Mit gdal_contour steht ein Programm zur Verfügung, das aus einem digitalen Terrainmodell Höhenkurven berechnet:

gdal_contour -a elev dtm110733.tif contour.shp -i 10.0

Mit diesem Befehl werden Höhenkurven mit einer Äquidistanz von 10 Metern erzeugt und in der Shapedatei contour.shp gespeichert. Zusätzlich wird die Höhe in das Attribut elev geschrieben.

Ohne jegliches Zutun wirken die Höhenkurven aber unruhig und es sind viele «Kleinst»-Höhenkurven vorhanden:

Ein schöneres Kartenbild ergibt sich durch vorgängiges Prozessieren des digitalen Terrainmodells. Mit einem Shell-Skript wird das Terrainmodell zehn Mal mit einer bestimmten Resamplingmethode umprojiziert. Das Umprojizieren ist in diesem Fall aber belanglos, da a) nichts umprojiziert wird und b) nur das Verschmieren der Rasterwerte durch das Resampling interessiert:

#!/bin/bash

cp $1 tmp_$1

for i in {1..10}
do
  gdalwarp -co COMPRESS=PACKBITS -overwrite -r cubicspline tmp_$1 smooth_$1
  cp smooth_$1 tmp_$1
done

rm contour_smooth.*
gdal_contour -a elev smooth_$1 contour_smooth.shp -i 10.0

ogr2ogr -overwrite -dialect SQLITE contour_smooth_reduced.shp contour_smooth.shp -sql "SELECT * FROM  contour_smooth WHERE ST_Length(GEOMETRY) > 100"

Das 10-fache Resampling findet in der for-Schleife statt. Anschliessend werden die Höhenkurven erzeugt. Der letzte Befehl löscht alle Höhenkurven, deren Länge kleiner 100 Meter ist. Dieser Befehl funktioniert erst mit gdal ≥ 1.10.

Et voilà: