So, willkommen, liebes Publikum. Wir machen weiter mit Herrn Pürmen-Kalberer. Bitteschön. Ja, Dankeschön. Ich erzähl kurz was über Geopackage. Das ist ein Format, das nicht mehr ganz neu ist,

aber doch erwähnenswert und wo ich auch gerne ein Update gebe, wie es dem so geht. Ich arbeite für die Firma SourcePoll in der Schweiz. Wir machen QGIS-Entwicklung, Support, Maintenance und WebGIS-Entwicklung.

Und ja, wir müssen auch Daten austauschen und mit Daten arbeiten. Von dem her betrifft uns das Thema selbst. Geopackage ist ein OTC-Standard, wurde 2014 publiziert, ist also schon ein paar Jahre alt. Und der Titel in der Spezifikation beschreibt recht gut, was es ist. Also ein Non-Propriety Platform, Independent Container für die Verteilen

und den direkten Gebrauch von Geospatial Data. Und das ist wirklich ein wichtiger Punkt. Es ist sowohl ein Austauschformat als auch ein Arbeitsformat. Das ist eigentlich gar nicht so selbstverständlich.

Und es können sowohl Vektordaten wie auch Rasserdaten gespeichert werden. Und das Speichermat, sage ich nur noch, ist ein SQLite-Filedatenbank. Geopackage.org hat eine eigene Webseite, da ist die Spezifikation drauf, sind Listen von Tools drauf und diverse Informationen.

Wer Postgres kennt, kennt PostGIS, also wenn er hier ist. Geopackage hat ein gleiches Verhältnis, ist die Spatial Erweiterung für SQLite. Also SQLite ist eine feilbasierte Datenbank, eine Embedded-Datenbank.

Und Geopackage definiert, wie man Geometrien darin speichert. Und dieses SQLite ist eigentlich ein Feil. Eine Spezialität ist, dass ich nicht direkt mit C-Funktionen als Programmierer darauf zugreifen kann,

sondern es gibt ein SQL-API, das heißt ich kann mit SQL-Funktionen direkt auf dieses Feil zugreifen, auf diese Daten. Also ich kann auch in der Kommandozeile schon Daten extrahieren, ohne dass ich zusätzliche Software brauche. Und hier geht es jetzt um die Spatial Data Types, die hinzugefügt werden.

Und Raster, die man speichern kann. Und zwar gibt es Kacheln und Kachelpyramiden, die definiert sind in diesem Geopackage-Standard. Die Geometrien, da gibt es Punkt, Multipunkt, Line, String, Multiline, String, Polygon, Multipolygon.

Und zwar als XYZM, also mit Z und mit M Dimensionen. Also man sieht schon mal, was fehlt vielleicht, also erste Aufschleißen vielleicht die Kurven, die hier nicht drin sind. Aber dazu gibt es noch Extensions, das heißt es ist wirklich eigentlich Simple Features, wo man sich reduziert hat.

Binär sind sie als WKB gespeichert, das ist eigentlich ein Blob, der dann in dieser File-Datenbank drin ist. Eine wichtige Einschränkung oder Vereinfachung, wie man es sagen will, ist, dass man nur eine Geometrie pro Tabelle speichern kann oder verwalten kann.

Das ist eigentlich wirklich eine reine Spezifikationssache. Es gibt auch sofern, die können mehrere speichern und mehrere verwalten. Aber vom Standard her ist vorgegeben, man arbeitet nur mit einer Geometrie. Und wenn man dann wirklich mit verschiedenen Geometriespalten arbeiten will,

dann muss man vielleicht eine View machen oder irgendwas, wo man dann die andere Spalte sieht. Es gibt schon Mittel, aber das ist jetzt eine Einschränkung, die mir immer noch weh tut eigentlich. Aber das ist jetzt halt so. Und das Argument war wirklich, dass es so einfach wie möglich ist. Es gibt Spatial Index, ein R3, und es gibt wie gesagt Rasterteilsets, also PNG, JPG.

Implementation gibt es unter anderem sehr viele. Die wichtigste ist eigentlich quasi im Geobereich GDAL OGR, weil das ist die Bibliothek, wo dann alle drauf aufbauen. Das heißt, wenn ich jetzt Kugis sage, dann ist es eigentlich hauptsächlich der GDAL-Treiber, der hier benutzt wird, der die Sachen unterstützt.

Geotools, das ist dann die Java-Desktop-Welt oder Java-Welt, nein nicht nur Desktop. Und Geo-Server, die darauf aufbaut, verwendet diese Bibliotheken, also die unterstützen das.

Dann FME hat eine Geo-Package-Unterstützung. ArcGIS hat es, ArcGIS Pro, vielleicht stimmt es unter anderem nicht mehr, als ich die vorhin geschrieben habe. Da ging nur lesen, also das war schon noch eine Einschränkung, die weh tut. Dafür ganz neu ist jetzt gerade die Nachricht gekommen, dass Geo-Media Geo-Package unterstützt und sogar das als neues Default-Format propagiert.

Map-Info hat es auch schon länger drin und viele mehr, das ist auf dieser Geo-Package-Org-Seite aufgelistet. In Kugis kann man, also mit jeder Version hat sich eigentlich der Geo-Package-Support verbessert.

Unter den Resten gibt es nicht mehr viele Einschränkungen, also ich kann es mit Drag & Drop bei Geo-Package reinnehmen, ich kann es im Browser öffnen, ich kann es im File-Dialog öffnen und überall wo vorher so Add New Shapefile Layer gibt es jetzt auch Add New Geo-Package Layer und so.

Mir psychologisch ist es auch so, dass es wirklich zuerst zu Obers kommt, das gibt der Add New Geo-Package Layer und dann kommen die anderen. Warst du das? Weiss auch nichts. Irgendwer hat das gemacht. Man kann editieren, natürlich speichern, laden. Ganz neu in Kugis 3 ist es auch das Zwischenformat in Processing.

Wer das kennt, diese Datenverarbeitungstools, die hatten bisher Shapefile als Zwischenformat in der Verarbeitungskette, weil das quasi der gemeinsame Nenner war, dass alle verstehen und da gibt es natürlich einige

Verluste, wenn man das macht und jetzt mit Geo-Package kann man da die Situation verbessern. Es gibt weiterhin Limitierungen, aber das ist nicht unbedingt Kugis Schuld. Bei Escolite ist es tatsächlich schwierig, zum Beispiel eine Spalte umzubenennen. Escolite

gibt nicht ein alter Table Rename Column, das gibt es nicht bei Escolite. Es gibt Methoden, um das zu machen, aber das ist dann recht unständlich und darum sind das noch so Einschränkungen, die es gibt. Es gibt wahrscheinlich noch mehrere kleine Einschränkungen, aber ich muss jetzt tatsächlich

sagen, dass ich aktuell zu wenig damit arbeite, um es gerade zu spüren. Ich habe jetzt einige rausnehmen können, die ich weiß, die hatte ich auf den alten Folien, die es nicht mehr gibt. Die Situation hat sich jetzt wirklich stark verbessert und es gibt nur noch ganz wenige Ecken, wo man an Grenzen stößt, wo man dann etwas vermisst.

Oh, Views sollte das heißen. Views editieren, das habe ich gesehen, geht noch nicht, aber gut, ist auch ein bisschen Spezialfall. Was ich noch nicht gesagt habe, Geo-Package hat einen Extension-Mechanismus, das

heißt, es gibt diesen relativ einfachen Kern, das ist ein Standard Geo-Package. Und wenn ich mehr da reinpacken will, darf ich das, aber damit es weiterhin quasi ein Standard Geo-Package ist, muss ich diese Extension registrieren. Also es gibt so eine Tabelle, das habe ich jetzt so, ich habe jetzt

etwas Zusätzliches gemacht, das ist die Extension und die kann ich dann auch spezifizieren. Ich verweise da dann mit Metadaten auf die Spezifikation und da steht drin, ok, ich habe noch ein paar Tabellen hinzugefügt und ja, was auch immer. Und da gibt es auch eine offizielle Seite dafür, bisher war das alles ein bisschen verstreut, wo diese Extensions gesammelt werden auf geopackage.org.

Ich habe hier ein paar herausgepickt, eine Extension ist sogar in der Corespezifikation drin, aber da schon als Extension markiert, nämlich die Kurven, Kreisbögen, die sind bereits spezifiziert, wie man die speichert und viele Tools können das auch, aber es ist dann bereits eine Extension, aber ja, ist halt so.

Und da gibt es noch andere Sachen, über Elevation Data gibt es eine Extension, Feature Tiling, OVS Context hat jemand eine Extension definiert.

Und mein Werk ist noch dieses Kugis Map Styling, diese Kugis Map Styling Extension, die ich jetzt noch kurz vorstelle. Die Idee dahinter ist, mit geopackage kann ich gut Daten austauschen, aber ich will eigentlich auch gerade die Karten auch austauschen.

Und häufig geht es halt so, ich gebe die Daten und die Kartenbeschreibungen in irgendeiner Form, jetzt bei Kugis ist das Kugis-File, plus vielleicht noch ein paar Bilder dazu, die es noch braucht, also SVGs und solche Sachen. Und wieso die nicht einfach direkt in diesem Spatial Item Geopackage speichern.

