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 .
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.
height="288"> value="http://www.tripline.net/api/tripviewer.swf" /> /> name="allowFullScreen" value="true" /> name="flashVars" value="tripId=6410741502631003B225FC83C9742523&tripDataUrl=http://www.tripline.net/api/v1/kml/6410741502631003B225FC83C9742523?version=.2&mapsApiKey=ABQIAAAAA9rk3PBVYmwBFaK8U6L2BBSGk6n9_7P4Hc_MSCrbXGvqZu06axRNzkfL-lfkb7tx0GF_c1LVYHgGQg&embed=1" /> src="http://www.tripline.net/api/tripviewer.swf" type="application/x-shockwave-flash" width="512" height="288" allowFullScreen="true" AllowScriptAccess="always" bgcolor="#111111"flashVars="tripId=6410741502631003B225FC83C9742523&tripDataUrl=http://www.tripline.net/api/v1/kml/6410741502631003B225FC83C9742523?version=.2&mapsApiKey=ABQIAAAAA9rk3PBVYmwBFaK8U6L2BBSGk6n9_7P4Hc_MSCrbXGvqZu06axRNzkfL-lfkb7tx0GF_c1LVYHgGQg&embed=1">
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:
Registration for these events are completely free, and space is limited. Reserve your spot now using the following links below!
Bring your laptops, your brains, and we'll see you soon!
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:
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:
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 theexistence 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?).
First, let's go over a few new features for static maps:
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.
Give us feedback in our Product Forums.
Follow