ObsKML

UPDATE: March 27, 2008 Xenia documentation is being migrated to http://code.google.com/p/xenia/wiki/XeniaHome

see also XeniaPackageSqlite and JCNotes

A discussion page for an observations oriented KML. See also this developer article .

KML currently handles spatial and temporal tags, but not data content. The below is an attempt to devise a content schema and mapping which would allow not only the display of data content, but also some meaningful data sharing within the observations community using KML/KMZ as a data transport mechanism. The kml tag used below is the 'Metadata' tag which carries the content in a more formalized xml schema.

Anyone wishing to share their data observation similarly, please email jeremy.cothran[at]gmail.com . I will maintain a registry of data observations available in this format to promote the format. I can also act to collect and promote additional lookup entries(observation and unit of measure types, etc) as needed. Examples of perl scripts which using XML::LibXML to reprocess xml feeds into ObsKML are located here

ObsKML Design Goals

The current design goals of ObsKML are to provide:

• a minimal common XML schema/vocab for sharing latest in-situ data on a report basis
• a low entry cost facilitator/catalyst to other aggregations/products/services
• some default analysis/visualization through some simple XML reprocessing/restyling http://carocoops.org/gearth/latest_placemarks.kmz for KML based products like Google Earth/Maps

or conversely to avoid the opposite of the above - stalled out technical specifications which never cross the field from expert debate and testbeds to actual utility in part due to an overly complex services/query only focus rather than a simpler data/document one. Popular data and data formats are primary critical issues - software and services are dependent and secondary considerations.

Another way of looking at this is towards a REST or Resource Oriented Architecture(ROA) approach(a file/format based approach) to sharing data as contrasted with a Service Oriented Architecture(SOA) web services based approach.

See also Benjamin Carlyle's web design thoughts at lessons of the web and the war between REST and WS-*

excerpted from from the Carlyle link below

Prefer low-semantic-precision document types over newly-invented document types
I think this is one of the most interesting lessons of the Web. The reason for the success of the Web is that a host of applications can be added to the network and add value to the network using a single basic content type. HTML is used for every purpose under the sun. If each industry or service on the Web defined its own content types for communicating with its clients we would have a much more fragmented and less valuable World-Wide-Web.

Related Links

Charlie Savage blog
http://cfis.savagexi.com/articles/2007/08/13/why-is-rest-so-hard-to-understand
http://cfis.savagexi.com/articles/2007/08/14/resources-and-representations-redux
http://cfis.savagexi.com/articles/2007/11/09/its-the-links-stupid

http://www.infoq.com/articles/rest-introduction
http://en.wikipedia.org/wiki/Resource_oriented_architecture

Schema simple

The below sample kml file shows an example of two observations listed at a platform. The xml schema is available here.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<Document>
  <name>Obskml sample</name>
  <open>1</open>
  <Placemark id="carocoops.CAP1.buoy">
    <name>carocoops.CAP1.buoy</name>
    <description>An html table derived from the obs kml metadata tags would be displayed here</description>
    <Point>
      <coordinates>-79.68,32.86,0</coordinates>
    </Point>
    <TimeStamp><when>2007-01-15T14:00:00</when></TimeStamp>

    <Metadata>
    <obsList xmlns="http://carocoops.org/obskml/1.0.0/obskml_simple.xsd" >

    <obs>
      <obsType>air_temperature</obsType>
      <uomType>celsius</uomType>
      <value>21</value>
      <elev>3</elev>
    </obs>

    <obs>
      <obsType>water_temperature</obsType>
      <uomType>celsius</uomType>
      <value>16</value>
      <elev>-1</elev>
    </obs>

    </obsList>
    </Metadata>
  </Placemark>
</Document>
</kml>

The above schema represents two observations from a single platform.

The 'elev' tag in the above schema corresponds to elevation. Positive is meters above sea level and negative is meters below sea level. Missing or unknown elevation values can leave an empty elev tag like <elev />

A recommended but not required convention is to use the Placemark id attribute to help uniquely identify observations between data providers. The recommended convention is the concatenation of <operator>.<platform>.<package> like carocoops.CAP1.buoy or nws.KCAE.met

Observation listing order is preferred to be from highest elevation/altitude to lowest elevation/depth.

Redundant sensors/observations would be listed in their order of importance (primary, secondary, etc).

Schema complex

Here is a link to a more complex xml schema for the kml metadata tag, incorporating

• value descriptive measurement types like for weather - overcast, cloudy, etc

• organization name
• organization url
• platform name
• platform url
• data url(s) - access to data in various formats and via various services
• sensor_order(s_order) - a way to distinguish between redundant sensors primary,secondary,etc
• quality control flag(s) - is data good, bad, suspect, etc

This additional metadata may or may not be available depending on the dataset and I want to focus on providing at least the minimal simple observation and unit of measure before branching into something more complex.

Generating and Styling ObsKML

Some sample/example cases showing how to generate or style ObsKML from other sources or convert from ObsKML to other formats.

Additional links

The Xenia relational database schema is the working schema we are using to aggregate various in-situ observations to before providing a variety of default output products such as maps, graphs and other csv and xml files.

JCNotes is a running developer log of points of interest, mainly in regards to tools/techniques for sharing observation data ( shorter summary of tools/approaches used ).

Diagram

Link to below image with further active image links
http://www.gliffy.com/publish/1329032/

to top