At the OGC Technical Committee meeting today in St. Louis, Google pushed out the initial release of an open-source library for parsing and publishing KML. Read more about it on the Google Open Source Blog.

libkml was originally “announced” about 6 months ago as part of the kick-off of the standardization of KML within the OGC.

libkml is interesting in several ways. KML itself is just an XML specification for geographic data. Nothing really special compared to other XML formats. However, as I’ve championed there is a big difference between types of developers that use and read schemas, and those that use libraries or simple examples and documentation to implement parsers or tools. This is justified in that developers (both consumers and producers as discussed here) are usually trying to solve some other problem and want to use a format like KML merely as a mechanism to publish and visualize their information. By providing a stable and full-featured library, developers are free to build tools around the library without having to deal with the intricacies and issues of the format itself.

Similarly to the effect of opening the standardization of KML to the OGC effected other organizations like Microsoft to embrace the format - an open-source library also encourages other implementations, or competitors, of KML applications. Google is primarily in the business of data organization and search - so the more tools that publish or utilize a format they can then index is a win.

Another implication of libkml is that a single library can grow with versions and features, again freeing the developer from having to track future versions or bug fixes to the format.

Lastly, libkml is written to be fast - which is essential for handling large KML documents, realtime visualization, and potentially even mobile/limited-resource clients. However, how small libkml can be made is left to be seen.

As Michael Ashbridge pointed out, this is a very “alpha release, not Beta in the Google sense”. In fact, in the documentation there is the very clear disclaimer: “THIS IS ALHPA SOFTWARE. Expect changes. We do not yet recommend use in production code.”

There are still a number of features that are not yet implemented that are forthcoming, or can be accomplished by the broader community. They’re looking for feedback from developers on the interface and functionality. The library is C++, with SWIG bindings currently in Ruby, Java, Python, Perl and PHP. There are examples for developers to get up and running quickly.

It’s released under the new BSD license. It is meant to be as open as possible for developers to use in both open-source and closed-source projects without worrying about interference with other licenses.

It’s great to see Google pushing on the open-{source,format} in geospatial. They’ve obviously done a lot to raise public awareness of placemarking and geospatial data with GoogleMaps and GoogleEarth - they’re now engaging the GIS community and helping them.

Hopefully people, at least developers and users in the know, can soon stop referring to KML strictly as “GoogleEarth format” or “GoogleEarth Layer”.

Dealing with Reality

An issue we commonly run into is the reality that there are a lot of KML and other data sources in the wild that are malformed. There is the common response “it works in GoogleMaps, why doesn’t it work elsewhere?”

libkml is able to handle, to some extext, ‘bad’ KML, but is very strict in outputting KML that is generated using the DOM API in the library. Hopefully this generally raises the quality of available KML.

lib{geo}

A potential extension to libkml that excites me would be the ability ingest a KML document and publish it out as other formats such as GeoRSS or GML. Especially if a higher-level interface was built onto libkml that abstracted away the specifics of KML and instead provided an interface for general geometry (and feature) creation and manipulation.

Unfortunately since my laptop hard drive died last week, I don’t have a development machine to build and play with this yet. But I expect to use this library in a number of projects.

Google Code Project: libkml.

This needs to be converted into one of these.

(via Google LatLong Blog)

After 5 years in Michigan, unfortunately it has come time to say good-bye. At least for now.

Corrie and I moved to the Detroit for her to attend the University of Michigan to get her Master’s degree and for me to work at Realtime Technologies building high-fidelity, immersive vehicle simulation software. Due to the university being in Ann Arbor, and RTI in Royal Oak, we lived in the very quaint, though quiet, town of Northville.

However, along the way things changed. Corrie and I became married, she decided to stay on for her Doctorate, and I left RTI to do geospatial consulting and eventually incorporate Mapufacture with Mikel. No longer needing to commute an hour each morning and afternoon, we moved to Ann Arbor to enjoy the small, but high-energy town.

Ann Arbor held many surprises - a thriving tech community, though struggling tech industry. Google has set up an office, but primarily offering AdSense sales and support. Organizations like Spark are working to encourage small businesses and development, but I never connected in a way that was helped me.

The best thing that happened in Ann Arbor was the serendipity that proximity offered through being introduced to Ed Vielmetti, a veritable hurricane of ideas, energy, and connections with the tech circle throughout the world. The cadre of entrepreneurs, innovators, and generally swell people that belong to this small, but quickly growing collective are a model of what any community should be. Not to mention meeting up at Eastern Accents for a2b3.

