Thin Web binding API to access timeseries data.
The Series REST API provides an access layer to sensor data via RESTful Web binding with different output formats like json, pdf or png. It provides a well defined Sevice Provider Interface (SPI) which can be implemented by arbitrary backend services to make series data available via the API
The Series REST API provides a thin access layer to sensor and observation data via RESTful Web binding. In addition, it offers several IO functionalities e.g.
- prerendering of series data,
- generalization,
- overlaying of data from multiple series
- conversion of raw data to other formats like pdf and png
Output formats for stationary, mobile, insitu and remote sensors are available, each filterable by metadata parameters. This enables clients to access the data via different approaches, e.g. to filter all series by phenomena first or by a special procedure.
Next to the Web API, a Service Provider Interface (SPI) defines the underlying interface for data providing backends. With this, the API is flexible enough to be put ontop of arbitrary data stores. Its modular design enables a seamless integration into existing Web applications.
The following main frameworks are used to provide this API:
- SOS Proxy: Allows to aggregate multiple OGC SOS instances under one API
- Direct database access: Allows to define Hibernate mappings to serve data directly from a database
- Fotoquest Data: tbd
- DWD Weather Alerts: tbd
- The SOS proxy demo provides an SPI implementation which accesses data from multiple Sensor Observation Services (OGC SOS).
- The Web application integration demo gives an integration demo which directly accesses the data from a database.
- The 52°North Helgoland Web Client consumes one or multiple instances of the REST API. A demo can be found under the http://sensorweb.demo.52north.org/client/#/
The client is published under the GNU General Public License v2 (GPLv2).
TBD, for now refer to https://github.com/52North/series-rest-api/pulls?q=is%3Apr+is%3Aclosed
We try to follow the GitFlow model, although we do not see it that strict.
However, make sure to do pull requests for features, hotfixes, etc. by making use of GitFlow. Altlassian provides [a good overview] (https://www.atlassian.com/de/git/workflows#!workflow-gitflow). of the most common workflows.
Henning Bredel (h.bredel@52north.org)
The Web API documentation gives a detailed overview on how to access the data provided by the API. Available I/O functions are described there, too, like generelization, chart rendering/overlay, etc.
The API documentation is in the 52°North wiki:
https://wiki.52north.org/bin/view/SensorWeb/SensorWebClientRESTInterface
How to provide a custom SPI implementation is beyond this section. See (...TBD...) to get detailed information on this.
In file WEB-INF/classes/config-general.json
add
"generalizer": {
"defaultGeneralizer": "lttb",
"noDataGapThreshold": 5
}
The parameters are described on the official Web API documentation.
Prerendering is supported for measurement data.
Prerendering configuration is a task which can be run regularly by a scheduler. Configuration is done as a
PreRenderingJob
bean. Checkout WEB-INF/spring/spi-impl-dao_tasks.xml
how to set up a prerendering
job. The actual rendering configuration for each series/phenomenon can be referenced within the job bean.
Rendering configuration tells how to render the actual series information. It comprises a phenomenonStyles
section (valid for a set of series for a given phenomenon) and a seriesStyles
section (which actually
overrides a phenomenon style of a specific series) Each section can override parameters made in the generalConfig
.
Only those series are prerendered having a match either in phenomenonStyles
or seriesStyles
.
In file WEB-INF/spring/config-general.json
you can set timeformat
Parameter. Please checkout the
Java SimpleDateFormat rules how the
format has to look like.
TBD
TBD
TBD