Ja, hallo allerseits, hier auf der FOSCES 2024 in Hamburg. Es freut mich, hier zu sein und dieser Vortrag knüpft ganz gut an den, den wir gerade gehört haben, an. Wir bleiben bei der OGC API Family, der neue Standard Family und gucken uns jetzt eine weitere Lösung an,

eine Python Server Software. Und genau zu mir noch kurz Astrid Emde. Ich komme aus Bonn, von der Wear Group, arbeite ich seit vielen Jahren dort, mache Schulungen,

habe viele Open Source Projekte, die ich in Projekten einsetze und habe viel mit Standards zu tun. Und da war natürlich dieses Thema Next Generations Standards für mich auch sehr interessant, so dass ich da jetzt mich mit PyGeo API beschäftigt habe. Und genau, ich bin von der Wear Group, wir haben auch einen Stand hier auf der FOSCES,

kommen Sie gerne vorbei, wir können Sie beraten, wenn Sie eine Lösung mit Open Source Software suchen. Ja, PyGeo API, ich bin jetzt keine Entwicklerin des Projektes, ich bin interessiert und habe mir über dieses Projekt die neuen Standards angeschaut und

habe gesehen, dass dieses Projekt auf vielen internationalen Konferenzen vertreten ist, dort Workshops hält und war auch auf der letzten FOS4G bei einem Workshop und daraus heraus habe ich gedacht, Mensch, jetzt stelle ich das doch mal auf der FOSCES vor und bringe die Software auch zu uns.

Eine Frage in die Runde, wer von euch oder von Ihnen nutzt PyGeo API schon? Okay, zwei Hände gehen hier hoch von, ich würde sagen, ein paar hundert, die jetzt hier sitzen. Genau, das heißt, da ist noch Potenzial und ich hoffe, dass der Vortrag da

hilft, das Projekt spannend zu machen. Ja, das wurde 2018 gegründet vom Tom Kralides, das ist jemand, der im OSGeo Board ist und der schon ganz lange in der OSGeo Community unterwegs ist, auch beim Mapsaber Projekt beispielsweise mitmacht und er hat es am Valentinstag mit Herz und Liebe angefangen,

das Projekt und war am Anfang Einzelkämpfer und hat jetzt aber eine größere Community und Mitstreiter und Streiterinnen gefunden. 2022 ist das Projekt dann OSGeo Projekt geworden, für die, die das nicht kennen, das heißt, dass man so ein Inkubationsprojekt durchläuft und zertifiziert wird und quasi in die OSGeo, in die Open Source Software Foundation aufgenommen wird,

wie zum Beispiel PostGIS, QGIS, Geo Server, Mapserver, ganz viele andere Projekte auf. Es ist unter der MIT-License das Projekt und wir werden gleich sehen, diverse OGC API-Standards wurden umgesetzt, sind compliant und sind teilweise auch Referenzimplementierungen.

Und es ist so, dass die Anforderungen von den neuen Standards, die werden ja laufend weiterentwickelt, die werden direkt im Projekt umgesetzt. Wenn wir hier auf den nächsten Link gehen, da sehen wir auch, das Projekt ist beim OGC

quasi registriert und da kann man sich weitere Informationen dann auch anschauen, wie das Projekt eingebunden ist. Im Moment haben wir die 0.16. Version, die kam erst vor einigen Wochen heraus und da habe ich auch hier nochmal den Link eingefügt. Ja, hier das ist das PyGeo API Team, nicht ganz komplett, aber da sieht man ein paar Player.

Hier, das ist der Tom Granides aus Kanada, der das ganze ins Leben gerufen hat und das ist wirklich ein internationales Team, was da aktiv ist. Und auch über den Link, den ich eingebaut habe, kann man noch sehen, dass da sehr viele Beitragende mit dabei sind. Ja, die Entwicklung ist an Sprints orientiert. Es gibt mehrmals im Jahr, gibt es Code Sprints, Community Sprints.

Vor ein paar Wochen war erst der Joint Code Sprint von OSGEO, Apache Software Foundation und dem OGC. Da wird an den Standards gearbeitet und es wird dann direkt versucht, die Neuerungen auch in die Software einzubauen.

Ja, sodass es da einen sehr engen Austausch gibt zwischen Softwareentwicklern und dem OGC. Und das ist auch was, was jetzt mit dieser neuen OGC API Family so eine Rungenschaft ist, die dort sich entwickelt hat. Genau, also Tom Granides und der Angelos Chochos, der jetzt hier nicht drauf sind, das sind beides OSGEO Board-Member, die sind auch im OGC.

Und über die OSGEO kann man auch beim OGC Mitglied werden. Das haben wir einen Partnervertrag aufgebaut, sodass wer da Interesse hat, gerne da auch nochmal auf mich zukommen kann. Und ja, jetzt schauen wir uns die Software ein bisschen näher an.

Genau, wenn wir über die neuen Standards reden, dann Stress, JSON, OpenAPA und Swagger hatten wir eben schon gehört. Das sind auf jeden Fall Komponenten, die hier wichtig sind. Und wir haben einen Core mit abstrakter API. Da ist auch ein agnostischer Client eingebaut.

Also da ist der Default Flask, in dem das umgesetzt wurde. Aber der kann auch ausgetauscht werden, sodass ich zum Beispiel auch eine andere Umsetzung da nutzen könnte und den Django beispielsweise so einen Client programmieren könnte. Dann ist das ganze Plugin orientiert. Das heißt, ich kann für verschiedene Datenquellen beispielsweise auch eigene Plugins erstellen.

Das sehen wir später noch. Die Konfiguration, die PyGeo API benötigt, die erfolgt in Jaml. Da schauen wir auch gleich einmal rein, wie das auch sehen kann. Dann werden OpenAPI Dokumente und die Datenverknüpfung, die werden dann automatisch aus den Konfigurationen erzeugt.

Und ein Feature, was zum Beispiel dann diesen neuen Standards auszeichnet, das ist, dass die Über-Such-Maschinen findbar sind. Ja, die Installation ist auch unkompliziert. Da gibt es verschiedene Wege. Da gibt es auch eine Seite, die sich mit der Installation beschäftigt.

Das Projekt ist auch auf der OSGeo Live. Wer das da direkt ausprobieren möchte und ansonsten gibt es hier diese Möglichkeiten. Ja, und dann gibt es eine sehr schöne Demo. Und die Demo, da kann man sich direkt auch den Code unter GitHub anschauen, sodass man sieht, dass das, was in der Demo zu sehen ist, welche Konfiguration entsprechend dahinter steckt.

Ja, schauen wir hier nochmal uns die OTC API Family an. Wenn ich da mal auf der Seite schaue, dann sehen wir, haben wir hier sehr viele Standards, die gerade diskutiert werden.

Das sind hier 16 Stück. Und da kann man sich zu jedem Standard auch anschauen, wie gerade der Status ist. Und wir haben eben gesehen, da war auch ein Link zu GitHub, sodass man das hier sehr gut verfolgen kann. Und man sieht dann auch, in welchem Status gerade die einzelnen Teile sind, die so einen Standard dann aufbauen.

Gut, und wenn wir jetzt dann schauen, wie der Stand bei PyGeo APIs in der Umsetzung ist, sehen wir, dass hier acht Standards bearbeitet werden oder in Umsetzung sind. Und an der Grafik hier unten sehen wir, dass genau die Umsetzungen OTC Compliant sind.

Und dass das Projekt auch für einige von den Standards eine Referenzimplementierung ist. Für OTC Features, API Features, OTC API EDR und OTC API Tiles. Ja, und wie können wir jetzt Datenquellen anbinden?

Das geht via Plugins, hatte ich schon angesprochen. Da gibt es für Feature, also für Vectordaten, diverse Datenquellen, die wir hier nutzen können. Elasticsearch, PostgreSQL, PostGIS, CSV, GeoJSON, OGR, MongoDB und so weiter. Und über OGR, wer schon mit OGR zu tun hatte, der wird wissen, dass darüber sehr viele Vectordaten dann auf einen Schwung zur Verfügung stehen.

Und so das Projekt auf jeden Fall sehr viele Vectordaten bedienen kann. Bei Coverage haben wir X-Array und Rasterio und auch GDAL. Und bei Tiles haben wir diverse Unterstützungen.

Bei Rackets, Elasticsearch und TinyDB. Und wir werden gleich auch noch was über Facetten hören. Und das Ganze ist aber auch noch erweiterbar. Das heißt, ich kann mein eigenes Plugin entwickeln. Das kann ich dann auch dem Team vorstellen. Das kann dann womöglich auch in den Chor übertragen werden oder kann eigenständig als separates Plugin weiterleben.

Dann gibt es eine Galerie, die kann man sich anschauen. Und da sehen wir, wo die Software schon im Einsatz sind. Und kann sich entsprechend hier diese Lösungen dann anschauen.

Und das kann man im Nachgang dann in Ruhe sich mal anschauen. Hier haben wir zwei recht neue Projekte. Das sind hier diese spanischen Projekte. Da habe ich auch noch mal die links separat eingefügt. Die sind jetzt erst im letzten Jahr hinzugekommen. Und da sehen wir jeweils dann die Kollektionen. Wir sehen, dass es hier OTC API Feature-Dienste sind.

Und könnten uns dann entsprechend die einzelnen Feature anschauen. Das machen wir gleich noch für ein anderes Thema. Ja, und zwar gucken wir erstmal auf jeden der einzelnen Standards und schauen uns das ein bisschen im Detail an. Wir haben hier bei den Kollektionen eine Landing-Page, über die wir dann zu den Kollektionen kommen.

Und im Endeffekt zu jedem einzelnen Item. Das ist hier so ein Demo-Datensatz, den wir über die Demo-Seite gleich uns anschauen können. Und da werden wir die verschiedenen Bereiche uns nochmal anschauen.

Genau, das heißt, OTC API Feature übernimmt die Aufgaben, die ja vor der WFS gemacht hat. Wir können Daten abfragen, erzeugen, wir können die auch verändern oder auch löschen. Und jedes Feature in so einer Kollektion hat eine eindeutige Adresse. Das ist hier unten zu sehen. Da ist jedes Item über die Idee dann eindeutig referenzierbar.

Und wie wir eben schon in dem Screenshot gesehen haben, haben wir eine HTML-Anzeige mit Karte. Und können auch die Sachdaten uns anzeigen lassen. Und auf der anderen Seite haben wir aber auch die JSON-Anzeige. Wir haben Paging, wir haben diese Suchmöglichkeit nach den Datensätzen.

Und wir haben diese verschiedenen Parts des Standards, die entsprechend schon umgesetzt wurden. So und jetzt möchte ich mal kurz den Blick auf diese Demo-Seite richten. Das heißt, hier ist diese Landing-Page, die wir gerade angesprochen haben. Wir haben hier Kontaktmöglichkeiten, können uns als Provider hier eintragen.

Haben dann den Link zu den Kollektionen. Also wir sehen, was letztendlich hier in dieser Umsetzung umgesetzt wurde. Wir haben die Kollektionen, wir haben Processes, was hier vorliegt. Wir haben Teilmatrix-Sets. Und wir könnten jetzt hier uns die einzelnen Kollektionen anschauen.

Da haben wir hier beispielsweise diese Lakes, die wir gerade gesehen haben. Haben hier die Bounding Box zu dem Thema. Und können dann entsprechend die Alzen-Datensätze hier abfragen. Und haben dann die Bounding Box zoomen zu dem Feature.

Und haben entsprechend dann noch Attributdaten, die hier zur Verfügung stehen. Wir können wechseln zu der JSON-Ansicht und können entsprechend das auch als JSON anfordern. Da ändert sich hier das Format in der URL und können aber auch wieder diese HTML-Ansicht dann ansteuern.

Genau, wenn wir dann schauen, wie das Ganze konfiguriert ist, springen wir jetzt hier einmal in diese YAML-Datei, von der ich gesprochen habe. Da bin ich hier direkt zu den Lakes mal gesprungen. Da sehen wir, so ist der Syntax, also die Kollektion bekommt einen Namen. Sie ist vom Typ Collection.

Ich kann dann einen Titel, eine Beschreibung, ich kann Keywords vergeben. Ich kann dann angeben, in welcher Projektion die Daten vorliegen. Ich kann Links hinzufügen und kann dann bestimmen, welchen Extent die Daten haben.

Eine Bounding Box angeben und dann auch die Projektion. Das sind hier immer so Links, die man angibt. Dann kann ich entsprechend auch die Projektion angeben. Wenn ich jetzt transformieren möchte oder auch in anderen Projektionen die Daten unterstützt werden sollen, dann könnte ich hier auch eine Liste an Projektionen aufführen, sodass auch eine Transformation ermöglicht wird.

