The API strives to be backwards compatible, i.e. features and datastructure once introduced to the core will stay available. However, to add new features and functions will require to add new content to existing data structures (which won’t break backwards compability, though).
Also new endpoints may be introduced over time like we did in
The API provides Information about the current Version in a custom HTTP Response Header, returned on the
[...] API-Version: 1.2.3 [...]
/datasets: More generic series metadata which can have different value types
/platforms: More generic metadata from where observations are made
/geometries: Separated endpoint to query different types of geometries
Platforms vs. Stations
v2.0 the following sensor platforms are supported:
stationarysensor platforms are fixed at a given
mobilesensor platforms do observe data along a
insitusensor platforms do observe data at the location the platform is currently at
remotesensor platforms do observe data from distance (like cameras or satellites)
There are four possbile types of a platform can have:
insitu platforms are associated with a
which can be either
remote platforms can reference observations to
observedGeometries: Either a fix geometry (
static or an observed geometry (
dynamic) on its own
(which may or may not vary over time e.g. sea water level via satellite).
By having more types filtering gets more important for clients to get the right data out from the API.
platform’s geometries can now grow and get very huge (e.g. moving platforms with long tracks).
To make them better to handle from clients geometries can be filtered under
Therefore additional query parameters now exist:
platformTypescan be used to filter on all resources which ensures to only get those resources related to the given filter.
platformLocationsto filter insitu geometries (
observedGeometriesto filter remote geometries (
geometryTypescto filter on different geometries (like
Station resource relates to the combination of a
platform (located at a 0-dimensional location geometry) where
are made. Retrieving the former output under
/platforms endpoint, one can now filter via
/platforms?platformTypes=stationary,insitu or still can get the collection via
Timeseries vs. Datasets
dataset is more flexible. While
timeseries only support
(which are implicit) a
dataset contains the
valueType member which indicates the actual
type of data (e.g. different scalar values or even aggregate types).
Check out in more detail under the Value Types section.
data vs. getData
getData was a bit confusing within a RESTful API. That’s the reason why
data for a dataset has been renamed to
/datasets/<id>/data). To stay backwards
compatible the old
getData still exist under the old endpoint (