Standardisierung des Time-Slider Zeitformats

[Manuel Heueck]

Der Timeslider im WMS-T Modul kann in seiner aktuellen Form nur Jahreszahlen im Zahlenformat verarbeiten, Für die breitere Nutzbarkeit wäre eine Standardisierung des Zeitformats nach ISO 8601 vorteilhaft. Ein Beispiel für einen Dienst, welcher dieses Zeitformat nutz ist der Layer “QFF (Luftdruck Meeresspiegel) aus ICON-EU“ vom Deutschen Wetterdienst (DWD). Der Dienst ist unter Folgender Adresse zu erreichen:

https://maps.dwd.de/geoserver/dwd/wms?service=WMS&version=1.1.0&request=GetMap&layers=dwd%3AIcon-eu_reg00625_fd_sl_QFF&bbox=-23.53125%2C29.46875%2C62.53125%2C70.53125&width=768&height=366&time=2022-01-26T00%3A00%3A00.000Z&srs=EPSG%3A4326&styles=&format=application/openlayers

Der hier verwendete Referenzzeitpunkt ist der 26. Jan 2022, 0 Uhr (2022-01-26T00:00:00.000Z)

Da es sich um Vorhersagedaten handelt muss der Zeitparameter immer wieder entsprechend angepasst werden. Die grundsätzliche Struktur der Adresse bleibt jedoch. Als zusätzliche Information ist diesem Eintrag ein Ergebnis der Abfrage und das ergebnis der getCapabilities als Screenshots beigefügt.

‌

[Dennis Sen]

Hallo Herr Heueck,

ich habe mich daran gemacht die WMS-T-Implementierung anhand des DWD-Dienstes zu verallgemeinern. Dabei bin ich auf ein Problem gestoßen, was den diensteseitig kommunizierten Extent angeht. Dort steht (jetzt im Moment) `2022-02-16T00:00:00.000Z/2022-02-22T06:00:00.000Z/PT1H` als verfügbarer Zeitraum. Tatsächlich sind aber nicht für den ganzen Zeitraum Daten verfügbar, ich kann erst ab 2022-02-17T06 Vorhersagedaten abfragen.

Übersehe ich vielleicht ein allgemeingültiges Kriterium, anhand dessen man erkennen könnte, dass dort der frühestmögliche Zeitpunkt liegt? Oder ist der Dienst selbst an dieser Stelle fehlerhaft? Ich erhalte für Zeitpunkte im Extent vor dem letzten Modelllauf (das entnehme ich jedenfalls der Fehlermeldung) aktuell diese Fehlermeldung:

<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE ServiceExceptionReport SYSTEM "https://maps.dwd.de/geoserver/schemas/wms/1.1.1/WMS_exception_1_1_1.dtd"> <ServiceExceptionReport version="1.1.1" >   <ServiceException>
      java.lang.RuntimeException: java.io.IOException: Could not read coverage data. 
java.io.IOException: Could not read coverage data. 
Could not read coverage data. 
No data available for NinJo NWP data request: model: ICON6_NEST, label: -, element: Pressure reduced to MSL, leveltype: mean sea level, level: --, modelrun: 17.02.22 06:00, forecasttime: -108000000, ensemble_category: null, ensemble_value: null
</ServiceException></ServiceExceptionReport>

Auch davon abgesehen ist die Implementierung noch nicht abgeschlossen. Vielleicht können Sie mir bei dieser Zwischenfrage ja weiterhelfen.

Viele Grüße

[Manuel Heueck]

Hallo,

vielen Dank für die Antwort. Ich habe mir die Sache nochmal genauer angesehen. Die Sache ist anscheinend etwas komplexer. Wie Sie schon angegeben haben, kann ich auch bei der Abfrage erst Datewn ab dem von Ihnen genannten Zeitraum abrufen. Beim Blick auf die Capabilites habe ich gesehn, das diese Zeitangabe eine Zeile Tiefer als Reference Time angegeben wird. Ich habe in meinem Mailverkehr mit dem DWD ochmal nachgesehen und kann folgenden Aussschnitt daraus hier einfügen:

