search

bundesAPI / sofortmassnahmen

Zivilgesellschaftliche Beteiligung zu den „Sofortmaßnahmen Zweites Open Data Gesetz“
96 stars 3 forks source link

Bundesamt für Strahlenschutz: Gamma-Ortsdosisleistung #30

Open LilithWittmann opened 3 years ago

LilithWittmann commented 3 years ago

https://odlinfo.bfs.de/DE/index.html

Hypercookie commented 3 years ago

https://odlinfo.bfs.de/json26a81cf54345c5b33f6a026c50517290/stamm.json

scheint alle messstellen zu beinhalten

Hypercookie commented 3 years ago

@3nol und ich könnten das fix dokumentieren

LilithWittmann commented 3 years ago

@Hypercookie hier ein Repo. https://github.com/bundesAPI/strahlenschutz-api

jens-ox commented 3 years ago

Hash kann man scheinbar weglassen: https://odlinfo.bfs.de/json/stamm.json

Keys aus stamm.json kann man für den Retrieval einer einzelnen Messstation nutzen: https://odlinfo.bfs.de/json/082150170.json

@Hypercookie bist du da schon dran? Sonst kann ich mich um die OpenAPI-Spec kümmern :blush:

jens-ox commented 3 years ago

Dokumentation in PDF-Form hier: https://odlinfo.bfs.de/downloads/Datenbereitstellung-2016-04-21.pdf

jens-ox commented 3 years ago

Initiale Schemas: https://github.com/bundesAPI/strahlenschutz-api/pull/1

LilithWittmann commented 3 years ago

Super! Domain ist aufgeschaltet. https://strahlenschutz.api.bund.dev/

Hypercookie commented 3 years ago

@jens-ox Uh.. da warst du schneller als ich :) danke dir

jens-ox commented 3 years ago

Der MD5 im JSON-Pfad bereitet mir noch Kopfzerbrechen - die Daten ohne MD5 sind alte Daten. Der Hash ist im initialen Payload der Seite eingebettet:

var jkey = '72bd24b6b2d47858e51caa57fe170232';

Browserspezifisch ist der Hash nicht, das Datum hab ich auch schon in verschiedenen Formaten probiert. Scheint sich aber auch mehrmals pro Tag zu ändern 😞

Hypercookie commented 3 years ago

Die 1-Stunden-Mittelwerte und die Stammdaten werden zu den folgenden Zeiten aktualisiert: 04:30 Uhr UTC 10:30 Uhr UTC 16:30 Uhr UTC 22:30 Uhr UTC

Passt das eventuell zu dem mehrmals am tag?

Hypercookie commented 3 years ago

Es sind auch keine gehasheten UnixTimeStamps von keinen dieser Uhrzeiten. Wenn der hash/key mit dem HTML statisch kommt lässt das sowieso nichts gutes vermuten. Grade da man sich für die eigentliche Datenschnittstelle registrieren muss.

KLiebrecht1 commented 3 years ago

So, bin jetzt auch hier. Hab den ganzen Tag rumprobiert.

Es wird wohl kein Weg dran vorbeiführen, vor JEDEM JSON-Aufruf einer Messstelle VORHER die entprechende HTML-Seite aufzurufen und den aktuellen Key daraus zu extrahieren.

https://odlinfo.bfs.de/DE/aktuelles/messstelle/<Ortskennung>.html

Daraus den aktuellen Key extrahieren und damit die JSON-Daten abrufen

https://odlinfo.bfs.de/json<AktuellerKey>/<Ortskennung>.json

jens-ox commented 3 years ago

Ich habe mal den BFS-Leuten geschrieben und nach Zugangsdaten gefragt. Vielleicht lässt sich ja darüber was ableiten 🙈

Ich nehme an (und hoffe!), dass das irgendein Timestamp-Hash ist. Dann könnte man sehr schön auch historische Daten abfragen.

KLiebrecht1 commented 3 years ago

Hast du die Zugangsdaten mittlerweile erhalten? Und konntest du daraus etwas ableiten?

jens-ox commented 2 years ago

Ja, habe mittlerweile Zugangsdaten bekommen - die Daten sind vom Format her identisch zu den öffentlich verfügbaren, außer dass man nicht den Key braucht. Ich habe Herrn Müller, der für die Schnittstelle verantwortlich zu sein scheint darum gebeten, die JSON-Files ohne Key mitzuaktualisieren. Er meint, er werde sich bei mir melden, sobald das der Fall ist.

mlechner commented 2 years ago

