1
================================================================
2
MS RFC 13: Support of Sensor Observation Service in Mapserver
3
================================================================
6
:Author: Yewondwossen Assefa
7
:Contact: yassefa@dmsolutions.ca
15
This is the a first attempt to support part of the OGC Sensor Web Enablement (SWE) in Mapserver.
16
The different specifications developed around the SWE are :
18
- Sensor Observation Service (SOS) : provides an API for managing deployed sensors and retrieving sensor data.
19
- Observation & Measurement: Information model and encoding for observations and measurements.
20
- Sensor Alert Service : A service by which a client can register for and receive sensor alert messages. The service supports both pre-defined and custom alerts and covers the process of alert publication, subscription, and notification.
21
- Sensor Model Language : Information model and XML encoding for discovering, querying and controlling Web-resident sensors.
22
- Sensor Planning Service : A service by which a client can determine collection feasibility for a desired set of collection requests for one or more mobile sensors/platforms, or a client may submit collection requests directly to these sensors/platforms.
23
- Transducer markup Language (TML) : General characterizations of transducers (both receivers and transmitters)
24
- Web Notification Service : Executes and manages message dialogue between a client and Web service(s) for long duration asynchronous processes.
27
The intention here is to support the SOS mandatory operations.
28
Please refer to the OGC site (http://www.opengeospatial.org/functional/?page=swe)
29
for more details on the SWE initiatives.
34
From the user perspective there will be an SOS interface will offer the three core operations
35
(GetCapabilities, GetObservation and DescribeSensor). A full description of what could be available is
36
presented in Annexe A.
41
- All the development will be localized into a mapogcsos.c file.
42
- There will be additions to the mapows.c/h file to integrate the dispatch of the requests.
43
- In mapgml.c (function msGMLWriteWFSQuery), extract the loop that writes features ( gml:featureMember)
44
into a separate function so the the GetObservation can also use it to output the results.
45
- The SOS capability will be available when Mapserver is built using the flag USE_SOS.
48
Mapscript implications
49
----------------------
51
The are no special implication for the mapscript module
57
There will be an attempt to use the libxml2 (http://xmlsoft.org/) library when generating the GetCapabilities document. Decision to go ahead will be based on ease to use and speed of output.
63
It is proposed that automatic tests with map/data/expected
64
results be added into the msautotest project to test the
65
GetCapbilities and GetObservation requests.
71
Bug 1710 : http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1710
77
- +1 : Assefa, Warmerdam, Nacionales
81
Note : discussions, concerns are available in the mapserver dev list (Feb 2006 RFC 13 : SOS support)
84
Annexe A : Sensor Observation System (SOS) support in Mapserver
85
-----------------------------------------------------------------
87
This is a first attempt to define what will be supported in Mapserver to be able to deploy a Sensor Observation System (SOS)
90
Specifications and useful links used :
92
- Sensor Observation Service (SOS) (OGC 05-088r1, Version 0.1.1)
93
- Observation and Measurement (OGC 05-087r1, toward Version 1.0)
94
- Sensor ML : Sensor Model Language(ML) OGC 04-019r2
95
- http://www.opengeospatial.org/functional/?page=swe svn link for members : https://svn.opengeospatial.org:8443/ogc-projects/ows-3/schema4demo/
97
SOS provides several operations divided into core mandatory operations
98
(GetCapabilities, DescribeSensor and GetObservation) and optional transactional and
99
enhanced operations. The first implementation of SOS in Mapserver will only address the core operations
102
**1. GetCapabilities Request**
104
The GetCapabilities request will use the following parameters :
108
- Request : fixed at GetCapabilities
109
- Service : fixed at SOS
112
**2. GetCapabilities returned document**
115
Attached at the end of the document examples of a GetCapabilities document.
116
The following elements are SOS items included in the capabilities document,
117
with an equivalent Mapserver implementation
120
- ServiceIdentification (all elements are extracted from metadata at the web level)
122
- Title : extracted from a metadata at web level ows/sos_title. Same concept as wms/wfs
123
- Abstract : metadata ows/sos abstract
124
- ServiceType : Fixed to SOS
125
- ServiceType version : Fixed to 0.3
126
- Fees : metadata Ows/sos_fees
127
- Access Constrains : metadata : Ows/sos_constrain
130
- ServiceProvider (all elements are extracted from metadata at the web level,
131
using an equivalent name as the SOS element)
144
- ElectronicmailAdress
148
- ContactInstructions
150
- Operation Metadata : This part of the capabilities defines the operations
151
that will be supported which are GetCapbilities and GetObservation.
152
For more information refer to
153
https://svn.opengeospatial.org:8443/ogc-
154
projects/ows-3/schema4demo/ows/1.0.30/owsOperationsMetadata.xsd
156
- Operation : GetCapabilities
158
- Operation Name : Fixed at GetCapabilities
159
- HTTP : Connect point URL extracted. Only the Get request method is
161
- Parameter : includes name and version. We could use the parameters
162
to propagate the name of the service SOS and the version. Other
163
parameters may be added if needed.
165
- Operation : GetObservation
167
- Operation Name : Fixed GetObservation
168
- DCP (HTTP) : extracted from a metadata
169
- Parameter : We could use this to propagate the parameters needed
170
when doing a GetObservation request (Offering, eventTime)
172
- Operation : DescribeSensor
175
- Filter Capabilities
177
The Filter Capabilities that will be supported are the same ones that are
178
currently supported in Mapserver (http://mapserver.gis.umn.edu/docs/howto/filterencoding) :
179
Spatial Capabilities, Logical Operators, Comparison Operators
181
There is a mention in the specifications of ogc filter temporal capabilities,
182
but I could not locate the exact definition of it. In any case,
185
- SOS Contents (Observation Offerings)
187
As explained in SOS specifications (section 6.2) , “ ...An observation offering
188
is also analogous to a layer in a Web Map Service because each offering is intended
189
to be a non-overlapping group of related observations. Each Observation Offering is
190
constrained by a number of parameters including sensor system that report observation,
191
Time, phenomena, geographical region ... “
193
In Mapserver an Offering will be represented by a group of layers using
194
mapserer's group parameter. The metadata associated with a group
195
(offering will be taken from the first layer of the group)
197
The following properties would be set at a group level.
199
- Standard Properties
201
- id : Unique Offering Identifier. Mandatory
202
- name : name used with the offering. Optional
203
- description : description of the offering. Optional
205
- Bounded By : used to define the geographical boundaries of the Offering.
206
It should be extracted from a metadata. Mandatory
208
- EventTime : used to define a valid time range for the offering. It should be extracted
209
from a metadata. Mandatory
211
- Procedures : series of URLS reference to one or more systems that supply
212
observations in the offering. It should be extracted from a metadata. Mandatory
215
- Observed property : Observables/Phenomena that can be requested in this offering.
217
Two specializations are identified in the specifications:
219
- Constrained : modifies base phenomenon by adding a single constrains (ex surface
220
water temperature add a constrain that depth is between 0, -0.3)
221
- Compound which is either a composite (a set of component phenomena that may or may not
222
relate to each other)or a phenomenonSeries that applies one or more constrainstList to
225
There is no clear cut indication which representation would be the more natural for
226
Mapserver but if we consider the group/layer/attribute combination, we can see that
227
a group of layers could represent an offering, a layer would be an observed property
228
(or phenomenon) and the attributes would be the composite phenomenon defining the
231
The capabilities document will include CompositePhenomenonType element with an mandatory
232
id element identifying the phenomenon and optional elements such as name and
236
- Feature Of Interest
238
The definition given in the specification is : This is a single feature or a
239
collection of features that represents the object on which the sensor systems are
240
making observations. In case of in-situ sensor this may be a station to which the
241
sensor is attached or the atmosphere directly surrounding it. For remote sensors this
242
may be the area or volume that is being sensor.
243
It is represented by GML feature type and is expected to include bounding box extents.
245
In our case here, this would be equivalent to the “bounded by” element defined earlier.
247
Note that in the implementation of Mapserver, It is assumed that geographical
248
information used to represent the individual sensors represent the feature of interest
249
of the sensor. This is a requirement to be able to do spatial queries.
253
MIME type of the result that will be returned to a GetObservation request.
254
Fixed to text/xml;subtype=”om1.0.30”
257
**3. GetObservation Request**
259
The GetObservation request used to retrieve observation data will be supported using
260
the Get method. Post method will not be supported in the first implementation.
262
Here are the parameters that will be supported and their definitions :
264
- Offering : Equivalent to the Offering Id identified in the capabilities (Mandatory)
265
- evetnTime : single time or time period. This will be used as a Time filter to do the
266
queries using an identified time attribute. (Optional)
267
- observedProperty : Identifies the layer in Mapserver (Mandatory)
268
- featureOfInterest : Additional geographical filter using a bbox. (Optional)
269
- Result : Will be used to filter using the OGC Filter supported capabilities.
272
**4. Get Observation Response**
274
An observation response should contain the following information :
276
- Information describing the Offering
277
- Valid time (instances or period)
278
- Description of the phenomenon (like the offering name)
279
- location and feature of interest for the offering
280
- The result associated with the offering
282
In the case of Mapserver implementation, what is proposed is to be returned an
283
observation collection reflecting the query results. Here is the different elements
286
- name : The offering unique identifier
287
- description : Description of the offering
288
- time : Valid time instance or period
289
- featureofinterest : Geographical extents covered of the offering
290
- Member : This is repeated for all the observations returned. The following
291
are the parameters included for each member
293
- observed property : the phenomenon observed
294
- location : geographical coordinates
296
- result : Result of the observation. In the first implementation It is proposed
297
that the gml:feature member is returned. This gives the possibility to return
298
one/more attribute values in an easily manipulated format. The will be equivalent
299
to a gml:feature member returned in wfs.
302
**5. Describe Sensor**
305
The Describe sensor request uses two parameter that are SensorId (Mandatory) and an
306
optional outputFormat.
308
In this phase the DescribeSensor will use a metadata of URL type set on the layer and
309
relay the request. There won't be any SensorML output generation done in Mapserver in
316
- http://vast.uah.edu:8080/ows/weather?request=GetCapabilities
317
- http://vast.uah.edu:8080/ows/weather?
318
request=GetObservation&offering=WEATHER_DATA&time=2004-
319
04-01T05:00:00Z/2004-04-01T06:00:00Z&format=application/com-xml
added
removed
rfc/ms-rfc-13.txt
