-
Notifications
You must be signed in to change notification settings - Fork 21
Release Notes v2.0.0
The Web API became more generic. Next to a station (which makes stationary-insitu measurement observations), we added a more flexible resource: The platform. Besides stationary-insitu types, we differentiate now between stationary, mobile, insitu and remote. The old station can be considered as stationary/insitu typed platform.
Similarly, the new /datasets endpoint allows to differentiate between more observation types than just measurement (i.e. timeseries). Types like count, text, record or complete customized output types are now possible.
The new /geometries/ endpoint allows new workflows for data exploration. Also it is the access point for multi-dimensional and observed geometries. These are more natural for mobile or remote platforms than having just 0-dimensional location data.
Here are the new endpoints:
/datasets//platforms//geometries/
The API endpoints behave fully backwards compatible to not break existing clients. This means that the parameter collection endpoints respond with data related to stationary, insitu and measurement. For example, a feature
which is referenced only by datasets won't be listed in /features. You'd have to append platformtypes=all to your request. Same is true for other endpoints.
Allows to use the domainId (instead of database Id) to identify resources. Requirements to make this work is to extend dataset mapped table with an identifier columns. This will map to domainId as usual.
From the Web API perspective, all requests to resource collections and /datasets/data endpoints require the query parameter matchDomainIds=true. POST data requests to /datasets/data which are not of type measurement require the handleAs=<datasetType> as well (measurement is the default).
An offering can be mapped now to other data than procedure. Old behaviour can be achieved by copying ProcedureResource.hbm.xml to OfferingResource.hbm.xml.
Adds a new boolean parameter showTimeIntervals to enable output showing start and end time of observations (in SOS terms phenomenontimestart and phenomenontimeend).
By default the parameter is set to false to allow backwards compatibility and easy/simple access to series data (via timestamp which always has been mapped to phenomenontimeend). When showTimeIntervals=true the output contains a timestart attribute (if mapped and is not null) showing the observation start.
To allow service to be stored in database, ServiceInfo (handled by Spring only in v1.x) became ServiceEntity which can still be optionally configured (and @Autowired) via Spring. If not present in Spring config, it is expected to be loaded from database.
If available parents and children can be part of a procedure/offering now. The parent extension adds available hierarchy info to the /datasets/<id>/extras?fields=parents
Allows to output resultTimes from observation data. Available result times can be requested from /datasets/<id>/extras?fields=resulttime. Then data requests can be dedicated to a particular result time, e.g.
datasets/measurement_6/?resultTime=2016-11-02T12:00:00- datasets/measurement_6/data?timespan=P1Y/2017-03-14TZ&resultTime=2016-11-02T12:00:00`
In combination with hierarchical procedures, this is convenient to query ensemble data. Ensembles of (re-)calculating datasets are aggregated and requested via result time.
On prerendering mode only single series charts are rendered. To add fine grained title configuration on series grouped via phenomenona a java String.format template can be used.
Choose one of the following
-
%1$s➡️ Platform label -
%2$s➡️ Phenomenon label -
%3$s➡️ Procedure label -
%4$s➡️ Category label -
%5$s➡️ Offering label -
%6$s➡️ Feature label -
%7$s➡️ Service label -
%8$s➡️ Unit of Measure
Use the template for the title config within config file config-task-prerendering, e.g. Platform: %1$s, Phenomenon: %2$s [{%8$s}]
Some databases do contain timestamps without timezone information but are not in UTC. In SOS (from v4.3.12 onwards) related contexts this is handled automatically and can be configured via SOS admin interface. However, in non-SOS related contexts this can be configured via jdbc.time.zone property within application.properties file.