MapServer and Sensor Observation Service

[Stephen Woodbridge]

Daniel,

I think the issue here is would any of the existing community benefit 
from this, be able to use it, etc or not. It seems like this would add a 
lot to the documentation and complexity to mapserver from the point of 
view or newbies trying to learn things and from testing and release 
management.

So if a bunch(?) of other users need this functionality in mapserver, I 
guess I would be OK with it, but my gut based on the description and my 
needs today, would say make it a separate project built on top of 
mapserver. It seems you have had similar concerns because you are asking 
these questions and thought up these scenarios.

I think this gets back to the need for a mapscript like API for "C" that 
is stable and that other can build C-based applications on.

My 2 cents,
  -Steve

Daniel Morissette 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