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.

Cross-posted from the GeoIQ Blog

Last Week I participated in a panel with spatial archival experts at the at the Society of American Archivists. Led by Butch Lazorchak of the Library of Congress, and also joined by Steve Morris from GeoMAPP, and John Faundeen from USGS, the panel was a full spectrum discussion of “Geospatial Data Preservation” ranging from the Library of Congress’ $10 million acquisition and access to the infamous Waldseemüller 1507 map Universalis Cosmographia of ‘America’ USGS’s environmental conditions for storing historic satellite imagery to GeoMAPP’s work in gathering time-stamped state geospatial data. Butch in particular provided an inspiring overview on what’s special about Spatial – density of data, representation vs data, and the difficulty in capturing interactivity of more modern digital maps.

The Archivists were a new community to me – people that are passionate about the capturing and storing of data – often until the end of time! But they also vary in their core missions – often diverging on the utility of the captured data and information. Very few seem to be really thinking about archives as a useful resource today and only focusing on the long-time storage and eventual access of the data by some unknown entity. As one member of GeoMAPP said: “All of the Archives are storing this superseded GIS data in dark archives and aren’t really providing access to the datasets and don’t have web mapping interfaces”

Clearly, we think a bit differently about archiving – choosing to focus foremost on access to data which will result in improved archiving of data, distribution, and analysis on utility and benefit. My presentation Maps as Narratives: Making Spatial Archives Accessible

focused on the concept that maps have been, and are increasingly a vital resource for people in their daily lives and work. By providing users tools to access and use historic and realtime data, we can then capture this data and provide it to other users and data repositories.

Particular to internet feeds, and social media we can’t easily predict what data will be useful. Neogeographers create visualizations of twitter streams, photos, foursquare checkin’s, friend locations. How do we know which of these are the modern correspondances of tomorrow’s US President or Global business leader? Through easy mechanisms for sharing data and maintaining links we can begin tracking this information in it’s varied forms, providing better insight and archiving of data for later reuse, whether it is tomorrow or in 100 years.

I was fortunate enough to be selected to attend the #NASATweetup to see the last launch of Space Shuttle Endeavor – STS-134. Along with 150 other lucky selected people including even @dens, the Obamas, Gabi Giffords, Seth Green, Levar Burton and numerous inspiring astronauts we’ll be at the countdown clock with a front row seat the second to last launch of the entire shuttle program.

Endeavor is carrying the Alpha Magnetic Spectrometer to the International Space Station that will perform some inspiring science on measuring dark matter radiation. There’s also a host of spiders, aggressive bacteria and other science experiments that will be run on the iSS. I’ll have more photos and stories up soon.

Yesterday Steve Coast announced that Bing had released a new tool for doing automatic road detection using satellite imagery. The concept is definitely interesting as it provides a way to rapidly generate road data over the entire globe without need of manual tracing.

However, I remarked that it was particularly interesting that Steve was working on this. Several years ago, when OpenStreetMap was still an ambitious but unproven concept many people argued that road detection was a useful, and perhaps necessary, mechanism for actually capturing all the road data. Steve was quite adamant that while it was possible – and he demonstrated it – it wouldn’t work for other reasons.

OpenStreetMap is more than just a set of lines that render to nice maps. It is a topologically connected, classified and attributed, labeled network of geographic entities. Each road consists of intersections, road classifications, names, speed limits, overpasses, and lanes. OpenStreetMap has provided a very rich set of linked, geographic data.

And beyond the data, it has built a community of invested members that careful capture, annotate, and cultivate the data in OpenStreetMap. This means that the data is captured, but also updated and maintained (ideally) with new information, changes, and other entities such as parks, buildings, bus stops and more.

So Steve convincingly pointed out that automatic road identification was interesting, it would circumvent these other benefits of what OpenStreetMap was working on: rich connected data, and a community of volunteers that would build and maintain the dataset. Road detection has a tendency to generate a large amount of data in an area that no one is actively working on the data. So you can gain what appears to be good coverage but limited local knowledge on intersections, names, and other metadata.

I don’t think that these are insurmountable problems. The act of capturing GPS data can be tedious, inaccurate, or not readily possible in remote areas. Road detection can provide this data and users can work afterwards to improve the data, either remotely or using even simpler mobile devices that a user can annotate features without having to capture the entire geographic road line.

So my comment the other day was about pointing out an interesting change in message and strategy. I applaud the work of Steve and the Bing team in developing new tools, but there are many other pieces that warrant consideration. Steve even asked often if the bulk import of the TIGER/Line data was good or bad for the US community. In the end, I believe it was the right thing as it provided a canvas of data using open data that provided a validity to skeptics that OpenStreetMap was viable and valuable.

Now that OpenStreetMap has become increasingly adopted by the world’s largest providers and users of data it is time to evaluate new tactics for gathering and maintaining data. However this can’t be at the expense of what made OpenStreetMap a success for the past 5+ years.

This morning MapQuest launched their US support of OpenStreetMap at open.mapquest.com. In playing with the interface, I noticed how MapQuest added a tab at some point for showing and hiding the sidebar of search results and other associated design choices and differences.

MapQuest uses an “Outie” tab (highlighted in the screenshot below). The design choice was clearly to make it very explicit for users to show and hide the sidebar as it protrudes into the map interface. The pan and zoom controls are on the right-hand side, so when you toggle the sidebar, the controls stay in the same location. Another interesting aspect is how the map resizes. In MapQuest, the same geographic center and extents remain in the screen center – so as the sidebar closes the map shifts to the left and expands slightly.

Curious about how this varies, I checked in Google Maps. They chose to be much more subtle about their sidebar toggle. It is an “innie” that is subtly hidden within the header. Closing the sidebar turns the selection to an “outie”, but still remains out of the way in the header. A particularly interesting decision is that the map remains in the same location – so the zoom pan controls move but new areas of the map are exposed. So while the user doesn’t have a context shift (points on the map remain in the same area of the screen) the map now needs to be recentered so that the focus area can be kept in the center.

Lastly, looking at Bing maps it’s a bit of a hybrid between the two. The sidebar tab is in the header like Google, but hiding the sidebar re-centers the map like MapQuest. The controls in Bing are in the header, so they don’t need to shift when the sidebar is toggled. What’s perhaps a little confusing is there is also an “X” close button next to the sidebar tab that clears the search results. It’s not really clear why you would want to clear results – and instead there should be an option to go back to the “table of contents” or similar concept that shows simple links for directions and more.

Much like the emergence of Pan-Zoom bars have become the defacto standard in web mapping interfaces – the sidebar has also become nearly ubiquitous. So it’s interesting to see the slight variations as interaction designers experiment with what users will find easy to understand.