Google Fusion Tables
Google Fusion Tables was a web service provided by Google for data management. Fusion tables can be used for gathering, visualising and sharing data tables. Data are stored in multiple tables that Internet users can view and download.
The web service provided means for visualizing data with pie charts, bar charts, lineplots, scatterplots, timelines, network graphs, HTML-formatted card-layouts, and geographical maps. Data are exported in a comma-separated values file format. Visualizations could be embedded in other websites, and updated realtime as data in the table changed.
From the Fusion Tables website:
Google Fusion Tables is a service for data management, integration and collaboration.
You can easily upload data sets from CSV, KML and spreadsheets, and visualize the data using a variety of tools. Users can merge data from multiple tables and conduct detailed discussions about the data. You can easily visualize large data sets on Google Maps and embed visualizations on other web pages.
Developers can use our API to build applications over Fusion Tables.
Google closed Fusion Tables on December 3, 2019.
Features
Fusion Tables accepted a data file structured as a simple database table, typically a.csv but also other delimiters. It also imported KML, reading each KML placemark or geospatial object into its own row. Fusion Tables files were private, unlisted or public, as specified by the user and followed the convention established by other Google Docs apps. Files were then listed and searchable in the user's Google Drive.The size of uploaded data set was limited to 250 MB per file with a total limit of 1 GB per user. An API allowed data to be ingested automatically. Visualizations were also embeddable into other web pages to support static or live-updating data within publications.
Structured Data Search, Publication and Reuse
search
The 'New file' flow also supported searching on existing published tables, encouraging people to reuse and build on existing data before creating new data or making a new copy of the same data. The 'live update' nature of a re-used table could be an advantage to the user where data sets might be receive corrections or be regularly updated.'fusion'
The 'fusion' in the name Fusion Tables came from the ability to create a 'file' that is really just a view on a join of two or more other files. For example, to publish a map about election results in Illinois, one could upload a table with election results, and then create another file that joins this table with a KML of US electoral districts. Because it was a virtual join rather than a copy, changes to either of the base tables would be reflected in the joined table. The join would extract the districts relevant to the Illinois elections, and the result would be easy to put on a map and embed in a news article or other website.Columns from different tables were displayed with a different background color, to help keep track. Multiple tables could be joined using the same key column. Edits to the data needed to happen to the original underlying table, not in the joined table.
reuse
Fusion Tables encouraged read-only reuse of publicly published data sets, or other data sets shared with the user. Although the user could not edit the read-only data set, the user could create visualizations and filtered views on the data in new tabs in the UI. These views would not affect the original file for the file owner or anyone else, but would appear whenever the user who created them opened the file. These tabs were indicated with a dotted line outline.editing
The UI supported adding rows and editing data, which was also possible programmatically through the Fusion Tables API.Data Visualizations
During import, Fusion Tables automatically detected various data types in the data, and generated a few appropriate visualizations. All tables saw a row view and a card view; those with many types of location data saw a map visualization automatically created as well.Data types supported within the table view included standard strings, numbers but also images and KML.
Maps
Types of location data automatically detected included: latitude/longitude information in one or two columns, KML place descriptions, and some types of placenames, and addresses, which were sent to the Google Maps Geocoding API in order to put them on the map. The results of geocoding were not available in the table; only on the map.Fusion Tables was tightly integrated with the Google Maps geocoding service, as well as the Google Maps API, which supported an experimental FusionTablesLayer. Fusion Tables supported KML descriptions of geographic points, lines and polygons as a datatype within the tables. By providing a way to ingest, manage, merge and style larger quantities of data, Fusion Tables facilitated a blossoming of geographic story-telling. Many data journalists used these features to visualize information acquired through a Freedom of Information Act request as part of their published news stories.
Card View
An HTML subset templating language supported customizable card layout and map infowindows displaying static and data field content. Incorporating a call to the Google Chart API could dynamically render a chart based on the data within a single row in the card or infowindow.Other visualizations
Table view, standard pie charts, scatter plots and line graphs, timeline, chloropleth map, network graph, and motion chart.Filtering
Simple filtering tools provided automatic summaries of values in data columns, and allowed the visualized data to be filtered with checkboxes.Publishing and Customizing
By supporting simple queries, embeddable HTML snippets for visualizations, and a simple HTML templating language for customizing layouts, Fusion Tables straddled the point-n-click world and the production software engineering world with a 'scriptable' functionality that allowed many data owners with limited software development time or expertise to develop highly custom, expressive websites and tools with their data. See .Maps created in Fusion Tables could be exported to KML and viewed in Google Earth, making Fusion Tables an important authoring tool for many of the non-profits and NGOs working closely with Google Earth Outreach to spread information about their work.
History & Impact
Fusion Tables was inspired by the challenges of managing scientific data collections in multi-organization collaborations, such as the DNA barcoding collaboration between University of Pennsylvania ecologist Dan Janzen, the International Barcode of Life, and the University of Guelph.The website launched as part of Google Labs in June 2009, announced by Alon Halevy and Rebecca Shapley. The service was further described in a scientific paper in 2010.
Maps Visualization
Following positive feedback about Fusion Tables' integration with the Intensity map in the Google Visualization API, the team worked closely with the Google Maps team to add support in Feb 2010 for KML point, line and polygon objects as a native datatype in the tables, visualized on top of Google Maps' basemap. Additionally, some smarts were applied to detect data columns that described locations and to send them to Google's Geocoding service so they could be rendered on the map. Shortly thereafter in May 2010, the FusionTablesLayer was offered as an experimental feature of the Google Maps API.The integration of Fusion Tables with Google Maps through the FusionTablesLayer was Google's first foray into server-side rendering of users' data onto Google Maps tiles. Prior to the FusionTablesLayer, map pins were rendered on top of basemap tiles in the browser client. By creating many objects for the client to track, this could make maps slow, and effectively limited Google Maps to showing approximately 200 user data points. The FusionTablesLayer demonstrated fast, server-side rendering of large and complex user data onto the Google Maps base map.
The supported sending filter queries to the FusionTablesLayer to dynamically adjust the data shown on the map. These maps could be embedded in another webpage with a simple snippet of HTML code. The open-sourced point-n-click tool helped people create the snippets, and later the snippet was also available easily in the Fusion Tables UI. In May 2011, Fusion Tables added the ability to style data on the map, as well as default and simple HTML customizable infobubbles through both the web app and the APIs.
Fusion Tables offered a readily accessible solution for working with data on a map that previously required clunky and expensive desktop software. It met many simple GIS use cases. Fusion Tables was presented as part of the Geo track at Google IO in May 2011: .
Adoption
In October 2010, FusionTables demonstrated reliability under heavy traffic spikes when hosting the map visualization of the Iraqi War Deaths data set embedded in a news article from The Guardian. Shortly after the March 2011 earthquake and tsunami in Japan, crisis responders used Fusion Tables to reflect road status and shelters with close-to-realtime updates. Google's Crisis Response team continued to use Fusion Tables as a key tool for creating and updating relevant maps after a crisis.In the 2011, as Google Labs was closed, Fusion Tables 'graduated' into the list of default features in Google Docs, under the title .
In April 2012, Fusion Tables created its own 'labs' track with several experimental features, including a new version of the user interface, a network graph visualization, and a preview of the revised Fusion Tables API, which officially launched in June 2012.
Merging tables continued to be a key, if difficult to discover, part of Fusion Tables. Merging tables was, for example, a great way to use publicly available authoritative KML boundaries for places many people might have data about, such as counties or electoral districts. In August 2012, Fusion Tables launched integration with Table Search, another Google Research project from Alon Halevy.
Presentations & Trainings
Fusion Tables was described in talks at the in 2011 and 2013.American Geophysical Union 01 Dec 2011 -
and
Reviews
Conference Papers & Publications
More in- Balakrishnan S., Jacqmin-Adams K., Lee H., McChesney R., Shapley R. . In: Shekhar S., Xiong H., Zhou X. Encyclopedia of GIS. Springer, Cham
- . Jayant Madhavan, Sreeram Balakrishnan, Kathryn Brisbin, Hector Gonzalez, Nitin Gupta, Alon Halevy, Karen Jacqmin-Adams, Heidi Lam, Anno Langen, Hongrae Lee, Rod McChesney, Rebecca Shapley, Warren Shen. Google Inc. .
- Brambilla M., Ceri S., Cinefra N., Das Sarma A., Forghieri F., Quarteroni S. . In: Ceri S., Brambilla M. Search Computing. Lecture Notes in Computer Science, vol 7538. Springer, Berlin, Heidelberg
- Field Information Management Systems for DNA Barcoding. Deck John, Gross Joyce, Stones-Havas Steven, Davies Neil, Shapley Rebecca, and Meyer Christopher. Chapter 12 in: W. John Kress and David L. Erickson, DNA Barcodes: Methods and Protocols, Methods in Molecular Biology, vol. 858
- . Eliza S. Bradley, Dar A. Roberts, Philip E. Dennison, Robert O. Green, Michael Eastwood, Sarah R. Lundeen, Ian B. McCubbin and Ira Leifer. Earth Science Informatics, 17 September 2011.
- - Semantic Scholar
- . Jonathan Goldberg Kidon, Massachusetts Institute of Technology. Dept. of Electrical Engineering and Computer Science, 2010. 61 pages.
- . Hector Gonzalez, Alon Y. Halevy, Christian S. Jensen, Anno Langen, Jayant Madhavan, Rebecca Shapley, Warren Shen, Jonathan Goldberg-Kidon. Proceedings of SIGMOD 2010, Indianapolis, Indiana.
- . Hector Gonzalez, Alon Y. Halevy, Christian S. Jensen, Anno Langen, Jayant Madhavan, Rebecca Shapley, Warren Shen. Proceedings of the Symposium on Cloud Computing, 2010, Indianapolis, Indiana.
Deprecation
Fusion Tables had an avid following that was disappointed to learn of the deprecation.