Für diese zwei Layer gibt es zwei Nachfolgeprodukte mit folgendem Namen:

·         dwd:Icon-eu_reg00625_fd_sl_QFF (https://maps.dwd.de/geoserver/dwd/wms?service=WMS&version=1.1.0&request=GetMap&layers=dwd%3AIcon-eu_reg00625_fd_gl_T&bbox=-23.53125%2C29.46875%2C62.53125%2C70.53125&width=768&height=366&srs=EPSG%3A4326&styles=&format=application/openlayers)

·         dwd:Icon-eu_reg00625_fd_gl_T (https://maps.dwd.de/geoserver/dwd/wms?service=WMS&version=1.1.0&request=GetMap&layers=dwd%3AIcon-eu_reg00625_fd_gl_T&bbox=-23.53125%2C29.46875%2C62.53125%2C70.53125&width=768&height=366&srs=EPSG%3A4326&styles=&format=application/openlayers)

Inhaltlich stecken in diesen Layern nun mehr Informationen. Konkret bedeutet das für den QFF-Layer, dass dort die stündlichen Vorhersagezeitschritte bis vv+120h für die letzten fünf gerechneten Modellläufe bereitgestellt werden. Die von Ihnen genutzten Vorhersagezeitschritte sowie der aktuellste Lauf können in der WMS-Abfrage Mithilfe von Parametern spezifiziert werden, z.B. vv+72h (time=2021-08-27T06:00:00.00Z) für den aktuellen heutigen 06 UTC-Lauf (dim_reference_time=2021-08-23T06:00:00.000Z):

https://maps.dwd.de/geoserver/dwd/wms?service=WMS&version=1.1.0&request=GetMap&layers=dwd%3AIcon-eu_reg00625_fd_sl_QFF&bbox=-23.53125%2C29.46875%2C62.53125%2C70.53125&width=768&height=366&srs=EPSG%3A4326&styles=&format=application/openlayers&&dim_reference_time=2021-08-23T06:00:00.000Z&&time=2021-08-27T006:00:00.00Z

Gleiches gilt für den Temperatur-Layer, hier kommen sind jetzt zusätzlich noch andere Höhen im Metern dazu. Hier muss die Elevation (elevation=2) spezifiziert werden, um die 2m-Temperatur abzurufen. Eine beispielhafte WMS-Abfrage für den Vorhersagezeitschritt vv+48h für den aktuellen Lauf kann wie folgt aussehen:

https://maps.dwd.de/geoserver/dwd/wms?service=WMS&version=1.1.0&request=GetMap&layers=dwd%3AIcon-eu_reg00625_fd_gl_T&bbox=-23.53125%2C29.46875%2C62.53125%2C70.53125&width=768&height=366&srs=EPSG%3A4326&styles=&format=application/openlayers&elevation=2&dim_reference_time=2021-08-23T06:00:00.000Z&&time=2021-08-25T006:00:00.00Z

GetCapabilities: https://maps.dwd.de/geoserver/dwd/Icon-eu_reg00625_fd_gl_T/wms?request=GetCapabilities&service=WMS

Wenn man den Parameter “dim_reference_time” mit angibt bekommt man auch für den Startpunkt noch Daten. Wenn der Parameter nicht benutzt wird und nur Time, dann sind nur Daten für den aktuelen Lauf in dem Fall 17.2.22 6Uhr im Stundenintervall abrufbar. Ich hoffe das hilft etwas beim Verständis. Ansonsten können Sie mich gerne auch direkt kontaktieren.

Viele Grüße

‌

Manuel Heueck

[Dennis Sen]

Hallo Herr Heueck,

im Merge Request https://bitbucket.org/geowerkstatt-hamburg/masterportal/pull-requests/3238 habe ich einige der Probleme behoben. Dort liegt auch eine Konfiguration bei, mittels der der Layer `Icon-eu_reg00625_fd_sl_QFF` angesehen werden kann.

Allerdings funktioniert die Abfrage weiterhin nur eingeschränkt rückwirkend. Soweit ich in der Spezifikation nachlesen konnte, sollte der Wert für den Referenzzeitpunkt backendseitig automatisch mit dem in den GetCapabilities angegebenen Default befüllt sein, wenn nicht explizit vom Client angegeben. Ich habe den in den GetCapabilities spezifzierten Defaultwert für die Referenzzeit auch clientseitig ausprobiert, am Verhalten hat sich jedoch nichts geändert.

Ich vermute mittlerweile, dass hier ein Fehler im Dienst selbst vorliegt.

Dies ist die Antwort für den ersten Zeitpunkt, der derzeit laut Extent “time” verfügbar sein soll:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE ServiceExceptionReport SYSTEM "https://maps.dwd.de/geoserver/schemas/wms/1.1.1/WMS_exception_1_1_1.dtd">
<ServiceExceptionReport version="1.1.1" >
<ServiceException>
   java.lang.RuntimeException: java.io.IOException: Could not read coverage data.java.io.IOException: Could not read coverage data.Could not read coverage data.No data available for NinJo NWP data request: model: ICON6_NEST, label: -, element: Pressure reduced to MSL, leveltype: mean sea level, level: --, modelrun: 22.02.22 06:00, forecasttime: -104400000, ensemble_category: null, ensemble_value: null
</ServiceException>
</ServiceExceptionReport>

Ich habe den abgefragten Zeitpunkt dann noch einen Tag zurück gedreht, sodass die Abfrage außerhalb des Extent liegt. Dann kommt dieser Fehler:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE ServiceExceptionReport SYSTEM "https://maps.dwd.de/geoserver/schemas/wms/1.1.1/WMS_exception_1_1_1.dtd">
<ServiceExceptionReport version="1.1.1" >
<ServiceException code="InvalidDimensionValue" locator="dwd:Icon-eu_reg00625_fd_sl_QFF">
    Sun Feb 20 00:00:00 GMT 2022 is not an element of the time dimension of layer dwd:Icon-eu_reg00625_fd_sl_QFForg.geoserver.platform.ServiceException: Sun Feb 20 00:00:00 GMT 2022 is not an element of the time dimension of layer dwd:Icon-eu_reg00625_fd_sl_QFFSun Feb 20 00:00:00 GMT 2022 is not an element of the time dimension of layer dwd:Icon-eu_reg00625_fd_sl_QFF
</ServiceException>
</ServiceExceptionReport>

Da im zweiten Fall sprechend geantwortet wird, dass die Abfrage nicht im richtigen Zeitrahmen liegt, in ersterem Fall aber ein Lesefehler innerhalb von Java zu passieren scheint, nehme ich an, dass es sich um einen Fehler im Dienst handelt.

Inhaltlich ist sinnvoll, dass die Luftdruckvorhersage von heute um 6 keine Daten für gestern beinhält. Nur technisch ist diese Einschränkung nicht allgemeingültig am Dienst erkennbar, und wird dem Fehler nach auch vom Dienst selbst nicht erkannt. Vielleicht könnte der DWD hier Messdaten aus der Vergangenheit bereitstellen? Das wäre auch in der Animation schön, ein Ist-Verlauf mit Weiterberechnung.

Viele Grüße

[Dennis Sen]

Der zugehörige PR https://bitbucket.org/geowerkstatt-hamburg/masterportal/pull-requests/3238 ist gemerged und die dort beschriebenen Anpassungen werden in der nächsten Version verfügbar sein.

[Dennis Sen]

Da es hier direkt keine Rückmeldung gab, nehme ich an, dass das Issue geschlossen werden kann. Sollte doch ein allgemeingültiger Fehler in WMS-T enthalten sein, gern wieder öffnen oder ein neues Issue erstellen.

Viele Grüße