We've had several new feature announcements for the Google Maps API in the last few months, including high resolution static maps, the new Street View Image API, and the use of high DPI map tiles in the JS Maps API on mobile devices. I'm here to give you some tips for using these new features to improve your existing mobile JS map app .

1. Upgrade Your App to Use the v3 API
   If you're still using the v2 Google Maps API it's time to change that. Period. This is one of the best improvements you can make to your map app. The v3 Google Maps API was designed for the mobile web and it is significantly faster than its predecessor. Not only is the v3 Google Maps API designed to load fast on mobile browsers, but your app will be upgraded immediately because your map will automatically access high DPI map tiles, which have better on screen fidelity.

2. Use the Static Maps API to Improve User Experience
   Check your Google Analytics data (or server logs ) to see if your app is being accessed by devices with browsers that can't or don't fully support JavaScript. You can add logic to your app (e.g, server-side user agent checking) to determine whether you should serve your JS Maps API-based app or a static map image that shows the same or similar information. Although your users won't be able to interact with the map, they'll appreciate the ability to view the map. You can even add markers and other features to the static map . You'll also be able to take advantage of the high resolution Static Maps API.

3. Use StreetView Images to Provide More Context
   Chances are your map app gives users access to all kinds of information, whether it's your own data and images or our very own Places API. Give your users some additional context by using the Street View Image API to provide a general idea of what a location looks like at street level. When you provide a location in your URL request, the API will snap to the panorama photographed closest to that particular location.

4. Use the JS Maps API Only When It Makes Sense
   If all you need is a small map for context, you should be using the Static Maps API. This may seem obvious, but we've come across a few mobile apps that seem to use the JS Maps API to provide nothing more than a thumbnail. Use the Static Maps API to load a small image and, if needed, link that thumbnail to open up a larger map (whether your own page that uses the JS Maps API or maps.google.com).
   

And again, if you're still using the deprecated v2 Google Maps API in any of your apps (mobile or otherwise), it's time to migrate your app to the v3 Google Maps API, as we're more than halfway through the three year deprecation period.

Posted by Andrés Ferraté, Developer Relations, Google Maps API

