Free data a GFC casualty

The US government has been a proponent of free data for quite a while now and over the years it established a number of national programs to allow easy access to wast resources of public information. However, the annual budgets for e-government initiatives were slashed by 75% last month, putting in question the survival of such programs like data.gov (it is the repository for publicly available data that was promised as a platform to power software and analysis created by and for the public). Comments from federal CIO Vivek Kundra indicate that data.gov will not be shut down but “…there will be no enhancements or other development to address needs for improvement”. So, although the policy of free data remains unchanged, significant cost of delivering that policy may be its ultimate “undoing”.

Meantime, in Australia, the progress towards opening up government data vaults has taken another step forward. Earlier this week Australia’s Information Commissioner, John McMillan, unveiled eight new rules for Federal agencies to adhere to when considering the publication of government data. These rules are:

  • Open access to information – a default position,
  • Engaging the community,
  • Effective information governance,
  • Robust information asset management,
  • Discoverable and useable information,
  • Clear reuse rights,
  • Appropriate charging for access, [So, not entirely free access!]
  • Transparent enquiry and complaints processes

The Principles are not binding on agencies, and operate alongside legal requirements about information management that are spelt out in the FOI Act, Privacy Act 1988, Archives Act 1983 and other legislation and the general law.

Despite the launch of data.gov.au portal, there is no federal program in Australia to facilitate access to public data on a large scale (ie. the US style) and the onus so far is on individual agencies to manage the dissemination of public information in their possession. State and Territory governments are pursuing their own initiatives. This “piecemeal approach”, although slower in implementation, may prove to be a more sustainable model for enabling access to public data, considering the vulnerability of large scale initiatives to budgetary pressures of the government of the day in these uncertain times.

Google I/O 2011 – The Geo Developers

Google I/O was about the maturation of many of the Geo APIs, this year’s was more about their sophistication, both in the designs discussed and the applications on display. Like the sun standing still at the solstice, let’s take a moment to reflect on recent events and look ahead to the coming season.

Several new features made their debut at I/O this year. The much-anticipated Places API took the stage, as did its companion the Places Autocomplete API. Dynamic Styling was introduced for Fusion Tables layers in the Maps API, allowing layer styling to be defined by the API application via Javascript. Finally, some extremely helpful open source Javascript libraries were introduced to make Maps API development even easier.

Joining us on stage were several developers who came to share their expertise. Justin O’Beirne of 41Latitude talked about map usability and design in the “Designing Maps Applications for Usability” session. The Guardian UK’s Simon Rogers joined us to talk about how the Guardian is using Fusion Tables to visualize the data they collect in “Managing and Visualizing Your Location Based Data.” Yoni Samlan from SCVNGR also came to discuss developing with the Places API in “Location-based App Development.”

In addition to the sessions led by the Geo team, the developer sandbox featured eight Geo API partners who engaged directly with I/O attendees. Joining us in the sandbox were HistoryPin, Icon Fitness, Ubisense, The Wall Street Journal, Footprint Feed, The Bay Citizen, Arc2Earth, and Travel Game. The apps on display ranged from location-based gaming using the Latitude API to tools for citizen journalists to map public data using Fusion Tables. You can learn more about two of our sandbox partners in these video case studies:

  • The Bay Citizen (video) – The Bay Citizen explains the benefits of the Fusion Tables layer with Google Maps API to build infographics for their online newspaper. The Bike Accident Tracker visualizes the prevalence of bike accidents across San Francisco.
  • Historypin (video) – HistoryPin lets users upload historical photos, geotag them on a Google Maps, and overlay the old imagery on top of new Street View imagery, enabling users to see what their cities looked like at different points in time.


Geo APIs Summer Learning Series (apologies to the Southern Hemisphere)

But at the heart of Google I/O are the sessions themselves. This year, speakers from the Maps, Earth, and Fusion Tables teams covered a wide range of topics, from ensuring high performance and usability across all browsers to visualizing huge data sets with Fusion Tables. The amount of material covered was enormous…but we want to expand upon it.

To that end, we’re pleased to announce the “Geo APIs Summer Learning Series” on the Geo Developers Blog. Over the coming weeks, each talk will be getting its own blog post from the session speaker, pulling in what was discussed at I/O and then digging deeper into the technical content. Here is how the series will unfold:

Week of July 6th
Connecting People and Places
Location Based App Development using Google APIs
Secrets and Surprises of the Google Geo APIs

Week of July 11th
Managing and visualizing your location based data with Fusion Tables
Designing Maps Applications for Usability on Mobile and Desktop

Week of July 18th
High Performance KML for Maps and Earth
Speedy Maps

Week of July 25th
Map your business, inside and out
GIS with Google Earth and Google Maps

If you’d like a head start, videos of all the I/O sessions are linked above. Be sure to visit the Geo Developers Blog throughout July for even more great content from the Maps, Earth, and Fusion Tables teams.

 

Chrome’s file browser handler

During the day 2 keynote of Google I/O, I was excited to see Box’s integration with the Chromebook’s file browser handler getting demoed on the big stage. The integration makes local files and files you encounter on the web easily accessible to cloud services inside Chrome OS.

Chrome’s file browser handler utilizes the new HTML5 file system API, designed to enable web applications to interact with local files. This API lets web applications read files, edit files, and create new files within a designated local space on a user’s machine. This includes creating binary files for application data, and in Box’s case, accessing user-created files to let people easily move their content to the cloud.

As mentioned during the Google I/O keynote, the integration between Box and the Chrome OS file browser handler only took our team a weekend to build. We were able to build the integration quickly because of the simplicity of both Chrome’s file browser platform and Box’s API, both of which were designed to make content integrations like this easy for developers to implement.

In this case, the Quick Importer tool from the Box API made the entire development process just a few steps:

1. We created a Chrome extension manifest to work with Box.
[php]{
"name”: "Box Uploader",
…
"file_browser_handlers": [
{
"id”: "upload",
"default_title": "Save to Gallery", // What the button will display
"file_filters": [
]
}
],[/php]

2. In the Chrome manifest, we specified the relevant file types to which the service applies. In our case, that’s most file types, as seen below. Specialized services may just want certain types, such as images for Picasa.
[php]"file_browser_handlers": [
{
"id": "upload",
"default_title": "Save to Box",
"file_filters": [
"filesystem:*.*"
]
}
],[/php]

3. With some JavaScript code connecting to the file browser handler, we set up a way to upload files through Box’s Quick Importer.
[php]<strong>var</strong> fm = <strong>new</strong> FileManager<strong>()</strong>;
fm.uploadServer = ‘https://www.box.net/&lt;…&gt;’;

<strong>if</strong> <strong>(</strong>bgPage <strong>&amp;&amp;</strong> bgPage.filesToUpload.length<strong>)</strong> <strong>{</strong>
<strong>var</strong> entry;
<strong>while(</strong>entry = bgPage.filesToUpload.pop<strong>())</strong> <strong>{</strong>
entry.file<strong>(function(</strong>file<strong>)</strong> <strong>{</strong>
fm.uploadFile<strong>(</strong>file<strong>)</strong>;
<strong>})</strong>;
<strong>}</strong>
<strong>}</strong>[/php]

That’s actually all there was to the integration.

Once the file is uploaded to the Box API’s Quick Import URL, our page is displayed to authenticate the user, to let the user select a Box folder to save the file, and then to upload the file.

While such an integration can be customized through our API, our Quick Import provided an easy and fast means to connect the platforms. Developers can customize the integration by using direct calls to our API, and take advantage of additional features such as automatic sharing, if they prefer.

Thanks to the simplicity of Chrome’s file browser handler and some extra tools in the Box API, our development time was very short (just a weekend), but it could have actually been even quicker. We had a couple of unusual complications that weekend:

1. The Google Chrome team was still experimenting with the file browser, so development from both sides was happening in parallel, which can be a bit tricky. Now that the file browser has been thoroughly tested, you should have an even easier time.

2. I took my girlfriend out a couple times, since her final exams were coming up soon afterward. I love you, Hayley!

Once the content has been uploaded to Box, it’s accessible to many Google services, including Gmail, Google Docs, and Google Calendar, through additional integrations on our site with Google Apps. Ah, the wonders of open platforms.