bundesapi / dwd-api Goto Github PK

Der DWD bietet die Wetterstationsdaten auch über eine Geodatenschnittstelle an, namentlich WFS (Geodienste Doku)

Die WFS URL für den CDC ist:
https://cdc.dwd.de/geoserver/ows?service=WFS&version=2.0.0&request=GetCapabilities
und kann z.B. in QGIS genutzt werden.

Sinnvoll ist es, direkt einzuschränken, da man sonst mit der ersten Anfrage alle Daten angereicht bekommt, was üblicherweise nicht gewollt ist, da je nach Rechnerausstattung zu aufwändig und der Download entspechend lange dauern kann (kein flüssiges Arbeiten möglich).

In QGIS bietet sich das Plugin WFS 2.0 Client an, mit dem die Datenabfrage direkt eingeschränkt werden kann, z.B. auf den Layer CDC:OBS_DEU_P1M_RR Monatssumme der Stationsmessungen der Niederschlagshöhe in mm für Deutschland, die aktuelle Ausdehnung im Viewer und eine maximale Anzahl Features.
In den Layer Properties kann unter Source der query builder genutzt werden, um SQL-artige Statements wie "SDO_NAME" LIKE 'Rheinstetten' zu definieren.

SELECT * FROM OBS_DEU_P1M_RR WHERE OBS_DEU_P1M_RR.SDO_NAME LIKE 'Rheinstetten'

Oder ist das nicht Teil der API bzw. der API-Dokumentation? Ich kenn mich mit API's ehrlich gesagt wenig aus, aber habe zum Lernen mal mit der DWD-API rumgespielt und das ging erstaunlich einfach, nur musste ich etwas für die verschiedenen Felder selber erraten, um welche Einheit es sich handelt. Wenn man Erfahrung hat ist das kein Problem, für einen Programmierneuling ist es aber vielleicht nicht offensichtlich wie man aus einem Integer eine Zeit bekommt und sowas, denke da kann man nachbessern. Was ich zum Beispiel ertüfteln musste, war:

• temperature: Temperatur ist in Zehntel °C integers angegeben, musste ich also durch 10 teilen um °C zu bekommen
• timeStep: Zeit in Millisekunden (hoffe ich)
• start: Unix-Zeit integer in ms. Um die Zeiten der jeweiligen Temperaturemessungen zu erhalten, muss für jede Messung jeweils einen timeStep zu dieser Startzeit addieren.

Vielleicht geht das auch über den Anspruch einer API-Dokumentation hinaus, aber falls nicht, wollte ich mal fragen, wo man da einen PR machen könnte, um die Dokumentation in dieser Hinsicht zu verbessern :)

In der Open API Spezifikation wird ein Parameter stationsIds bzw. stationsId gefordert.

Laut dem DWD Stationslexikon stammen die genannten Beispiele aus der Spalte Stationskennung. Wenn man Werte aus der Spalte StationsID verwendet, antwortet die Schnittstelle mit einem leeren JSON Objekt {}.

Könnte man in einer neuen API-Version den Parameter in stationsKennung umbenennen?

Hello,

are there any updates on the access-control header issues?
Currently it is not possible to use any of the apis from a browser client.

11:28:59.583 Quellübergreifende (Cross-Origin) Anfrage blockiert: 
Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf https://dwd.api.proxy.bund.dev/v30/stationOverviewExtended?stationIds=undefined. (Grund: CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt). 
Statuscode: 200.

In z.B. https://dwd.api.proxy.bund.dev/v30/stationOverviewExtended?stationIds=10505 ist „sunshine“ enthalten (stündliche Daten), aber in was ist das angeben? Offenbar kann es größer als 100 werden, also scheiden Minuten und Prozent aus. Promille vielleicht?

(Eventuell sollte ich einfach auf besseres Wetter warten.)

In der DWD API-Dokumentation heißt es

Beim Parameter stationsIds handelt es sich um die Stationskennungen. Die List der Stationskennungen kann z.B. hier eingesehen werden.

Im oben verlinkten Stationslexikon habe ich in die Tabelle geschaut und gemerkt, dass die Stationskennung 10519 doppelt für verschiedene Städte vorkommt, und zwar neben Königswinter-Heiderhof (mich von Interesse) auch in Karlsruhe-Durlach.

import pandas as pd

stations_lexikon = pd.read_html("https://www.dwd.de/DE/leistungen/klimadatendeutschland/statliste/statlex_html.html?view=nasPublication")[0]["Stationslexikon"]
print(stations_lexikon[stations_lexikon["Stations-kennung"] == "10519"][
    ["Stations_ID", "Stations-kennung", "Stationsname"]
])

#       Stations_ID Stations-kennung            Stationsname
# 8348        10519            10519  Karlsruhe-Durlach (Ph)
# 9203          603            10519  Königswinter-Heiderhof
# 9206          603            10519  Königswinter-Heiderhof

Ich bin nicht überrascht dass die gleiche Kennung für mehrere Stationen unterschiedlichen Typs in einer Stadt erhalte, aber dass die gleiche Stationskennung in verschiedenen Städten vorkommt hat mich überrascht, weil ich erwartet hatte, damit über die API eindeutig Wetterdaten für einen bestimmten Standort zu erhalten.

Wenn ich in der API die Stationskennung 10519 verwende, bekomme ich die Wetterdaten für Königswinter-Heiderho und nicht Karlsruhef, jedenfalls scheint es so wenn ich die Temperaturen vergleichen mit dem was ich in der DWD-App sehe. Das ist eigentlich auch was ich möchte.

