1ST DRAFT - Where's the $$$ - OGC moving backward

I’ve spent much of this week along with some of the drones from the 'gol at the Open Geospatial Consortium (OGC) Technical Committee meeting in St. Louis. KML is at last 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 iron curtain.

So amongst the continued detailed work on the WANKS standards we know so well, there was much debate about the potential of RESTful interfaces (note: the freetards have been doing this for eons) and the use of lightweight technologies such as GeoJSON and AtomPub as realistic alternatives to creating transactional web services beyond mash-ups (note: nobody actually uses that stuff).

It becomes really interesting when the new and existing are combined (lambrini and coke for example), 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 paradigm technologies, new approaches to creating standard paradigms may also be needed, after-all the pace at which technologies are introduced and adopted by the mass-market paradigm is much faster than the traditional standards process can keep pace with paradigm.

Perhaps a new approach is needed where paradigm standards are defined at the same time as new applications paradigm and functionality is developed, so that the standards process is driven by individuals and organisations implementing new functionality paradigm 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 NASCAR with a picture of a bank, “I’d like some money.. bit I rather not know how it’s made, so we hit up Google for a grant”.

My release of my 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 paradigm, 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. [note: I hate these product sponsor paragraphs, talk to larry about doing less]

I have been to perhaps half a dozen Technical Committee meetings over the last few years, and almost all have been some of the most boring parts of my life. I leave St. Louis feeling happy to be alive and hope OGC can remain the positive influence on the industry it has been up to now, but that I don't have to give them any more money.

Written and submitted from the Westin Hotel, St. Louis, using its broadband network (hope Terminal 5 is ready for my return !)