OK. Microsoft decided it wanted to put a few spaces within my URL when I
pasted it in the original email. The links are corrected below:
For your consideration, here's a link to an SOS providing weather station data:
Capabilities:
http://vast.uah.edu:8080/ows-dev/weather?request=GetCapabilities
GetObservation request (1 day's worth of observations):
<http://vast.uah.edu:8080/ows5-dev/weather?request=GetObservation&version=0.0.31&offering=WEATHER_DATA&time=2004-04-01T05:00:00Z/2004-04-01T06:00:00Z&format=application/com-xml>
One of the drivers for the om:Observation schema using SWE Common data types
and encoding definitions, is that it would support a wide range of observation
types (single observations, time series observations, and coverages such as
grids and images) in the same way and in an efficient manner. They are also
meant to be self-describing without relying on community-specific agreements.
The Observation schema using SWE Common also supports true binary and simple
MIME types (e.g. JPEG) through out-of-band links to flat files or within SOAP
messages with attachments. However, it is not expected or intended to simply
describe and point to a NetCDF or EOS-HDF file, since those can themselves have
complex structures in which knowledge of the format is required. We currently
have SOSes that utilize NetCDF as the data source, but subset these files at
the server level and repackage them as om:Observation. To explore some other
SOS/WCS services that provide other types of data in om:Observation, check out:
<http://vast.uah.edu/joomla/index.php?option=com_content&task=section&id=8&Itemid=64>
All of this discussion again brings up, of course, what we discussed in Paris
... the need for the various web service groups (SOS, WFS, WCS) and encoding
groups (SWE, GML, NetCDF, EOS-HDF, video, etc) to all begin to meet together
for the sake on defining harmonization and/or dividing lines between OGC
services and encodings.
Thanks.
Mike Botts
