Page tree
Skip to end of metadata
Go to start of metadata

Die kommunale Digitalisierung lebt vom Informationsaustausch. Um die vielfältigen Informationen zu strukturieren, haben wir unsere offene Datenbank.

Kommen Sie bei weiteren Fragen gern in unsere gemeinsamen Austauschtermine; Anmeldung für Kommunen in NRW und Mitglieder im KDN kostenfrei unter: https://www.kdn.de/veranstaltungen/termine/

Über neue Termine und Projekt-Meilensteine informieren wir über unsere OZG-Informationsverteiler: https://www.kdn.de/ozg/informationsverteiler/

direkt springen zu:

Allgemein

Log-in (im Prinzip nicht notwendig, da wir Open Data liefern)

Um Daten der Datenbank zu konsumieren, also zu nutzen, benötigen Sie kein Log-in: Es ist Open Data!

Das heißt: Wir stellen Daten zur Digitalisierung der Kommunen in NRW kostenfrei, strukturiert, exportierbar und sogar per API zur Verfügung.

Die Anmelde-Funktion dient lediglich folgenden Zwecken:

  • Schutz personenbezogener Daten, in unserem Fall: Projektkontakte
  • Aktiver Eingabe von Daten

Wenn Sie als Kommune Daten selbst pflegen möchten, also zum Beispiel Dienste eintragen, dann kommen Sie zunächst in eine unserer offenen Austauschrunden zur Datenbank, um sich mit dem Tool vertraut zu machen. Anschließend können Sie uns kontaktieren, um einen kostenfreien Zugriff zu erhalten.

Infos zum passwortgeschützten Bereich liegen für den berechtigten Personenkreis hier:

Fragen zum Menüpunkt "OZG Überblick"

OZG-Umsetzungsprojekte

Da wir agil und stufenweise arbeiten, gehen wir in aller Regel zunächst mit einer fachlich abgenommenen Minimalversion auf unseren technisch soliden Infrastrukturen in Betrieb und bauen diese dann sukzessive gemäß der Priorisierungen der Projektgruppen aus.

Die Pilotierung übernehmen diejenigen Kommunen, die den Dienst auch selbst mit ausgewählt und gestaltet haben in den gemeinsamen Projektteams. Wir suchen in vielen Projekten noch kommunale Beteiligung und Sie können sich bei Interesse gern bei den jeweils angegebenen Themenfeldkoordinator*innen im KDN-Kompetenzzentrum Digitalisierung melden, um einen Dienst frühzeitig zu nutzen: https://mitgliederportal.kdn.de/pages/viewpage.action?pageId=23858255

"EfA" ist die Abkürzung für "Einer für Alle" und bedeutet: bundesweite Lösung.

Die Projekte setzen in der Regel mehrere Leika-Leistungen um. Diese sind allerdings nicht alle gleich hoch priorisiert.

OZG-Leistungen

Die Daten der Liste https://ozg.kdn.de/ozg-leistungen stammen von d-NRW, die sie, aufbereitet mit NRW-spezifischen Zuständigkeitsinformationen, von der bundesweiten Plattform https://informationsplattform.ozg-umsetzung.de/iNG/app/ erhalten. Aufgrund der NRW- und kommunal-spezifischen Aufbereitung kann es in Einzelfällen zu Zeitverzögerungen und Differenzen zur bundesweiten Plattform kommen. Für die Kommunen in NRW kann unsere offene Datenbank als führend gelten.

Leika-Leistungen

Hier eine Erläuterung:

Die Daten zu Leika-Einzelleistungen beziehen wir teilweise automatisiert über die APIs vom Portalverbund.NRW: https://ozg.kdn.de/verwaltungssuchmaschine

Wir reichern sie an mit Informationen zur kommunalen OZG-Umsetzung in NRW.

Fragen zum Menüpunkt "Kommunen in NRW"

Für eine Liste der Leistungen, die Ihre Kommune im OZG umsetzen muss, geben Sie Ihre Kommune hier ein: https://ozg.kdn.de/kommunen 

Erklär-Video: https://youtu.be/52QBPdx68Mo

Sie können von jeder eingetragenen Leistung aus auf Details klicken. Diese stammen teilweise direkt aus der Schnittstelle im Portalverbund.NRW.

Erklär-Video: https://youtu.be/i4FeA9wySGc

Fragen zur Datennutzung per API

Sie können sich der offenen Schnittstellen unserer offenen Datenbank bedienen. Diese enthalten alle öffentlich zugänglichen Daten: https://ozg.kdn.de/api

Erklär-Video: https://youtu.be/qEXxDe-fEY0

Einer unserer Nutzer hat uns als kleiner Einstieg in Excel/PowerQuery mit der API/Datenabfrage folgende Videos empfohlen, um bisschen mit der API in Excel zu spielen. Es handelt sich um externe Inhalte, die der KDN nicht verantwortet und geprüft hat.