Die Daten könnten auch temporär sein. Das heißt, es könnte auch sein, dass ich vielleicht verschiedene Zeitstände in den Daten habe. Da könnte ich auch hier dann so einen Bereich aus den Daten auswählen. Dann kommt der nächste Part.

Ich muss sagen, wo kommen denn die Daten her? Das sind dann diese Provider, die Plugins, die dann hier zum Tragen kommen. Da ist es vom Typ Feature, der Provider, den ich nutzen möchte. Ich habe hier GeoJSON und verweise hier in diesem Fall auf die Daten und gebe noch die eindeutige ID an.

Das heißt, so wird jetzt so eine Collection definiert. Wenn wir noch mal weiter nach oben schauen, zu dem Server selber, da sehen wir die Adresse von dem Server. Wir haben hier die Kontakt an Daten, die Lizenz, den Provider.

Das, was wir da eben auf dieser Seite gesehen haben, das ist hier alles im YAML-Sundags definiert worden. Die Dokumentation dazu ist auch sehr gut. Das heißt, man kann sich zu jedem Blog das entsprechend anschauen. Wer vielleicht aus der Mapserver-Welt kommt, der wird das mögen.

Das erinnert so ein bisschen an Map-Dateien. Dann hat man auch diese ganzen Parameter und entsprechend ist es sehr gut strukturiert. Wir hatten schon eben CRS angesprochen. Das heißt, es kann sein, dass ich hier verschiedene Projektionen unterstützen möchte. Ich muss dann angeben, in welcher Projektion die Daten vorliegen und kann so entsprechend dann die Umrechnung in andere Projektionen ermöglichen.

Die CRS-Angaben sind in den Metadaten und auch für die Daten werden die definiert. Manche Feature-Provider machen die Umrechnung dann selber, wie zum Beispiel OGR oder PostGIS. Für manche Datenprovider, für CSV oder so, wird dann die Umrechnung von PyGeo API durchgeführt.

Hier sieht man nochmal die Swagger-Ansicht. Da ist es nämlich auch möglich, in der OGC API Features Transaction auszuführen. Das heißt, wir können auch Datensätze erzeugen oder können die bearbeiten

oder können auch Datensätze löschen und da kann man hier auch über diese Seite die Befehle sehr gut ausprobieren. Auch OGC API Maps wird unterstützt und da möchte ich hier auch mal zeigen, wie das konfiguriert wird. Da gibt es verschiedene Datenquellen, die wir quasi nutzen können.

Wir können das über Maps Server Mapscript bereitstellen oder über eine WMS-Fassade. Und da sehen wir jetzt hier einmal die Ansicht, wie es mit Mapscript wäre. Das heißt, wir haben hier eine Data-Angabe, wo die Daten liegen, haben den Type map

und können hier jetzt noch verschiedene Optionen setzen. Das sind hier Punktobjekte in diesem Fall. Das ist der Name von den Layer und hier verweisen wir auf ein SLD für das Styling. Und das ist jetzt hier für den MIME-Type, also für die Ausgabe.

Dann sehen wir hier dieses Beispiel für eine Fassade. Und zwar ist es so, dass es das auch für andere Dienste gibt, also auch für WMTS und für CSW gibt es solche Fassaden. Und entsprechend kann ich hier auf einen anderen Dienst zugreifen

und habe jetzt hier quasi als Data-Angabe, wird hier ein anderer Dienst angesprochen. Hier noch einmal eine Folie, wo man sieht, wie die Aufrufe dann sind. Wenn ich jetzt so ein OTC API Maps-Projekt nutze, das heißt, ich kann da eine B-Box-Abfrage machen

oder ich kann so einen Zeitparameter mitgeben. Oder kann hier auch die B-Box die Projektion von der B-Box angeben, sodass ich dann auch transformierte Ausschnitte entsprechend anfordern kann. Ja, dann könnte ich OTC API Records verwenden.

Das heißt, da könnte ich quasi so einen Katalogdienst erzeugen und würde da mit Elastic Search Catalog oder mit so einer CSW-Fassade meine Daten bereitstellen und könnte die hier zum Beispiel im QGIS dann einbinden und danach suchen.

