Hubbry Logo
Google Fusion TablesGoogle Fusion TablesMain
Open search
Google Fusion Tables
Community hub
Google Fusion Tables
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Google Fusion Tables
Google Fusion Tables
Google Fusion Tables
View on Wikipedia
from Wikipedia

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.

Key Information

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.[1]

Features

[edit]

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.[2] 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

[edit]
[edit]

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'

[edit]

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

[edit]

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

[edit]

The UI supported adding rows and editing data, which was also possible programmatically through the Fusion Tables API.

Data Visualizations

[edit]

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

[edit]

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

[edit]

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

[edit]

Table view (rows & columns), standard pie charts, scatter plots and line graphs, timeline, chloropleth map, network graph, and motion chart.

Filtering

[edit]

Simple filtering tools provided automatic summaries of values in data columns, and allowed the visualized data to be filtered with checkboxes.

Publishing and Customizing

[edit]

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 Archived 12 August 2019 at the Wayback Machine.

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

[edit]

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.[3] The service was further described in a scientific paper in 2010.[4]

Maps Visualization

[edit]

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.[5] 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.[6]

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

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.[8] 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

[edit]

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,[9] Fusion Tables 'graduated' into the list of default features in Google Docs, under the title "Tables (beta)" Archived 18 November 2019 at the Wayback Machine.[citation needed]

In April 2012, Fusion Tables created its own 'labs' track with several experimental features,[10] 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,[11] another Google Research project from Alon Halevy.

Presentations & Trainings

[edit]

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

[edit]

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

Conference Papers & Publications

[edit]

More in Google Scholar

Deprecation

[edit]

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

Fusion Tables had an avid following that was disappointed to learn of the deprecation.[14][15]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Google Fusion Tables

View on Grokipedia
from Grokipedia
Fusion Tables was a cloud-based developed by for the management, integration, visualization, and collaborative sharing of tabular data sets. Launched experimentally on June 9, 2009, as part of , it enabled users to upload files such as spreadsheets and CSVs, merge disparate tables based on common attributes, and generate interactive displays including maps, charts, and cards without requiring advanced programming skills. The service integrated seamlessly with for geospatial representations, facilitating applications in , , and geographic information systems (GIS) by automating geocoding and rendering large datasets on maps. Fusion Tables supported real-time collaboration among multiple users, allowing simultaneous editing and versioning of , akin to but tailored for structured tables. It provided an for programmatic access, released in December 2009, which extended its utility for developers embedding visualizations into applications. Over its decade-long run, the tool gained adoption for simplifying complex tasks, though it lacked the scalability of enterprise databases and faced limitations in handling very large volumes or advanced querying. In December 2018, Google announced the discontinuation of Fusion Tables and its API, effective December 3, 2019, citing a strategic shift toward other data-focused products like and . Users were encouraged to export data and migrate visualizations, with embedded maps and charts ceasing functionality post-shutdown, marking the end of a service that had democratized basic data visualization for non-experts. No significant controversies surrounded the tool, though its abrupt retirement prompted discussions on alternatives for legacy mapping projects.

Overview

Purpose and Core Functionality

Google Fusion Tables was a cloud-based service designed to enable users to manage, integrate, visualize, and collaborate on structured tabular without requiring advanced database expertise. Launched in 2009 as part of 's efforts to democratize handling, it targeted a wide audience including , journalists, and businesses by providing web-centered tools integrated with the Google ecosystem. The primary purpose was to facilitate the upload and organization of large datasets, surpassing the limitations of traditional spreadsheets, while emphasizing ease of use for non-technical users through automated features like geocoding via the . At its core, the service supported importing data from formats such as CSV, KML, and Spreadsheets, allowing users to merge tables, filter rows, and perform basic queries using a simplified interface. Visualization capabilities formed a central functionality, enabling the creation of interactive maps, charts, line graphs, heat maps, and network diagrams directly from the data, with options to customize styles and embed outputs on websites. Collaboration tools permitted sharing tables with specific permissions, real-time editing, and row-level discussions to foster group analysis and feedback. The platform's design prioritized for datasets up to hundreds of thousands of rows, with built-in support for location-based rendering to highlight spatial patterns in data. By hosting data in the cloud, Fusion Tables ensured accessibility across devices and integrated seamlessly with other services, though it imposed limits on file sizes and query complexity to maintain performance. This combination of features positioned it as a lightweight alternative to full database systems, focusing on and public data dissemination rather than enterprise-level transactions.

Development Origins

Google Fusion Tables emerged from a Google Research initiative to develop cloud-based tools for managing structured data, addressing limitations in traditional database systems that were often inaccessible to non-experts. The project focused on enabling seamless data integration, visualization, and collaboration without requiring users to handle synchronization across files or servers. It was launched experimentally on Google Labs on June 9, 2009, with initial support for uploading tabular data in formats such as CSV, spreadsheets, and KML files, capped at 100 MB per table and 250 MB per user. The development was led by Alon Halevy of Research, who co-announced the tool alongside Rebecca Shapley from the user experience team, leveraging interdisciplinary expertise from 's data management, machine learning, and interface design groups. Additional key contributors included Hector Gonzalez, Christian S. Jensen (on leave from ), Anno Langen, Jayant Madhavan, Warren Shen, and Jonathan Goldberg-Kidon (on leave from M.I.T.), all affiliated with . This team aimed to create a web-centered service that prioritized user-friendly operations over conventional paradigms, such as joining tables on primary keys and embedding discussions directly on data elements. Motivations for the project included the growing need for accessible data handling amid increasing online data volumes, particularly for merging disparate sources and publishing interactive views like maps via or charts through the Google Visualization API. By hosting data in the , Fusion Tables eliminated local storage burdens and facilitated real-time sharing, initially targeting researchers, journalists, and organizations requiring collaborative analysis without . The system's design emphasized empirical and iterative refinement based on early user feedback from participants.

Features

Data Upload and Management

Google Fusion Tables allowed users to upload tabular data directly through its web interface or by integrating with , supporting formats such as (CSV), (TSV), other delimited text files, KML for geospatial data, spreadsheets, and spreadsheets. Uploads were limited to 100 MB per file, with an overall storage quota of 250 MB per user account. Once uploaded, tables supported up to 500,000 rows and 5,000 cells per row, enabling management of moderately large datasets in the cloud without local storage requirements. Users could edit data by modifying individual cells, rows, or columns directly in the interface, with changes tracked through versioning to allow reversion to prior states. Schema evolution was facilitated by adding, removing, or renaming columns post-upload, accommodating evolving data structures. A key management feature was table merging, which performed joins on common keys across disparate tables—even those owned by different users—to integrate data without physical duplication, supporting both inner and outer joins via the "File > Merge" option. This enabled collaborative data enrichment, such as combining attribute data with geospatial layers in KML format. Access controls allowed tables to be set as private, shared with specific collaborators for joint editing and markup, or published publicly.

Visualization Capabilities

Google Fusion Tables enabled users to generate interactive visualizations directly from uploaded tabular data, supporting types such as maps, charts, timelines, motion charts, and network graphs. These tools allowed for quick rendering of data patterns without requiring programming expertise, with options to customize colors, labels, and filters. The service integrated technology for many visualizations, facilitating embedding on web pages or sharing via links. Map visualizations were among the most prominent features, accommodating point-based displays via geocoded addresses, latitude-longitude coordinates, or KML imports, with markers sized or colored by attributes. Intensity maps, functioning as heatmaps, overlaid point density or attribute values to highlight geographic concentrations, such as population hotspots or event clusters. Users could toggle between marker and heat views, apply clustering for dense datasets, and embed maps using the API's Fusion Tables Layer for advanced interactivity. Chart options included bar, , line, and scatter plots, suitable for categorical or numerical comparisons, with support for multiple series and axis configurations. Motion charts animated data over time or categories, similar to Gapminder-style bubbles, requiring date, text, and numeric columns for dynamic of trends and correlations. Timelines plotted events chronologically, while network graphs depicted relational data as nodes and edges, useful for social or connection analyses. Card views rendered rows as customizable cards, often with images, for gallery-like presentations. All visualizations were responsive to data filters and queries, updating in real-time as users interacted, and supported through shared views. Limitations included reliance on Google-hosted rendering, which capped sizes for complex at around 250,000 rows, and lack of advanced statistical overlays. Despite these, the tools democratized data visualization for non-experts, particularly in and academia, until the service's in 2019.

Collaboration and Sharing Tools

Google Fusion Tables facilitated collaboration through sharing mechanisms integrated with Google accounts, allowing owners to grant access to specific users or groups for viewing or data. Permissions distinguished between read-only viewers and editors, with the system tracking contributions to attribute changes to individual collaborators. Edit permissions enabled real-time modifications, such as merging datasets or adding markup, while maintaining a record of who altered specific data elements. A built-in discussion feature supported threaded conversations at the granularity of entire tables, rows, columns, or cells, enabling collaborators to annotate and debate points directly within the interface. Discussions remained linked to the context, and any edits made by permitted users during active threads appeared inline in the conversation history for all participants, including viewers. This functionality promoted iterative refinement, such as resolving discrepancies in merged datasets or enhancements to public tables. Visibility settings offered three tiers: private (accessible only to the owner), shared with designated collaborators, or public, which made tables discoverable via search engines and embeddable in external sites. Public sharing extended to visualizations, where users could generate and distribute or embeds for maps and charts independent of the raw data, subject to the table's overall permissions. The Fusion Tables API further enabled programmatic and permission management, supporting automated workflows for team-based .

Filtering and Querying Mechanisms

Google Fusion Tables enabled users to filter data subsets through an interactive web interface, where conditions could be applied to specific columns using operators such as equals, contains, greater than, or range-based criteria, effectively narrowing datasets for or visualization without altering the underlying table. Multiple filters could be combined logically to refine results, and aggregated summaries—such as counts, averages, or sums grouped by categories—could be computed and displayed alongside raw filtered rows. These filtered views preserved the original data integrity while allowing persistent subsets to be shared or embedded in maps, charts, or timelines, supporting exploratory workflows by isolating relevant portions of large tables exceeding 100,000 rows. Programmatic querying relied on the Fusion Tables , which supported a subset of for and manipulation, including SELECT statements with WHERE clauses for conditional filtering on numerical, textual, or geospatial predicates. For instance, queries could filter rows matching 'column = value' or complex conditions like 'column1 > 100 AND column2 CONTAINS "term"', with support for LIMIT to cap results and ORDER BY for sorting. Aggregation functions enabled GROUP BY operations to compute statistics across filtered groups, while JOIN capabilities merged tables on primary keys, facilitating across disparate datasets hosted by different users. The SQL , available until its in January 2013 in favor of a RESTful v1.0 retaining equivalent query functionality, processed requests by decomposing high-level SQL into distributed low-level scans, optimizing for cloud-scale tables but eschewing transactional guarantees in favor of read-heavy analytical use cases. In map-based visualizations, filter queries dynamically adjusted displayed markers or polygons via the API, enabling real-time data subsetting tied to user interactions.

Technical Specifications and Limitations

