Sensible observation services

I cry like the man in the classic anti-littering PSA whenever I read about implementations of the OGC's sensor "web" specification because environmental observation and real web architecture fit like a hand and a glove. What is an ASOS station or a data buoy if not a very dedicated and precise non-human blogger? Instead of routinely cranking out blurbs about Google Earth imagery updates, ArcGIS service patches, or RESTful architecture, it cranks out regular sets of scalar values: air or water temperature, dew point or salinity, wind speed or wave height.

ObsKML, too, recognizes the fitness of syndication for sensor observations, but KML doesn't really handle this kind of payload very well. Neither does RSS 2.0. Atom does have a general and robust content model that can deal with sensor observations as well as it does imagery or HTML: the observations go in an entry's content element, and all other entry elements serve as metadata.

...
 <entry>
   <id>urn:uuid:a261b59f-3692-4a00-a3bb-320a7448e0d8</id>
   <title>ASOS 89000 Obs</title>
   <updated>2009-03-14T16:00Z</updated>
   <georss:where>
     <gml:Point><gml:pos>-90.0 0.0</gml:pos></gml:Point>
   </georss:where>

   <!-- Human-readable summary -->
   <summary>Temp:-35.0, WindSpeed:5.0/10.0, WindDir:15.0, ...</summary>

   <content type="text">
     <!-- ASOS data here -->
     0187725020200111250051+40690-074170FM-15+0009KEWR...
   </content>
 </entry>

OpenSearch gives you a way to specify how a client slices a logical feed into bite-sized chunks. Goodbye, GetRecords(), GetCapabilites(), and GetObservations(). Hello, observations.

Comments

Re: Sensible observation services

Author: Jeremy Cothran

Thanks for the mention of ObsKML, it might be better in broader practice/acceptance to separate the idea of a simple Obs xml schema from the particular location/time xml wrapper whether it be KML,GeoRSS,etc.

The human/machine bias/divide that I continue to see is that any possible syndication format/wrapper/xml-based host(KML,GeoRSS,Atom,etc) has at its core a human audience focus with free-format text/html as the data payload(content tag in Atom) not providing support for simple/minimal xml schemas leaving the possibility of simple machine-to-machine syndication and automated parsing unaddressed.

As I have not seen any evidence of public interest in simple xml content schemas(public is a consumer of display/styled data, and only a producer in regards again to human-only-readable data in regards to free-form text/html) and no simple xml schema interest/support from technically capable search engine companies,instrument manufacturers,etc then the OGC spec/standards for better/worse seem to be the only game in town.

Thanks

Jeremy

Re: Sensible observation services

Author: Sean

No, Atom supports all kinds of payload, even text/xml, not only HTML.

Content schema isn't really the point here. I'm talking about how you get content/data to clients and how you synch it. Atom is simply better for this than SOS.

Re: Sensible observation services

Author: Jeremy Cothran

Yes, I was incorrect in stating that Atom content tag doesn't support xml schema, think I looked at an old spec page and see obvious examples as listed at http://data.octo.dc.gov Probably a little confused also by your example where the content is type 'text' and some domain-specific text-only format.

I understand and agree with your point that Atom is the bees knees for XML syndication(with an eye on browser performance Javascript/AJAX/JSON-related influence/interaction in the future).

Just adding pointwise that without any popular simpler content standards which might be understandable/implementable by non-OGC experts(the wider public, similar to the popularization of GML as KML), that the content standard and its related syndication are left in OGC's field and influence alone.

Jeremy

Re: Sensible observation services

Author: Sean

And I think that the OGC tends to get the expert formats right. It's the protocols for interacting with the services that suck for the web. Atom with SensorML or GML payloads could be a good solution.