DescribeSensor and GetObservation must support HTTP POST

[tomkralidis]

For SOS 1.0.0, DescribeSensor and GetObservation must support HTTP POST.

Snippets of email from OGC swe.wg list:

""" 1./

For GetCapabilities, the server must implement HTTP GET and can optionally implement HTTP POST.

For DescribeSensor and GetObservation, the server must implement HTTP POST.

2./

that (HTTP GET for DescribeSensor and GetObservation) would just be extra, non-standard functionality that your SOS service provides above and beyond what's defined in the SOS specification.

"""

Assefa: any comments on what this means for fixes to mapogcsos.c?

Will set milestone following initial discussion.

[tomkralidis]

I have the initial functionality working. I used libxml2's xpath functionality (very slick!) to parse the XML POST value. Notes:

• added sosParamsObj (r7074)
• added msSOSParseRequest() to mapogcsos.c
• this works in the same manner as mapwfs.s. msSOSParseRequest (called in msSOSDispatch) "flattens" the GET or POST request into an sosParamsObj. sosParamsObj is then passed to the appropriate request handler (currently GetCapabilities, DescribeSensor, GetObservation)
• libxml2's xpath support calls for well formed XML with namespace declarations, etc. This is a good thing :). So the XML POST requests sent by the client must prefix element names appropriately.

Changes:

• for msSOSDescribeSensor, I had to change things so that in sos_describesensor_url, the substituted variable to be used by the end user MUST be "%sensorid%". Previously, this was done by a generic loop to match the param passed on the GET request to the substitutable keyword in the sos_describesensor_url. Because the SOS POST request is not as "flat" as the GET request, this was changed.

Assefa: do you consider this a major backwards compatibility issue, now that users MUST use %sensorid% ? If so, we could put in some code to pick off "%variable" within sos_describesensor_url.

I haven't commited the changes in mapogcsos.c because this will lessen, but not break, msSOSGetObservation, which I have yet to completely implement against POST.

Assefa: if you want, I could send you a patch.

I've whipped up a test area at ​http://devgeo.cciw.ca/sos

[tomkralidis]

OK, committed in r7077. GetObservation GET support is as per normal, but POST lacks the following functionality to process:

• eventTime
• result
• featureOfInterest

I also bootstrapped msSOSDispatch() to better handle incoming requests.

[assefa]

• for msSOSDescribeSensor, I had to change things so that in sos_describesensor_url, the substituted variable to be used by the end user MUST be "%sensorid%". Previously, this was done by a generic loop to match the param passed on the GET request to the substitutable keyword in the sos_describesensor_url. Because the SOS POST request is not as "flat" as the GET request, this was changed.

Assefa: do you consider this a major backwards compatibility issue, now that users MUST use %sensorid% ? If so, we could put in some code to pick off "%variable" within sos_describesensor_url.

Tom, I think the change is acceptable. Not sure how widely this is used but I suspect It is still "new". I was thinking since parameter sensorid is somehow equivalent to procudure, if that woul dbe confusion to users ? (maybe use another name that really means subsitition if the sos_describesensor_url). Also does this parameter need to be adverized ?

I haven't commited the changes in mapogcsos.c because this will lessen, but not break, msSOSGetObservation, which I have yet to completely implement against POST.

Assefa: if you want, I could send you a patch.

From the last logs. I am assuming this is now committed? If there are other patchs you want me to test, I can do so.

Overall, It looks good. I will do more testings in the coming days. Thanks for this new feature.

I've whipped up a test area at ​http://devgeo.cciw.ca/sos

[tomkralidis]

Replying to assefa:

• for msSOSDescribeSensor, I had to change things so that in sos_describesensor_url, the substituted variable to be used by the end user MUST be "%sensorid%". Previously, this was done by a generic loop to match the param passed on the GET request to the substitutable keyword in the sos_describesensor_url. Because the SOS POST request is not as "flat" as the GET request, this was changed.

Assefa: do you consider this a major backwards compatibility issue, now that users MUST use %sensorid% ? If so, we could put in some code to pick off "%variable" within sos_describesensor_url.

Tom, I think the change is acceptable. Not sure how widely this is used but I suspect It is still "new". I was thinking since parameter sensorid is somehow equivalent to procudure, if that woul dbe confusion to users ? (maybe use another name that really means subsitition if the sos_describesensor_url). Also does this parameter need to be adverized ?