Data Handling Constraints

Google Fusion Tables restricted uploads to a maximum of 1 MB per HTTP request, with batch additions limited to cells rather than rows. Individual tables could store up to 500 million cells in total, though practical constraints often arose from query and visualization processing. Users faced an overall storage quota of 250 MB across all tables. Query results and mapping operations processed only the first 100,000 rows of , excluding larger datasets from full geospatial rendering or outputs. visualizations enforced a 500-feature-per-tile limit, potentially causing incomplete displays for dense geographic . Supported import formats were limited to structured files such as CSV, KML, Excel spreadsheets, and sheets, requiring tabular organization without native handling for unstructured or binary content like images. Column data types were confined to basic categories including text, numbers, dates, booleans, and locations (via geocoding, / pairs, or KML geometries), with automatic during import but no support for complex nested structures or relational foreign keys beyond simple merges. These constraints prioritized lightweight, web-centric over enterprise-scale databases, often necessitating data subsetting or external preprocessing for larger or non-tabular datasets.

Integration with Google Ecosystem

Google Fusion Tables operated as a native component of , enabling users to create, store, and organize tables alongside other Drive files such as documents and spreadsheets, with sharing permissions managed through Drive's collaborative controls. Data importation supported direct uploads from and other Drive-hosted spreadsheets in formats including CSV, KML, and Excel, streamlining workflows by leveraging Drive's file compatibility without requiring external transfers. The platform maintained tight integration with for geospatial applications, automatically rendering table data as interactive map layers, markers, and heatmaps using embedded Maps APIs to visualize location-based attributes. provided programmatic extensibility, allowing scripts to query, insert, update, or synchronize data between Fusion Tables and Sheets, as demonstrated in enterprise automation examples for roadmap . Generated visualizations, such as maps and charts, could be embedded via iframes into or other applications, ensuring dynamic updates tied to the underlying table data for enhanced intra-ecosystem sharing.

API and Extensibility

Google Fusion Tables offered a RESTful that facilitated programmatic interactions with its , querying, and visualization capabilities, allowing developers to , manage, and retrieve tabular data without relying solely on the web interface. The supported core operations including table creation, insertion of rows, SQL-based queries for filtering and aggregation, and export of results in formats such as or CSV. In June 2012, released an enhanced version of the , building on the prior SQL by incorporating metadata management for tables and columns, such as renaming or altering schemas, which expanded options for automated data pipelines and custom applications. This update enabled more robust extensibility, including integration with external scripts for dynamic data merging from multiple sources and generation of visualizations like maps and charts via calls. Extensibility extended to interoperability with other Google services, notably the JavaScript API, where Fusion Tables layers could be overlaid on maps for geospatial rendering, supporting features like styled markers and heatmaps driven by table data. Developers also leveraged (KML) exports from Fusion Tables to integrate data into tools like , enabling extensible geoscience and mapping workflows through XML-based customization. However, the 's discontinuation on December 3, 2019, alongside the service itself, halted all programmatic access, prompting migrations to alternatives like or for similar extensibility needs.

History and Evolution

Launch and Initial Release

Google Fusion Tables was publicly announced on June 9, 2009, through a post on the Research blog by Alon Halevy of Research and Rebecca Shapley of . The service launched as an experimental offering under , aimed at simplifying cloud-based by allowing users to merge multiple data sources, facilitate discussions, perform queries, generate visualizations, and publish results on the web. It targeted users handling large tabular datasets, such as spreadsheets, by providing a platform for integration and collaboration without requiring local software installations. At launch, core features included uploading tabular data files with a limit of 100 MB per dataset and 250 MB total per user, supporting formats like CSV and enabling real-time collaborative editing with automatic version syncing. Users could share tables publicly or with specific collaborators, including options to selectively hide sensitive rows or columns, and engage in granular discussions attached to individual rows, columns, or cells. Data fusion capabilities allowed merging tables via joins on primary keys, while visualization tools integrated with for geographic displays and the Google Visualization API for charts, lines, and other graphics; exports were possible in CSV format. Initial constraints encompassed the dataset size limits and basic join functionality, with the announcement noting plans to expand join types and additional features based on user feedback through a dedicated . The service emphasized web-centric accessibility, positioning it as a precursor to broader cloud tools, though it remained in experimental status without immediate support. Early adoption focused on exploratory use by and organizations seeking straightforward handling in the ecosystem.

Key Updates and Expansions

In February 2010, enhanced Fusion Tables' mapping functionalities to support the upload and visualization of larger geographic datasets, improving scalability for location-based . This update addressed initial limitations in handling extensive tabular data with spatial components, allowing users to merge tables and generate heat maps or custom overlays more effectively. The Fusion Tables API was introduced on December 14, 2009, enabling developers to query, insert, update, and delete data programmatically, which expanded its utility for custom applications and automated workflows. This API integration facilitated embedding dynamic visualizations that refreshed automatically with data changes, bridging Fusion Tables with external services like . On September 13, 2011, Fusion Tables gained direct integration with , permitting seamless import of spreadsheets and enhanced collaboration features within the ecosystem. This expansion streamlined data management by allowing users to edit and visualize content without exporting files, aligning Fusion Tables more closely with Google's productivity suite. Subsequent developments in 2012 included a redesigned and experimental features such as network graph visualizations, broadening options for non-geospatial data representation. Card-based views were also added, providing snapshot-style displays of individual data rows for quicker insights into structured information like profiles or events. These updates reflected iterative improvements aimed at and diverse analytical needs, though official emphasized ongoing refinements without a formal .

Usage Patterns and Case Studies

