Beim Reanimieren des INTERLIS Benutzerhandbuches wollte ich zu Beginn gleich die ganze Sache auf INTERLIS 2.4 migrieren. Aber wenn ich mehr als bloss ein Soft-Update gemacht hätte (also in der ersten Zeile 2.3 mit 2.4 ausgetauscht), wäre der Aufwand doch beträchtlich gewesen und lieber eine Sache nach der anderen erledigen. Und je mehr ich vom Benuterhandbuch migrierte, desto weniger wollte ich einfach die Modelle und Transferdateien updaten. [read more]
Posted on 2026-05-15
|
1093 words
|
Stefan Ziegler
Wir sind momentan daran einen Piloten für den zukünftigen, standardisierten AV-Webservice umzusetzen. Das wird sowas ähnliches wie der ÖREB-DATA-Extract. D.h. es gibt einen XML-Auszug und einen PDF-Auszug, der sich direkt und vollständig aus der XML-Datei ableiten lässt. Der AV-Webservice liefert Information aus der amtlichen Vermessung pro Grundstück (und nicht ganze Gemeinden). Wie beim ÖREB-Kataster lassen wir den Service durch eine externe Firma entwickeln. [read more]
Was Kleines und Kurzes: Es gibt ein neues Apache Hop Plugin: einen Geometry Calculator: Es wird row-by-row prozessiert. Folgende Features gibt es bereits: Probiert es aus und meldet Fehler. Das Komplettpaket wurde mit dem GDAL-Plugin upgedatet, das jetzt hoffentlich auch unter Windows funktioniert. HOP_JAVA_HOME=/Users/stefan/.sdkman/candidates/java/25.0.1-tem \ HOP_OPTIONS="--enable-native-access=ALL-UNNAMED -Xmx2048m" \ . [read more]
Sich ein wenig über das INTERLIS Referenzhandbuch lustig machen, gehört praktisch zum guten Ton. Wenn man das macht, macht man es wahrscheinlich aus dem falschen Grund: Es ist ein Referenzhandbuch und kein Getting Started Manual oder ähnliches. Aber: es gibt ja noch das INTERLIS Benutzerhandbuch. Das fristet leider ein Schattendasein, obwohl es wirklich gut ist. Vielleicht geht es an der einen oder anderen Stelle bereits zu weit aber das macht es nicht schlecht. [read more]
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». [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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 weiterentwickeln Richtung brauchbar. [read more]
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. [read more]
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. [read more]
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? [read more]
Posted on 2025-10-17
|
1013 words
|
Stefan Ziegler
Ich habe bereits mehrere Male über INTERLIS und Python geschrieben und gezeigt, dass man durchaus was damit machen kann: INTERLIS leicht gemacht Teil 53 INTERLIS leicht gemacht Teil 33 INTERLIS leicht gemacht Teil 22 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. [read more]
Posted on 2025-09-16
|
1490 words
|
Stefan Ziegler
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. [read more]
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. [read more]
«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. [read more]
Posted on 2025-07-22
|
1998 words
|
Stefan Ziegler
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. [read more]
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. [read more]
Posted on 2025-07-20
|
1234 words
|
Stefan Ziegler
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. [read more]
Posted on 2025-06-13
|
1042 words
|
Stefan Ziegler
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. [read more]
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 bestimmter (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. [read more]
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. [read more]
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. [read more]
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. [read more]
Posted on 2025-02-09
|
1770 words
|
Stefan Ziegler
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. [read more]
Posted on 2025-01-26
|
1223 words
|
Stefan Ziegler
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. [read more]
Posted on 2025-01-12
|
1258 words
|
Stefan Ziegler
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. [read more]
Posted on 2025-01-05
|
1557 words
|
Stefan Ziegler
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. [read more]
Posted on 2024-12-27
|
1651 words
|
Stefan Ziegler
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. [read more]
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. [read more]
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. [read more]
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. [read more]
Posted on 2024-10-15
|
1034 words
|
Stefan Ziegler
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. [read more]
«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. [read more]
Posted on 2024-06-03
|
1397 words
|
Stefan Ziegler
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. [read more]
Posted on 2024-05-31
|
1338 words
|
Stefan Ziegler
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. [read more]
Posted on 2024-05-29
|
1148 words
|
Stefan Ziegler
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. [read more]
«Mach' Cloud Optimized GeoTIFF!» sagen sie. «Dann brauchst du keinen WMS mehr!» behaupten 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? [read more]
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. [read more]
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. [read more]
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. [read more]
Posted on 2023-12-30
|
1046 words
|
Stefan Ziegler
Wie im vorangegangenen Blogpost aufgezeigt, wird WFS dank Cloud Native Formate für gewisse Anwendungsfälle 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. [read more]
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. [read more]
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. [read more]
Posted on 2023-11-03
|
1174 words
|
Stefan Ziegler
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. [read more]
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. [read more]
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. [read more]
Posted on 2023-08-13
|
1097 words
|
Stefan Ziegler
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. [read more]
Posted on 2023-07-20
|
1084 words
|
Stefan Ziegler
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: Csv2Parquet Csv2Excel OgdMetaPublisher Die ersten Beiden wandeln eine CSV-Datei in eine Parquet- resp. [read more]
Posted on 2023-07-10
|
1514 words
|
Stefan Ziegler
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. [read more]
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. [read more]
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. [read more]
Posted on 2023-05-10
|
1038 words
|
Stefan Ziegler
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. [read more]
Posted on 2023-01-18
|
1130 words
|
Stefan Ziegler
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. [read more]
Posted on 2023-01-11
|
1193 words
|
Stefan Ziegler
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. [read more]
Posted on 2023-01-01
|
1159 words
|
Stefan Ziegler
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. [read more]
Ich habe ein paar Features implementiert: [https://github.com/claeis/ilivalidator]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. [read more]
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. [read more]
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. [read more]
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). [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
Posted on 2022-05-14
|
1217 words
|
Stefan Ziegler
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. [read more]
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. [read more]
Posted on 2022-04-19
|
1546 words
|
Stefan Ziegler
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). [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
Posted on 2021-10-25
|
1085 words
|
Stefan Ziegler
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. [read more]
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. [read more]
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. [read more]
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. [read more]
Posted on 2020-09-23
|
1035 words
|
Stefan Ziegler
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. [read more]
Posted on 2019-09-23
|
1309 words
|
Stefan Ziegler
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. [read more]
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. [read more]
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. [read more]
Posted on 2018-12-31
|
1122 words
|
Stefan Ziegler
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. [read more]
Posted on 2018-12-10
|
1269 words
|
Stefan Ziegler
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. [read more]
Posted on 2018-12-09
|
2343 words
|
Stefan Ziegler
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: Kartenau [read more]
Posted on 2018-10-23
|
1002 words
|
Stefan Ziegler
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. [read more]
Posted on 2018-10-21
|
1203 words
|
Stefan Ziegler
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. [read more]
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. [read more]
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. [read more]
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»). [read more]
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. [read more]
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. [read more]
Posted on 2017-09-12
|
1073 words
|
Stefan Ziegler
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. [read more]
Posted on 2017-08-27
|
1484 words
|
Stefan Ziegler
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 [read more]
Posted on 2017-07-28
|
1148 words
|
Stefan Ziegler
Im Rahmen unseres Infrastrukturprojektes SO!GIS 2.0 wollen wir unsere Dienstleistungen konzentrieren und professionalisieren. Dazu gehört auch die Sparte Entwicklung. Wir wollen neben der eigentlichen Codequalität (inkl. Tests, Tests und Tests) auch die Prozesse drumherum verbessern. Dh. zum Beispiel wird etwas am Code verändert, soll die Software neu gebuildet werden. Jeder Build soll zur Bereitstellung lauffähiger Software auf einem Environment führen. [read more]
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. [read more]
Posted on 2017-04-10
|
1140 words
|
Stefan Ziegler
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). [read more]
Posted on 2017-02-13
|
1062 words
|
Stefan Ziegler
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. [read more]
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. [read more]
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, sieh [read more]
«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. [read more]
Posted on 2017-01-01
|
2400 words
|
Stefan Ziegler
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. [read more]
Posted on 2016-12-29
|
1123 words
|
Stefan Ziegler
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. [read more]
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. [read more]
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. [read more]
Posted on 2016-10-23
|
1823 words
|
Stefan Ziegler
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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»): [read more]
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. [read more]
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. [read more]
Posted on 2016-05-30
|
1019 words
|
Stefan Ziegler
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 (. [read more]
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. [read more]
Posted on 2016-02-11
|
1391 words
|
Stefan Ziegler
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. [read more]
Posted on 2015-11-28
|
1270 words
|
Stefan Ziegler
Die Eidgenössische Vermessungsdirektion aggregiert verschiedene Metadaten der amtlichen Vermessung. Dazu zähle ich: Spannungsarme Gebiete Stand der amtlichen Vermessung Stand der Periodischen Nachführung 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. [read more]
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. [read more]
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.) [read more]
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. [read more]
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? [read more]
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? [read more]
Posted on 2015-08-09
|
1005 words
|
Stefan Ziegler
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. [read more]
Posted on 2015-06-24
|
1246 words
|
Stefan Ziegler
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]
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. [read more]