3 · Kontextabgrenzung¶
Die Kontextabgrenzung zeigt die ODI als schwarze Box und macht sichtbar, wer von außen mit ihr kommuniziert und über welche Kanäle. Das Kontextdiagramm unten fasst beide Sichten zusammen.
Das Diagramm zeigt die ODI als zentrales System in der Mitte. Links stehen die Datenbereitsteller, die Daten in die Plattform einspeisen; rechts die Datennutzer, die Daten aus ihr beziehen. Unten sind die Nachbarsysteme abgebildet, auf die die ODI intern angewiesen ist.
Fachlicher Kontext¶
Aus fachlicher Sicht hat die ODI zwei klar getrennte Seiten:
Datenbereitsteller liefern Daten an die ODI. Das sind in erster Linie Mitarbeitende und IT-Systeme der öffentlichen Verwaltung in Schleswig-Holstein:
- Fachverfahren – spezialisierte Verwaltungssoftware, die Datensätze automatisiert per REST-API an das Staging-Backend liefert.
- Fachportale – Portale oder Content-Management-Systeme, die bestehende Datenbestände per API oder manuell exportieren.
- Dateien / CSV – Mitarbeitende laden Dateien direkt über das Schema-Staging-Frontend (
odi-schema-staging-frontend) oder per API hoch. - Geodaten – Geodaten (GeoJSON, GeoCSV) werden über das Staging-Backend eingespeist und im Geo-Stack (GeoServer, PostGIS) weiterverarbeitet.
- IoT-Sensoren – Echtzeit-Messdaten von Sensoren (Umwelt, Mobilität, Infrastruktur) gelangen über die OGC SensorThings API oder MQTT in den Dynamic-Data-Stack.
Datennutzer beziehen Daten aus der ODI. Sie stellen keine Daten bereit, sondern konsumieren:
- Bürger:innen – laden Datensätze als CSV, Parquet oder JSON aus dem Datenkatalog herunter.
- Entwickler:innen – nutzen die REST-APIs des Staging-Backends und des Datenkatalogs für eigene Anwendungen; stellen SPARQL-Abfragen an den Linked-Open-Data-Endpunkt.
- Fach- und Drittportale – binden die ODI-Daten über DCAT-AP-konforme Feeds, OGC-Dienste (WFS/WMS) oder REST-Schnittstellen in ihre eigenen Portale ein.
- ODW-Frontend – das neue
open-data-web-Frontend liest Daten aus dem Datenkatalog und stellt sie in einer modernen Oberfläche (Suche, Tabellenansicht, Karte, API-Beispiele) bereit.
Technischer Kontext¶
Die folgende Tabelle beschreibt, über welche Protokolle und Schnittstellen die Kommunikation mit der ODI erfolgt.
| Schnittstelle | Richtung | Protokoll / Standard | Gegenüber |
|---|---|---|---|
| REST API – Upload | eingehend | HTTPS · REST · JSON · Multipart | Fachverfahren, Fachportale, Frontend/BFF |
| REST API – Download / Katalog | ausgehend | HTTPS · REST · JSON | Entwickler:innen, ODW-Frontend, Drittportale |
| DCAT-AP-Feed | ausgehend | HTTPS · RDF/JSON-LD | Drittportale, Metadaten-Harvester |
| SPARQL-Endpunkt | ausgehend | HTTPS · SPARQL 1.1 · JSON/XML | Entwickler:innen, Semantic-Web-Clients |
| Geodienste (WFS/WMS) | ausgehend | HTTPS · OGC WFS 2.0 · WMS 1.3 | GIS-Anwendungen, Drittportale, Masterportal |
| SensorThings API | eingehend + ausgehend | HTTPS · OGC SensorThings 1.1 | IoT-Sensoren, Echtzeit-Clients |
| MQTT | eingehend | MQTT 3.1.1 / 5.0 | IoT-Geräte, Sensoren |
| OIDC / JWT | eingehend | HTTPS · OAuth 2.0 / OIDC | Alle schreibenden Clients (Keycloak) |
| CI/CD | intern | GitLab API · Docker Registry API | openCode, Container-Registry |
Nachbarsysteme¶
Drei Systeme liegen außerhalb der ODI, sind aber für ihren Betrieb konstitutiv:
| System | Rolle |
|---|---|
| Dataport Identity Provider (Keycloak) | Externes Keycloak, an das der ODI-eigene Keycloak per Federated Identity angebunden ist. Verwaltungsmitarbeitende melden sich über ihren Dataport-Account an. |
| IONOS Cloud | Betriebsplattform: Managed Kubernetes (Stage und Produktion mit je eigenem Node-Pool), Managed PostgreSQL-Cluster, Managed S3-Objektspeicher, NFS-Fileservice und Container-Registries. |
| openCode (GitLab) | Quellcode-Plattform für alle odi-*-Repositories. GitLab CI baut die Docker-Images per Kaniko; die Container-Registries bei IONOS nehmen die Images entgegen. |