Dann OTC API Processes könnte ich nutzen und kann da eigene Python-Skripte erstellen. Und hier gibt es ein Demoprojekt, Hello World, da könnte ich einen Namen übergeben und dann entsprechend eine Nachricht und würde dann entsprechend eine Antwort zurückbekommen. Und das kann ich auch durch eigene Python-Skripte, die ich erstelle, dann entsprechend erweitern.

Genau, Environmental Data Retrieval, damit kann ich Umweltdaten anfordern. Das könnten zum Beispiel Netz-CDF-Dateien oder ZAH-Dateien sein und könnte die entsprechend hier zu einer bestimmten Koordinator abrufen.

Oder auch Stack wird unterstützt, da könnte ich zum Beispiel GRIP2, also solche Wetterdaten anfordern und habe hier noch einen weiteren Standard. Es gibt auch diverse Service Provider, die unterstützen würden beim Umstieg auf PyGeo API.

Das ist auch ein sehr offenes Projekt, wo man auf jeden Fall eingeladen ist auch mitzumachen. Und was ich noch sehr empfehlen kann, hier gibt es einen Workshop, das ist über Docker installiert. Und da gibt es ganz schöne Beispiele, über die man dann die einzelnen Standards sich auch anschauen kann.

Und dann gibt es hier noch verschiedene Kommunikationswege mit dem Projekt, Mailing-Liste, Chat und auch Meldungen auf Social Media. Und damit möchte ich auch zum Ende kommen. Ich hoffe, es waren ein paar Anregungen dabei, Ideen.

Und auf jeden Fall hoffe ich, dass es Lust gemacht hat, dieses Projekt sich mal genauer anzuschauen. Es gibt da auf jeden Fall noch ganz viel zu entdecken. Es ist gut dokumentiert, es gibt tolle Demos und Workshop-Unterlagen. Und es ist auf jeden Fall auch ein guter Einstieg, um sich mit dem Thema, mit den neuen OGC-Standards zu befassen.

Ja, in Juli ist dann die Phosphory in Tartu. Da gibt es auch wieder einen Workshop von dem Team. Wer da die Möglichkeit hat, zu kommen, das lohnt sich sicherlich. Und ansonsten danke ich für die Aufmerksamkeit.

Herzlichen Dank, Astrid. Ich freue mich hier gleich. Es ist nicht eine Frage, die am meisten Votes bekommen hat, sondern eine Aussage. Und ich lese das sehr gerne vor. Wir finden Sie toll, Frau Emde.

Ach so, okay. Ich habe keine Geschlechterangabe dahinter. Dann doch noch zu einer Frage. In welchen Anwendungsgebieten kann und wird Pi-GeoAPI bereits eingesetzt? Es sind eigentlich zwei. Was ist in Zukunft geplant, auch im Hinblick von Anwendungsgebieten?

Genau, ich hatte ja schon angesprochen, dass ich da jetzt nicht keine Entwicklerin bin, sondern das Projekt eher so verfolge. Und ja, also ich weiß, dass der Tom Kalides, der arbeitet in Kanada und hat viel mit Wetterdaten zu tun.

Und die nutzen das halt in ihrem Stack und nutzen das produktiv, um die Wetterdaten beispielsweise da zu veröffentlichen. Und ich denke schon, dass der Ehrgeiz von dem Projekt ist, alle Standards umzusetzen und da am Ball zu bleiben. Also, die sind auf jeden Fall sehr, sehr engagiert.

Und es ist auch so, dass es da eine ganz große Schnittmenge auch zu anderen Projekten gibt aus der US-Geo. Und da auch die US-Geo-Projekte an sich sehr, sehr aktiv sind, jetzt die neuen Standards umzusetzen. Eine weitere Frage war, was sind die Unterschiede zu bestehenden Projekten, wie beispielsweise Geo-Server?

Ja, also genau, letztendlich, wenn man jetzt schon so einen Stack hat und hat den Geo-Server im Einsatz oder Kuge-Server oder Map-Server, dann gibt es dort auch Umsetzung der Standards. Also auch bei allen drei Projekten ist auch OTC API Features zum Beispiel umgesetzt und kann auch mit der bewährten Software genutzt werden.

