Google Maps Terrain

What do you do if you're Google and you've got excellent terrain data for most of the world?


You make it available on Google Maps of course!

Google Maps now features 'Terrain' in place of 'Hybrid', with the hybrid selection becoming a 'Show Labels' option under Satellite view.

Terrain data varies depending on the terrain resolution they have available, but it covers the whole world, just like Google Earth.

It reminds me of the old style relief atlases I used to browse through at the library, and a old hardcover book my parents had for the Grand Canyon. Love it.

View Larger Map

Android in Action

It's been a week since Google released their first cut of the Android SDK and despite Scoble's claims to the contrary, thousands of developers spent last week developing their first Android applications.

Where Are My Friends?

Here's what I was able to do in about 14hrs of development.



It reads the address book to find my friends, uses the Location Based Services to show how far away I am from them, and then plots everyone within 10km on a map. Philipp over at Google Blogoscoped has published my experience, leave a comment here or in the Blogoscoped forum if you've got questions -- or send me an email at Reto.Android@Radioactiveyak.com.

Today I'm a desktop and mobile developer.

As a development platform Android is phenomenal; It's powerful and it's intuitive. I week ago I was a desktop developer dabbling with online apps -- today I'm also a mobile developer. I don't say this lightly, desktop development is what I do to pay the bills.

Doesn't it make sense to launch the SDK well in advance of any actual phones?

Erstwhile video blogger Scoble is disappointment with Android. It seems this is largely because the launch "videos were boring". Robert? Dude? Who gives a shit about the videos? Developers don't want videos, they want CODE. Code, samples, and a well documented API. I still haven't watched the videos, I was too busy using the SDK to spend time looking at the pretty moving pictures. Apparently the shiny lights distracted Scoble as he screeches "[I] DO NOT TRUST THINGS THAT THEY WON’T SHOW ME WORKING". Android works. I've seen it, I've used it. They announced a software stack not hardware, and the software stack is available right now.

True, there are no phones yet, but Android is about development tools for 3rd party developers, so doesn't it make sense to launch the SDK well in advance of any actual phones? Google aren't going to out Apple the iPhone but they may just out Microsoft Windows Mobile.

You can bet that there's more than one Android project to duplicate the iPhone interface in excruciating detail.

There's been some complaints about the Android UI. It's true, the emulator isn't groundbreaking. It doesn't have to. It exists solely to provide the functionality developers need to write apps. How many projects do you think are right now in the process of reskining that bad-boy? The iPhone interface is as inevitable as this MS Messenger skin. The shipping UI is irrelevant, it's the flexibility of the SDK to create a new UI that's important.

Despite Scoble not knowing "...a single developer who has had his/her hands on Android" there are more than 4,500 members on the Android developer forums and more than 4,000 messages. Even if only 1% of them come up with a useful mobile application that's still about 30 more useful mobile applications than I've ever come across for Symbian.

The Android phone won't have the iPhone's consumer appeal. It's very true, but it's also entirely beside the point.

Read enough articles and you'd think that if Google doesn't immediately grab 30% of the mobile market at launch they Fail. That's short term thinking. Developers will write applications for Android phones because they literally can't write them for other platforms. One will get you ten that the iPhone SDK won't have nearly the level of phone access that Android provides.

Eventually people will be buying Android phones because the applications they *need* only run on Android phones. Don't believe me? Do you think people run Windows for the pleasure of it? Worst case scenario? Android forces people like Apple and Symbian to offer the same SDK access in order to keep their market. I'll take that and still call Android a net win.

Google's strategy seems to be 'make it open' -- with 'make it popular' a distant second.

People probably won't be lining up around the block on the release day for the first Android mobile but just like Google search and just like GMail, Android is going to change the way we think of mobile phones.

What made the PC so popular? Why has the web taken off? Because *anyone* with the inclination could bring their vision to life at minimal cost. If you've ever tried programming for a mobile phone you'll know it's expensive and difficult -- that's why there's so few *good* mobile phone applications, and very few for free. The Android platform is going to get thousands of developers playing around with new applications for mobiles, in the same way early IBM compatible PCs got thousands of electronics hobbyists interested in programming computers.

Eventually the availability of popular apps on Android phones is going to encourage more phone makers to release Android versions and networks to release Android phones. It costs them nothing in licensing.

People love iPhones, companies love options.

I don't run Windows because I like it, I run it because 75% of the applications I use every day only run under Windows; plus I can write powerful software for myself really easily.

Corporations will start buying Android phones for the same reason almost every company that's not a graphic design house runs Windows -- it's a more universal development environment with deeper access to the underlying hardware. I work for an investment bank, they'd never dream of writing corporate software for the iPhone; do you think the 300 Java developers here might be able create something useful with Android?

Google Android SDK Released

The SDK for Google's mobile phone platform, Android, has been released today.

A series of YouTube videos gives us our first look at what the Android phone OS actually looks like -- and it looks phenomenally cool.

The 'preview' SDK has everything you need to create and test your Android apps, along with an emulator that will let you see what your phone apps will look like when deployed.


