Hallo zusammen, ich bin Katrin und gemeinsam mit meinem Kollegen Ralf werden wir in den nächsten 20 Minuten vorstellen, wie wir Stack für unsere freien Geodaten verwenden. Stack Spatial Temporal Asset Katalogs, wir haben es gerade von

Matthias gehört, was da alles dazu gehört und wie die Spezifikation aussieht. Wir setzen Stack ein auf Basis von Open Source Software und Cloud-Technologie und wie das Ganze funktioniert werden wir jetzt vorstellen.

Kurz zu uns, wir kommen vom Landesamt für Geoinformation und Landesvermessung Niedersachsen. Das Amt gliedert sich in Katastroemter, Regionaldirektionen und die Zentrale in Hannover und das sind insgesamt 53 Standorte. Wir sind mehr als 2000 Mitarbeitende und kommen aus den Bereichen Geoinformatik, Vermessung,

Verwaltung und Informationstechnologie. Zu unseren Aufgaben der Landesvermessung zählen die Eigentumssicherung, die Transparenz des Grundstücksmarktes, die Kampfmittelbeseitigung, Gefahrenabwehr, Umweltschutz und die Daseinsvorsorge.

Ralf und ich und eine ganze Menge weitere Kolleginnen und Kollegen, einige sind heute auch hier und werden auch in den nächsten Tagen Vorträge halten, arbeiten dabei im Kontext der Modernisierung der Verwaltungsaufgaben in agilen DevOps-Teams. Diese bezeichnen wir bei uns als GeoLabs. Ich arbeite in der Rolle als Product Owner und Ralf als Developer.

In den GeoLabs arbeiten wir nach Scrum, Nutzen, Open Source und Cloud-Technologien. In unserem in Hannover angesiedelten Team Spatial Data Infrastructure Service erarbeiten wir Lösungen, um die Geodaten der Landesvermessung mit Cloud-Infrastruktur modern und sicher nutzbar zu machen.

Und um über Stack auf die Geodaten des LGN zugreifen zu können, entwickeln wir in unserem Team Microservices zur Katalogisierung der Geodaten nach der Stack-Spezifikation. Und in Zusammenarbeit mit den 14 anderen DevOps-Teams wird die Vision einer Geodaten- und Serviceplattform umgesetzt.

Und der Stack-Service wird dabei nur einer von vielen Buchbaren-Services auf der Plattform sein. Kommen wir aber jetzt zu Open Data, HVD und Stack. Das LGN betreibt seit 2021 diese Open Geodata-Website, über die freie Geodaten heruntergeladen werden können.

Über diese Website kann man über eine Kartenanwendung manuell kacheln, auswählen und diese herunterladen. Die meisten Geodaten sind außerdem über Standard-OGC-Services wie WMS, WFS oder WCS verfügbar.

Über eine API wurden die Geodaten bislang noch nicht bereitgestellt. Und ab Juni diesen Jahres soll sich das ändern und an dieser Stelle hier auf der Website dann Rastedatensätze über die Stack-API verfügbar sein.

Und weitere APIs aus der OGC-API-Familie sollen folgen. So, den gesetzlichen Rahmen überhaupt die Stack-API anzubieten, die gibt die Europäische Richtlinie vor, die Durchführungsverordnung zur Festlegung bestimmter hochwertiger Datensätze.

In dieser Richtlinie steht, dass öffentliche Geodaten, die das höchste sozioökonomische Potential haben, kostenlos und frei über eine API zur Verfügung zu stellen sind. Und mit einer API sollen durch eine breite Nutzerbasis Mehrwerte für die Gesellschaft generiert werden. Und durch den Einsatz von Restful-Prinzipien wird dann der Nutzerkreis von bislang GIS-Nutzenden auf auch IT-Entwickelnde ausgeweitet.

Wir im Team haben uns mehrere Spezifikationen angeschaut und für die Rastedaten haben wir uns für Stack entschieden, weil Stack alle Anforderungen dieser Richtlinie erfüllt und dabei auch noch eine gute Durchsuchbarkeit der Geodaten bietet.

Und die für HVD explizit geforderte freie Lizenz, die kann man sehr gut in dem Feld License, Matthias hat das vorgestellt, in einer Stack-Collection abbilden. Bei uns im LGN werden unter anderem diese hochwertigen Daten geführt, die dann ab Juni über eine Stack-API bereitgestellt werden.