Google Fusion Tables was commonly used for rapid creation of interactive visualizations from tabular , particularly geospatial mappings where users uploaded spreadsheets with information to generate embeddable maps and charts. This pattern facilitated quick and , allowing teams to merge multiple tables, apply filters, and publish results online without advanced programming. Users often employed it for in fields like and , where it enabled non-technical users to visualize trends via heatmaps, lines, or network graphs from datasets exceeding limits. In , Fusion Tables supported story development by cataloging and mapping public data sources, such as aggregating socioeconomic indicators for regional reporting. A notable application involved dynamic through aggregated info displays, where reporters combined datasets to illustrate trends on interactive platforms. For , marketers visualized networks to assess SEO performance, creating graphs that highlighted domain connections and referral patterns from large link datasets. Case studies highlight its practical deployment in ; researchers used Fusion Tables to map drug overdose deaths by integrating mortality data with , enabling flexible filtering by location, time, and demographics to track patterns from 2010 onward. In environmental analysis, it processed National-Scale Air Toxics Assessment (NATA) geospatial data to visualize national variations in exposures, aiding identification of high-risk areas through merged and emission tables. applications included mapping home listings with overlaid property metrics, such as risks or neighborhood stats, to assist users in location-based decision-making as demonstrated in 2011 examples. Educational uses encompassed archiving and mapping collections, like Indiana University's Cushman photographic dataset, where geolocated images were plotted to explore historical urban changes.

Reception and Impact

Adoption Metrics and User Feedback

Google did not publicly release detailed adoption metrics for Fusion Tables, such as total user counts or active table numbers. The service's architecture was engineered to accommodate millions of user tables, reflecting ambitions for broad in . Publicly searchable Fusion Tables numbered in the thousands, enabling users to discover and integrate existing datasets. User feedback emphasized Fusion Tables' strengths in simplifying data upload, visualization, and for non-experts, particularly through integrated mapping and querying features. Reviews on data visualization platforms rated it 8.3 out of 10 across five evaluations, commending ease of use (8/10), features (8.9/10), and integration capabilities (8.9/10). Early adopters appreciated its collaborative aspects, likening it to "spreadsheets on steroids" for combining tabular analysis with database-like queries. Critiques highlighted performance inconsistencies, such as beta-stage glitches and limitations in advanced customization compared to specialized tools. Storage caps at 250 MB per user and challenges with large-scale rendering drew complaints from users handling extensive geographic data. The 2019 deprecation announcement elicited user concerns over workflow disruptions, with recommendations to migrate to alternatives like or , underscoring dependency among niche practitioners in research and journalism.

Academic and Professional Applications

In academic settings, Google Fusion Tables supported visualization and collaborative analysis, particularly for geospatial and tabular datasets exceeding the limits of spreadsheets. Researchers utilized it to create interactive maps and charts from CSV or Excel files, enabling seamless integration of latitude/longitude for without advanced programming skills. For example, in , a 2014 study applied Fusion Tables to visualize urban tree benefits, hosting and publishing layers for public access and overlaying metrics like on . In and , it facilitated network graphs linking sources to essays or historical entities, as demonstrated in tutorials for mapping relational in liberal arts curricula. informatics projects, such as those by the , employed it from 2015 to aggregate and visualize species occurrence tables, supporting sharing among scientists. Professionally, Fusion Tables served as a lightweight tool for and reporting, allowing teams to upload, merge, and embed visualizations like heat maps or line charts directly into web applications. In , it enabled rapid creation of interactive maps for topics such as economic trends or public safety, with reporters using it as early as to handle datasets larger than permitted. A 2015 case study in the sector illustrated its application for mapping home claims , where analysts imported geospatial coordinates to generate shareable dashboards for internal decision-making or client presentations. Small organizations leveraged its cloud-based merging of tables—via keys like IDs—for ad-hoc , such as joining with geographic overlays, though limited enterprise adoption. Overall, its emphasis on web-centric appealed to non-technical professionals, with reporting in 2010 that users valued the service for quick prototyping over heavy database systems.

Strengths and Achievements

Google Fusion Tables provided a user-friendly interface for transforming tabular into interactive visualizations, such as maps and charts, with minimal technical expertise required, leveraging for geocoding and display of location-based datasets. Its free, cloud-based model supported seamless uploading of spreadsheets and CSV files, enabling of data views without local software installation. A key strength lay in its data merging capabilities, allowing users to join multiple tables on common keys—similar to operations—facilitating integrated analysis of disparate datasets in a collaborative environment accessible via Google accounts. This extensibility through APIs further empowered custom applications, such as embedding visualizations in websites or combining with for enhanced interactivity. The platform achieved notable adoption in journalism for data-driven storytelling, exemplified by The Guardian's 2007-2011 mapping of Iraq war casualties using Fusion Tables to plot incident locations and details, which informed public discourse on conflict impacts. In the nonprofit sector, organizations like Atlanta's Drake House employed it to visualize homeless population distributions, aiding targeted service delivery and resource planning. Academic users applied it in interdisciplinary projects, such as overlaying literary references with geographic data to explore spatial themes in texts. Additionally, it supported real-time election result visualizations, as in Turkey's 2011 national elections, where dynamic Fusion Tables interfaces delivered province-level updates to millions via Google.com.tr.

Criticisms and Shortcomings

Performance and Scalability Issues

