Google Maps Platform: juli 2008

3D Data Representation with the Thematic Mapping Engine

donderdag 24 juli 2008

Posted by Bjørn Sandvik,thematicmapping.org Thematic Mapping Web Interface

Thematic Mapping Engine (TME) lets you create thematic or statistical maps on-the-fly in the web browser. It then returns a KMZ file which you can view directly with the Google Earth browser plugin, or you can download to view in the regular Google Earth.TME supports various thematic mapping techniques like choropleth maps, proportional symbol maps and animated maps. The goal of this project has been to explore the pros and cons of doing thematic mapping with KML. You can read about the various techniques on the thematic mapping blog The Thematic Mapping Engine is also a good example of what you can achieve with open source tools and datasets in the public domain:

A world border dataset is loaded into a MySQL database. The same database contains tables with statistics from UNdata.

A PHP script generates KML by querying the database and adding styles according to the parameters given by the user.

Map legends are generated on-the-fly using the GD graphics library.

All files are zipped into one KMZ file which is stored on the web server. A link to the file is returned to the user.

The user interface is build with Ext JS and AJAX techniques.

So far, you can only create thematic maps with statistics from UNdata (http://data.un.org). The possibility to add your own data will be supported in a future release.Two examples (all statistics from UNdata):Infant mortality rate in 2005 visualized as a prism map (extruded polygons). Mobile phone subscribers in 2004 visualised with proportional 3D objects (mobile phone model downloaded from 3D Warehouse).

Improvements to Ads in the Maps API

maandag 21 juli 2008

Posted by Jim Payne and Brandon Badger, Maps API TeamOur Maps API team strives each day to develop features to help developers build the next generation of great maps mashups. One of the requests that we've received from our developer community is to build features that will help convert map traffic into revenue for their site. To that end, we've been working hard on improving the program that allows Maps API sites to choose to display Local Business Ads on their map as part of the AdSense for Content program. As with all Google ads products, we feel that success depends on providing ads that actually improve the user experience, while at the same time allowing businesses to reach their target audience. Although we've had an ads program in the API for some time, this week, we are pleased to announce some key improvements to that system:

An improved user and advertiser experience. Ads now display "flat on the map," and we've introduced new more informative category icons. We've also built a system to "nudge" ads so they do not obscure key elements on the map. Check out an example of the new look and feel.

Improved coverage. We introduced GAdsManager last year, but didn't show many ads. Now, our coverage is much improved without impacting relevance. We also now show ads for all countries where the Local Business Ad format is supported. (For your ad to show up on API sites, you need to opt-in to the "Content Network.")

Continuous ad serving. You may have noticed that ads would not be refreshed when users panned the map, so your highly interactive Maps API site wouldn't be able to take advantage of the program. We've changed this. Ads are now loaded whenever the user moves the viewport to a new location.

We hope that these improvements will help you generate some revenue from your Maps API site and continue to make it better.You can read more details about these changes on the Maps API Developer Forum or sign up for an AdSense account to get started.NOTE: To be clear, this program has always been and remains completely opt-in for API users. You are under no obligation to display ads in order to use the Maps API. For more details see the Maps API Terms of Service.

Wacky Wednesday: Change the background color of your map!

woensdag 16 juli 2008

Posted by Pamela Fox, Maps API TeamSometimes, we fulfill feature requests that we never realized we had, and then wonder why it took us so long to discover that hidden desire in our heart. GMapOptions.backgroundColor, introduced in 2.119, is one of those features. It's never been asked for and it's a trivial code change, but it's damn nifty. By setting it, you can change the background color of the tiles that appears before tiles load, and on the north/south edges of the world at the low zoom levels. You can use it to make your map blend into the rest of the page, make your tiles blend in better when loading, or just to be obnoxious (hot pink tiles, anyone?).The example below shows setting both the backgroundColor of the map and the page to our beautiful ocean blue. If that piques your interest, check out this demo that lets you try out any color with any of our default map types (like #000000 with G_SKY_MAP_TYPES).<br /><a href="http://gmaps-samples.googlecode.com/svn/trunk/backgroundcolor/bgcolor_sea.html">Link to ocean background color map</a><br />

Spreadsheet gadgets: free dynamic data for your maps

donderdag 10 juli 2008

It's reading data from a simple spreadsheet and displaying it here. Any changes a collaborator makes to the underlying spreadsheet will be reflected on this page. So what's new about this approach? Spreadsheet gadgets can be embedded directly in spreadsheets, like the heat map in this sheet, or even on on their own sheet. And spreadsheet gadgets can be accessed from within Google Docs Spreadsheet's built-in gadget picker, so they're very easy for everyday folk to discover and use.

For more info, check out our post on the Google Gadgets API blog.

Posted by Justin Kosslyn, Google Spreadsheet TeamIn the past, Pamela's blogged about ways to create map mashups out of published spreadsheets using the Spreadsheets GData API. Well now we have a more integrated approach using spreadsheets gadgets. For the uninitiated, here's a spreadsheet gadget I'm using to plan my road trip:It's reading data from a simple spreadsheet and displaying it here. Any changes a collaborator makes to the underlying spreadsheet will be reflected on this page. So what's new about this approach? Spreadsheet gadgets can be embedded directly in spreadsheets, like the heat map in this sheet, or even on on their own sheet. And spreadsheet gadgets can be accessed from within Google Docs Spreadsheet's built-in gadget picker, so they're very easy for everyday folk to discover and use.For more info, check out our post on the Google Gadgets API blog.

Using Static Maps and HTTP Geocoding to Location-enable Lonely Planet Mobile

dinsdag 8 juli 2008

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?).

How to write KML like a rock star

donderdag 3 juli 2008

Sudjam, LLCNine Inch Nailsthe slip

GeoIP®Jason Birch's blog <Placemark>
<description>17875 downloads.</description>
<styleUrl>#base</styleUrl>
<MultiGeometry>
<Point>
<coordinates>-118.2,34.0,0</coordinates>
</Point>
<Polygon>
<extrude>1</extrude>
<altitudeMode>relativeToGround</altitudeMode>
<outerBoundaryIs>
<LinearRing>
<coordinates>
-118.1,34.1,12512500
-118.3,34.1,12512500
-118.3,33.9,12512500
-118.1,33.9,12512500
-118.1,34.1,12512500
</coordinates>
</LinearRing>
</outerBoundaryIs>
</Polygon>
</MultiGeometry>
</Placemark><ScreenOverlay>NIN websiteperformance pageKML file<NetworkLink>Trent ReznorTopspin MediaPosted by Michael Weiss-Malik, Nine Inch Nails fan

5 Ways to Use Static Maps, Plus New Features!

dinsdag 1 juli 2008

Posted by Pamela Fox, Maps API TeamFirst, 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.

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

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)

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.)

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

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).