MapServer SOS and SWE DataBlock
As part of MapServer’s support for standards-based interfaces, the SOS Server support is coming along quite well. With SOS 1.0.0 now adopted (although the schemas and standards document are not on the OGC public website yet), this provides a good opportunity to update the SOS support (which was previously at 0.0.31 and 0.1.2). This also was also a good time to move some of the GML code out of mapogcsos.c and into modular functions within mapgml.c.
Already numerous updates have been made. Some work is still required for GetObservation output (formatting, application schema, etc.). In parallel, Charlton Purvis has requested SWE DataBlock support as an output format for GetObservation requests. What the heck is a DataBlock, you say?
MapServer’s SOS GetObservation output is very WFS-ish in appearance (we use om:member to encapsulate a gml:featureMember, among other data). Of course, each attribute (or column value) is output as:
<pitch<2.5<yaw>-1.4538</yaw> ... <pitch>1.49672</pitch><yaw>-1.59275</yaw>
Observation data can become quite voluminous. Coupled with the baggage in redundant tag names, and you have quite a large response.
Let’s not be confused here. One big benefit of XML is that it allows for expressive and self-describing content models. At the same time, there are some situations where a more compact representation is beneficial.
Enter the SWE DataBlock. An XML construct, the DataBlock puts forth a header, if you will, which defines the field names and types, as well format separators. What then follows is a “block” of data, similar to a CSV file. Check out this example for a better idea. MapServer will still support the existing GetObservation output; we are simply adding another resultModel to the mix.
I think this will be a welcome addition to MapServer’s SOS support. I initially thought OGR‘s CSV write support would be a good fit, but Frank thought, for such a simple output, we might as well do this inline.
I think SWE DataBlock is pretty useful. I wonder whether WFS GetFeature requests would benefit from this as well.
