SOS Server structural changes
Tom.Kralidis at EC.GC.CA
Wed Oct 18 17:03:09 EDT 2006
> -----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?
> 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
> >> 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
More information about the mapserver-dev