Opened 16 years ago
Last modified 15 years ago
#2662 new enhancement
support DescribeObservationType
Reported by: | tomkralidis | Owned by: | tomkralidis |
---|---|---|---|
Priority: | normal | Milestone: | 6.0 release |
Component: | SOS Server | Version: | svn-trunk (development) |
Severity: | normal | Keywords: | |
Cc: | assefa |
Description
DescribeObservationType is an optional operation of SOS 1.0.0. The following parameters apply to DescribeObservationType:
parameter | required/optional | value |
service | required | "SOS" |
request | required | "DescribeObservationType" |
observedProperty | required | string (i.e. layername) |
For GetObservation responses (which are non DataBlock), we output a gml:featureMember.
Even though om:result is of type xs:any, because GML 3.1.1 is ref'd in the SOS schemas, XML validators attempt to validate the gml:featureMember. GML is designed as a building block, so output GML responses must validate to an application schema which extends GML.
Similar to WFS DescribeFeatureType, DescribeObservationType outputs an XML schema of the underlying structure of the layer. An example of this is at http://trac.osgeo.org/mapserver/browser/trunk/msautotest/wxs/expected/wfs_describe_feature_type_gml3l0.xml.
We need to implement DescribeObservationType given our om:result is GML.
We use GML so as to leverage clients who are GML aware (i.e. OGR).
To implement msSOSDescribeObservationType, the following steps are required:
- do parameter checking (msSOSDispatch already checks for service and request), so we only have to check for the required observedProperty parameter
- check that the layer indeed exists
- extend the gml:_Feature with the attributes in the layer
- output the response
This should satisfy DescribeObservationType. Then, msSOSGetObservation will have to be modified to ref the DescribeObservationType namespace and url in xsi:schemaLocation.
Note that this ticket will then solve #2646 as well.