MapServer and Sensor Observation Service

[Kralidis,Tom [Burlington]]

> 
> On 1/27/06, Daniel Morissette <dmorissette at dmsolutions.ca> wrote:
> > Hi,
> >
> > We are working with Tom to implement a Sensor Observation Service 
> > (SOS). Since they already have a bunch of WMS/WFS services based on 
> > MapServer, they would like to have this as an extension to 
> MapServer, 
> > with the same configuration mechanism that their administrators are 
> > already used to. However, the SOS is in this grey area of features 
> > that may or may not belong in MapServer depending on how we look at 
> > them.
> >
> > So we are considering two options on which we would like to 
> have your
> > opinion:
> >
> > 1- Implement SOS as a new service type supported by MapServer (i.e.
> > mapsensor.c) just like the current WMS/WFS/WCS support, an optional 
> > feature that could be enabled/disabled at compile-time.
> >
> > 2- Create a separate project independent of MapServer for 
> the SOS. It 
> > would be built on top of map.h and libmap, but would not be part of 
> > the MapServer source and distribution.
> >
> > In both cases, the result would be more or less the same: a 
> SOS that 
> > is configured via a the same MapServer mapfiles that are used for 
> > WMS/WFS, and that uses the same data access methods from 
> maplayer.c... 
> > the question is really whether we think that this feature 
> belongs in 
> > MapServer (#1) or not (#2).
> 
> Daniel,
> 
> Could you briefly describe the SOS, and how it would be 
> integrated with MapServer?  Is this another datasource, we we 
> read from remote sensors and then plot the results as point 
> features?  It is another way of publishing MapServer point 
> data (where mapserver is the server)?  Both?
>

Note: this would not read from 'remote' sensors, but from a datasource
in the same way traditional data connections are made in MapServer
(shapefile, OGR, etc.).

Initially, I think this would be a facade on top of MapServer to output
as per the SOS specification.

In many ways, I would initially see this as the same inner workings as
OGC:WFS, but with a different output content model.

The added complexity is involved in how to integrate Sensor and Platform
metadata.  Brief explanation:
 
An OGC:SOS basically provides information about sensors/stations/etc.,
foreach station, there is associated:

- platform metadata (the instrument)
- sensor metadata (what it measures)
- observations (i.e. the data)

The platform and sensor metadata are based on the SensorML
specification, which could be quite complex.  So how do we integrate
this type of info into the MapServer / mapfile model?  IMHO, at this
point, I don't think implementing a SensorML library would be
beneficial, so we might be better off to use LAYER/METADATA to point to
the SensorML documents.

> If the implementation were able to be quite localized to one 
> module in MapServer, and if it sorts of fits with the 
> mapserver role of publishing geospatial data on the web, then 
> I don't think I would mind it living within the mapserver tree.
> 

I think it sort of fits with the MapServer role in terms of:

- data access
- ability to query by attribute
- ability to query by spatial predicates
- ability to query by temporal predicates

Interested in hearing the community's feedback here.

Cheers

..Tom