Auf diese Duplizierung kam ich nur, weil ich in meinem Skript eine Funktion schreiben wollte, die von der stationID automatisch den Stationsnamen über das Stationslexikon herausholt, was jetzt aber doch nicht so eindeutig ist wie ich erhofft hatte.

Das kommt sogar recht häufig vor

station_name_counts = stations_lexikon.groupby("Stations-kennung")["Stationsname"].agg(
    [lambda namen: len(set(namen)), lambda namen: set(namen)]
)
station_name_counts.columns = ["counts", "Stationsnamen"]
station_name_counts = station_name_counts[station_name_counts["counts"] > 1]
station_name_counts.sort_values("counts", ascending=False)

#                   counts                                      Stationsnamen
# Stations-kennung                                                           
# 10791                  3   {Großer Arber, Obereschach, Grosser Falkenstein}
# 10639                  3  {Langen (BZ), Darmstadt (US-Air-Base), Lauda-K...
# 10156                  3     {Lübeck, Sankt Goarshausen, Lübeck-Blankensee}
# 10515                  3          {Heidelberg-Königstuhl, Koblenz, Bendorf}
# 10875                  3         {Hayingen (PH), Mühldorf, Obertaufkirchen}
# ...                  ...                                                ...
# 10424                  2                            {Leonberg/Württ., Werl}
# 10419                  2        {Ingelfingen (PH), Lüdenscheid (Flugplatz)}
# 10418                  2                        {Lüdenscheid, Hermuthausen}
# 10410                  2                        {Weinsberg, Essen-Bredeney}
# T362                   2              {Winterberg, Winterberg-Altastenberg}
#
# [402 rows x 2 columns]

War mir nicht sicher wen ich hier am besten zuerst anpingen soll und über welche Kanäle, aber dachte vielleicht kriege ich über ein Issue Antworten, vielleicht weiß jemand von euch mehr. Vermute die Stations-kennung ist vielleicht nur innnerhalb eines Stationstyps eindeutig. Z.B. ist 10519 in Karlsruhe-Durlach vom Typ PE (phänologische Beobachtungen) und die sind vielleicht eh nicht über die API erreichbar, bin mir aber nicht sicher, denn wüsste jetzt nicht wie ich Karlsruhe-Durlach 10519 über die API anpingen kann 🤷

Was von Seiten der API-Dokumentation gemacht werden muss ist möglicherweise nur ein Hinweis zum Kommentar zur stationID, vielleiht gibt es aber auch weitere Parameter mit denen man die die Stations einschränken kann?

Übrigens ist mir auch bewusst, dass die Stationslexikon-Tabelle nicht Teil der API ist, aber irgendwie gehört sie meines Erachtens nach zur Dokumentation und daher würde ich sie gerne verstehen.

Ich habe auf der Testseite der DWD-Api für einige Stationen nur noch eine leere Response erhalten.
Beispielsweise für Bad Lippspringe (03028) ist das der Fall.

Nach etwas Recherche habe ich diese Liste hier gefunden, auf der der Station auch die ID 10430 zugewiesen ist, für welche ich dann auch Daten bekomme:
https://www.dwd.de/DE/leistungen/met_verfahren_mosmix/mosmix_stationskatalog.cfg?view=nasPublication&nn=16102

Ich kenne den Hintergrund der Änderungen nicht. In der alten Liste sind ja auch noch stillgelegte Stationen enthalten und beide sind ja auch weiterhin vom DWD-Server abrufbar, aber evtl. sollte man das mal prüfen und den Link anpassen.

Unterstützt die API das Ausgeben von Wetterwarnungen bei Angabe einer PLZ?
Ich spiele mit der Idee, einen Telegram Bot zu erstellen, der die Nutzer nach der PLZ fragt und anschließend über Wetterwarnungen informiert.

In https://dwd.api.proxy.bund.dev/v30/stationOverviewExtended?stationIds=10505 enthält "sunshine" in "forecast1" folgendes Array:

[
    490, 540, 540, 530, 530, 530, 510, 470, 370, 190,   0,   0,   0,   0,
      0,   0,   0,   0,   0,   0,   0,   0,  80, 210, 320, 390, 410, 390,
    370, 340, 270, 230, 140,  50,   0,   0,   0,   0,   0,   0,   0,   0,
      0,   0,   0,   0,  30, 100, 170, 200, 220, 210, 180, 150, 120,  80,
     10,   0,   0,   0,   0,   0,   0
  ]

Das ergibt keinen Sinn wenn man bedenkt, daß das stündliche Werte sind, die bei Mitternacht beginnen. In "forecast2" sieht es sinnvoll aus:

[
      0,   0, 110, 400, 430, 200,  10,   0,   0,   0, 160, 560, 540, 390,
     40,   0,   0,   0, 220, 630, 650, 400,  30,   0,   0,   0, 280, 720,
    660, 450,  30,   0,   0,   0, 230, 560, 590, 400,  30,   0,   0,   0,
    240, 620, 610, 450,  50,   0,   0,   0, 290, 620, 620, 450,  60,   0
  ]

Hier liegen 3 Stunden zwischen zwei Einträgen, d.h. die Sonne fängt um 6 Uhr morgens an zu scheinen. Das ist plausibel.

In den Swagger "Try it out" Beispielen bekommt man die Fehlermeldung: TypeError: NetworkError when attempting to fetch resource., beispielsweise bei /dashboard/{AGS}.json.

Ich glaube, dass das daran liegt, dass die API nicht den Header access-control-allow-origin: * sendet. In der Browserkonsole werden die Daten im Netzwerktab angezeigt:

Bei der Autobahn-API funktioniert das "Try it out", da die API den Header korrekt sendet: