SOS Server structural changes

[Kralidis,Tom [Burlington]]

> -----Original Message-----
> From: UMN MapServer Developers List 
> [mailto:MAPSERVER-DEV at LISTS.UMN.EDU] On Behalf Of Daniel Morissette
> Sent: 18 October, 2006 5:00 PM
> To: MAPSERVER-DEV at LISTS.UMN.EDU
> Subject: Re: [UMN_MAPSERVER-DEV] SOS Server structural changes
> 
> I saw this post on mapserver-users a few days ago and was 
> waiting to see if there was anyone using SOS who would 
> comment. Since there were no comments then I assume that the 
> current SOS stuff is not widely used yet and my first 
> reaction would be to keep only one method in 5.0 (the new one).
> 

That was my sentiment also.

> In my quick read I was not able to completely understand what 
> you are proposing as a new method, but I assume that you and 
> Assefa have figured something that would work at least as 
> well for the simpler cases that were supported before, so 
> dropping the old method should not create any new 
> limitations, correct?
> 

Correct.

> Daniel
> 
> 
> Kralidis,Tom [Burlington] wrote:
> > 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
> >>
> 
> 
> --
> Daniel Morissette
> http://www.mapgears.com/
>