Google Fusion Tables with Apps Script

I started with Apps Script in the same way many of you probably did: writing extensions to spreadsheets. When it was made available in Sites, I wondered whether it could meet our needs for gathering roadmap input from our sales engineering and enterprise deployment teams.

Gathering Roadmap Data

At Google, teams like Enterprise Sales Engineering and Apps Deployment interact with customers and need to share product roadmap ideas to Product Managers. Product Managers use this input to iterate and make sound roadmap decisions. We needed to build a tool to support this requirement. Specifically, this application would be a tool used to gather roadmap input from enterprise sales engineering and deployment teams, providing a unified way of prioritizing customer requirements and supporting product management roadmap decisions. We also needed a way to share actual customer use cases from which these requirements originated.

The Solution

This required bringing together the capabilities of Google Forms, Spreadsheets and Moderator in a single application: form-based user input, dynamically generated structured lists, and ranking.

This sounds like a fairly typical online transaction processing (OLTP) application, and Apps Script provides rich and evolving UI services, including the ability to create grids, event handlers, and now a WYSIWYG GUI Builder; all we needed was a secure, scalable SQL database backend.

One of my geospatial colleagues had done some great work on a demo using a Fusion Tables backend, so I did a little digging and found this example of how to use the APIs in Apps Script (thank you, Fusion Tables Developer Relations).

Using the CRUD Wrappers

Full sample code for this app is available and includes a test harness, required global variables, additional CRUD wrappers, and authorization and Fusion REST calls. It has been published to the Script Gallery under the title “Using Fusion Tables with Apps Script.”

The CRUD Wrappers:

/**
 * Read records
 * @param {string} tableId The Id of the Fusion Table in which the record will be created
 * @param {string} selectColumn The Fusion table columns which will returned by the read
 * @param {string} whereColumn The Fusion table column which will be searched to determine whether the record already exists
 * @param {string} whereValue The value to search for in the Fusion Table selectColumn; can be '*'
 * @return {string} An array containing the read records if no error; the bubbled return code from the Fusion query API if error
 */
function readRecords_(tableId, selectColumn, whereColumn, whereValue) {

  var query = '';
  var foundRecords = [];
  var returnVal = false;
  var tableList = [];
  var row = [];
  var columns = [];
  var rowObj = new Object();

  if (whereValue == '*') {
    var query = 'SELECT '+selectColumn+' FROM '+tableId;
  } else {
    var query = 'SELECT '+selectColumn+' FROM '+tableId+
                ' WHERE '+whereColumn+' = ''+whereValue+''';
  }

  var foundRecords = fusion_('get',query);

  if (typeof foundRecords == 'string' && foundRecords.search('>> Error')>-1) 
  {
    returnVal = foundRecords.search;
  } else if (foundRecords.length > 1 ) {
    //first row is header, so use this to define columns array
    row = foundRecords[0];
    columns = [];
    for (var k = 0; k < row.length; k++) {
      columns[k] = row[k];
    }

    for (var i = 1; i < foundRecords.length; i++) {       row = foundRecords[i];       if( row.length > 0 ) {    
        //construct object with the row fields
        rowObj = {};
        for (var k = 0; k < row.length; k++) {
          rowObj[columns[k]] = row[k];
        }
        //start new array at zero to conform with javascript conventions
        tableList[i-1] = rowObj; 
      }
    }
    returnVal = tableList;
  }

  return returnVal;
}

Now all I needed were CRUD-type (Create, Read, Update, Delete) Apps Script wrappers for the Fusion Tables APIs, and I’d be in business. I started with wrappers which were specific to my application, and then generalized them to make them more re-usable. I’ve provided examples above so you can get a sense of how simple they are to implement.

The result is a dynamically scalable base layer for OLTP applications with the added benefit of powerful web-based visualization, particularly for geospatial data, and without the traditional overhead of managing tablespaces.

I’m a Fusion tables beginner, so I can’t wait to see what you can build with Apps Script and Fusion Tables. You can get started here: Importing data into Fusion Tables, and Writing a Fusion Tables API Application.

Tips:

  • Fusion Tables is protected by OAuth.This means that you need to authorize your script to access your tables. The authorization code uses “anonymous” keys and secrets: this does NOT mean that your tables are available anonymously.
  • Some assumptions were made in the wrappers which you may wish to change to better match your use case:
    • key values are unique in a table
    • update automatically adds a record if it’s not already there, and automatically removes duplicates
  • Characters such as apostrophes in the data fields will be interpreted as quotation marks and cause SQL errors: you’ll need to escape these to avoid issues.
  • About”) and column names to construct your queries

    via Ferris Argyle

Google Earth: An Illustrated History of the World

Robert Rosenberg recently emailed us to let us know about a very ambitious new project he’s working on, called the Illustrated History of the World. In his words:

The IHW project is the Foundation’s effort to bring together existing multi-media web content such as Google Earth, You Tube, and Wikipedia in order to create an interactive narrative of world history based upon the content of our Tables of Instances.

tribus.jpg

If things go as well as they’re hoping, the result could be a very useful resource for teachers and students to help supplement their history and geography lessons.

As of now, the project is a bit cumbersome to load on your computer, as the main KMZ file is roughly 108MB! They’re already working on ways to reduce the size of that, likely putting it into a network link so it can be loaded in smaller chunks as needed. The other advantage to using a network link is that the data can be automatically updated, rather than requiring the user to re-download it from their site.

You can learn more on their website at TribusOrganum.org. They’ve also started a thread in the Google Earth Community to help solicit more feedback.

Google Fusion Tables: So Easy — So Disruptive

Andrew Zolnai shows how quickly you can start working with Google Fusion Tables and Google Maps.  There are limitations to Google Fusion Tables that will probably confine it’s use in the near future (data has to be public), but that will all be resolved when it becomes part of the Google Docs suite soon enough.  I really can’t imagine visualizing data outside of Google Fusion Tables anymore with web mapping.  The pieces are all there.

Not pictured: The world benefiting from Googlezilla's breath.