However, Ann Arbor has the ardruous task of continuing to build, and maintain, this germination in the light of the difficulty that affects the Detroit region with economic downturn and general lack of benefits that other urban centers offer. There is no mass transit outside downtown Ann Arbor. Detroit continues to have problems with government, infrastructure, and corporations. Commuting is both the expectation (Motor City), but also the bane of creating a vibrant “young” population.

It’s not clear where I’ll end up (geographically). Corrie is a newly minted Dr., and is weighing her various potentials for how she’ll save the world (or at least make it a greener place) and also where it makes sense for both of us to be for a couple of years. I know I’ll maintain the great connections I’ve forged with Arborites and Michiganders, and know I’ll be back to visit soon.

Any one know a good tech community that needs a curler?

Spotlight has been in Mac OS X for quite awhile now, but in general, I haven’t found it very useful. However, when this tip came across at Mac OSX Hints on how to use operators for ranges in Spotlight metadata I got some ideas about doing geo-searches on my desktop machines.

To summarize, Spotlight is a system-wide metadata storage engine. Mac OS X provides a nominal vocabulary of metadata you can store, but you can also extend this to add your own metadata. Various applications like Yojimbo add metadata keys to store tags and other info with files. What’s especially great is that by applications using Spotlight, it means you can tie into this underlying metadata without having to use the application itself.

Using simple command-line parameters, you can do search for words, or specific metadata such as file type:

• mdfind -s "Hawaii"
• mdfind -interpret "keyword kind:image"

Great, but what about the range queries and Geo search? One of the default metadata items stored are kMDItemLatitude and kMDItemLongitude. In fact, you can use mdimport -A to get a list and description of all available metadata items.

You can then do geographic queries like: latitude:<20 longitude:>20 and get all files you’ve created (such as photos or documents) while in Hawaii. You can also do better bounding box searches. To play with this I wrote a small RubyCocoa app to do geographic queries and display the location on a map.

GeoSpotlight allows you to search without a box and add other Spotlight predicates to search by, say, keyword, title, city, time, etc. Check out the Query Expression Syntax for details on how to do this.

This was a quick mock-up and I’ll probably extend it to do bounding box specifying using the map interface and also locating documents via drag and drop.

The new version of Mac OS X, Leopard, came with a much anticipated feature - an officially supported set of Ruby bridges to Cocoa (the Mac OS X Framework) and AppleScript. Digging around I couldn’t find the pre-installed versions, but it was easy enough to gem install rb-appscript

I’ve been playing around with the very complete examples over the last couple of days and am really impressed with how easy it is to build Cocoa apps in just a few lines of Ruby code and using the new InterfaceBuilder. You get full-fledged support of all OS X’s goodness without having to worry about Objective-C.

However, I hadn’t fully considered some of the implications of this until I was stumbled across the open-source OmniFocus-UI. It is a Rails app written as an iPhone interface to the Productivity application (GTD) OmniFocus. It essentially provides a very lightweight web interface to the application by way of the AppleScript interface. rb-appscript and RubyOSA are two Ruby AppleScript bridges that make AppleScript actually really nice to work with.

The fact that it’s a Rails app is almost silly. There is no database connection to speak of. All storage and primary functionality is handled by the app itself. OmniFocus-UI could probably be rewritten as a Camping or Merb application very easily with a much smaller footprint.

The way the Rails app works is that the controllers just route commands via rb-appscript. So when you want a list of contexts (organization of todos), the Rails app just needs to do the following in Ruby:

require 'appscript'
doc = Appscript.app("OmniFocus").default_document
doc.contexts.get.length

Or to see how many Inbox items you have:

doc.inbox_tasks.count

If instead you want to use RubyOSA, it’s really just the Class name that changes (and some more underlying bits):

require 'rbosa'
doc = OSA.app("OmniFocus").default_document

What this means is, it’s very easy to build web interfaces on top of any AppleScript-able Mac application. The one difficulty, however, is configuring your Mac to make it easily externally accessible from anywhere on the Web. If you’re handy on IT, you can always setup port-forwarding on your router.

However, if you just want setup & forget, you should check out Prism (http://goprism.com) - which creates secure, private web accessible connections to your home computer.