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. Google evolves cloud spatial data offerings.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.

About Data Cloud Computing Google Fusion Tables Google Maps Spatial Databases

Paul Nalos


7 Responses to “Google Evolves Spatial Offerings with Fusion Tables”

  1. […] This post was mentioned on Twitter by Google Fusion Tables, Safe Software. Safe Software said: "Google Evolves Spatial Offerings with Fusion Tables", new post from Paul on It's All About Data. […]

  2. Phillip H. says:

    Google Fusion Tables of course will get lots of attention because its google, but it doesn’t seem to be generating nearly the number of maps that BatchGeo is.

    I think that the potential is huge for Fusion Tables, but the interface is quite klunky compared to some of the other tools out there. I think it will work better as an API for these tools.

  3. Paul Nalos says:

    Hi Phillip,

    I enjoyed taking at look at your BatchGeo; thanks for the link. I especially appreciate the copy/paste/submit approach for loading data; I can’t imagine an easier or faster way to turn your spreadsheet into a sharable map (literally only a few clicks and seconds). On the topic of “number of maps created”, I would be very interested in any data you (or others) have. For example, one tweet from Mapperz in response to this post claims there are over 1Tb of maps in Fusion Tables.

  4. […] technologies that we’ve recently talked about on this blog include cloud data stores such as Google’s Fusion Tables and Microsoft’s Azure; emerging data types like 3D and LiDAR; and the more general Data […]

  5. […] geo apps like Fourquare and Gowalla took off, while us professional geonerds got some cool new tools too. While making predictions can be a dangerous game, I thought I would share a few of my personal […]

  6. […] my earlier post on Fusion Tables, I haven’t had a chance to play with Earth Builder. We’ll likely ask for that when new data […]

  7. […] been over a year and a bit since I last talked about Fusion Tables, and Google has continued to emphasize it as their solution for hosting user maps and tabular data. […]

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts