Re: [SensorML] CSML and O&M SWE

• To: "'Luis Bermudez'" <bermudez@xxxxxxxx>, "'SensorML Forum'" <sensorml@xxxxxxxxxxxxxxxxxx>
• Subject: Re: [SensorML] CSML and O&M SWE
• From: "Mike Botts" <mike.botts@xxxxxxxxxxxxx>
• Date: Thu, 13 Mar 2008 11:58:33 -0500

Hi Luis.

*** looks like Alex and I were working on similar email in sync ****

I think that SWE Common within O&M is fairly able to handle lots of data
types in an efficient and robust way. We at UAH and other places have
utilized SWE Common to robustly describe, transport, and visualize a wide
range of data including time-series weather stations, SRTM elevation grids,
navigation measurements from UAVs and satellites, scanner data from
satellite and aircraft-borne remote sensors, real-time Doppler radar
radials, orbital elements, gridded forecast models culled from NetCDF, etc.,
etc.

However, your email brings up several aspects that are very timely for
discussion (don't you hate when one of my emails starts with a statement
like that ... I'll TRY to keep this short). There are some missing pieces
surrounding SWE Common, SensorML, and O&M that need to be addressed, but I
think the standards themselves are proving useful and powerful:

(1) first one needs to recognize that what is represented in the output of a
sensor or process in SensorML, as well as what is packaged in an
om:Observation is data content, not graphics content. In other words, we may
give you a time series of temperature, pressure, wind chill, etc., but we
don't tell you how to portray it. One might wish to show the temperature as
a time series plot or take the latest value an display it as a text label at

Similarly, looking at data from a remote sensing scanner on a polar orbiting
satellite, we also don't tend to tell you in the SensorML and O&M that you
should portray this as a gridded image. It again is just a time series of
observations where the scanning geometry characteristics of the sensor might
suggest that you could show this as an image with X being along scan and Y
being along satellite track, but you could also chose to display the
spectral curve at a single pixel point.

The same can the true of the time-series location of an aircraft or
satellite. It's a collection of time-based measurements that COULD be
recognized as a line. However, unlike GML that tends to portray much of its
geospatially oriented data as geometries, we have tended to focus on the
idea that these are measurements in SensorML, O&M, and SOS. That is one of
the reasons why I perhaps consider most GML Features as higher-level data
that can perhaps be derived from lower-level sensor Observations. The same
argument can be applied to SOS versus WFS.

(2) That being said, Alex and I have constantly argued both within ourselves
and between ourselves, as to the importance of defining data in SWE Common
as being of a particular geometry. We typically end up shying away from it,
still convincing ourselves that this is a portrayal issue perhaps.

(3) Now that doesn't mean that we shouldn't define records and arrays as
being of a particular type. This appears to be what is being done in the
CSML Feature Types that you send in your email. So using the "definition"
attribute in SWE Common, one might specify a DataRecord or DataArray as a
type with expected components:

<swe:DataArray definition="urn:ogc:def:property::PointMeasurementSeries">
 <swe:elementCount>
   <swe:Count>
     <swe:value> 120 </swe:Count>
   </swe:Count>
 </swe:ElementCount>
 <swe:elementType>
   <swe:DataRecord definition="urn:ogc:def:property::pointMeasurement">
     <swe:field name="time">
       <swe:Time definition="urn:ogc:def:property:observationTime"/>
     </swe:field>
     <swe:field name="temperature">
       <swe:Quantity
definition="urn:ogc:def::property::atmosphericTemperature">
         <swe:uom code="Cel"/>
       </swe:Quantity>
     </swe:field>
     <swe:field name="pressure">
      ... Etc

Notice that the definition attribute for the DataRecord defines it of being
of type "pointMeasurement" which is helpful, but the type "pointMeasurement"
would not necessarily be an XML Schema that tells you that the components
must be temperature, pressure, etc.. Instead a definition or profile for
"pointMeasurement" might only tell you that it has a collection of
measurements and that the first component must be of type "observationTime".

Similarly, notice that the definition of the DataArray is of time
"pointMeasurementSeries" which might be define as a sequential collection of
time-based point measurements ("pointMeasurement").

I think these definitions for aggregate types can be very helpful in
developing consistency in presenting certain types of data, and also in
portrayal (see 5 below).  I think the work done in CSML and other efforts
would be VERY useful in this regard.

(4) Sooooo, not only do we need to get busy and VERY serious about defining
dictionaries for "simple" property types like "temperature",
"wind-chill-factor", "conductivity", etc., but we need to also define
definitions and profiles for things like "pointSeries", "swath", "grid",
etc.

(5) Now, we get into a discussion Gregoire Berthiau and I were having just
yesterday on how we can define suggested portrayal of particular types.
Those of you familiar with Space Time Toolkit might know that we take the
data content coming from SOS services or SensorML processes and map those to
Stylers where the properties are specified using the OGC Styled Layer
Description (SLD) standard. Based on those stylers, we can then render to
OpenGL for display on the screen or to KML for feeding a Google Earth
client. Currently this requires us to set this up in the Project or at
run-time by the user.

However, if we had certain aggregate types defined, such as "nadirTrack",
"profileSeries", "swath", "grid", "timeSeries", etc, we could define default
styles using SLD. These could be local maintained by the client or
discoverable like everything else should be.


I'm very excited about us persuing this as part of our properties
dictionary. I think the benefits are enormous and could do much to ease
portrayal and allow more direct mapping of SWE Common to other formats like
NetCDF.

Your thoughts?

Thanks.
Mike Botts


--------------------------------------------------------
Mike Botts, Ph.D.                   mike.botts@xxxxxxx
Principal Research Scientist          http://vast.uah.edu

Huntsville, AL 35899 USA            (256) 652-0165 cell
--------------------------------------------------------

-----Original Message-----
From: sensorml-bounces+mike.botts=nsstc.uah.edu@xxxxxxxxxxxxxxxxxx
[mailto:sensorml-bounces+mike.botts=nsstc.uah.edu@xxxxxxxxxxxxxxxxxx] On
Behalf Of Luis Bermudez
Sent: Thursday, March 13, 2008 9:08 AM
To: SensorML Forum
Subject: [SensorML] CSML and O&M SWE

Hi Alex,

I have heard in various discussions that apparently O&M SWE schemas doesn't
accurately represent all the information necessary to accurately interpret
the data ( e.g. plotting ). For example NETCDF does a good job providing
dimensions, so you know how to interpret and plot the data. Also CSML has
different types of features types (enclosed image), which allow to present
each type of data in a very structured way, and thus interpreting it
apparently is much easier.  I imagine if we have specify the procedure that
we could infer how it needs to be interpreted ( best plot for that type of
data ).

Is SWE missing something ? How is the best way to present a result within
O&M/SWE that captures "semantic" information (e.g. dimensions) about how to
interpret the results ?

- Luis