Google Fusion Tables imposed strict limits on dataset size, capping storage at 250 MB per user and restricting mapping and query results to the first 100,000 rows of data, beyond which additional rows were inaccessible for visualization or geospatial operations. These constraints stemmed from the service's architecture, which relied on for storage but prioritized ease of use over unbounded growth, rendering it unsuitable for datasets exceeding these thresholds without data partitioning or external workarounds. Performance degraded noticeably with larger tables, particularly during geospatial visualizations; for instance, generating map tiles could violate the 500-feature-per-tile limit, causing incomplete renders or excessive load times as the system attempted to oversized clusters. Users reported slower marker loading on embedded compared to local JSON files, attributing delays to network-dependent queries against Fusion Tables' remote backend rather than client-side processing. Query execution speeds were also hampered for tables approaching row limits, with geocoding requests subject to quotas that could halt operations after high-volume calls, necessitating batching or delays. Scalability efforts included optimizations like SSD integration to extend beyond initial RAM constraints, enabling handling of moderately larger workloads through hybrid storage tiers. However, the service's design as a "database in the " for non-experts inherently favored over elastic scaling, leading to comparisons with more robust platforms like AWS where storage could reach terabyte levels without equivalent row or quota barriers. These limitations often prompted users to fragment data across multiple tables or migrate to alternatives for production-scale applications, underscoring Fusion Tables' positioning as a prototyping tool rather than an enterprise-grade solution.

User Experience Drawbacks

Users reported frequent bugs and glitches in the interface, such as unexpected rendering errors during visualization creation, which disrupted workflow despite developer acknowledgments via email. Early versions imposed strict row limits of 100 to 250 entries, severely hindering for datasets beyond small scales and rendering large-scale visualizations impractical without external preprocessing. Visualization tools lacked depth in customization, with minimal interactive features like fixed node positioning in network graphs that prevented manual adjustments, leading to cluttered or suboptimal displays. Mobile responsiveness was inadequate, causing poor display of embedded maps and tables on smartphones, which compelled users to rely on workarounds for custom sites rather than native views. The upload process was constrained by a 1 MB limit per Excel file and overall storage caps of 250 MB per table, complicating data import for non-technical users and necessitating splits or conversions that increased setup friction. and interfaces, while aimed at non-experts, often felt rudimentary, with challenges in querying and merging tables without database knowledge exacerbating usability for broader audiences.

Broader Reliability Concerns with Google Products

Google's frequent discontinuation of products exemplifies a broader pattern of operational unreliability, where services are launched with user adoption but later terminated, often disrupting workflows and . Data compiled by independent trackers indicate that Google has shuttered over 250 products and services as of 2025, accounting for approximately 51.5% of its total offerings since inception, with annual terminations peaking at over 25 in alone. This "fail fast" strategy, while fostering innovation, has led to systemic user dissatisfaction, as evidenced by the abrupt end of tools like in 2013, which forced millions to migrate feeds and integrations elsewhere. Such practices undermine confidence in Google's commitment to longevity, particularly for data-centric applications where users invest significant effort in curation and visualization. Analysts note that products failing to achieve high daily or generate substantial —often undefined thresholds like $1 billion annually—are prime candidates for sunset, regardless of niche utility or institutional reliance. For example, the 2019 deprecation of services like Google+, which amassed 500 million users, highlighted risks of and obsolescence, mirroring challenges in tools. Critics, including technology commentators, argue this churn damages by fostering a of betrayal, making enterprises hesitant to embed products in due to fears of sudden . User forums and retrospectives frequently cite emotional and operational tolls, such as rebuilding custom datasets or retraining teams, which compound over repeated incidents. While attributes shutdowns to resource reallocation toward high-impact areas like AI and services, the opacity of decision criteria—often limited to internal metrics—exacerbates reliability doubts.

Deprecation

Announcement and Timeline

Google announced the deprecation of Fusion Tables on December 11, 2018, via its official Workspace Updates blog, specifying that the service and its associated would be fully turned down on December 3, 2019. This provided users with approximately one year to migrate their data and visualizations. Following the shutdown, embedded Fusion Tables elements—such as maps, charts, tables, and cards hosted on external websites—ceased to function after December 3, 2019, rendering them inaccessible without prior export. The Fusion Tables Layer in the JavaScript was similarly discontinued on the same date, with support ending in API version 3.38 (version 3.37 being the final supported release). Users retained the ability to export their table data through until March 3, 2020, after which all remaining data was permanently deleted by , eliminating any further recovery options. This timeline aligned with 's broader strategy to consolidate resources toward more advanced data tools, though no extensions were granted despite user feedback in some developer communities.

Official Reasons and Strategic Shifts

announced the shutdown of Fusion Tables on December 11, 2018, stating that the service and its would cease operations on December 3, 2019, while embedded visualizations like maps, charts, tables, and cards would continue to function post-shutdown. The company did not disclose specific internal metrics such as user adoption rates or maintenance costs as factors, focusing instead on the evolution of its tools ecosystem. Officially, Google framed the deprecation as an opportunity to advance user capabilities, noting that it had been "working on new tools to help you do more with your data" following feedback on desired enhancements. Recommended successors included Google Sheets for foundational data management and simple visualizations, Google Data Studio (later rebranded as Looker Studio) for sophisticated reporting and dashboards, Google My Maps for geospatial representations, and Google Cloud's BigQuery for handling large datasets with SQL-based querying and machine learning integrations. This positioning emphasized Fusion Tables' limitations in scalability and feature depth compared to these alternatives, though Google provided no quantitative comparison of performance or user migration success rates. The move aligned with broader strategic shifts at during the late 2010s, including a company-wide effort to rationalize its product portfolio by sunsetting niche or stagnant services in favor of unified platforms that integrated with core offerings like and services. Launched in 2009 as an experimental tool for collaborative data visualization, Fusion Tables had remained a standalone beta-like product without significant updates, contrasting with the rapid iteration seen in enterprise-focused tools like Data Studio, which gained advanced features such as real-time collaboration and third-party connector support by 2018. This consolidation reflected 's prioritization of high-growth areas like cloud analytics over specialized, lower-priority consumer and small-team data tools, enabling resource reallocation to products with stronger monetization potential through subscriptions and API usage.