Das sind die topografischen Karten, historische Karten wie die preußische Landesaufnahme, aber auch die digitalen Ortofotos, Geländemodelle, Oberflächenmodelle und 3D-Gebäudemodelle.

Die HVD-Durchführungsverordnung fordert, dass für jeden dieser als API bereitgestellten Datensätze ab Juni dann eine API-Service-Beschreibung, wie die hier dargestellte, verfügbar ist. Über die standardisierten Stack-API Endpunkte können die Daten angefragt, gesucht und aus anderen Anwendungen angesprochen werden.

Zusätzlich verwenden wir bei uns im LGN die transaktionalen Endpunkte, hier in orange dargestellt, mit denen wir regelmäßig neue Stack-Items ergänzen bzw. unsere Kataloge aktualisieren.

Die Artis-Strategie unserer Landesvermessung gibt vor, dass die Geodaten auch intern über standardisierte Schnittstellen, wie Stack, genutzt werden und nach dem Prinzip Eat Your Own Dog Food greifen auf ein und dieselbe Cloud -Ressource dann andere öffentliche Verwaltungen, unsere Kundinnen und Kunden, aber eben auch die Kolleginnen und Kollegen zu.

Die Kolleginnen und Kollegen in den Katastroemptern, die nutzen Intian Kugis und damit sie eben Kugis und Stack, also Stack -Kataloge, die Assets nutzen können, wird das Plugin Stack-API-Brause verwendet, um die Assets direkt in ein Kugis-Projekt einzubinden.

Und das Schöne ist, dass die Stack-Assets direkt als Layer in Kugis eingebunden werden können, ohne dass die Geodaten heruntergeladen werden müssen. Wir setzen dafür das Format Cloud-Optimized-Geotiff in unseren Stack-Assets ein, was ein dynamisches Nachladen ermöglicht.

So, kommen wir jetzt zum ganzen Kern unserer Entwicklungsarbeit im Team. Damit unsere Geodaten in Collections, Items und Assets strukturiert nach der Stack-Spezifikation verfügbar sind, haben wir in unserem Team das Produkt Stack-Service erstellt.

Der Stack-Service ist ein Self-Service für Geodatenbereitstellende, der die Geodaten nach Stack katalogisiert. In dem Schema von links nach rechts bringen also die Nutzer ihre Geodaten mit und lassen sie von dem Service automatisiert in einen Spatio-Temporal-Asset-Katalog überführen.

Die zuerstellende Stack-Struktur ist dabei frei wählbar. Und es ist das Ziel dieses Produkt auch anderen Geodaten-Haltenden bereitzustellen über die schon erwähnte Service-Plattform der Landesvermessung.

So, Ralf, du stellst uns jetzt vor, wie unser Stack-Service funktioniert und nach welchen Kriterien er entwickelt wurde. Genau. Vielen Dank, Katrin. Ja, also in den Geolabs erstellen wir unsere Dienste dann nach einer Referenzarchitektur, die wir mal festgelegt haben.

Und neben der Entwicklung für die Cloud sind dann halt so Sachen wie die Hochverfügbarkeit und die Skalierbarkeit sehr wichtige Themen, damit die Anwendungen jederzeit erreichbar sind und auch keine langen Wartezeiten bei den Seitenaufrufen entstehen. Und aufbauend auf einer Microservice-Architektur steht bei unseren Anwendungen immer die Sicherheit im Fokus. Also

neben Verschlüsselungen der Kommunikationswege sowie minimalen Zugriffsfreigraben für die Anwendung wird dort das Zero-Trust-Prinzip verfolgt. Und dann des Weiteren soll die Kommunikation der Dienste restful sein und der Austausch zwischen den Diensten soll halt mit Event-Streaming passieren.

Ja, das Ziel ist eine Bereitstellung von Diensten für die Mitarbeitenden, das hatte Katrin gerade schon gesagt, um dann im Self-Service eine Stack-Instanz zu administrieren und auch diese mit Daten zu befüllen. Und wie wir das jetzt auf die Referenzarchitektur umgesetzt haben für unseren Stack-Service, zeige ich jetzt in einer Übersicht. Das Diagramm baut sich jetzt gleich so Stück für Stück

auf, das ist auch stark vereinfacht, beinhaltet nur die wichtigsten Dinge, um das halt hoffentlich verständlich rüberzubringen. Ja, als Cloud-Anbieter kommt bei uns derzeit die IBM Cloud zum Einsatz und alle Dienste laufen dabei in der Location in Frankfurt. Und die Basis unseres Services ist zum einen unser Stack-Service, aber dann auch die Stack-Fast-API

