Today Google announced that they are enforcing free usage limits on the Google Maps API. Beyond the free limit of 25,000 views per day, sites will start having to pay $4 per 1,000 views. They will automatically charge your credit card based on these usage fees and it’s not clear if you can set a “cut-off” limit or if it will have the similar suprises as overseas cell charges.

I find this is a bit of a surprising action from Google. In 2005 they changed the mapping and geospatial web by providing a powerful, easy to use great API (eventually), and primarily free of charge slippy map platform. The term “GoogleMap” became synonymous with being able to pan and zoom through the entire world without any reloading of the page or poor user experience. Since then, there have been millions of sites that have used GoogleMaps to provide simple map views and location services. Assumedly this information has been of huge value to Google in understanding interest, spatial-context, and generally eyeballs to Google tools and content.

Google has also worked to monetize maps, often subtly through sponsored map markers, and other times more directly through in-map ads. Each of these decisions brought discussion and disent but it was difficult to argue with the fact that the tool was still free to use. Google has clearly put real value in content and engineering into Google Maps. The quality of geocoding, data availability and power of the API has always been extremely capable and arguably the best of breed.

Now, with a very direct pay requirement being imposed this will dramatically change the adoption of GoogleMaps. Developers will have to consider very carefully how they will afford the potential – and optimistically likely – fees that the service will require as it becomes successful.

Fortunately, there are still a few really good alternative options for developers of sites if they can’t afford the usage fees. MapQuest has really embraced the future of open by supporting and integrating OpenStreetMap into their sites. Microsoft Bing maps are very capable and there are many more – not least of which is a developer “rolling their own”.

This interesting change by Google also validates abstraction libraries such as Mapstraction. Mapstraction provides a common API where a developer can easily switch between map provider libraries without having to rewrite their code – something that would likely cost much more in the short term than paying for usage fees. On GeoCommons we use ModestMaps to be able to switch to any map data provider service.

I’m very interested to see the general developer reaction to this change.

It’s a little difficult to keep up with everything while I’m traveling. Pleasantly I noticed in my inbox that an announcement from O’Reilly went out that included my name.

Brady Forrest and I collaborated on producing a business-oriented analysis of the phenomenal growth around geospatial technology. The report, Where2.0: The State of the Geospatial Web covers various aspects of providers and potential opportunities in a variety of domains that are affected by the emergence of many factors.

Some of these topics include: the impact of open and user-contributed geographic data on traditional data vendors and subsequent tools that rely on the availability, coverage, and quality of this data; highly-connected mobile devices, now often with developer available interfaces for location sharing and high-bandwidth internet connections; models for location-based advertising; and next generation applications such as games, augmented & immersive reality; as well as many more.

It was definitely interesting writing the report from a more practical and business perspective. My background has been in pushing and developing new technologies. I found it eminently useful to think of it from a reverse perspective on evaluating the percolating usefulness across markets and uses. It is valuable for both business development as well as application development to connect.

In addition to the discussion and analysis of the current state of the geospatial web, the report includes a fairly broad directory of companies, applications, and organizations in Where2.0 across the multiple domains. It also includes in-depth profiles of some of the major players.

The report is primarily for businesses that are interested in starting up, or entering, the geo- space and want to get a view of the landscape. It should also be useful for existing organizations that want to understand how the various technologies, acquisitions, and developments may affect their current market.

You can get a discount by using this link.

The report was originally written this Spring and originally announced at Where2.0. We’ve been continuously updating the report with new information such as the completion of the TeleAtlas/TomTom and NAVTEQ/Nokia mergers and the implications as well as the iPhone 3G with built-in GPS and Core Location API. The GeoWeb is a fast-moving space, so it’s definitely difficult to attempt to grasp for a quick snapshot. We hope to update it more in the future as Where2.0 evolves.

Last week, Alan Gutierrez gave an excellent presentation at the Burton Catalyst Group titled “How social networking saved New Orleans: Powered by community, New Orleans residents exposed city hall and the power of social software” or “Innovating Your Way Out of Total System Failure” . Get the slide deck (powerpoint, 32MB)) and digg the story here.

It’s a compelling tale of emergent behavior by a community to leverage the tools it has at hand to enact powerful change. Too often large tools are built to be the end-all-be-all solution to perceived problems and pain points. However, the actual tried and true method of cobbling together solutions from a variety of tools, each as appropriate, leads to agile toolsets and better communication.

On a very similar note, my talk for FOSS4G 2008 in Cape Town has been accepted. Rebuilding a City through Community Participation, Neogeography and GIS will present the technical details of utilizing open-data, open-source and closed-source GIS tools, loosely coupled systems, workshops and open discussion to build cartographic visualizations. As a developer I enjoy tech-talk, I find the application based presentations much more interesting.

The presentation will use the New Orleans mapping as the case study, and while I can’t convey the “in-the-field” experiences Alan, Francine, Karen, and the others living in the city can tell, I hope I can share the experiences to inspire other communities to employ similar tactics to engage their neighbors and government.

The project is still very much a work in progress, but it’s exciting for exactly the reasons Alan gave in his talk – people are already doing the effort and passion – just help them pull the pieces together to have a great impact.

Two months ago I talked about working with Alan from Think NOLA to provide tools and technologies for bringing together the quickly growing user-generated datasets, collaborative mapping, and historic information towards advocacy, awareness, and planning in rebuilding the neighborhoods of New Orleans.

What has been most amazing about the project is that there were emergent, self-induced projects that were actively addressing many areas of capturing information. They are using Flickr for geotagged photos of historic buildings, spreadsheets of demolition permits exported as KML, and key historic maps that outline the original city planning.

The project was selected as a finalist in the NetSquared challenge, which means they were given the opportunity to come out to San Jose to meet with the other 20 projects and discuss their ideas, goals, progress, and cooperations. While the conference itself will award three top-voted projects with funding, the point of the conference and discussion isn’t solely this monetary support.

In planning for the conference, the entire discussion occurred publicly on Alan’s Blog at http://thinknola.com/post/gis. Through open discussion, numerous other projects and individuals contacted Alan to share support, data sets, ideas and future collaborations. NetSquared served as a catalyst for focusing a specific set of projects, but the longer effect is that it has brought together people that will carry the project forward and make sure everyone succeeds.

As a prototype, I used Mapufacture to combine together Francine’s Flickr photos, planning documents of school rebuilding, and the 1924 Taylor’s planning map of New Orleans. It is just a simple demonstration of what is possible using a combination of Neogeography, GIS, and community participation. The next step will be to build better tools for basic analysis and discussion. In addition, the data is open and available for other people to download for their own visualizations, analysis and collaborations.

Prototype: http://mapsomething.com/demo/neworleans

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.