Name des Good Practice
OGC APIs in Bund und Ländern API Umsetzung in der Urban Data Platform Hamburg
Beschreibung des Good Practice
OGC APIs verfolgen den Ansatz den Zugriffs auf verteilte Geodaten , sowie die Integrierbarkeit in beliebige Webanwendungen und Prozesse zu vereinfachen. Unter der Überschrift OGC API werden die Standards des OGC seit 2017 grundlegend überarbeitet und modernisiert. Dieses Good Practice Beispiel geht auf Fragen ein, die sich bei der Umsetzung von OGC API - Featuresin der Urban Data Platform Hamburg (s. hier) gestellt haben. Diese betreffen auch Aspekte der zukünftigen Umsetzung weiterer OGC APIs, die sich auf einen Datensatz beziehen lassen (z.B. Tiles, Styles, Maps).
Schlagworte
Geben Sie ein oder mehrere treffende Schlagworte für das von Ihnen eingereichte Good Practice an.
Vorschläge: Geodienste, OGC, APIs, , OGC API, Features, REST, OpenAPI
Nutzerkreis
Bezogen auf OGC API: Um die „alten“ OGC-Dienste wie WMS, WFS in Anwendungen und Prozesse einbinden zu können, benötigte man bisher spezielle Kenntnisse der zugrundeliegenden OGC-Standards. Mit der Umstellung auf die neuen OGC APIs soll die Nutzbarkeit und Anwendung von Geodaten stark vereinfacht werden und der Nutzerkreis damit vergrößert werden.
Bezogen auf Good Practice: Datenbereitsteller der GDI-DE
Architektur Komponente
Das
Ein Großteil der OGC APIs lässt sich auf einen Datensatz beziehen (z.B. Tiles, Styles, Maps). Da es seitens OGC keine eindeutigen Vorgaben gibt, war zu entscheiden, wie verschiedene OGC APIs für einen Datensatz nach außen veröffentlicht werden. Soll es eine integrierte OGC API oder viele verschiedene OGC APIs pro Datensatz geben?
Good Practice Beispiel bezieht sich auf Geodatendienstkomponenten Good Practice Beispiel beschreibt eine Neuerung der Geodatendienstkomponenten in Bund und Ländern die sich direkt auf nahezu alle übrigen Architekturkomponenten der GDI-DE auswirken.
Verweise auf verwendete Normen oder Standards
Das vorgeschlagene Dieses Good Practice Beispiel bezieht sich auf die Nutzung der hier aufgeführten OGC APIs in der GDI-DEbeschreibt die Umsetzung von OGC API - Features in der Urban Data Platform Hamburg. Dabei werden auch einige Aspekte der zukünftigen Umsetzung weiterer OGC APIs, die sich auf einen Datensatz beziehen lassen (z.B. Tiles, Styles, Maps), adressiert.
Sonstige Verweise
Geben Sie andere Verweise an, z. B. auf Papiere, Präsentationen usw.
- Website der OGC zu OGC APIs
- Elearning Modul OGC API Features: OGC API - Features — OGC e-Learning 2.0.0 documentation (opengeospatial.github.io)
- Beispielumsetzung der Länder:
- Hamburg: OGC API - Features Hamburg
- hinzufügen sobald veröffentlicht: Tutorial/Guide zur Nutzung OGC API - Features, das gerade erarbeitet wird (zukünftig unter https://lgv-hamburg.atlassian.net/wiki/spaces/EDDUN/pages/109183062/OAF+OGC+API+Features)
Relevanz und erwarteter Nutzen
OGC APIs vereinfachen und modernisieren den Web-basierten Zugriff auf Geodaten. Durch die Nutzung gängiger Web-Standards (z.B. REST, OpenAPI) in den OGC API Standards sinkt die Hürde, Geodaten zu nutzen und in Prozesse und Anwendungen zu integrieren. Damit Nutzer der Urban Data Platform Hamburg von diesen Vorteilen profitieren, wurde in einem ersten Schritt OGC API - Features umgesetzt und für einen Großteil der Datensätze produktiv bereitgestellt. Dies erfüllt die Anforderungen der GDI-DE Architektur (s. Kap. 6.4.3). Dieses Good Practice Beispiel geht auf Fragen ein, die sich bei der Umsetzung von OGC API - Features in der Urban Data Platform Hamburg (s. hier) gestellt haben. Diese betreffen auch Aspekte der zukünftigen Umsetzung weiterer OGC APIs, die sich auf einen Datensatz beziehen lassen (z.B. Tiles, Styles, Maps).
Welche Domain für OGC APIs?
Die klassischen OGC Dienste (WMS, WFS) sind unter https://geodienste.hamburg.de zu erreichen. OGC APIs stellen eine grundlegende Modernisierung und Überarbeitung dieser Standards unter Nutzung gängiger Web-Standards dar. Um dieser Hinwendung zum Mainstream auch in der genutzten Domain Ausdruck zu verliehen, haben wir uns entschieden, die OGC APIs unter https://api.hamburg.de zu veröffentlichen.
Umgang mit verschiedenen OGC APIs pro Datensatz?
Ein Großteil der OGC APIs lässt sich auf einen Datensatz beziehen (z.B. Tiles, Styles, Maps). Da es seitens OGC keine eindeutigen Vorgaben gibt, war zu entscheiden, wie verschiedene OGC APIs für einen Datensatz nach außen veröffentlicht werden. Soll es eine integrierte OGC API oder viele verschiedene OGC APIs pro Datensatz geben?
| Integrierte OGC API | viele OGC APIs | |
|---|---|---|
| URL | ../datasets/v1/{dataset}/{OGCAPI-Ressource} | |
| Beschreibung | Eine OGC API pro Datensatz, von dort alle verfügbaren OGC API Ressourcen | Viele unabhängige OGC APIs (Features, Tiles, Styles, ..) pro Datensatz |
| Beispiele | ../datasets/v1/schulen/collections ../datasets/v1/schulen/styles | (keine Entsprechung) ../features/v1/schulen/collections ../styles/v1/schulen/styles |
Vor allem mit Hinblick auf die Nutzerfreundlichkeit haben wir uns für eine integrierte OGC API pro Datensatz entschieden, z.B. https://api.hamburg.de/datasets/v1/schulen. Alle OGC API Ressourcen sind von einer integrierten Landing Page aus zugänglich und in einem OpenAPI-Dokument enthalten. Über einen prominenten Link wird auf die Metadaten zum über die OGC API dargestellten Datensatz verwiesen.
Umgang mit nicht final-standardisierten OGC API Bausteinen?
Die Standardisierung von OGC API ist noch nicht abgeschlossen und erfolgt modular. Um die Nutzbarkeit der bereitgestellten OGC APIs (und damit der Geodateninfrastruktur) zu erhöhen, werden auch Bausteine (Building Blocks) bereitgestellt, die den Standardisierungsprozess im OGC noch nicht vollständig durchlaufen haben, aber hilfreiche Funktionen bieten. Darunter OGC API – Features Part 3 Filtering, Pt. 5 Schemas oder Pt. 8 Text Search). Außerdem kann so Nutzer-Feedback zu den API-Bausteinen generiert werden. Der Reifegrad (Maturity) der bereitgestellten Bausteine wird im Open API Dokument beschrieben, z.B. https://api.hamburg.de/datasets/v1/schulen/api?f=htmlBeschreiben Sie, warum das Good Practice entwickelt wurde. Erläutern Sie bitte in der Beschreibung, ob die Good Practice - darauf abzielt, (einige) der GDI-DE Architektur Anforderungen zu erfüllen UND/ODER - über diese Anforderungen hinausgeht, um die Nutzbarkeit/Nutzbarkeit der Geodateninfrastruktur zu verbessern UND/ODER - Daten oder -Dienste zur Durchführung einer bestimmten Aufgabe nutzt und welche Vorteile für Implementierer, Nutzer oder andere Interessengruppen zu erwarten sind.
Angestrebtes Ergebnis
Beschreiben Sie, was möglich sein sollte, wenn Sie das Good Practice befolgen.
Identisch zu erwartetem Nutzen oben?
Nachweis der Umsetzung und Unterstützung
Erbringen Sie gegebenenfalls den Nachweis, dass die Lösung - in die Praxis umgesetzt wurde, idealerweise in mehr als einem Kontext (mehr als ein Bereich/Werkzeug/Bundesland), - breitere Unterstützung erhalten hat, indem Sie auf Online-Diskussionen oder die Dokumentation der Aktivität in einer geeigneten öffentlich zugänglichen Ressource (z. B. GitHub) verweisen, - von einem Normungsgremium gebilligt wurde und/oder - über eine klar definierte Verwaltungsstruktur und/oder einen Nachhaltigkeitsplan verfügtDie OGC APIs für Datensätze der Urban Data Platform Hamburg sind unter https://api.hamburg.de/datasets/v1/ veröffentlicht. Die Umsetzung erfolgt mit der Open Source Software ldproxy. Seit v2.20.0 unterstützt das Masterportal Layer vom Typ OGC API - Features.
Beschränkungen
Gibt es Ihnen bekannte Grenzen des Good Practices? Diese Information dient dazu, klar herauszustellen für was das Good Practice verwendet oder nicht verwendet werden kann. Dies kann ggf. Nachnutzern helfen einzuschätzen, ob eigene Anforderungen durch das bereitgestellt Good Practice abgedeckt werden.