Introduction
Let’s do some bookkeeping about the different metadata information we will collect and publish.
Rebuild times reflect job scheduling times using cron, stated as respective system time (currently CET in Europe/Berlin).
Metadata about stations and devices
List of stations/devices (locations) from luftdaten.info
Station information metadata from https://luftdaten.info/.
List of DWD stations for 10min measurements
- File: dwd-stations-10min-grafana.json (todo)
List of DWD stations for 60min measurements
- File: dwd-stations-60min-grafana.json (todo)
How to request a resource
Introduction
There are different ways of requesting a metadata resource. Let’s use the station information metadata from luftdaten.info to demonstrate this by example. All responses should yield the contents of the resource luftdaten-stations-grafana.json, which is a static file generated by luftdatenpumpe.py.
Request variants
GET request
With this GET request, the resource gets addressed by filename. It offers a convenient way to dispatch to metadata resources on the filesystem.
http GET https://weather.hiveeyes.org/metadata/luftdaten-stations-grafana.json
POST request - by filename
With this POST request, the resource gets addressed by filename. It offers a convenient way to dispatch to metadata resources on the filesystem.
echo '{"target": "luftdaten-stations-grafana.json"}' | http POST https://weather.hiveeyes.org/metadata/search
POST request - custom expression
With this POST request, the resource gets addressed by using a custom expression. This offers an advanced way to dispatch to metadata resources on other subsystems.
echo '{"target": "SELECT * FROM luftdaten_stations"}' | http POST https://weather.hiveeyes.org/metadata/search
Under the hood, this query expression is mapped to the static resource "luftdaten-stations-grafana.json" to reflect it as a database table called "luftdaten_stations" using a custom rule stored in the variable "ngx.shared.metadata_routes".