User Disruptions and Migration Challenges

The discontinuation of Google Fusion Tables on December 3, 2019, led to immediate disruptions for users who had embedded visualizations—such as maps, charts, tables, and cards—on websites, applications, or documents, as these ceased rendering entirely on that date. Developers integrating Fusion Tables via the Maps JavaScript API encountered errors starting in August 2019, prompting early warnings but complicating ongoing projects reliant on real-time data layers. Applications like MIT App Inventor and ODK Collect, which leveraged the Fusion Tables API for data storage and querying, faced compatibility breaks, requiring developers to refactor code or seek workarounds before the API shutdown. Data access persisted briefly post-shutdown, with users able to export tables via downloads or until March 3, 2020, after which all data was permanently deleted from Google's servers. However, failure to export in time risked irrecoverable loss, particularly for users with large datasets or those unaware of the extended window, exacerbating disruptions for academic researchers and small organizations dependent on Fusion Tables for ad-hoc geospatial analysis. The export process supported formats like CSV and KML, but these often stripped specialized Fusion Tables features, such as merged table views and automatic geocoding, necessitating manual reconfiguration in new tools. Migration challenges stemmed from the lack of a direct, user-friendly replacement for Fusion Tables' core strengths in simple and visualization, with Google's recommended alternatives— for warehousing, Data Studio for reporting, SQL for relational storage, and Maps Platform for geospatial rendering—requiring greater technical expertise, SQL proficiency, and potential costs for scaling. Non-technical users reported difficulties in recreating interactive maps and dynamic queries, often facing caching issues with live data updates or limitations in free tiers of alternatives. Third-party guides and webinars emerged to address these gaps, highlighting common pain points like mapping and visualization loss during transfers to tools such as FME or CARTO. Users expressed frustration over the one-year notice period proving insufficient for complex workflows, with some resorting to proprietary solutions like Maptitude or GIS to approximate Fusion Tables' ease of embedding and sharing. Overall, the transition underscored broader reliability concerns with tools, as deprecation left legacy integrations vulnerable without backward compatibility provisions.

Legacy and Alternatives

Influence on Data Visualization Tools

Google Fusion Tables pioneered cloud-based with integrated visualization capabilities, enabling users to upload tabular data from formats like CSV or spreadsheets and automatically generate maps, charts, and network graphs without coding expertise. Launched in June 2009 as a project, it emphasized web-publishing of interactive visualizations, such as geocoded maps via automatic conversion of addresses to latitude-longitude coordinates, which facilitated rapid analysis for journalists and researchers plotting datasets on . These features influenced user expectations for accessible, no-code visualization in subsequent tools, as evidenced by alternatives developed post-deprecation that replicated elements like drag-and-drop mapping and dynamic cloud data handling. For instance, platforms such as Carto and GIS Cloud incorporated similar merge/join functionalities for combining datasets and spatial analysis, directly addressing gaps left by Fusion Tables' shutdown on December 3, 2019. Within Google's ecosystem, its collaborative data sharing model contributed to the evolution toward tools like Looker Studio (formerly Data Studio), which expanded on simple visualization for broader business intelligence needs. The service's emphasis on merging multiple tables and visualizations in web pages set a precedent for hybrid database-spreadsheet tools, though its niche focus on free, lightweight mapping limited broader adoption in like Tableau or Power BI, which prioritized advanced analytics over Fusion Tables' simplicity. Its discontinuation underscored the demand for scalable, collaborative platforms, prompting migrations that highlighted its role in normalizing cloud-first data exploration for non-specialists.

Post-Shutdown Developments

Following the shutdown of Google Fusion Tables on December 3, 2019, users were required to export their data prior to permanent deletion, with Google providing access via the Fusion Tables Archive Tool and Google Takeout service until March 3, 2020. Exports were primarily in CSV format, allowing manual import into other platforms, though embedded visualizations—such as maps and charts—ceased functioning immediately after shutdown, disrupting websites and applications reliant on real-time updates from Fusion Tables. Migration efforts focused on transferring data to Google-recommended successors like for large-scale querying and (formerly Data Studio) for visualization, though these required SQL proficiency and lacked Fusion Tables' simple fusion of heterogeneous data sources. Community-driven solutions emerged, including add-ons for like Mapping Sheets to replicate mapping features by uploading CSV exports and generating interactive layers. For geospatial data, integrations with Engine allowed importing Fusion Tables exports for advanced analysis, preserving some analytical workflows despite the loss of native hosting. Third-party alternatives gained traction post-shutdown, with platforms like GIS Cloud and CARTO offering cloud-based mapping and capabilities compatible with CSV imports from Fusion Tables. No open-source direct successor materialized, but users adapted by combining tools such as Jupyter notebooks for visualization or integrations in platforms like Power BI for sharing public datasets. Data loss occurred for unexported tables after March 2020, highlighting risks of , as noted in archival efforts by groups like , which documented the service's irrecoverable termination. Google recommended for data storage and querying, combined with (previously Google Data Studio) for visualization, as primary paths for users transitioning from Fusion Tables after its shutdown on December 3, 2019. supports uploading and merging tabular data at scale using SQL, handling datasets up to petabyte sizes, while facilitates embedding interactive charts, maps, and reports from or other connectors, replicating Fusion Tables' basic visualization workflows. For geospatial emphasis, CARTO provides a cloud-based platform for importing CSV or KML files, performing spatial joins akin to Fusion Tables' , and generating embeddable maps with heatmaps and choropleths. Similarly, Online enables drag-and-drop uploads of spreadsheets, automated geocoding, and customizable symbology for point, line, and polygon layers, with free tiers for basic use though advanced features incur costs. Business intelligence tools like Tableau Public (free edition) and offer robust alternatives for non-spatial data merging and dashboarding, supporting Fusion Tables-like filtering, aggregation, and export to interactive visuals, but require separate integrations for full mapping via extensions like Tableau's built-in maps or Power BI's plugin. GIS Cloud serves as another option for collaborative mapping, allowing real-time edits and access for embedding, positioned as a direct workflow substitute for smaller teams. No single tool fully replicates Fusion Tables' seamless integration of free storage, fusion, and embedding without trade-offs in cost, scalability, or , prompting many users to combine services like for lightweight editing with specialized visualizers.

