SOS extension for the GeoServices REST API
1 like788 views
This project aims to provide environmental data from the European Environment Agency (EEA) in a standardized way. 52North developed an extension to the GeoServices REST API that adds Sensor Observation Service (SOS) functionality. This will allow the EEA to access sensor data from various member states in a uniform manner and reduce the need for custom adapters to integrate each new data source.
SOS extension for the GeoServices REST API
- 1. This talk describes a project which 52°North, ATKINS, and conterra are currently conducting for the European Environment Agency. The general aim is to provide the environmental data of the EEA collected from various data sources in a homogeneous way. As a requirement of this project, 52°North has developed an extension for the GeoServices REST API based on ArcGIS Server 10.1. This extension resembles the functionality of a Sensor Observation Service and embeds this SOS functionality into the Geoservices REST API which is currently working it‘s way through OGC. 1
- 2. EEA‘s mission is to support the sustainable development and improvement of Europe‘s environment, by providing timely, targeted and reliable information. 2
- 3. The EEA is a centralized European agency based in Copenhagen. It is collecting data from several environmental organizations from overall 32 member states. 3
- 4. Besides their responsibility to collect the data from the member state organizations, the EEA disseminates the data and derived information products. The data then serves as a basis to support European decision makers, but also to inform the general public. In her keynote talk at the ESRI user conference 2011, EEA‘s executive director, Jacqueline McGlade, pointed out in-situ sensors as an increasingly important data source for the EEA. 4
- 5. Thereby, the relevant sensors are manifold contributing to different data themes. 5
- 6. However, this variety of data sources at the associated member state organizations leads to a significant problem for the EEA. This figure illustrates the current situation. The data providers offer their data in proprietary formats via FTP or HTTP access. To cope with this variety, the EEA has to write manually adapters for each new data source. To do this in a timely manner is difficult. Then, the data is imported into the existing infrastructure which is based on ESRI‘s ArcGIS technology at the EEA. The data is provided to data consumers via application-specific interfaces. 6
- 7. 7
- 8. So, instead of various data access interfaces, the EEA will promote the SOS interface in future towards their data providing member state agencies. 8
- 9. 9
- 10. This slide shows the architectural overview of the developed solution. 10
- 11. Before the SOS Geoservices REST API is presented, here a short review of the general Geoservices REST API which is currently in the OGC standardization process within the Geoservices REST SWG. This screenshot shows an excerpt of that Geoservices REST API, the definition of the Layer / Table resource. As you can see at the bottom, each resource description contains the resource hierarchy figure. 11
- 12. The SOS Geoservices REST API is aligned with the general Geoservices REST API. We defined three types of resources offered by an SOS server: Observations, Procedures (=sensors) and Features (or features of interest). From this selection of resources, you can already see that the underlying model of the SOS REST API resembles the O&M 2.0 model. In fact, you can say, that this SOS REST API implements the conceptual model of the SOS 2.0. 12
- 13. The ArcGIS Server SOS Extension has been tested for a data set from the EEA which has been generated by a network of around 1500 air quality stations all across Europe, as shown in the figure. In an example setup, 30 days of data were loaded into the database which means over 1 million observations. 13
- 14. 14
- 15. As an example, the important Observation resource is describe in some more detail in the following. By accessing the Observations resource, a description of so-called observation offerings are returned to the client. They group observations and give information about those observation groupings, such as temporal and spatial extent. Then, observations can be requested by using the ‚query‘ operation on the Observations resource. Those query operations are the common way of filtering on resources within the Geoservices REST API. 15
- 16. 16
- 17. This query operation allows to filter on the observations resource with several parameters. Those parameters are basically the same as the GetObservation operation of the SOS 2.0 supports. 17
- 18. 18
- 19. The returned observations are encoded in a JSON format. Here, a simplified example is shown. The newly defined JSON encoding is aligned with O&M 2.0. 19
- 20. 20
- 21. 21
- 22. 22