We’ve just launched Tripline (http://www.tripline.net), and we’re excited to talk about how we’re using Google Maps. We’ve been laboring for months in solitude, so it feels great to finally talk about what we’ve built.

Tripline is all about maps. The Tripline concept goes back to 2005 when I started manually creating map-based plans to visualize upcoming trips. I’m one of those people who can stare at the moving map on an airplane for the duration of a long flight, so my desire to understand travel from a geographical viewpoint is inherent, and I think quite common. And, as we so often see in movies, a moving line on a map is a great way to tell a story.

The Tripline Player uses the Google Maps API for Flash and animates progression from point to point using a simplified KML-like data structure. We chose Flash primarily because it was the best platform to combine the maps, animation, and soundtrack elements that were part of the design. It also means that trips are shareable, as you can see from the example embedded above. We chose the terrain view because we think it best conveys the feeling of an adventurous journey. One of my favorite things to do is to press play, enter full screen mode and just sit back and watch a story unfold. The Google Maps API for Flash helps make that experience smooth and beautiful. It’s essential to our product.

The player represents the end-product of a created trip, but what about the creation process itself? Our goal was to make trip-creation as simple and flexible as typing a bullet list, and we spent a lot of time working towards that goal. We’re using many different Maps API components in our trip editor, including geodesic polylines, custom markers and custom infowindows. To add places, we’re using the Google AJAX Search API and the Geocoder API, and for trip thumbnails, we’re using the Google Static Maps API.

Speed and reliability are also essential. Users will forgive a lack of features and even bad design, but if your application is slow, you’re dead. The Google Maps APIs are always on and always fast, which is something that very few services can guarantee. That's one of the key reasons why we use Google services to support the core capabilities of our product. We’ve been live now for just under a month, and it’s been smooth sailing. We’re also hard at work on our next release, so stay tuned for more. Thanks Google.

Posted by Byron Dumbrill, Founder & CEO, Tripline

We're really excited to announce two upcoming hackathons for our Google Geo APIs. The first will be held in New York City on November 20th followed by a second one in Mountain View on December 15th. This will be a great learning opportunity for any developer interested or currently involved in building Geo-enabled applications using our APIs. Come join us for a great session where you'll be able to hack away on your own projects alongside our engineers who'll be readily available to provide support. Below is a list of the various Google Geo APIs you'll learn about:

• Google Maps API
• Google Maps API V3
• Google Maps API for Flash
• Google Maps Data API
• Google Earth API
• KML

Registration for these events are completely free, and space is limited. Reserve your spot now using the following links below!

• November 20th @ New York, NY
• December 15th @ Mountain View, CA

Bring your laptops, your brains, and we'll see you soon!

Posted by Pamela Fox, Maps API Team

So, it appears that a few thousand of you developers were sending our static map server requests with "&maptype=satellite" in them. Why would you do that? Did you think that we'd see all the requests and just decide to start returning satellite imagery to you? Well, fine. You were right. Here you go:

http://maps.google.com/staticmap?center=27.87515,86.871815&zoom=10&size=500x100&maptype=satellite
(Mount Everest looks significantly more interesting from satellite view than map view; I hear it's hard to build roads there.)

And just to anticipate those of you who are thinking to yourself about what a mighty fine plan that was, and how you're going to start sending "&maptype=hybrid" and "&maptype=terrain", here, have those map types too:

http://maps.google.com/staticmap?center=27.87515,86.871815&zoom=10&size=500x100&maptype=hybrid

http://maps.google.com/staticmap?center=27.87515,86.871815&zoom=10&size=500x100&maptype=terrain

Okay? Happy now?? Statistically, many developers should be — since "add other map types" has been our top starred static maps feature request in the public issue tracker since the launch of the Static Maps API.

So check out the documentation and start using the new map types for your thumbnail maps, mobile maps, or any of the other reasons we mentioned in our last static maps post. You can also check out the other goodies in this release in the Static Maps API changelog. Enjoy, and let us know in the forum if you have any questions (or just nifty examples to share with us).

We at Lonely Planet are thrilled to share some experiences from our latest project, http://m.lonelyplanet.com, a location-based world travel guide for mobile devices enabled by mashing the Google Static Maps API, the Google HTTP geocoder, and our new Content API. We’ve been publishing travel content for decades, (in case you’re not familiar, we’re the guides with blue spines in your local bookshop), but we’re excited because this is the first time we’ve been able to deliver our information in a mobile and spatially relevant way, allowing us to ask questions like “what should I explore today?” and “what’s around me worth exploring?”

Of course, to answer these questions, we need to know the lat/lng of both our user and the points of interest (POIs) around them. POIs aren't a problem, as our authors plot these on a map during their on-the-ground research. User locations are trickier. As our mobile site is a browser-based service, we don't (yet!) have the luxury of APIs for grabbing precise locations via GPS, wifi, or cell tower triangulation.

So, for the moment we’ve asked our users to self-select their location by entering it into a form field. Because typing on typical mobile keypad is painful, we wanted to save thumbs and offload parsing to a geocoder which could deal with the ambiguity of short location descriptions, various zip/post code formats etc. Enter Google's geocoder (HTTP flavour – no JavaScript available on most mobile browsers!). We can proxy this API from our server and allow users to enter a wide variety of location descriptors, from zip codes (90210) to tube stations (holborn) to street names (oxford street) to suburbs (footscray) and the geocoder will decipher it, geocode it, and return either a lat/lng or a list of options for disambiguation.

Once we know the user's lat/lng, we can assess which content is most spatially relevant to them by calculating proximity to POIs in our database. To this end, we use the POI proximity method from our Content API, in which we pass in the user's location and a radius in kilometers, returning POIs within range in their order to proximity. This service uses the Haversine formula, a tip we picked up from Pamela a couple of months ago.

Once we’ve got the POIs, the next step is plotting them (and the user’s location) on a map. Since ours is an application for a baseline of devices with limited capabilities, we don't have the luxury of Flash, AJAX, or JavaScript. Enter the Google Static Maps API. By passing in our geocodes, a set of parameters for labeling markers, and a map height / width (calculated per device by querying screen sizes from WURFL) the Static Maps API produces for us an image displaying a marker for the user's location and for each of the POIs.

To help our users explore further, we augmented the map with a lightweight navigation bar (north, south, east, west, zoom in, zoom out) so that users can pan around the map to surrounding areas. This little navigation bar uses a bit of code we thought we’d share:

Let's say we have a static map of width w pixels, height h pixels, centered at (lat,lng) and zoom level z.

$map_link = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}¢er={$lat},{$lng}&zoom={$z}";

Then, we can generate north, south, east, and west 'panning' links as follows (this example assumes the existence of a mercator projection class with standard xToLng, yToLat, latToY, lngToX routines):

// a mercator object
$mercator = new mercator();

// we'll pan 1/2 the map height / width in each go
 
// y coordinate of center lat
$y = $mercator->latToY($lat);

// subtract (north) or add (south) half the height, then turn back into a latitude
$north = $mercator->yToLat($y - $h/2, $z);
$south = $mercator->yToLat($y + $h/2, $z);

// x coordinate of center lng
$x = $mercator->lngToX($lng);

// subtract (west) or add (east) half the width, then turn back into a longitude
$east = $mercator->xToLng($x + $w/2, $z);
$west = $mercator->xToLng($x - $w/2, $z);

So that our north, south, east, west links are:

$north = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}¢er={$north},{$lng}&zoom={$z}";
$south = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}¢er={$south},{$lng}&zoom={$z}";
$east = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}¢er={$lat},{$east}&zoom={$z}";
$west = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}¢er={$lat},{$west}&zoom={$z}";

