SOS Server structural changes

[Kralidis,Tom [Burlington]]

Any responses on this one (see below)? 

> -----Original Message-----
> From: UMN MapServer Users List 
> [mailto:MAPSERVER-USERS at LISTS.UMN.EDU] On Behalf Of 
> Kralidis,Tom [Burlington]
> Sent: 15 October, 2006 7:18 PM
> To: MAPSERVER-USERS at LISTS.UMN.EDU
> Subject: [UMN_MAPSERVER-USERS] SOS Server structural changes
> 
>  
> 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
>