Aber ja, dieses Pi-Geo-API-Projekt zeichnet sich schon sehr da aus, dass die sehr eng mit dem OTC da zusammenarbeiten und ja, da bei der Standardentwicklung auch vorne dabei sind. So würde ich es formulieren.

Dankeschön. Dann möchte ich hier die Fragerunde öffnen. Gibt es Fragen aus dem Publikum? Da ist eine Frage.

Ja, hallo. Wenn ich das eben richtig gesehen habe, ist dort auch schon der Part 4 von der OTC API Features umgesetzt, ist das richtig?

Part 4, ja genau, das ist schon so weit umgesetzt. Obwohl das noch Draft ist? Also das Team versucht schon immer so nah wie möglich dann auch das umzusetzen, was quasi jetzt schon da entwickelt wird. Ist das der einzige Server, der das hat bisher oder gibt es noch andere Implementierungen?

Vielleicht weißt du das noch jemand anderes? Keine Ahnung. Also bei diesen Sprints sind halt auch noch andere Projekte immer vertreten und ich weiß jetzt aber nicht genau inwieweit GeoServer zum Beispiel auch immer versucht da am Ball zu bleiben, aber ich weiß nicht, genau, der Pirmin Kalberer, der ist ja auch sehr hinter dir oder Jakob?

Ich wollte selber sagen, ich habe das auch mal ausprobiert mit dem Part 4 und meines Wissens geht es nicht mit PostGIS, sondern nur mit einer anderen Datenquelle, die ich sehr exotisch fand. Also es geht an sich schon, aber eben noch nicht mit einer Datenquelle, die ich eben häufig benutzen würde.

Das ist mein letzter Stand, da müsste man vielleicht auch nochmal verifizieren. Danke. Ich wollte noch dazu sagen, dass bei GeoAPI quasi die OGC-Referenzimplementation für einige Standards ist, das heißt die implementieren bereits, bevor der Standard da ist.

Also das ist auch ein Fortschritt, dass mit der Standardisierung auch schon eine Implementation mitentwickelt wird. Und jetzt weiß ich nicht in welchen, also in anderen Teilen sind andere Projekte führend und Referenzimplementationen, z. B. der LD-Proxy hat für gewisse Standards ist da an der Front und umsetzt schon die Entwürfe um.

Aber jetzt sagen wir GeoSaver und so, das sind dann eher die implementieren dann die fertigen Standards. Genau, so würde ich es auch sagen.

Weitere Fragen? Hallo, jetzt mal aus Sicht der VAR Group als langjährige GIST-Consultant.

Für was für ein Projekt würdest du denn heute dazu tendieren, bei GeoAPI zu verwenden, anstelle von jetzt einem System, was schon battle-proven ist, wie z. B. Mapserver oder GeoServer. Also ihr z. B. nutzt ja glaube ich sehr viel Mapserver auch.

Wie würdest du diese Entscheidung fällen, wenn ich ankomme? Also mal zwei Beispiele, irgendwie so ein Forschungsprojekt, fernerkundungslastig und irgendeine Gemeinde mit den klassischen Daten, irgendwie Naturschutzgebiete und dies das, tralala. Ja, das ist eine gute Frage.

Also wenn jetzt der Mapserver, GeoServer, Kugiserver den Standard, den du benötigst, schon umsetzt, dann brauchst du jetzt ja nicht zusätzlich jetzt noch PyGeoAPI einrichten. Wenn du jetzt eher Richtung API-Features gehst oder Maps oder so und hast das schon vorliegen. Aber einige Standards sind ja nicht umgesetzt, beispielsweise vom Mapserver-Projekt oder GeoServer.

Und da ist es natürlich dann schon attraktiv, diese Lösung dann zu nehmen. Aber genau bisher habe ich mich jetzt auch eher aus Interesse damit beschäftigt, wo wir das im Moment noch nicht bei der VAR Group im Einsatz haben. Und das wird sich jetzt noch zeigen, ob da Anfragen in dem Bereich dann aufkommen.

Da oben ist noch eine Frage? Nein, ich glaube da winkt noch jemand. Da winkt jemand? Okay, gut, ja dann schön.

Ich habe es auch gemeint, ja. Die testen uns, ob wir auch wirklich aufpassen. Gut, wenn außer Winken keine Fragen mehr sind, dann nochmal schönen Applaus für Astrid.