Google Evolves Spatial Offerings with Fusion Tables
Last month, Google added support for spatial queries to Fusion Tables and deprecated their Map Data API, with a goal of migrating users from the latter to the former. This change affects how users and developers store and interact with spatial data using Google’s web applications and APIs. Google’s strategy of trying different approaches for similar problems and then building on successes has served them well, and this shift offers an interesting look at where spatial data in the cloud may be going. I’d like to look at the change from the perspective of two communities: users and developers.
Impact on Users
Users aren’t directly affected by spatial queries in Fusion Tables — you can’t (yet) filter data with a bounding box or circle in the web interface — but indirectly benefit from new applications this capability enables. More on that below.
One difference for users is how they enter spatial data. Google’s My Maps service allows users to draw points, lines, and areas directly on the map, and share them with others. With Fusion Tables, users provide locations as part of a spreadsheet: You can load addresses, place names, or lat/long coordinates directly from text columns, or import arbitrary geometry from KML. Addresses and place names are automatically converted (geocoded) into map locations, and users can fix incorrect locations using a search-and-select procedure. This approach makes it extremely easy to get at spatial data hidden in spreadsheets and databases; simply concatenate address fields into a single column and Fusion Tables does the rest. Why the comparison with My Maps? I expect it will be around for a long time to come, but the Map Data API deprecation has led to speculation about its role in future.
If getting your data into Fusion Tables is dead simple, the great part is what comes next. You can visualize your data using charts and maps, perform basic analysis (business intelligence) using filters and aggregation, and share the results on a web page or in Google Earth via a KML network link. Changes to the source data are reflected immediately, making it a valuable tool for collaboration. While simple, I agree with Brian Timoney that this is real GIS. It also has the potential to be hugely disruptive as Andrew Zolnai was able to quite easily demonstrate.
If you already have spatial data, importing it into Fusion Tables gives you access to its sharing, visualization, and analysis toolset, and recent excitement around a Shapefile importer suggests there is some user demand for this. While I didn’t try this tool, I used our FME to convert a large Shapefile into KML (we support hundreds of spatial formats), and then loaded that using Fusion Table’s built in importer. I quickly realized that the 100 Mb limit makes Fusion Tables inappropriate for maps with large numbers of linear or area features with lots of vertices (think detailed coastlines or region boundaries), but these can be generalized to include less detail. Even if you don’t generalize, Google’s visualization will do that for you, so the focus is clearly not on managing highly detailed shapes. As Jason Birch points out, extending FME to access Fusion Tables directly is an interesting opportunity for us, and would streamline the import process and allow for spatial joins with other formats.
Impact on Developers
The Map Data API includes spatial queries similar to those recently added to Fusion Tables, so this isn’t the main difference. I think the transition points toward the benefits of a structured store for cloud spatial data and a familiar SQL-style syntax. This is particularly interesting as many of the NoSQL cloud databases are exploring less structured, less SQL-based alternatives.
Using the table I imported above, I found the new spatial queries both performant and easy to use. If you’re interested in more information about developing for Fusion Tables, this post from ProgrammableWeb gives a clear overview, or you can check out five samples from Google of what has been done.
Fusion Tables provides a simple and powerful way to share and visualize your data, and includes an API for developers to build the next great spatial cloud app. Its focus on the spreadsheet model (neither unstructured nor fully relational) and simple SQL-style queries represent one option for spatial data in the cloud. I’m watching with great interest: How will this paradigm fare against its less- (e.g., NoSQL) or more- (e.g. SQL Azure) structured cousins in the cloud? On reflection, I think Fusion Tables is more about bringing computer mapping to everyone than being the ultimate cloud spatial database, but am confident it will influence both arenas for a long time to come.