SOS Server structural changes

[Daniel Morissette]

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).

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?

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/