I believe they may be the same, at least at the interface level. Might be easier, for consistency, to rename to %procedure% ? Do you agree?

I haven't commited the changes in mapogcsos.c because this will lessen, but not break, msSOSGetObservation, which I have yet to completely implement against POST.

Assefa: if you want, I could send you a patch.

From the last logs. I am assuming this is now committed? If there are other patchs you want me to test, I can do so.

Yup, this has been committed.

Overall, It looks good. I will do more testings in the coming days. Thanks for this new feature.

I've whipped up a test area at ​http://devgeo.cciw.ca/sos

[assefa]

I believe they may be the same, at least at the interface level. Might be easier, for consistency, to rename to %procedure% ? Do you agree?

Yes that makes sense.

[tomkralidis]

Replying to assefa:

I believe they may be the same, at least at the interface level. Might be easier, for consistency, to rename to %procedure% ? Do you agree?

Yes that makes sense.

For the record, I've opened #2409 for this change in particular.

[tomkralidis]

FYI this is now advertised in GetCapabilities in r7402. msautotest also updated in r7403.

[tomkralidis]

We're getting there.

There are a few issues w.r.t. supporting SOS 1.0.0 and what we have implemented now, in particular with GetObservation

processing:

• eventTime: we currently support:

<gml:TimePeriod>
 <gml:beginPosition>2005-09-01T11:54:32</gml:beginPosition>
 <gml:endPosition>2005-09-02T14:54:32</gml:endPosition>
</gml:TimePeriod>

OR

<gml:TimeInstant>
 <gml:timePosition>2003-02-13T12:28-08:00</gml:timePosition>
</gml:TimeInstant>

SOS 1.0.0 supports:

<ogc:T_Equals>
 <gml:TimePeriod>
  <gml:beginPosition>2005-09-01T11:54:32</gml:beginPosition>
  <gml:endPosition>2005-09-02T14:54:32</gml:endPosition>
 </gml:TimePeriod>
</ogc:T_Equals>

OR

<ogc:T_Equals>
 <gml:TimeInstant>
  <gml:timePosition>2003-02-13T12:28-08:00</gml:timePosition>
 </gml:TimeInstant>
</ogc:T_Equals>

Note that there are many variations of time querying, but I've boiled it down to 1./ what we support 2./ the easiest

migration path.

• featureOfInterest: we currently support:

<gml:Envelope>
 <gml:lowerCorner srsName="EPSG:4326">-66 43</gml:lowerCorner>
 <gml:upperCorner srsName="EPSG:4326">-62 45</gml:upperCorner>
</gml:Envelope>

SOS 1.0.0 supports:

<ogc:BBOX>
 <gml:Envelope>
  <gml:lowerCorner srsName="EPSG:4326">-66 43</gml:lowerCorner>
  <gml:upperCorner srsName="EPSG:4326">-62 45</gml:upperCorner>
 </gml:Envelope>
</ogc:BBOX>

Note that there are many variations of time querying, but I've boiled it down to 1./ what we support 2./ the easiest migration path.

• result: we currently support as per mapogcfilter.c. Since SOS 1.0.0 uses Filter 1.1.0 we have to support that version. #2111 should help us here.

Finally, as we are using libxml2 for parsing the XML POST request, I've yet to figure out how to copy a tree of XML at a certain level to a string (which we would then pass to mapogcfilter.c in the same way we currently do).

Assefa: comments here? Will you continue to use CPL to parse the XML in filters for Filter 1.1.0, or use libxml2 to do this? If the former, then converting the XML to a string and pass along will work.

[tomkralidis]

This fix is committed in r7686. Notes:

• the various query encodings (eventTime, result, featureOfInterest) differ from what we support. Having said this, I have not changed anything in in the existing codebasse w.r.t. processing these, yet have used other means to support what SOS expects and what we support (level of node traversal passed, and masking for result [i.e. filter])

A testsuite to exemplify SOS and POST support (working off trunk) is at ​http://devgeo.cciw.ca/sos

Will leave this open for a few days for comments, etc., and will let other CITE specific bugs handle further details.

[tomkralidis]

Initial fix is in trunk. There are other tickets open related to this more specific to semantics, which will be taken care of in those tickets.