[Mapserver-users] Sensor Web Enablement (SWE), YSI and MapServer

[Kralidis,Tom [Burlington]]

Hi Yves,

Quite simply, UMN MapServer currently does not support the OGC SWE
approaches.  Most OGC SWE approaches are in discussion paper form and
not adopted OGC specifications.  I would love to see MapServer support
OGC SWE, once OGC SWE specs are publically adopted.

If you want to do this with UMN MapServer, my initial suggestion is
setup as OGC:WMS and OGC:WFS.  This is what we've done with some of our
water quality monitoring data with UMN MapServer.  We do have OGC:SCS of
some of our sensor stuff, deployed with a commercial solution.

Hope this helps.

..Tom

=========================
Tom Kralidis
Systems Scientist
Environment Canada
Tel: +01-905-336-4409
http://www.ec.gc.ca/


-----Original Message-----
From: mapserver-users-admin at lists.gis.umn.edu
[mailto:mapserver-users-admin at lists.gis.umn.edu] On Behalf Of Yves
Moisan
Sent: Tuesday, July 20, 2004 10:49
To: Mapserver-users at lists.gis.umn.edu
Subject: [Mapserver-users] Sensor Web Enablement (SWE), YSI and
MapServer


Hi All,

One of the objectives I had attending the recent OGIS conference,
besides getting to know you all, was to understand how to
store/retrieve/process in situ sensor data, in my particular case water
quality data coming from YSI 6600 sondes, and deliver it in a map over
the web.  I wanted to be able to draw the envelope of the "data service
tier" vs any client app, because I want to build my own client without
bundling the data tier into it.  Data must remain accessible to other
parties and of course MapServer/Server is where the data tier ends.  At
the time, I figured MapServer could spew out maps with little dots
showing sensor locations, people click on the dots, get the data in
tabular format.  Standard stuff.  I hadn't thought of sensor data
*standard storage* per se, though.

I am currently developing a small Python utility to gobble up YSI 6600
sonde data.  For now, I want to be able to simulate sonde data using a
"data generator" that would write such binary files for the sake of
having a system pseudo-working.  We are not getting a sonde any time
soos, but I want to get going.  When I get a sensor working, then I want
to use such a utility to QA sensor data and potentially to view it in
environments such as SciPy.  I don't want to use YSI's Ecowatch, at
least not in a production environment.  The data format is binary and as
of yet I have no clue as to how to decypher it, so I am playing around
with the file.  BTW, anyone knows of a "binary file explorer" type of
thing that would try and find patterns in arbitrary binary files and
suggest data extraction schemes, e.g. firts 4 bytes are chars, next 600
are floats ... ?

Anyhow, the jist of this message is about the SWE initiative -- which I
have just found out about today -- and its relation to MapServer.  I was
hoping to store sensor data in a sort of staging environment.  At the
first level, the original .DAT files.  At the second level, the data
would be stored in more pallatable formats for HTML/SVG output and it
would have been QA'd.  For that last level, I am not sure I would want
to serialize the data in XML (but then, maybe yes!) before stuffing it
in a DB.  Since I am using Python, I thought maybe of pickling it to a
flat file.  That would allow me to write a QA module (checking for NaN's
etc.) in Python and that would also let me use Python XML serialization
modules to pipe it through (using mod_python ?) before sending out to
the Web.  That's the flatfile/ObjectDB option.  Another would be to use
the flat file for QA, then spew the results out in tabular format into
PostGIS.  That'a probably closest to what would be amenable to MapSever.
What is the status of SWE in the context of MapServer ?  I gather SWE it
is not a spec yet, but is it coming strong?

The point is simple : I have sensor data that I want to show up on a map
and above all store it so it can be "OGC Serviced" when SWE clients
start to appear.  I'll probably have to write a SWE client.  If I do, I
want to do it with Python (thanx Sean for that point on your slide, but
I was already convinced!) and I'll want an adapter for Zope and maybe
Twisted (also my problem).  I just want to do it in the most "OGC
compliant", Pythonic way.

Any pointers ideas out there ?

Thanx

Yves Moisan