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