To see the site in action, go to http://m.lonelyplanet.com in your mobile browser, select the "What's around me?" feature and enter your location or a place you're planning to travel. Make sure to send us feedback - as this is our first location-based service there are plenty of things we're learning as we go. At the moment we're experimenting with additional ways of enhancing the accuracy of the user's location - like everyone else, we're excited about the location capabilities available on the Nokia, Android and iPhone platforms and are thinking through services which could make best use of those.

As you've seen from this post, our mobile site is really just a mash-up of our own Lonely Planet Content API and the Google geo API's. The Content API is available through our newly launched developer program, so if you head over to developer.lonelyplanet.com and join our developer community, you can build the site yourself! The only thing we ask (actually, 2 things) is that you remain non-commercial and that you don’t openly compete with us. So, sign up! We’d love to see what you can create using our content, Google’s geo services, and any other API you choose (YouTube? Flickr? Twitter? Others?).

Ken Hoetmer – Digital Mapping Manager
Chris Boden - Head of Wireless & Innovation
Kris Nyunt – Senior Engineer, Wireless & Innovation
Follow us on Twitter @ lplabs

Posted by Pamela Fox, Maps API Team

First, let's go over a few new features for static maps:

• We support larger maps, up to 640X640 pixels.
• We use a more compact Google logo for maps less than 100 pixels wide.
• We support the ability to specify a map viewport by sending in a span and center (instead of zoom and center).

More info in the documentation.

Now, for the good stuff. I've just spent the last 3 hours surfing the web, looking for example sites using our Static Maps API, and I'll admit that I had no idea developers were using static maps in so many different ways. Below, I've summarized the various techniques and linked to example sites for each. I urge you to 1) visit each of them, and 2) decide your favorite technique and implement it on your own site.

1. Include a static map on the page, go to a large interactive map when clicked. This is a good technique for those of you who'd like to cater to map-centric users versus text-centric users.
   
   Example sites: Booking.com (pictured above), TripAdvisor, OpenRice, Qype, HotelTravel, and ADN



2. Include a static map on the page, and replace that with an interactive map after some user interaction. This is a good technique if you'd like interactive maps on every page, but are worried about them making the page load too slowly for users on a slow connection.
   
   Example sites: Yelp, GumTree, and Geocaching (pictured above - For a good laugh, check out the difference between their map when you're logged in versus when you're not)
   



3. Include a static map on the page that's centered on the geographical region that a page is about. This is a good technique if you just want a quick reference map for the user, and if you don't have multiple points to display.
   
   Example sites: Wedding Mapper Venues (pictured above), Adriagate, citybeat, and Opt.be (this one links to a maps.google.com URL for the displayed location, which is a good variation on this technique and should be minimal extra work for the developer.)



4. Use static maps inside a gadget. This is a great technique for all gadgets, since often times users will have multiple gadgets on the same page (on iGoogle or their own sites). Each gadget should ideally take as little time as possible to load, so that the parent page loads quickly.
   Example Sites: Geo IP Locator Gadget (pictured above), and Google Map Search Gadget



5. Use static maps for mobile implementations of map sites. This is a no-brainer, as Javascript isn't supported across most/all mobile browsers (and loading all the interactive map resources can be a bit much over a mobile connection).
   Example Sites: Mobile YellowBot, Mobile Lonely Planet (pictured above), OrbitzTLC Traveler Update, and Non-JS Local Search (this demo is running on Google App Engine, using code written by a Googler and open sourced here).