References

  1. https://research.google/pubs/google-fusion-tables-data-management-integration-and-collaboration-in-the-cloud/
  2. https://research.google/blog/google-fusion-tables/
  3. https://maps.googleblog.com/2010/02/mapping-your-data-with-google-fusion.html
  4. http://googlecode.blogspot.com/2009/12/google-fusion-tables-api.html
  5. https://support.google.com/fusiontables/answer/9551050?hl=en
  6. https://workspaceupdates.googleblog.com/2018/12/google-fusion-tables-to-be-shut-down-on.html
  7. http://research.google.com/pubs/pub36257.html
  8. http://www.padjo.org/tutorials/mapping/basic-fusion-tables/
  9. https://earth.google.com/outreach/data/googleearthoutreach_fusion_tables_info_sheet.pdf
  10. https://www.uni-bamberg.de/fileadmin/eng-ling/fs/Chapter_3/41GoogleFusionTables.html
  11. https://people.cs.kuleuven.be/~bettina.berendt/teaching/2010-11-2ndsemester/ctdb/p175-gonzalez.pdf
  12. https://thodrek.github.io/CS839_spring18/papers/p1061-gonzalez.pdf
  13. https://stackoverflow.com/questions/13875853/how-to-upload-bulk-data-in-fusion-table
  14. https://www.sco.wisc.edu/wp-content/uploads/2018/04/quick_and_easy_web_maps_v1.2.pdf
  15. https://www.ghacks.net/2009/06/11/google-fusion-tables-offers-data-management-in-the-cloud/
  16. https://developers.googleblog.com/en/google-fusion-tables-api/
  17. https://drew.edu/wp-content/uploads/2023/09/Google-Fusion-Table-Tutorial-Working-with-NATA-Geospatial-Data.pdf
  18. https://andrewpwheeler.com/2014/07/18/using-google-fusion-tables-to-make-some-maps/
  19. https://cs598.github.io/papers/fusion-tables.pdf
  20. https://www.journalism.co.uk/skills/how-to-get-started-using-google-fusion-tables/s7/a544215/
  21. https://www.geodose.com/2017/05/how-to-create-earthquake-heatmap.html
  22. https://research.google/pubs/google-fusion-tables-web-centered-data-management-and-collaboration/
  23. https://dl.acm.org/doi/10.1145/1807128.1807158
  24. http://sites.computer.org/debull/A10sept/p25.pdf
  25. https://derekeder.com/blog/preparing-for-the-fusion-tables-sql-api-deprecation
  26. https://stackoverflow.com/questions/11952166/what-are-the-technical-limitations-when-using-fusion-tables
  27. https://cartographicperspectives.org/index.php/journal/article/view/cp71-peterson-et-al/html
  28. https://gsuite-developers.googleblog.com/2011/09/using-fusion-tables-with-apps-script.html
  29. https://gist.github.com/chrislkeller/3013360
  30. https://research.google/blog/introducing-new-fusion-tables-api/
  31. https://support.google.com/maps/thread/9569970/with-google-fusion-tables-being-turned-down-in-december-what-it-is-a-free-comparable-alternative?hl=en
  32. https://pubs.geoscienceworld.org/gsa/books/book/658/chapter/3806993/Geoscience-applications-of-client-server-scripts
  33. https://research.google/blog/google-fusion-tables-celebrates-one-year-of-data-management/
  34. https://drive.googleblog.com/2011/09/this-week-in-docs-format-painter-google.html
  35. https://blog.chrislkeller.com/googles-fusion-tables-gets-new-features-ui-ma
  36. https://research.googleblog.com/2009/06/google-fusion-tables.html
  37. https://www.dwrl.utexas.edu/2016/05/04/cool-tools-interactive-mapping-with-google-fusion-tables/
  38. https://www.seerinteractive.com/insights/visualize-your-backlinks-with-google-fusion-tables
  39. https://businessjournalism.org/2012/08/google-fusion-tables/
  40. https://knightlab.northwestern.edu/2014/03/05/displaying-of-aggregate-info-dynamic-storytelling-with-google-fusion-tables/
  41. https://www.annielytics.com/blog/seo/use-google-fusion-tables-simple-guide-marketers-video/
  42. https://pmc.ncbi.nlm.nih.gov/articles/PMC6507003/
  43. https://maps.googleblog.com/2011/11/finding-perfect-home-with-google-fusion.html
  44. https://u-next.com/blogs/data-science/using-google-fusion-tables-maps-home-insurance-case-study-2/
  45. https://miriamposner.com/blog/google-fusion-table-basics-with-ius-cushman-collection/
  46. https://www.odbms.org/blog/2011/08/google-fusion-tables-interview-with-alon-y-halevy/
  47. https://impacttrackertech.kopernik.info/products/googleFusionTable/
  48. https://www.predictiveanalyticstoday.com/google-fusion-tables/
  49. https://blog.ouseful.info/2012/02/29/more-thoughts-on-a-content-strategy-for-data-many-eyes-and-google-fusion-tables/
  50. https://vizworld.com/2009/12/google-fusion-tables-failure-beta-glitches/
  51. https://www.sciencedirect.com/science/article/abs/pii/S1618866714000703
  52. https://www.plu.edu/dhlab/wp-content/uploads/sites/330/2019/03/dh-how-to_-google-fusion-tables.pdf
  53. https://www.gbif.org/tool/81730/google-fusion-tables
  54. https://blog.frankel.ch/use-case-google-fusion-tables/
  55. https://guides.tricolib.brynmawr.edu/c.php?g=285329&p=1900628
  56. https://www.researchgate.net/publication/220831912_Google_Fusion_Tables_Data_management_integration_and_collaboration_in_the_cloud
  57. https://hornportfolio.com/2014/05/30/google-fusion-table-maps-and-javascript-the-power/
  58. https://pinardag-1.gitbook.io/datajournalism/4.case-studies-from-turkey-and-from-other-countries-of-impact-of-data-journalism-stories-in-social
  59. https://blog.google/outreach-initiatives/google-org/fueling-great-nonprofits-with/
  60. http://angiehosetheportfolio.weebly.com/google-fusion-tables-presentation.html
  61. https://blog.google/intl/tr-tr/sirket-haberleri/teknoloji/2011_06_secim-sonuclar-googlecomtrsecim2011den/
  62. https://stackoverflow.com/questions/46141965/website-performance-loading-markers-on-google-map-from-a-google-fusion-table-v
  63. https://gis.stackexchange.com/questions/15052/avoiding-google-maps-geocode-limit
  64. https://research.google/pubs/using-ssds-to-scale-up-google-fusion-tables-a-database-in-the-cloud/
  65. https://gis.stackexchange.com/questions/6615/google-fusion-tables-vs-amazon-web-services-which-is-better-for-gis-data
  66. https://go-to-hellman.blogspot.com/2009/06/linked-data-vs-google-fusion-tables.html
  67. https://abbymullen.org/lessons-from-a-google-fusion-table-graph/
  68. https://forum.getodk.org/t/many-fusion-table-duplicates-being-created/16055
  69. https://killedbygoogle.com/
  70. https://brandwell.ai/blog/killed-by-google-statistics/
  71. https://arstechnica.com/gadgets/2019/04/googles-constant-product-shutdowns-are-damaging-its-brand/
  72. https://www.whatsthehost.com/killed-by-google-list-of-products-and-services-sunsetted-by-the-loony-search-giant/
  73. https://medium.com/%40alaxhenry0121/why-google-might-kill-flutter-the-uncomfortable-truth-about-googles-history-60cd4862e306
  74. https://www.businessinsider.com/discontinued-google-products-2016-8
  75. https://www.slashgear.com/1654643/canceled-google-products-useful/
  76. https://www.reddit.com/r/degoogle/comments/171lptd/desiring_to_degoogle_because_of_google_constantly/
  77. https://developers.google.com/maps/deprecations
  78. https://9to5google.com/2018/12/11/google-fusion-tables-shutting-down/
  79. https://community.appinventor.mit.edu/t/warning-google-has-deprecated-the-fusion-tables-service-it-will-stop-working-on-december-3-2019/20545
  80. https://forum.getodk.org/t/google-fusion-tables-to-be-shut-down-on-december-3-2019/16741
  81. https://researchdata.wisc.edu/news/google-fusion-tables-takedown-what-it-means-for-users/
  82. https://support.google.com/fusiontables/answer/9185417
  83. https://stackoverflow.com/questions/53913550/migrating-google-maps-api-app-from-fusion-tables-to-datastore-data-layer
  84. https://fme.safe.com/webinars/a-dont-panic-guide-to-migrating-data-out-of-google-fusion-tables/
  85. https://www.computerworld.com/article/1711268/google-will-shut-down-fusion-tables.html
  86. https://carto.com/blog/google-fusion-table-alternative
  87. https://www.fastcompany.com/90279779/rip-fusion-tables-google-is-killing-off-the-beloved-data-visualization-tool
  88. https://www.giscloud.com/blog/gis-cloud-as-an-alternative-to-google-fusion-tables/
  89. https://medium.com/google-earth/download-your-fusion-tables-data-and-migrate-your-maps-278babd23879
  90. https://groups.google.com/g/mitappinventortest/c/YPxwZn_a1rQ/m/PLpq4360BwAJ
  91. https://www.quora.com/What-programs-are-similar-to-Google-Fusion-Tables
  92. https://www.thexs.ca/posts/google-fusion-tables-alternative-using-mapping-sheets-add-on
  93. https://samapriyaroy.medium.com/google-fusion-table-migration-with-within-google-earth-engine-93d103111ce7
  94. https://gis.stackexchange.com/questions/37075/seeking-cloud-based-alternatives-to-google-fusion-tables
  95. https://www.reddit.com/r/gis/comments/cq256t/tools_to_replace_fusion_tables_google_maps/
  96. https://wiki.archiveteam.org/index.php/Google_Fusion_Tables
  97. https://fme.safe.com/blog/2018/12/7-google-fusion-tables-alternatives/
Add your contribution
Related Hubs
User Avatar
No comments yet.