hier mit dem PG-Stack-Backend, das ist noch ein weiteres Backend zu dem, was Matthias gerade schon sagte. Und die Stack-Fast-API haben wir leicht modifiziert, um dort einen weiteren API-Endpunkt anzubinden, um den Extent der Collection updaten zu können, sowie dann noch die Einbindung von einem Open

Policy Agent zur Autorisierung, damit nicht jeder Daten draufschreiben kann, sondern nur der Ersteller dieser Instanz. Ja, der Stack-Service besteht dann eben danach aus vier weiteren Microservices, deren Funktionität zeige ich euch gleich noch so ein bisschen. Ich werde jetzt nicht auf jeden Service einzeln eingehen, weil das auch den Rahmen sprengen würde, aber so grob das, was die machen, das werde ich schon erklären.

Ja, und die haben wir alle in Golang selbst implementiert, das sind also keine anderen Bibliotheken, die wir nutzen. Ja, alle Anwendungen laufen bei uns dann in einer Serverless-Plattform namens Code Engine, so heißt sie bei IBM, und die basiert quasi einfach nur auf Knative, unterstützt damit auch Scale to Zero, was

bei uns dann halt im Ruhezustand keine Kosten verursacht und halt auch ein guter Kostenvorteil für uns ist. Der öffentliche Datenverkehr zu unseren einzelnen Diensten wird bei uns mit Traffic und dem OS2-Proxy abgesichert. Der OS2

-Proxy sorgt dabei dann für die Kommunikation mit unserem OADC-Provider innerhalb der Geolabs, das ist ein eigenes Team, und die greifen wiederum auf die Bund-ID zurück im Hintergrund, und ohne erfolgreichen Login wird dabei dann Zugriff auf die weiteren Microservices abgeriegelt. Also man muss unbedingt ein Bund-ID-Konto haben, um unsere Dienste im Moment nutzen zu können.

Und wir müssen den dementsprechend auch erst mal freischalten, damit nicht irgendjemand, der schon ein Bund-ID-Konto hätte, einfach anfängt darum zu spielen. Ja, diese Anwendungen laufen alle in einer Virtual Private Cloud Umgebung bei IBM, in der wir einen Kubernetes-Cluster installiert haben. Und des Weiteren haben wir dann noch weitere Managed Services von IBM im Einsatz, um bei uns den Administrationsaufwand im Team gering zu halten.

Also neben Datenbanksystemen wie Redis oder Postgres kommen dann noch Monitoring-Lösungen auf Basis von Systic und eine Logging-Lösung auf Basis von LogDNA zum Einsatz. Die helfen uns dann bei der Überwachung und Analyse der Dienste und schlagen gegebenenfalls auch dann

Alarm, falls mal irgendwas nicht so läuft, wie es laufen sollte oder irgendwelche falschen Requests reinkommen. Ja, hat auch noch den Vorteil, dass wir diese Managed Services nutzen, dass die Datenbank sich zum Beispiel auch via Autoscaling halt an die Gegebenheiten anpassen können. Hier ist jetzt nur eine Stage dargestellt auf der rechten Seite mit Code Engine und bei den Datenbanken.

Wir haben aber je Entwicklungsstage ein eigenes Projekt dafür jeweils, also für Development, Staging und Production. Um das aber ein bisschen übersichtiger zu gestalten, habe ich jetzt nur eine dargestellt. Bis auf die Leistungsdaten, was dahinter steht, also Production hat natürlich etwas mehr Power als jetzt Dev oder Staging, sind die aber sonst alle gleich.

Und mit IBM Schematics nutzen wir dann noch eine Provisionierungslösung als Dienst von IBM, was auf Terraform basiert. Zusammen mit Argo CD und Argo Workflows setzt das quasi unser GitOps-Konzept um für unsere Anwendung. Somit sind dann alle Zielzustände bei uns auch im Git versioniert und ungewollte Abweichungen, also

das bekommen wir mit per Meldung und können diese dann natürlich auch direkt rückgängig machen. Ja, somit sind dann auch alle Anforderungen an unsere Referenzarchitektur für unseren Stack Service erfüllt. Und dann können wir schon weiterschauen und beschäftigen uns jetzt mal mit der Erstellung einer neuen Stack Instance und deren Befüllung.

