Google Fusion Tables

Google Fusion Tables
Screenshot of Google Fusion Tables.
Type of site
Created byGoogle
URLgoogle.com/fusiontables
RegistrationOptional, included with a Google Account
Launched9 June 2009; 14 years ago (2009-06-09)
Current statusDiscontinued on 3 December 2019; 4 years ago (2019-12-03)

Google Fusion Tables was a web service provided by Google for data management. Fusion tables was 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 (on rows, columns and even cells). 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 3 December 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 (rows & columns), 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 examples.

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 (like addresses) 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 Fusion Tables SQL API 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 FusionTablesLayer Wizard 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 (change the color or visual presentation of) data on the map, as well as default and simple HTML customizable infobubbles (shown when an item on the map is clicked) 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: Managing and Visualizing your geospatial data with Fusion Tables.

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.[citation needed]

In the 2011, as Google Labs was closed, Fusion Tables 'graduated' into the list of default features in Google Docs, under the title "Tables (beta)".[citation needed]

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.[citation needed]

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 NICAR conference in 2011 and 2013.[citation needed]

American Geophysical Union 1 December 2011 - Visualize your data with Google Fusion Tables

DigitalNomad - Using Google Fusion Tables and overview deck

Reviews

Digital Humanities Blog, University of Alabama. Google Fusion Tables.

Conference Papers & Publications

More in Google Scholar

Deprecation

In December 2018, Google announced that it would retire Fusion Tables on 3 December 2019. An open-source archive tool was created to export existing Fusion Tables maps to an open-sourced visualizer.

Fusion Tables had an avid following that was disappointed to learn of the deprecation.


This page was last updated at 2024-01-31 06:24 UTC. Update now. View original page.

All our content comes from Wikipedia and under the Creative Commons Attribution-ShareAlike License.


Top

If mathematical, chemical, physical and other formulas are not displayed correctly on this page, please useFirefox or Safari