The development is done in Java (they suggest Eclipse but it's not required), and Google have provided tight integration with all the phone features (including GPS, phone, camera, ...) as well as Google services like XMPP and Google Maps.

Along with the SDK, documentation, discussion group, and developer blog; Google has also announced a 'Developers Challenge', where the top 50 in development apps share up US$10million in prizes. Shit, there go my weekends for the next 6 months.

I'll post more once I've had a chance to play with the SDK. The power and ease of use of this development environment is going to be a big factor in the future success of any future 'gPhones'. Certainly this free and open approach to phone app development, with total access to the phone's resources, is a giant step away from what's been available up until now.

Using Google Apps with the Google Mashup Editor

The thing I like most about Google's ever expanding lineup of online applications is the corresponding set of programming services. RSS, ATOM, JSON, and Gdata feeds ensure there's plenty of ways to access your data from stored in a Google app. At Hit For Six (source code), three of the tabs are populated with information from a Google data source - Spreadsheets, Calender, and Reader. Here's how to use these feeds as data sources within Google Mashup Editor (GME) to create interactive web applications.

One of the most common mashup tasks is geocoding a location to place a marker on a Google map

One of the coolest new features in the GME is the dynamic geocoder. When your creating a maps mashup it's inevitable that you'll be geocoding a location to put a corresponding marker on a map. The gm:map tag in GME lets you specify 'lat' and 'long' fields in your atom / RSS feed.

gm:map id="liveMap" data="${liveList}" latref="geo:lat" lngref="geo:long"

But what if you only have a named location? Previously you had to handle this manually, either pre-geocoding the location (as I did using Yahoo Pipes), or using JavaScript to handle it client side. The latest release of GME automates this step by supporting a geolocationref parameter that takes a field from your feed and places a marker on your map based on the result from the Google Geocoder.

gm:map id="calendarMap" data="${calendarList}" geolocationref="gd:where/@valueString"

This is perfect for a Google Calendar source where you have a location but not the literal lat/long coordinates; like the 'upcoming fixtures' tab at Hit For Six. The dynamic geocoder is not the same as the Google Maps search bar, and you can't limit its scope. To get the best results you need to include as much location context as possible when passing values (city, state, countryS). Some countries (like India) return locations for certain named locations (like sporting venues) in Maps, but won't work when using the geocoder.

A calendar is useful as a database but the Calendar UI has been designed specifically with appointments in mind

A calendar is a perfect database for time based information. I use Google Calendar to track upcoming book releases, store sporting fixtures, and record timesheets. But the UI is designed with appointments in mind and none of these use cases are appointments. Instead we can use the GME to produce a custom GUI that's right for our data, and the best way to leverage the data stored in a Google Calendar in the GME is using the ATOM feed. You can pass query parameters in to your calendar feed to filter and sort the returned entries.

http://www.google.com/calendar/feeds/radioactiveyak.com_7qt1thddqotp3eic9lud1jelq8@group.calendar.google.com/public/full?futureevents=true&orderby=starttime&sortorder=ascending&max-results=100

Start with a feed that returns only the items we're interested in. Limit by date (show future events only) and cap the maximum results (no more than 100). Then sort (by start time) on the server side. Next create your UI using the GME tags, custom JavaScript, and HTML. In Hit For Six I want to see these events listed and plotted on a map. Using the map tag and the runtime geocoder we can display the calendar entries on a map with a single line of code.

gm:map id="calendarMap" data="${calendarList}" geolocationref="gd:where/@valueString"

It's worth noting that the calendar service is relatively slow, so it's worth the effort to limit the number of returned events to prevent any timeouts. If you're interested in writing data to the calendar as well as reading it, Google's recently released Javascript client might be what you're after.

Publishing your spreadsheets with ATOM lets you create a custom database with an XML feed that updates in real time

I love the idea of using Spreadsheets as an online database. Publishing your Google Spreadsheets lets you specify an arbitrary data source that updates in real time based on spreadsheet changes. Using the ATOM output makes using spreadsheet data in GME pretty painless.

Set up and populate your spreadsheet, select publish and grab the ATOM feed address, make sure you choose 'list feed'.


The default action for entry labels is gsx:columnname, but it's worth pasting your feed into the GME feed browser to confirm. You can set up 'structured queries' to filter your datasource, and it's good practice to do these sorts of filters 'server side'.

A nice trick with spreadsheets is using a 'table of contents' worksheet that provides the feed location of other worksheets that you will use as data sources. In the Hit For Six 'Venues' tab I provide a list of countries which, when selected, populates a country specific ground list based on the corresponding worksheet.

http://spreadsheets.google.com/feeds/list/o01765357489133287312.3601895615788609870/od7/public/values

I can then add new countries and only have to update the spreadsheet, the website will reflect this change automatically.

It's not all beer and skittles

There are a couple of things you need to keep in mind when using Google data feeds rather than 'regular' RSS feeds.

• You can't spoof the feed requests to force frequent updates. Google services require specific feed request parameters (you can't add 'fake' parameters like &random=12354 or &datetime=20071022 to force the GME feed cache to update the data deterministically). That said, the GME team have negotiated a deal with the team that handles the feed caching to provide more frequent updates (in the order of 10mins rather than 6hrs). If that's still not fast enough, you can funnel your feeds through Yahoo Pipes.


• GME expects RSS feeds rather than XML data feeds. RSS feeds tend to add new items rather than modifying or removing existing ones. If you have data that changes often you may want to pipe it through Pipes first. That will let you change the calling string (by adding a random or time based parameter to the feed address) and force GME to refresh it completely.


• It's all open. Note that if you're using Google services as backends you're making that backend public. Once you set it up for your GME application to use, everyone has access to the underlying data. If that's not open enough, your GME code is an open source project by default (and requirement), so nothing's secret.