Picasa Web Albums data API - Now with geo support!

Wednesday, June 27, 2007 at 6/27/2007 08:31:00 AM

The latest release of Picasa Web Albums now includes support for geotagging your photos and albums, so you can show friends where you took your favorite pictures. We've also added API support for this functionality so that you can easily integrate geotagging into your applications!

What's it look like? We've implemented geo support using the GeoRSS and Geography Markup Language (GML) formats. The location of each photo and album can be described using a point-- represented by a latitude and longitude.

For instance, here's GeoRSS representing a picture taking in Tokyo, Japan:

    <gml:pos>35.669998 139.770004</gml:pos>

Of course, the Java Client Library also has support for retrieving and setting the location on an album or photo. Here's an example of setting the location on a PhotoEntry object, after using a custom getString helper method to prompt and get a string from standard input:

String latitude = getString("Latitude");
String longitude = getString("Longitude");
photoEntry.setGeoLocation(Double.valueOf(latitude), Double.valueOf(longitude));

Here's an example of retrieving the photo location:

Point photoLocation = photoEntry.getGeoLocation();
System.out.println("Longitude: " + point.getLongitude());
System.out.println("Latitude: " + point.getLatitude());

We look forward to all the great applications you create using the new geo functionality of Picasa Web Albums. Please be sure to share them using the Share Your Project page in the Picasa Web Albums data API Developer Forum.

Happy coding,

Ryan Boyd - The Google data APIs team

Reflections on XTech

Thursday, June 21, 2007 at 6/21/2007 01:56:00 PM

I recently participated in XTech 2007: a conference for those working with web and standards-based technologies. I've had some time to ruminate on the experience and I thought I'd share some ideas which rose to the top as I submerged myself in the deluge of information and interactions.

I attended a talk on OpenStreetMap, which looks like a very interesting solution to creating and annotating detailed maps. I find their list of public GPS traces particularly interesting. There was one problem that Steven Coast brought up which stuck with me, and that is inconsistencies in tagging. OpenStreepMap allows users to tag locations with anything they like, this simplicity and flexibility can lead to rich information, but can also lead to confusion when different people use the same tags for different things, or use different tags to describe the same thing. It's a difficult problem to deal with, and we've tried to tackle this in Google Base by providing an attributes feed. The attributes feed is a dynamic and searchable list of the tags, or attributes, that people are using when describing items of a particular type. I think it certainly helps with the problem of recommending annotations, but we're working to make it better.

I was also pleased to see several discussions centering on XMPP (the protocol used by Jabber, Google Talk, and other instant messaging clients), and I was surprised to see some of the applications people were building on top of this technology. A few years ago, I built a small application which used XMPP to dynamically edit a web page, and it seems others were thinking up even grander schemes. Twitter makes use of XMPP, and I saw a great demo by Massimiliano Mirra which showed how XMPP could be used as a programmatic communication channel to make single user applications into collaborative ones.

There were many other interesting presentations, people, and ideas at XTech this year, but I've rambled enough. Check out the XTech's website for more information on talks you may have missed, and keep an eye out for details on next year's conference.

Jeff Scudder - The Google data APIs team

Salesforce SOA Integration with Google data APIs

Friday, June 15, 2007 at 6/15/2007 08:18:00 AM

Salesforce.com recently announced the AJAX Proxy feature for Salesforce SOA. This feature, scheduled for availability in early July, avoids the cross-domain issues normally associated with communicating with external web services using client-side JavaScript.

We're really excited by this, as it will enable Salesforce applications to communicate with all of our Google data APIs directly from the browser. Salesforce released an in-depth article on the topic: Building a Google Calendar Mash-up with Salesforce SOA . This tutorial guides the reader through the process of performing many of the common Calendar data API operations, including:

  • Authenticating via AuthSub
  • Listing the user's calendars
  • Inserting events
  • Deleting events

This isn't the first we've heard about integrating Salesforce.com applications with Google data APIs. Charlie Wood, of Spanning Partners , talked about his experiences working with the Calendar data API and plans for synchronizing Salesforce.com and Google Calendar during his presentation at Dreamforce last year. His company has already developed Spanning Salesforce to enable the retrieval of RSS feeds of Salesforce.com data.

We look forward to hearing about the mashups you create using this new capability on the Salesforce.com platform. I encourage you to share them with the community using the new pages we created on each of the Google data API developer forums. You can also use these pages to share your own articles and tutorials.

Happy coding!

Ryan Boyd - The Google data APIs team

New Zend_Gdata PHP client library design

Tuesday, June 12, 2007 at 6/12/2007 01:17:00 PM

We're pleased to announce the release of a new version of the Zend_Gdata component of Zend Framework project. This component represents the PHP 5.1.4+ client library for Google data APIs and has been redesigned to enable more object-oriented usage.

