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.

I was gone for 5 days to the Ontario Curling Association’s Colts Provincial Playdowns, the top-tier competition after playing down against 130 other curling teams. We held our own, but the competition was very stiff.

It was a tough time to be away, a lot of amazing news came out. First and foremost is that Google adds support for GeoRSS. This is exciting news because it demonstrates the maturity and interest in the syndication of geographic content in blogs, CMS’s, sites, and news.

This will also add a little bit of more difficulty moving forward in GeoRSS. Now that a major company has added support, and assumedly a lot more developers will add support now as well, then the specification has to be much more cognizant of future changes, users, and upgrades. Before, the specification was really guided by the majority of developers using the standard itself. If some spec was changed, we all went out and updated our libraries. Now, however, we really need to denote versions, and how users can update their tools to accomodate both the new version and backwards compatibility.

On top of that exciting news, Google also open-sourced part of the GoogleMaps library. See the
gmaps-utility-library-dev FAQ. Currently this is limited to the GMarkerManager, but demonstrates their interest in opening the library up for interesting projects, ideas, and hacks.

Marc at Geonames points out that Google has a request for feature requests their mapping API. He supports the ‘Compatibility with other map APIs‘.

I disagree. If a mapping API vendor is required to (or tries to) stay within an agreed upon ’standard’ API, then that could stifle features/innovation. They would have to all agree on a standard to, say, add polygonal overlays, or moving objects (e.g. tracking realtime position of other vehicles)

However, when this ‘abstraction of API’ is relegated to other projects (as he points out Mapstraction, OpenLayers, and MyMap do this, they don’t just attempt it) then each of them can decide if they are a minimal set implementation (only allow what all allow), or a maximum set, or somewhere in between.

What is better if they just support mapping using data format standards. They should all consume open/non-partisan standards such as GPX, GeoRSS, GML, etc. That way someone doesn’t necessarily need to know the entire API if they can just load and map their common data source.

Is there a way to vote for the anti-request.

cross-posted from comments on Geonames

Gutenkarte was an amazing thing to see, mapping the locations within a book. However, it is only able to map and share public domain material.

Now GoogleBooks supports mapping of locations mentioned in books they’ve archived. See Lonely Planet USA for the locations mentioned in this travel guide. A great way to preview what locations the book focuses on and covers. (via hobu, via import cartography)

Or for fictional books, such as Neal Stephenson’s Quicksilver it can help you decipher what happened where.

Google has the benefit of being able to store and share the text for currently copyright material, which is a definite benefit. But the integration of maps really adds to the information and understanding of the material.

Brady points out on O’Reilly Radar some of the new layers in GoogleEarth. Most interesting though is his recap of feedback from Flickr’s Dan Catt on why Google isn’t currently displaying Flickr photos (despite perhaps the obvious that (Flickr! < Yahoo!) != Google).

His claim is that they take their bounding box parameters in different order: bbox=x1,y1,x2,y2. vs. box=x1,y1,x2,y2. However, based on my research of the API's, they look comparable. For example, Google Earth's view based refresh will do a bounding box request:

longitude_west, latitude_south, longitude_east, latitude_north

and the Flickr photo search expects the following BBox:

minimum_longitude, minimum_latitude, maximum_longitude, maximum_latitude

You can see that minimum_longitude is the same parameter as longitude_west, and so on. So I’m not sure why Dan Catt uses that as his explanation that the parameters don’t line up.

However, as Brady points out, what would really help everyone is if the services all spoke common languages, like Flickr outputting KML, or GoogleEarth consuming GeoRSS (since Flickr can output GeoRSS). My money would be on the latter, since there seems less impetus for a company like Flickr/Yahoo to export their data in a proprietary format.

Of course, the translation between the two formats, especially for basic geometry such as points, is trivial, so implementing both on both sides, or simple conversion utilities in the middle, would be straight-forward.

Extra Credit

For extra credit, implement said conversion utility to convert KML <=> GeoRSS using XSLT, or other language of your choice.

There are also various other Flickr/GoogleEarth utilities out there like displaying grids of the # of Flickr images in GoogleEarth.

Pleasant Surprise

While researching parts of this post, I found a new Flickr API method that I didn’t know existed before:

flickr.photos.getWithGeoData - “Returns a list of your geo-tagged photos.” However, you can’t do a search within this set other than by date. But at least now you can pull up a trail of your travels based on your photos.

“Where were you on the night of the 13th?!”

In the past, when using my Feed URL to get geotagged photos, I just made sure that photos had a tag “geotagged” and then grabbed all the photos with that tag.