Ja, zum Provisionieren einer neuen Stack Instance sprechen wir einen unserer Microservices aus dem Stack Service halt an, ich habe es mal rot umkringelt. Und dieser ist Open Service Broker konform und der ist dann für die Administration der einzelnen Stack Instancen zuständig.

Ja, dabei können wir noch verschiedene Parameter mit übergeben für die Konfiguration der Instance, so was wie ein Titel oder eine Description. Aber auch ob die Instance halt public sein soll, also von öffentlich oder ohne Zugangsdaten erreichbar ist oder ob diese privat sein soll und ob diese in der Code Engine skalieren darf. Also bei MinScale 0 darf das runter skalieren auf 0, keine Kosten erzeugen,

kann man aber auch hochstellen, je nachdem wie viel Geld man ausgeben möchte. Ja, diese Informationen werden dann einfach an den Broker gesendet via Post Request. Als Antwort erhält man dann zusätzlich den Namen der Instance, den vergeben wir mit einer Unique ID. Da gibt es noch keine Möglichkeit das selbst zu wählen und man erhält so die URL der Instance zurück unter der diese erreichbar ist.

Im Hintergrund werden dann verschiedene Sachen angelegt, in Traffic wird zum Beispiel noch ein Ingress angelegt und so weiter, damit das weitergerutet wird. Und nach ca. 30 Sekunden ist die Instance dann verfügbar und man kann mit ihr arbeiten.

Genau das soweit zur Erstellung. Im zweiten Schritt wollen wir die Instance dann befüllen. Dabei erstellen wir dann erstmal ein sogenanntes Mapping mit einem weiteren Microservice. Und dieses Mapping kann man sich vorstellen wie so eine Schablone, aus der wir dann Teile von Geodaten in diese Schablone einfügen und darin ein Stack Item erzeugen. Hier an dem Beispiel habe ich jetzt mal die digitalen Autofotos von Niedersachsen genommen.

Da haben wir zum einen einen Cloud Optimized GeoTiff und XML Metadateien vorliegen. Und aus diesen Daten können wir dann mit Hilfe eines weiteren Microservices Metadaten extrahieren. Wie zum Beispiel aus der XML Datei den Dateinamen oder aus dem Bild die Bounding Box. Im Hintergrund läuft das quasi in dem Microservice GDAL.

Der extrahiert das, um das dann in die Schablone einzusetzen. Wie man das jetzt genau in die Schablone einsetzt, habe ich jetzt mal nicht dargestellt, weil das ein bisschen sehr abstrakt ist. Aber das kann ich, wenn jemand Interesse hat, im Nachhinein nochmal zeigen. Genau, und die Syntax unserer Schablone ermöglicht uns das dann zudem weitere Operationen auf den einzelnen Feldern durchzuführen.

Hier bei dem Dateinamen sieht man zum Beispiel, dass die Punktiv-Endung entfernt wurde, um daraus dann die ID eines Stack Items zu generieren. Ja, und was wir dann am Ende haben, ist, dass wir ein vollständiges Stack Item erzeugt haben, welches dann aus den vorhandenen Geodaten erzeugt wurde.

Insofern die Struktur der Geodaten dann immer gleich bleibt, und das sollte bei den digitalen Autofotos in der Regel der Fall sein, können wir das Mapping immer wieder auf weitere Datensätze anwenden, um daraus ein Stack Item zu erzeugen. Also im nächsten Schritt können wir dann halt einen sogenannten Batch anstoßen, der dann eine Art Massenverarbeitung darstellt.

Wie gerade gesagt, was mit einem Datensatz im Mapping funktioniert, geht dann natürlich auch mit ganz vielen, und für einen Batch benötigen wir dann einfach nur noch die Mapping ID, die wir vorher erstellt haben, die Stack ID, die wir auch beim Erstellen der Instanz zurückbekommen haben, sowie die ganzen Datensätze, die eingefügt werden sollen, also URLs zu den Dateien. Und haben wir diese Daten dann alle aggregiert, können wir das auch wieder abschicken an unseren einen Microservice,

erhalten da eine Batch ID zurück, mit der wir den Status der Verarbeitung dann abfragen können. Und was jetzt noch passiert ist, ist, dass der eine Microservice im Hintergrund die Daten in einen Event Que geschrieben hat, und diese wird nun von einem letzten Microservice abgearbeitet,

