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