Und das macht diese Extension oder macht ein Plugin mit einer definierten Extension. Es schaut im Projekt, was brauche ich noch für zusätzliche Ressourcen, also SVGs und so weiter und speichert die im Geopackage in einer separaten Tabelle.

Und auch was wird im Print-Layout noch verwendet, irgendwelche Logos als JPEGs, dann werden diese als eine Asset-Tabelle gespeichert. Und das ist ein Kugis-Plugin, das die Speicherung macht und auch wieder das Laden macht. Das heißt, das ermöglicht mir direkt die Karte einzubetten, also die Kartendarstellung einzubetten.

Das ist die, was habe ich noch noch grafisch dargestellt, diese Implementation, die jetzt ein bisschen Kugis-zentriert ist. Das heißt, ich nehme Kugis, schreibe das ins Geopackage rein und kann es mit Kugis wieder lesen.

Jetzt gibt es aber auch Interessenten, die wollen noch anderes reinschreiben oder haben das jetzt vorallgemein. Das ist auch diese OVS-Context-Extension. Das haben wir sogar jetzt im gleichen Plugin kombiniert, wo auch SLDs und OVS-Contexts im Geopackage gespeichert werden.

Das heißt, das können dann auch andere Applikationen abgesehen von Kugis lesen. Plus es hat eine Implementation im Kugis-Plugin, die diese SLDs importiert und die OVS-Informationen umsetzt für Kugis. Das ist bisher ein experimentelles Plugin, das war jetzt mehr so ein Proof of Concept.

Aber jetzt zumindest der Kugis-Teil, den wir hier jetzt sehen, den werden wir jetzt nächstens wirklich fertig machen und produktionsreich machen. Dann wird es auch ein nicht mehr experimentelles Plugin sein. Das heißt, es erscheint dann im normalen Plugin-Manager auf.

Was habe ich noch? Ja, ich bin schon durch eigentlich. Jetzt habe ich zweimal überzogen, einmal bin ich zu schnell, das gleicht sich aus. Hier noch die Folie, was sind jetzt die Vorteile von Geopackage?

Schon mehrfach erwähnt, ich kann Daten austauschen und direkt nutzen. Es ist ein einzelnes File, muss ich vielleicht kurz noch sagen, manchmal sind es auch mehr als eines Files. Ich weiss nicht, wer schon gearbeitet hat, der sieht auf einmal so ein Journal-File. Das hat damit zu tun, wenn man vor allem Multi-User-Verarbeitung macht mit Geopackages oder mit SQLite,

dann hat man Locking-Probleme, die dann recht weh tun können. Und wenn man mit diesem Journal arbeitet, dann sind diese Probleme viel kleiner. Also dann kann ich da vier performanter größere Verarbeitungen machen und auch Mehr-User-Verarbeitungen machen.

Das ist dann für den Austausch ein bisschen weniger praktisch, das heißt ich muss dann das Journal entweder mitschicken oder, schöner ist, mit einer Zeile SQLite integriert dieses Journal ins Geopackage

und dann habe ich nur noch ein SQLite-File und kann das austauschen. Es ist eben einfach genug, ein File, das heißt ich kann es sowohl auf dem Server verwenden als auch auf dem Mobilgerät. Ich habe einen guten Extension-Mechanismus. Deshalb sage ich, und das mache ich jetzt hier, weiter sagen, Geopackage ist wirklich gut.

Auch danach fragen, also wenn es Geodatenportale gibt, fragen, kann ich auch Geopackages haben, weil das ist wirklich ein super Format, das auch noch länger in Gebrauch sein wird. Vor allem im Open-Data-Umfeld muss man da immer noch ein bisschen nachfragen, aber es gibt auch diverse Open-Data-Portale, die das von sich aus gemacht haben.

Bei den Advantages ist mir noch ein Disadvantage auch nicht in den Sinn gekommen, bei den Einschränkungen. Ein paar habe ich gesagt, also diese Multi-Geometrien. Wer jetzt von Spatial-Lite herkommt, der vermisst auch noch einiges. Also eigentlich ist ein bisschen Spatial-Lite der Vorläufer vom Geopackage, kann man sagen. Das war der Erste, der hat definiert, wie speichle ich Geometrien im SQLite.

Er hat ein Spatial-Lite-Paket gemacht oder Spatial-Lite-Software und viele Funktionen dazu gepackt. Also da hat es dann wirklich eine ganze Zeile von Verarbeitungsfunktionen

und da sind sogar Routing-Funktionen. Also sehr viel, sehr umfangreich, super Sache. Es sah dann sogar mal so aus, dass es zum Standard wird, aber die Standardisierung ist kompliziert. Dann kam ein anderer dazu, da haben wir gesagt, wir müssen aber ein anderes Binär-Format haben.