und dieser letzte Dienst kann sich so weit noch skalieren oder weitere Worker starten, um die Event Que abzuarbeiten und halt dann auch um die Parallel abzuarbeiten, und dementsprechend halt auch das schneller zu erledigen. Ja, und sobald ein Stack Item durch die verarbeitenden Dienste abgearbeitet wurde und in unsere Schablone eingesetzt wurde,

haben wir ein Stack Item, das wird noch validiert, und wenn das alles passt, wird das in unsere Stack Instanz geschrieben. Und nach der Verarbeitung der ganzen Daten wird dann noch mal am Ende der Extend von der Collection geupdatet, damit das sich an die aktuelle Bounding Box und an die zeitliche Ausdehnung anpasst.

Ja, hier sehen wir dann das Ergebnis unseres Batchlaws. In unserem Beispiel hatten wir 360 Items herausgesucht, und diese wurden in weniger als zwei Minuten verarbeitet und in die Stack Instanz eingefügt. Fehler sind dabei Gott sei Dank nicht aufgetreten. Und damit ist die Aufgabe unseres Stackservice eigentlich schon erfüllt. Wir haben eine Instanz erstellt und Daten bereitgestellt.

Und wie das Ergebnis dazu dann aussieht, wollen wir uns jetzt noch mal eben einmal im Stack Browser anschauen. Und da sieht man auf der Karte, dass unsere ganz zufällig ausgewählten Kachen sogar ein ganz schönes Bild ergeben. Und als Fazit können wir jetzt dann halt schon mal sagen, ja, wir haben jetzt einen Dienst mit unserem Stack Service,

der uns einen einfachen Workflow zur Verfügung stellt, um mit wenig Aufwand verschiedene Datensätze zu katalogisieren und das dann auch noch ohne wirklich Programmierkenntnisse besitzen zu müssen, was wahrscheinlich auch noch ein sehr großer Vorteil ist. Ja, neben den digitalen Auto-Fotos können wir dann natürlich auch alle weiteren Daten für HVD zum Beispiel zur Verfügung stellen und diese Daten wird sich dann auch innerhalb kürzester Zeit mal wieder updaten.

Also man muss nicht immer ewig warten, bis sowas passiert ist. Das kann man alles automatisieren. Ja, und mit diesen tollen Aussichten auf aktuelle freie Geodaten aus dem LGLN wollen wir uns fürs Zuhören bedanken erstmal und stehen jetzt noch für Fragen zur Verfügung. Danke.

Ja, vielen Dank für den Vortrag. Habt ihr die Details, die ihr da ausgewählt habt? Habt ihr das rescriptet und könnt ihr da auch den Font-Type ändern? Nee, das war tatsächlich Handarbeit. Ja, es gibt verschiedene Fragen. Gibt es hier im Raum Fragen eigentlich?

Dann, wir bräuchten das andere Nico für Fragen im Raum. Ja, eine kleine Frage nur. Sie hat ja eben gezeigt, dass die ID automatisch der Dateinahme wäre. Wie würde es damit umgehen, wenn man jetzt Daten mit dem gleichen Namen hochlegt? Sie hat ja eben gesagt, man kann dadurch leicht updaten.

Überschreibt ihr dann einfach die alte oder wirft das als Fehler raus und sagt, wie soll ich damit umgehen? Ja, also theoretisch würde das etwas überschreiben, ja. Aber du musst halt der Datenbereitsteller auch wissen, okay, wenn ich jetzt die Datei hochlade, was passiert damit? Also, dass ich die überschreibe oder muss ich da eine Dateibenehmung noch mit reinmachen? In unserem Beispiel war zum Beispiel das Datum noch mit drin.

Das würde das verhindern, aber man kann halt auch jedes andere Feld als den Dateinahmen auswählen. Zum Beispiel aus dem Metadatenfeld irgendwo was anderes ausziehen oder auch eine Unique ID generieren. Ja. Dann haben wir da noch eine Frage. Oder wir haben auch verschiedene Fragen, die hier auf den Platt zu sehen sind.

Hi, war jetzt bei den zwei Minuten Verarbeitungszeit das Hochladen in die Cloud schon bei oder lagen die Daten schon in der Cloud? Weil das kam mir jetzt sehr schnell vor. Ja, die Daten lagen schon in der Cloud, also das ist ein Voraussetzung, dass die da schon liegen. Man kann die Verarbeitungszeit trotzdem noch ein bisschen runterdrehen, indem man mehr Power draufgibt. Das war jetzt eine relativ kleine Instanz, die das abgearbeitet hat.

