SOS Server structural changes

[Kralidis,Tom [Burlington]]

Hi,

The following email is a result of meetings between Assefa and myself
last week (Assefa: please add anything I may have missed).

As of April 2006, OGC:SOS (version 0.0.31) server support has been
implemented in MapServer, funded by Environment Canada.

One of our project's underlying DB is setup such that sensor data is
structured as 2 tables (one for the observations and measurements, and
one for sensor metadata).

When we implemented OGC:SOS, we structured the mapfile SOS settings such
that one OGC:SOS procedure (i.e. a station) is analogous to one LAYER
object.  Procedure IDs are needed to advertise in OGC:SOS
GetCapabilities, as well as GetObservation Filter statements when
filtering by procedure ID.  This is functional and works as expected.

We have ran into scenarios where we may have networks of hundreds of
stations, and hence LAYER objects.  This has resulted in:

- huge mapfiles: we have a mapfile with 310 LAYER objects and 1MB in
size, which slows down processing at runtime
- custom compile of MapServer required (MAXLAYERS is defaulted at 50 in
map.h), which can be cumbersome in Win32 environments

Assefa and I discussed these issues last week and thought that an
alternate approach would be more efficient.

Proposal
--------

- have one LAYER object, with pointer metadata to a column which houses
the procedure, i.e.:

LAYER
...
 METADATA
...
  "sos_procedure_item" "station_id"
  "sos_sensorml_format" "http://host/getSensorML?station=%sensorid%" #
e.g. 1
  #"sos_sensorml_format" "http://host/stations/%sensorid%.xml
 END
END

Here's how the operations would be affected:

GetCapabilities: when MapServer processes a GetCapabilities, it would
generate a distinct list of procedures from sos_procedure_item and
output them in the Capabilities XML.

DescribeSensor: MapServer would do an HTTP redirect to
sos_sensorml_format, passing sensorid from the request (sensorid is a
required keyword of DescribeSensor).

GetObservation: when MapServer processes a GetObservation request
filtered by a procedure, it would pass this filter to query the
table/dbf/whatever with sos_procedure_item = procedureid.

This way mapfiles would be much easier to deal with and smaller in byte
size.

This would affect the way MapServer OGC:SOS works currently in terms of
existing implementations.  With this implemented, would we support both
ways of dealing with OGC:SOS, or eliminate the initial code approach?
How many folks are affected by doing the latter (I haven't seen much use
of MapServer OGC:SOS so far on mapserver-users)?

I would be interested in hearing what folks think about this before
moving ahead any further.  Keep in mind this is based on my
organization's requirements and our underlying sensor data, so ideas and
thoughts are welcome!

..Tom