52°North SOS data models

This site discusses the main data models, the 52°North SOS implementation is based upon and howto map your data onto these concepts.

Basic observation model of O&M specification

The 52°North SOS implements the OGC SOS specification and the OGC SOS relies upon the OGC Observation&Measurements specification. For this reason, the basic data of the 52°North SOS is based upon the basic Observation&Measurements model. Figure 1 shows the UML diagram of the basic observation model.

Figure 1: UML diagram of basic observation model of Observation&Measurements specification

An observation could be defined as an act of observing a phenomenon. A measurement is a specialized observation, whose result is a numerical value.

The basic observation model contains five components (as shown in Figure 1): The procedure element should point to the procedure (usually a sensor), which produced the value for the observation. The observedProperty element references the phenomenon that was observed. The featureOfInterest refers to the real world object to which the observation belongs. The samplingTime attribute indicates the time, when the observation was made. The observation value is contained in the result element.

The observation acts as a property value provider for a feature: It provides a value (e.g. 27° Celsius) for a property (e.g. temperature) of the featureOfInterest (e.g. weather station) at a certain timestamp. The location to which the observation belongs is indirectly referenced by the geometry of the featureOfInterest.

Identifying your data and mapping to the basic observation model

As shown in the previous section, an observation consists of five basic components:

• time
• location
• producing sensor (or procedure)
• phenomenon which has been observed
• observation result value

You have to identify these basic fields in your observation data.

Once you identified these components you have to map them as follows to the observation model:

• time --> samplingTime in O&M model
• location --> is contained in the location property of the feature of interest in O&M model
• producing sensor --> procedure in O&M model
• phenomenon which has been observed --> observedProperty in O&M model

The 52°North SOS standard data model

The data model of the standard 52°North SOS database is based upon the O&M observation model. Figure 2 shows the ER-diagram of current data model of SOS PostGIS database.

Figure 2: ER-diagram of current data model of SOS PostGIS database

The tables in the grey box of the figure will be automatically used by the SOS to store request parameters for a later getResult operation request. The rest of the figure shows the „data“ tables of the SOS database. The SOS will use the tables above to answer incoming requests or to update the values.

The following tables are contained:

1. feature_of_interest table – the feature_of_interest table stores data about the feature of interest. The geom column holds the geometry of the feature_of_interest and is of the PostGIS type geometry.
2. foi_off table – the foi_off table realizes the many-to-many relationship between offerings and features of interest. Remember to insert the relationships if you have inserted new offerings and/or new features of interest!
3. proc_foi table – the proc_foi table realizes the many-to-many relationship between procedures and features of interest. Remember to insert the relationships if you have inserted new procedures and/or new features of interest!
4. observation table – the observation table aggregates the data of an observation event like time, procedure (sensor or group of sensors), the feature of interest and the observation value, which is stored in a seperate table. Note that the columns observation_id, feature_of_interest_id, and procedure_id are foreign keys. You have to ensure that the values you want to insert in this columns are contained in the tables they reference on.
5. quality table – the quality table stores quality attributes for an observation. Qualities are optional and have not to be set. In this case set 'conf.sos.supportsQualit'y in config.properties file to 'false'. 1. procedure table – the procedure table stores data about the procedure. Only the procedure_id which should be the URN of the procedure as specified by the OGC must be contained. 1. proc_off table – the proc_off table realizes the many-to-many relationship between procedures and offerings. Remember to insert the relationships if you have inserted new procedures and/or new offerings!
6. offering table – the offering table stores each offering of this SOS. This table is only used when the SOS is initialized to read in the offerings of this SOS (e.g. gauge height) and the phenomena which are related to each offering. Note that if you have inserted new offerings, you have to restart your SOS to enable the changes.
7. phen_off table - the phen_off table is created to represent the many-to-many relationship between offerings and phenomena.
8. composite_phenomenon table – the composite_phenomenon stores composite phenomena.
9. com_phen_off table – the com_phen_off table realizes the many-to-many relationship between composite phenomena and offerings. Remember to insert the relationships if you have inserted new composite phenomena and/or new offerings!
10. phenomenon table – the phenomenon table represents phenomena. In the context of the new SOS specification phenomena are also called observedProperties. Only the phenomenon_id and value_type are required. The phenomenon_id should contain the URN of the phenomenon as specified by the OGC. The possible values of the value_type column are: integerType, doubleType, floatType for numerical values textType for textual (categorical) values
11. proc_phen table – the proc_phen table realizes the many-to-many relationship between procedures and phenomena. Remember to insert the relationships if you have inserted new procedures and/or new phenomena!
12. proc_off table – the proc_off table realizes the many-to-many relationship between procedures and offerings. Remember to insert the relationships if you have inserted new procedures and/or new offerings!
13. request_phenomenon table – the request_phenomenon table realizes the many-to-many relationship between phenomenon and request. This table is used for the support of the GetResult request.
14. request table – The request table stores information for the GetResult operation.
15. observation_template table – the observation_template table realizes the many-to-many relationship between procedure and request. This table is used for the support of the GetResult request.

How to get your data into the SOS?

There are two ways to insert data into the database. You can use the SOSFeeder Framework or you can use the transactional function of the SOS.

52°North SOS Feeder Framework (!!! development has been stopped !!!)

The SOS Feeder is a framework which can be used to insert data into the standard 52°North SOS database (PostgreSQL 8.1 or higher). The FeederServlet acts as interface for communication with the SOS DB Feeder.

For more information and how to use you can download the SOSFeeder from the same SVN as the SOS. Only the Repository-Path has to be changed to /swe/main/SOS/Feeder/SOSFeeder. In the doc folder you can find the installation guide.

SOS Transactional Profile

The transactional profile should enable data producers to register new sensors to the SOS using the RegisterSensor operation and afterwards to insert new observations using the InsertObservation operation. Both operations are very generic due to the reason that the RegisterSensor operation request contains a SensorML description as parameter and the InsertObservation operation request needs a om:Observation as parameter. As the transactional profile's implementation is at an early state, currently only sml:System is supported as description for sensor which should be registered. Furthermore, only numeric values for phenomena could be inserted into the 52°North SOS implementation.

In the Folder xml you can find examples for RegisterSensor (RegisterSensor.xml) and InsertObservation (InsertObs_samplingPoint.xml). Take a look at the comments in these example requests to get additional information about the request parameters.

SOS Importer

A new possibility to insert data into the SOS is the SOS Importer tool.

Troubleshooting

If you have questions regarding the data model or how to map/insert your data into the 52°North SOS, feel free to send your questions to the SWE Mailing List.

-- ChristophStasch - 07 Jan 2009