Es muss noch ein bisschen anders sein als Spatial-Lite. Aber Spatial-Lite unterstützt jetzt auch dieses Geopackage. Das heisst, wenn ich mit Spatial-Lite arbeite, dann kann ich auch sagen, ich kreiere mir aber ein Geopackage-kompatibles SQLite-Format. Und dann habe ich dann aber immer noch diese Spatial-Lite-Zusatzfunktionen.

Das heisst, man kann das auch ein Stück weit noch verheiraten. Aber grundsätzlich finde ich es sinnvoll, beides hat seine Berechtigung. Geopackage ist ein Standard, der beschränkt ist, aber in gewissem Maß.

Und halt die weiteren Funktionen mache ich halt im Desktop-GiS oder irgendwo anders. Das kann ich dazu bauen, aber sie sind nicht standardisiert. Aber dafür soll dieser Kern von allen unterstützt werden. Von dem her ist das eine gute Sache. Und dann, wenn man mit Extensions arbeitet, weiß man, man ist in einem Bereich,

wo nicht mehr alle mitarbeiten können und das alle verstehen, was die Anwendungen machen müssen. Sie müssen auch merken, ok, jetzt ist diese Extension drin. Und dann weiß ich einfach, jetzt muss ich aufpassen, bei diesen Tabellen darf ich nichts machen. Also er muss mindestens merken und die zusätzlichen Daten nicht zerstören.

Aber das heisst natürlich nicht, dass er sie dann auch verarbeiten kann. Gut, ja, das wäre meine Information zu Geopackage. Dann haben wir jetzt dafür ein bisschen mehr Zeit für Fragen. Ja, wir öffnen jetzt die Fragerunde. Danke, Herr Kalberer.

So, Sie haben jetzt die Gelegenheit, unserem Gast aus der Schweiz Fragen zu stellen. Das nächste Mal müssen Sie in die Schweiz fahren. Wahrscheinlich, bitte. Ja, hallo. Ich habe eine Frage, über die ich immer stolpere, also auch bei der Idee den Leuten das zu empfehlen.

Das hatte ich eigentlich immer schon vor, habe es aber bei QGIS 2.18 nicht gemacht, weil das Problem ja war, wenn ich editiere, einen Polygon durchschneide beim Geopackage, dann konnte man das nicht mehr speichern, weil der mit seinem eigenen Primärschüssel durcheinander gekommen ist und man gesagt hat, abbrechen, dann ist ein Teil verschwunden. Ich habe gesehen, im QGIS 3 ist das glaube ich behoben.

Gibt es denn noch Ansinnen, weil ja die 2.18 noch als Langzeitversion ein bisschen weiter läuft, das doch nochmal zurückzuportieren oder ist das schwierig? Weißt du da irgendwas von zu diesem Problem? Ich kann die Frage weiterleiten. Also gut, Ruhe ist es gar nicht hier, weißt du vielleicht. Also ich glaube nicht, dass es so schwierig wäre. Aber es ist Arbeit.

Diese Primärschlüsselproblematik beim Zerschneiden von Polygonen, eben 2.18 hat es noch, die Frage ist, ob es zurückportiert wird. Jürgen hat nicht aufgepasst. Bei 3 ist das Problem behoben. Die Frage ist, jetzt wird es auch in 2.18 zurückportiert.

Ich glaube nicht, da brauchen wir Funktionalität, um die Primärschlüssel zu erkennen und die ist halt nicht da in den Providern. Der Provider hat den Unterschied zu groß. Oder Guida hat die Funktion glaube ich noch nicht. Darin die Primary Keys zu erkennen. Wenn es das täte, dann würde das jetzt schon funktionieren. Das ist ja auch zum Beispiel, wenn man eine Spatial Light Datei

über den normalen OGR Treiber ins Kugel reinlegt, das ist das gleiche Problem. Wenn man den Spatial Light Treiber eigentlich nimmt, dann geht das gut. Ja, Guida kann nicht. Wahrscheinlich muss man dann irgendwann auf 3 umsteigen. Das macht man ja irgendwann sowieso. Ja genau, das ist sowieso eine gute Idee.

Noch mal eine Frage, die mir dann noch immer liegt. Die Spatial Light auf der einen Seite, Geo Package auf der anderen. Spatial Light hast du ja auch gesagt, bringt ganz viele Funktionen, auch Geo-Verarbeitungsfunktionen mit. Das ist ja beim Geo Package nicht so ausgewegt, das soll sozusagen so schlank bleiben. Das heißt, wenn man mehr machen will, dann arbeitet man einfach weiter mit Spatial Light.

Das ist meine Antwort, ja. Ja, vielen Dank für die Frage.

Soweit ich sehe, sehe ich keine weiteren Meldungen. Oder übersehe ich was? Nein. Gut, danke Herr Kalberer.