Es kommt aber halt immer ein bisschen darauf an, wie viel Metadaten auch ausgewertet werden in dieser Schablone. Ja. Ist zukünftig auch die Bereitstellung von Vektordaten per Stack geplant?

Moment, Moment, gleich nochmal ins Mikro, bitte. Die Antwort ist nein, wir wollen es nicht tun. Aber wenn, also die Entwicklung oder unser Entwicklungsplan sieht vor, dass wir auch für OGC API Features eine Lösung erstellen,

mit dem wir automatisiert OGC API Features Instanzen bereitstellen können für unsere Vektordaten. Wenn das zeitlich nicht passt, kann man auch, Matthias hat es gesagt, Vektordaten kacheln,

also Geo-Packages oder ZIP-Files als Assets eines der Katalogs zur Verfügung stellen. Also es ist eine Variante, die wir aber nicht präferieren, aber die durchaus möglich ist umgesetzt zu werden. Weil der Stack Service ist selbst da. Ja, Dankeschön. Nächste Frage. Wie wird der Stack in die GDI.de und damit um Klammern nach Transformation in dcat-ap in GovData überführt?

Werden die Metadaten für die Daten und Dienste wieder verwendet? Ich habe die Frage selber nicht verstanden, aber ihr wahrscheinlich. Bei uns in der Landesvermessung werden die Metadaten manuell oder werden in eine Anwendung geführt

und momentan gibt es noch keine Verbindung zwischen Stack und dem Metadatensystem, was bei uns eingesetzt wird.

Aber durchaus können die Daten ja beschrieben werden und kann in dem Metadatensystem angegeben werden, dass wir auch eine Stack-API zur Verfügung stellen und die ORL kann auch dort in der GDI in dem Metadatensystem hinterlegt werden.

In einigen Bundesländern, zum Beispiel in NRW, werden seit vielen Jahren hochwertige Geodaten auch DGM kostenfrei zur Verfügung gestellt. Warum in Niedersachsen erst jetzt? Diese Frage würde ich gerne einem anderen Kollegen weitergeben, der sitzt hier in der ersten Reihe.

Aber ich kann die Frage nicht beantworten. Weil Verwaltung manchmal nur funktioniert, wenn entweder politischer Wille da ist, der war in NRW gegeben, der war auch in Hamburg gegeben und in manchen anderen Bundesländern,

oder dann funktionieren auch Bundesländer wie Niedersachsen ganz gut, wenn es Gesetze oder Durchführungsverordnungen der EU gibt, die unmittelbar gelten. Mehr will ich dazu auch gar nicht sagen.

Wie wird Stack bei LGLN für alle Daten eingesetzt oder nur für Rasterdaten? Das habt ihr eigentlich nur für Rasterdaten? Erstmal nur für Rasterdaten. Der Zugriff auf den Stack Service API ist nur mit BundID möglich oder ist der Zugriff auf die konkreten Daten?

Die konkreten Daten, wenn man die Instanz öffentlich macht, kann man so abgreifen. Aber das Erstellen einer Instanz und das Befüllen einer Instanz, da braucht man halt eine Autorisierung für, damit wir auch ein bisschen so bestimmen können, wer ist da gerade drauf, wer nutzt es, um halt auch die Kosten gerade noch in den Griff zu halten.

Langfristiger Plan ist es wirklich, dass man so eine Geo-Plattform gibt, auf der man sich solche Service dann selbst buchen kann. Also dann quasi jeder wird das nutzen könnte, derzeit noch nicht. Ich hoffe, dass du es damit beantwortest. Danke. Kann Stack auch den OGC-CSW ersetzen?

Das kann ich nicht beantworten. Magst du dazu was sagen? Der Nachfolger von CSW ist ja quasi OGC API Rackets. Und dann wäre Rackets der Ersatz. Und Stack war dann, wie ja eben schon mal nach dem Vortrag in einer Frage beschrieben,

wäre dann quasi ein Profil, der auf Rackets auch laufen kann, um zusätzliche Beschreibungen hinzuzufügen und Daten verfügbar zu machen. Okay, danke. Und die? Ja, ich denke, da haben wir auch die letzte Frage beantwortet, die hier kam. Vielen Dank. Nochmal Applaus bitteschön für den Vortrag.