Man muss zwischen Anwendungsfehlern (Code >= 500) und HTTP-Fehlern (Code >= 400) unterscheiden. Fehlermeldungen mit Code 4xx sind keine Fehler in der Programmierung, sondern dienen als Information, das bei der Anfrage etwas nicht gestimmt hat. Der Hauptzweck der API ist die automatische Verarbeitung der Daten durch externe Anwendungen. Daher sind hier Fehlermeldungen bei ungültigen Aufrufen notwendig, damit die externen Anwendungen diese falschen Aufrufe erkennen können und per Exception-Handling verarbeiten können. Die Seite https://ozg.kdn.de/api dient der Dokumentation der vorhandenen Aufrufe.

Bei Aktivierung der Checkbox "Send Empty value" wird die API mit page=0 (identisch mit "page=") aufgerufen. Diese Seite gibt es nicht, da die Seiten bei 1 anfangen. Der Sinn der Fehlermeldung ist, die aufrufende Anwendung über einen falschen Aufruf ("Bad Request") zu informieren. 

Die Angaben für die Seitenanzahl stehen in den Ergebnissen ("hydra:first", "hydra:last"). Gemäß der Spezifikation der Hydra RESTful API Description Languages des W3C: https://www.hydra-cg.com/spec/latest/core/ Eine Paginierung in der REST-API zu haben gehört generell zu den Best-Practices für die API-Implementierung. Die API-Aufrufe für die Listen können ggfs. mehrere Tausend Datensätze beinhalten. Bei einem Aufruf ohne Paginierung müssten diese dann alle auf einmal zurückgegeben werden. Das würde sowohl beim OZG-Server als auch auf dem externen Server (bei einem Datenimport) für eine sehr hohe Speicher- und Prozessorauslastung bei dem Aufruf ohne Paginierung führen.


Beim Dynamic Content Loading ist die Paginierung zwingend notwendig, wenn die Daten direkt von der API in ein CMS eingebunden werden sollen und nicht in lokale Datenbanken importiert werden.
Beim nachladen der nächsten Datensätze muss es dann eine Möglichkeit geben, die zu ladenden Datensätze in der API einzuschränken. Dafür ist der page-Parameter gedacht.

Auch wenn die API-Daten in ein anderes System importiert werden sollen, muss für den Import nur eine Schleife verwendet werden, die alle Seiten durchläuft. Dafür sind nur wenige Zeilen Code notwendig.

Um die Flexibilität der API zu erhöhen, ist der zusätzliche Parameter "itemsPerPage" eingefügt, damit man die Anzahl der pro Seite geladenen Datensätze steuern kann.
Der Wert ist auf maximal 100 Einträge pro Seite beschränkt, um eine zu hohe Serverauslastung zu vermeiden. Der Standardwert ist unverändert 25. https://ozg.kdn.de/api/implementation_projects.json?page=1&itemsPerPage=100

Man kann die API in Excel nicht nur via „Schleife“ einbinden, sondern wie hier im Video https://www.youtube.com/watch?v=STjBoS1rQuQ in Form von Tabellen mit den Links zur API.

Mag nicht so super professionell wirken, hat aber den Vorteil, dass auch nicht Excel-Experten das Anzapfen der Daten gut nachvollziehen können. Die Überschriften der angezapften Daten sind unterschiedlich bspw. Column1.serviceKey entspricht der OZG-ID. Wenn nicht alle Spalten benötigt werden, kann man nur jene Spalten eingetragen, die auch aktiv genutzt werden.

Wir danken unserem Kollegen aus Gelsenkirchen für Input zu diesem Kapitel.

Fragen zur Daten-Pflege 

Fragen zur Weiterentwicklung der Datenbank selbst

Der Code ist nachvollziehbar und offen auf https://github.com/kdn-nrw/ozg

Bisher waren noch keine Änderungen an der Datenstruktur notwendig, daher gibt es bisher keine Versionierung.
Seit der Einrichtung der API wurde nichts mehr verändert, abgesehen von Beschreibungstexten für Swagger (https://ozg.kdn.de/api).

Die Datenstruktur ist grundsätzlich stabil und wird sich sehr wahrscheinlich nicht mehr stark verändern.
Falls doch grundlegende Änderungen notwendig sein sollten, würden wir Versionierung implementieren.

Wahrscheinlicher ist allerdings, dass nur einzelne Felder bzw. Eigenschaften entfallen oder geändert werden.
Für diesen Fall würden die alten Felder nicht entfernt, sondern als "Deprecated" markiert:
https://api-platform.com/docs/core/deprecations/

Falls wir Versionierung einführen, würde die jetzige Version weiterhin unter der bestehenden URL zugreifbar bleiben, die neuen API-Aufrufe wären dann unter neuen URLs zugreifbar.
D.h. die API wird auf jeden Fall rückwärtskompatibel bleiben.

Keine Antwort gefunden?

Melden Sie sich an zu unseren regelmäßigen Austauschterminen zur Nutzung der offenen Datenbank des KDN: https://www.kdn.de/veranstaltungen/termine/



  • No labels