Categories
OGC Thoughts

Where’s the cheese – OGC moving forward

St Louis

I’ve spent much of this week along with some of the other guys from Google at the Open Geospatial Consortium (OGC) Technical Committee meeting in St. Louis. KML is hopefully just a few weeks away from becoming an adopted standard, and the OGC as an community I’m pleased to say, is increasingly taking interest in geospatial technologies developed outside of its traditional membership.

So amongst the continued detailed work on the W*S standards we know so well, there was much debate about the potential of RESTful interfaces and the use of lightweight technologies such as GeoJSON and AtomPub as realistic alternatives to creating transactional web services beyond mash-ups.

It becomes really interesting when the new and existing are combined, one of the slickest demos I saw was using an extension to the existing SLD standard to control the server side creation of KML data from a component WMS service, populating attribute data into KML Extended data tags.

There is also growing recognition that as a reflection of the new technologies, new approaches to creating standards may also be needed, after-all the pace at which technologies are introduced and adopted by the mass-market is much faster than the traditional standards process can keep pace with.

Perhaps a new approach is needed where standards are defined at the same time as new applications and functionality developed, so that the standards process is driven by individuals and organisations implementing new functionality which is standardised once demonstrated to be both stable and useful !

This new approach which focuses more on the user need, was nicely summarised in a presentation from NASA with a picture of a cheese stall, “I’d like some cheese.. bit I rather not know how it’s made”.

Googles release of the libkml open source library should be seen in this context, as it allows developers to quickly get started in creating well formed KML files, and to experiment quickly by actually writing code. Want to write a FDO provider to read and write KML, then libkml is a great starting point, likewise if you want to write a new iPhoto geo-tagging plug-in, libkml deals with most of the basic requirements you would need. In both cases any extensions or changes that might be needed to KML can be tested and proven in a practial sense before becoming standardised.

I have been to perhaps half a dozen Technical Committee meetings over the last few years, and I leave St. Louis feeling more optimistic than even before that the OGC can remain the positive influence on the industry it has been up to now, change is needed but that’s recognised.

Written and submitted from the Westin Hotel, St. Louis, using its broadband network

7 replies on “Where’s the cheese – OGC moving forward”

I am happy to see that cases regarding standards such as the CORBA case has been remembered and that some lessons might have been learned here.
Having standards defined by a committee without immediately applying them in an application is really a bad thing.
Real standards are DEFACTO Standards like TCP-IP and now KML regarding GIS and not X-25 and GML. The committee standards tend to do too much and always become clunky as everybody has to leave the meetings more or less happy ;-).

Great news that KML is shortly going to be made a standard but what about the limited use of different coordinate reference systems? When are they going to move off using WGS84 and allow others as GML allows? This strikes me as a bit of an obstacle to overcome before the standard can bepublished surely?

GML: is it out there and usable?
I am looking at integrating an Intergraph SmartPlant architecture with ESRI, and looking at the interoperability options, it seems that GML is the data option. But who has done this besides within the scope of OGC? Can I realistically consider GML as an option?

Add a comment?

This site uses Akismet to reduce spam. Learn how your comment data is processed.