Any responses on this one (see below)?
> -----Original Message----- > From: UMN MapServer Users List > [mailto:[EMAIL PROTECTED] On Behalf Of > Kralidis,Tom [Burlington] > Sent: 15 October, 2006 7:18 PM > To: [email protected] > 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 >