Das Bundesamt für Strahlenschutz (BfS) begrüßt Initiativen zu Open Data und veröffentlicht seit vielen Jahren auch Daten zur Gamma-Ortsdosisleistung als Information für die Bevölkerung. Auf dem Portal ODL-Info (https://odlinfo.bfs.de) stehen die jeweils letzten verfügbaren Stundenmittelwerte der betriebsbereiten Messstellen sowie die Zeitreihen der einzelnen Messstellen im JSON-Format offen zur Verfügung. Eine standardkonforme API für die Daten auf ODL-Info existiert noch nicht. Die Umstellung auf OGC-konforme Geodatendienste (https://de.wikipedia.org/wiki/Open_Geospatial_Consortium), wie sie bereits im Geoportal des BfS (https://www.imis.bfs.de/geoportal/) eingesetzt werden und bei Daten mit Raumbezug internationaler offener Standard sind, befindet sich aktuell in Umsetzung. Sobald auch ODL-Info auf OGC-Standards umgestellt ist, können neben Geographischen Informationssystemen (GIS, z.B. https://www.qgis.org) gängige Programmbibliotheken wie OpenLayers (https://github.com/openlayers/openlayers), Leaflet (https://github.com/Leaflet/Leaflet) oder Vergleichbares in den jeweiligen Programmiersprachen für den anonymen Zugriff verwendet werden. Eine Authentifizierung oder Registrierung ist für diese Dienste nicht erforderlich. Bei Fragen ist das BfS auch gerne unter epost@bfs.de oder @strahlenschutz auf Twitter errreichbar. Auf Github sind unsere Open Source Projekte unter OpenBfS (https://github.com/OpenBfS) zu finden.

KLiebrecht1 commented 2 years ago

Gute Nachrichten! Das Bundesamt für Strahlenschutz hat die neue API veröffentlicht. Allgemein zugänglich, man braucht jetzt keinen Key mehr. Sehr schön. Dokumentation gibt es hier: https://odlinfo.bfs.de/ODL/DE/service/datenschnittstelle/datenschnittstelle_node.html

jens-ox commented 2 years ago

Hi @KLiebrecht1, ist im entsprechenden Repo schon umgesetzt ☺️

mlechner commented 2 years ago

Hallo @jens-ox und @KLiebrecht1,

das wichtige daran ist ja nicht, dass es da überhaupt irgendeine API von Behördenseite gibt, die idealerweise auch noch dokumentiert ist. Besser ist, dass die Datenschnittstelle des BfS nicht mehr custom ist, sondern wie das Geoportal des BfS, auf eine offene Standardschnittstelle auf Basis der OGC-Standards umgestellt wurde.

Die OGC Standards finden in der Webkartographie breite Verwendung und werden bei fast allen Geoportalen (von kommunal bis EU und darüber hinaus) eingesetzt. Das Nette daran ist, dass es in allen gängigen Programmiersprachen Bibliotheken gibt, die die Nutzung der OGC-Standards sehr einfach machen und man sich nicht selbst mit JSON oder XML parsing und dem Handling der resultierenden Objekte kümmern muss. Im Webmapping/JS sind das in erster Linie die beiden OS Projekte OpenLayers und Leaflet. Leider gibt es diese hohe Standardisierung nicht in vielen anderen Themenbereichen.

Übrigens gibt es von der OGC seit kurzem (Ende 2019 ☺️) die OGC-API Features oder auch hier. Damit wird dann auch eine OpenAPI konforme Veröffentlichung von Features als OGC Standard möglich. Das muss jetzt nur noch in die entsprechenden Projekte, wie Geoserver und eben den genannten JS-Libs implementiert werden (Anfänge dazu gibt es schon) und wir können unsere Daten auch darüber veröffentlichen.

We do our very best!

Marco

LilithWittmann commented 2 years ago

Also tbh. finde ich es relativ traurig das die einfach zugängliche API zugunsten von OGC komplett abgeschaltet wurde. OGC ist halt stand heute für die meisten Menschen weniger zugänglich als 3 json Endpunkte aus denen Daten rausfallen.

Wäre das jetzt wirklich linked open data, würde ich sagen "hey das ist es wert" aber so ist es halt mit der gleichzeitigen Abschaltung anderer Schnittstellen schon ein bisschen schade, dass es die leichter Zugänglichen Schnittstellen nichtmehr gibt.

crycode-de commented 2 years ago

@LilithWittmann Die bisherige (alte) offizielle Schnittstelle ist nach wie vor verfügbar und seit der Umstellung sogar ohne vorherige Registrierung frei nutzbar. Da die überarbeitete ODL-Info Webseite jetzt auf anderen Systemen gehostet wird, als die Datenschnittstelle, hat sich die URL zur alten Datenschnittstelle geändert. Entsprechende Weiterleitungen sind jedoch eingerichtet. Die json-Dateien der alten Schnittstelle sind in der gewohnten Form weiterhin unter https://odlinfo2.bfs.de/daten/json/ verfügbar und werden regelmäßig aktualisiert. Langfristig ist angedacht, dass die alte Schnittstelle irgendwann abgeschaltet wird. Hierzu werden vorab alle registrierten Nutzer informiert werden.

mlechner commented 2 years ago

@LilithWittmann Man kann sich bestimmt endlos darüber streiten, ob man die eine oder die andere API einfacher oder zugänglicher findet. Im Einzelfall mag eine custom API (und das ist die bisherige nun Mal) einfacher erscheinen als eine API, die auf einem internationalen offenen Standard beruht. Die Programmierarbeit hört aber nicht beim Abholen der Daten auf, sondern geht dann erst richtig los. Wenn ich mir dann für jede API eigene Klassen mit ihren Methoden bauen muss, ist der Aufwand unterschiedliche Datenquellen miteinander zu verknüpfen entsprechend aufwändig. Dagegen werden APIs, die auf Standards setzen, wie im Falle geographischer Daten die OGC-Standards, in den diversen Programmiersprachen über gängige Bibliotheken unterstützt, so dass die Handhabung in der konkreten Umsetzung sehr einfach ist. Um die Daten eines OGC-WFS Dienstes von einer anderen Behörde zu holen, muss ich im Idealfall :-) lediglich die URL und den Parameter des Layernamens (siehe Examplecode, l.14 ff): https://openlayers.org/en/latest/examples/vector-wfs.html) anpassen (für Python "OWSlib"). Nach meiner persönlichen Meinung darf die Forderung nach frei zugänglichen APIs nicht am "ob" halt machen, sondern sollte auch auf das "wie" eingehen (aber da rudern wie ja in die gleiche Richtung, sitzen vielleicht sogar im selben Boot).