The redesign was prompted by the desire to support a variety of different services with the same level of usability as our other client libraries. We aimed to comply with the following requirements when redesigning and implementing the new Zend_Gdata component:

  • A developer should be able to perform most functionality by looking only at the PHP documentation of classes, methods and a few examples.

  • A developer should not need to know the structure of the XML documents used by the GData services nor the namespaces, etc in order to use the library effectively.

  • As much consistency as possible should exist between the PHP client library and other GData client libraries, while still maintaining a PHP feel to the library.

  • The library should be usable by both experts and beginners in GData and PHP.

So, what does using the new client library look like? If you've previously used any of the other client libraries, the design should be very familiar. Take a look at the new Spreadsheets data API Developer's Guide for PHP, the updated Calendar data API Developer's Guide or the Reference Guide for more information on usage. The client library currently fully supports Calendar, Spreadsheets and generic Atom Publishing Protocol (App) services. We're also actively working on implementing extensions for the other Google data APIs.

You can download the new client library by visiting the Zend_Gdata download page on the Zend Framework site. The client library is also included as part of the main Zend Framework distribution, but full functionality for Calendar won't be available in the main distribution until the 1.0 RC3 release, scheduled for sometime in the next couple weeks.

If you're interested in the PHP client library or having any questions or problems, please join the mailing list. Zend also welcomes contributions to the Zend Framework and their wiki contains more information about contributing. This site also gives information on how to file bugs and feature requests in the issue tracker.

Please note that, due to the significant changes made in the new version of the Zend_Gdata component, we were not able to maintain backwards compatibility with the version that existed prior to Zend Framework 1.0. The Zend_Gdata 0.9.3 Beta and earlier releases will continue to be available on the download page for the time being in case you prefer the old approach of working more directly with the XML-centric data model. Also, the new version of the client library continues to allow you to work with the raw XML if desired.

I'm looking forward to seeing all the great applications written using the new version of the client library. Please share your project using the Pages feature in the developer forum for your favorite Google data API.

Ryan Boyd - The Google data APIs team

Picasa Web Albums API Support for Objective-C Developers

Wednesday, June 06, 2007 at 6/06/2007 12:51:00 PM

Mac users are a visual bunch, and Mac developers specialize in helping their users create and share images. To make it easy for Mac software to take advantage of the Picasa Web Albums API, I've updated the open-source Google Data APIs Objective-C Client Library to support browsing and uploading to albums. With the Objective-C framework, Cocoa developers can quickly make photo sharing via Picasa Web Albums a feature of their applications. The Google Mac blog includes some sample code, and the library is available to download from code.google.com.

Greg Robbins - The Google data APIs team

Open Data @www in 2007

Monday, June 04, 2007 at 6/04/2007 10:49:00 AM

I recently had the opportunity to attend and present Google data APIs at WWW2007 in Banff, Alberta, Canada. While the conference is traditionally focused on academic research, I presented as part of their Developer Track which was geared to technologies that can be more readily applied. It was an excellent conference -- highly organized with lots of interesting sessions-- way too many interesting sessions to attend them all.

The resounding theme across many of the sessions I attended was letting data be open and readily available for use in ways not imaginable to the people supplying the data -- turning raw data into actionable (or at least interesting) information. This is also one of the main goals of GData and part of the core mission of Google.

There were a couple of projects in this space that caught my eye:

This project aims to provide a worldwide collaborative set of map data. It allows contributors to upload GPS traces of their road travels, name the streets, areas and points of interest. Of course, they also allow the world to view the maps online, and even provide a RESTful API for programmatic access.

Provides online storage of structured data, for the world to contribute and view. Unlike Google Base, Freebase allows anyone (not just the original contributor) to edit the uploaded data. This works in a similar fashion to Wikipedia.

Apache Abdera
Apahce Abdera is a full-fledged implementation of the Atom Syndication Format and the Atom Publishing Protocol (APP). These two specifications are the basis for the Google data APIs and provide full CRUD capabilities. The Abdera project includes both client, data model, and server components-- enabling you to expose your data to the world, and provide a mechanism for it to be easily accessed and integrated into other applications.

I'd encourage you to take a look at these projects and find ways that you can expose your own data to the world. Of course, also see what you can do to mash up your data with Google data APIs while you're at it!

All the best,

Ryan Boyd, Google data API team

New GData Developer Guides - Spreadsheets and Blogger

Thursday, May 24, 2007 at 5/24/2007 11:07:00 AM

Everywhere I go people are always saying to me, "Man, those Blogger and Spreadsheet developer guides are really cool, but I want to know how to do things in .NET and Python." Well, okay, so maybe it's not everywhere I go, but the question has come up, and we thought we should do something about it.

Today, I'm happy to announce new versions of the Blogger API developer guide and the Spreadsheets API developer guide, both in a new tabular format. We've split each language into its own section, and shown you how to do a set of common operations in Java, .NET, Python, and HTTP (because many of us like to know what goes across the wire). If you notice a similarity to recent changes we made to the Calendar developer guide, it's because this revision is part of an ongoing effort to make our documentation more useful to you, the software developer. I also took this opportunity to clear up some issues that some of you have pointed out in the old documents. So check it out! If you see anything amiss, we'll talk it over in the Spreadsheets API discussion group or the Blogger API discussion group.

Jeff Scudder - The GData Team