By far the most popular request from developers since the day we launched has been access to the Google Reviews offered on Google+ Local. We’re therefore delighted to announce that the top 5 Google Reviews for a Place are now included in the response to a Place Details request. Each review is accompanied by additional information such as the scores given by the author, author details, and the date that the review was submitted.

Today we are introducing Text Search, a whole new way of searching that broadens the scope of the Places API to any device that can accept text input, be it from a keyboard or from voice recognition.

Text Search brings the flexible capabilities of the Google Maps search field to your application. Rather than requiring the user’s location to search around, Text Search interprets free text queries that can include both what the user is searching for, and where they are searching for it. For example, you can submit a search for “Pizza in New York”, or “Sushi near Sydney”. You can also bias queries to a particular area, so that even queries with no address component can be correctly interpreted.

Another popular request from developers has been access to the opening hours for businesses. The Place API now returns the 7 day opening hours for a Place in the Place Details results where available. Place Search results also now include a property that indicates if a Place for which opening hours are available is currently open.

Today we are also introducing support for paging, which increases the number of search results that can be retrieved to 60. Applications can now request two additional sets of 20 results after the initial request has been made.

• You can now specify a precise color for features as an RGB value in addition to the existing adjustment filters for hue, saturation, lightness, and gamma.
• You can now style the outline stroke of features separately from the interior fill, and the label text separately from any icon.
• You can now adjust the width of line features such as roads and rivers, and also the width of feature outlines.

At SXSW Interactive in 2011, I attended a session on geotemporal data visualization that made me keen to make it easier for Maps API developers to build visualizations similar to those discussed. For this reason I’m particularly excited to introduce a simple, yet powerful, new concept to the Maps API v3 that we call Symbols.

Unlike the image icons currently used for marking locations on a map, a Symbol is defined as a vector shape. The size, stroke width, color, and opacity of the shape, are all set by the Maps API application and can be dynamically modified. A small number of shapes, such as a circle, are provided by the Maps API, and custom shapes can be expressed as an SVG path.

Symbols open up a wide range of compelling new possibilities for data visualization and visual effects. For example, the below map illustrates the expansion of the Walmart chain of stores between 1962 and 2006:



In addition to using symbols to represent point features you can also decorate polylines with Symbols. One or more symbols, such as an arrowhead, can be placed at fixed positions on the polyline or repeated along the polyline. Because the polyline that has been decorated does not need to be visible, this feature can also be used to created dotted or dashed polylines, and just as the style of the symbols can be dynamically modified, so too can their location on the polyline:

Developers often ask how they can represent large amounts of data on a map. Improvements in web browser technology have increased the number of markers that can be rendered by a Maps API application, but above a certain threshold the density of markers can overwhelm the user.

An alternative approach is to use a heatmap, and to enable this approach we’re launching support for browser rendering of heatmaps by the Maps API using the new Heatmap Layer. Your Maps API application can define the colour spectrum, intensity range, and behaviour of the heatmap when the map is zoomed. Here’s the Walmart example from above, but this time visualized as a heatmap:

• Changes to pricing. While the Maps API remains free for the vast majority of sites, some developers were worried about the potential costs. In response, we have lowered the online price from US $4 per 1,000 map loads to 50¢ per 1,000 map loads.

• Simplified limits. We’re eliminating the previous distinction between Styled Maps and regular unstyled maps. The same usage limits and pricing now apply to applications using Styled Maps and the default Google Maps style.

• To monitor whether your site might be affected by the Maps API usage limits, use a Google APIs Console key with your applications. Daily usage reports will then be generated in the console.

• If you are a high-trafficked site, please consider Google Maps API for Business, our enterprise offering with technical support, a service level agreement, and additional benefits.

• Non-profit organisations aren’t affected by the Maps API usage limits and can also apply for a free Maps API for Business license through the Google Earth Outreach grants program.

• You can generate revenue from your Maps API application using AdSense for Maps, which enables you to display relevant ads on or alongside your map.

When searching for business it’s often the case that you have very fine grained requirements. You don’t just want a restaurant, you want a Mexican restaurant. You don’t just want a clothes shop, you want a vintage clothes shop. You don’t just a want a bar, you want a bar that offers live music.

The Google Places API offers filtering over 100 different types, including restaurant, clothing_store, and bar. As rich as this type scheme is, it can not cover the infinite range of fine grained requirements that you or your users might have.

For these situations the Places API now offers keyword search, which searches places based on an arbitrary text string. Results are matched against all the information that Google has about a business, including country specific categories, cuisine, and Google review content.

Keyword searches can also be combined with type filters. For example, you could add a type filter of ‘bar’ to a keyword search for ‘wine’ to ensure your search results include only drinking establishments, and not wine merchants.

By default, the Google Places API orders the search results it returns using the same ranking algorithm as Google Maps, which prioritises places that are popular or prominent. This is great for local discovery and check-in apps, as these are the places likely to be the most interesting or relevant. However for certain types of search, such as gas stations or atms, the closest result is usually preferable.

To help with these use case the Places API can now rank results strictly by distance. In order to rank results by distance you must use some form of query or filter on the search. This can be a name filter, a type filter, or a keyword search. When results are ranked by distance it is not necessary to provide a search radius as the Places API will try to return the 20 closest results within reasonable distance.

We understand that many web sites know that all of their users are located in a single country. For example if a U.S. based online retailer ships only to U.S. addresses, there is no need for Autocomplete to offer completions for addresses outside of the U.S. We have therefore launched country filtering, which allows you to constrain the completions to a specific country.

We also recognise that many applications prompt users to enter a location that is not as fine grained as an exact street address. I you are booking a hotel or browsing for real estate you are often prompted to enter the city or zipcode you are interested in. To address this need we have introduced additional type filters that allow you to limit completions to only cities, or to only coarse grained features such as zipcodes, states, and countries.

• There are certain Maps API Services, such as Places and Street View, which you are permitted to use without a Google Map. This update clarifies that if you do choose to use a map with these services it must be a Google Map.
• This update clarifies that business, residential address, or telephone directory listings services may continue to use the Maps API, but may not use business listings content provided by the Maps API or the Places API.
• This update clarifies that you are not permitted to use or provide any content provided by the Maps API in an API that you offer to others, even if your implementation provides substantial additional features or content.
• This update adds additional terms to protect the privacy of geolocation data and requires that you obtain the consent of your users to geolocate their position and notify them of how that information will be used.

• population
• age
• race
• marital status
• housing status

The map updates we are rolling out today include a number of improvements, such as more accurate water bodies, and more comprehensive parks coverage. The “Report a Problem” tool allows Google Maps users, and Maps API developers, to notify Google of errors in our map data, with email notification when their error reports have been resolved. For more information, see our announcement on the Google LatLong blog.

As with previous map data updates, it’s important that any data you have cached for these countries that was obtained using a Maps API service such as the Geocoding API be refreshed following this update. Periodical refreshing of cached data will also ensure that you benefit from any updates and corrections that are applied in future. If you have any questions or concerns, please consult the relevant Maps API forum.

Posted by Thor Mitchell, Product Manager, Google Maps API

• Update your site to use the Maps API more efficiently, reducing your usage to below the limits
• Contact the Maps API Premier sales team to discuss licensing options
• Enable billing on your APIs Console Project

• Reduce your usage to below the limits
• Opt-in to paying for your excess usage at the rates given in the FAQ
• Purchase a Maps API Premier license

Switch to googleapis.com

Faster reflection of MapMaker edits

Map coverage of Israel

Street View preview

Animated transitions between 45 degree headings

High DPI map tiles on mobile devices

However use of the Maps API for Flash remains a small percentage of overall Maps API traffic, with only a limited number of applications taking advantage of features unique to the Maps API for Flash. In addition, the performance and consistency of browser JavaScript implementations has progressed, making the JavaScript Maps API an increasingly suitable alternative.

Consequently we have decided to deprecate the Maps API for Flash in order to focus our attention on the JavaScript Maps API v3 going forward. This means that although Maps API for Flash applications will continue to function in accordance with the deprecation policy given in the Maps API Terms of Service, no new features will be developed, and only critical bugs, regressions, and security issues will be fixed. We will continue to provide support to existing Google Maps API Premier customers using the Maps API for Flash, but will wind down Developer Relations involvement in the Maps API for Flash forum.

We understand that this decision will be disappointing for Maps API for Flash developers. We hope you will consider migrating your applications to the Maps API v3, which offers many additional benefits such as Street View, Fusion Tables integration, Places search, and full support for mobile browsers. Our Developer Relations team and many skilled members of the JavaScript Maps API community are available to assist you in doing so on the Google Maps JavaScript API v3 forum.

Google remains supportive of Flash as a development platform for Rich Internet Applications for Chrome, Android, and other devices. However by consolidating our development on the Maps API v3 we can focus all of our resources on delivering great new Maps API features for the benefit of as many developers as possible.

Posted by Thor Mitchell, Product Manager, Google Maps API

For this reason, we're introducing a new feature of the Static Maps API that smoothly doubles the size of the whole image including labels, icons, and overlays, to suit high resolution screens. To apply this upscaling to an existing Static Maps API image, simply append &scale=2 to the URL.

The image returned will contain the same level of detail, but be twice as wide and tall without the stepping or blurring that results from upscaling an existing image:

scale=1 (default)	scale=2

Note that when using the scale parameter the pixel size of the returned image is the product of the size and scale values given in the URL. The size parameter therefore now specifies the size of the required image in Density-independent pixels or Points, as they are known in the Android SDK and iOS SDK respectively.

Web based apps can also benefit from higher resolution Static Maps by adding a scale=2 image to the page with a CSS width and height that matches the size parameter. By default, the browser on many mobile devices upscales images in web pages by a device specific factor based on the pixel density of the screen. However these devices will preserve additional detail in the image if the image pixel : CSS pixel ratio matches or exceeds the scaling factor, which can be found by querying window.devicePixelRatio in JavaScript.

For example, below are the above two maps side-by-side with the same CSS size. On a desktop screen with a window.devicePixelRatio of 1.0 these will look almost indistinguishable. However open this blog post on a device with a high resolution screen, such as a Samsung Nexus S or Apple iPhone 4, and the image on the right will look significantly sharper.

scale=1	scale=2

As an added benefit, Maps API Premier developers can also request maps with a scale factor of 4. Although this exceeds the maximum window.devicePixelRatio of current mobile devices it does facilitate generating maps for printing at high quality:

scale=4

Note however that the largest image pixel size that the Static Maps API can generate for Premier customers, regardless of the value of the scale parameter, is 2048x2048. Consequently at scale=4 the largest available value for the size parameter is 512x512. Note also that any use of the Static Maps API for generating maps to print must comply with the Permission Guidelines for Google Maps and Earth, which apply equally to Maps API Premier customers.

For more information on the scale parameter, and the other great Static Maps features, check out the Static Maps API documentation. We hope this feature helps your apps enjoy the full benefit of the high resolution screens that are increasingly popular, and makes them just that little bit easier on the eye!

Posted by Thor Mitchell, Product Manager, Google Maps API

At Google I/O this year we began integrating access to business information into the Maps API v3 with the launch of the places library, which adds Places Search and Autocomplete. As part of our ongoing effort to extend this integration, deliver a detailed and complete map, and offer a consistent user experience between Google Maps and the Maps API, we will shortly be adding these clickable business icons to the Maps API v3 as well.

If your application does not specify a specific version of the Maps API to load these icons will appear on the map by default from early next week, unless you are a Maps API Premier customer. The business icons will be classified with the poi.business Styled Maps feature type. If you would prefer that your Maps API application not include these icons, you can remove them ahead of next week’s release by setting visibility:off on the labels element of poi.business for your map. Maps API Premier customers who would like their maps to include these icons can enable them today by setting visibility:on.

You can preview these icons, and the InfoWindow that is shown when they are clicked, on the map below:

In order to allow you to control visibility of these icons, and other features, across all the default map types, you can also now specify styles for your map in MapOptions. This enables you to selectively restyle roads, labels, and other features on Hybrid and Terrain maps in addition to Road Maps. Note however that the base satellite imagery (for Satellite and Hybrid maps) and base relief imagery (for Terrain maps) cannot be restyled.

For more information on setting map styles across map types, please see our updated Map Styling documentation. The Styled Maps Wizard has also been updated to apply styles across all maptypes. As always, if you need assistance applying styles to your Maps, or have any other Maps API questions, we recommend you post your questions to the Maps API v3 Forum.

Posted by Thor Mitchell, Product Manager, Google Maps API

Following the introduction of the Places API at Google I/O last year, we worked with developers in a limited preview to understand what was needed to ensure the Places API is as powerful and easy to use as possible. In the “Connecting People with Places” session at this year’s I/O I was very happy to announce that having implemented the feedback we received during the preview, the API is now accessible to all:

The Places API is provided in two ways, a set of XML and JSON web services, and a set of corresponding classes in the Maps API v3.

The web services are ideal for mobile app developers, and can be queried from the developer’s own infrastructure, or directly from the app running on the smartphone. The Places API Search service focuses on location-based search, delivering up 20 Places in the vicinity of a user’s location. Search results can be filtered by Place name, or by one of over 90 categories, such as ‘restaurant’, ‘night_club’ or ‘spa’. The Places API Autocomplete service focuses on text based search, providing autocompletions of Places near the user as they type.

The Places API Report services also allows apps to submit new Places provided by users, which are instantly added to subsequent search results, and also delete them at a later date if required. Apps that allow users to identify the Place they are in at the time can also pass this “check-in” signal back to the Places API Check-in service which factors this real time popularity signal into the ranking of subsequent searches, so that the Places popular with users of the app are ranked higher in real time.

The Engineering Lead for the Places API, Marcelo Camelo, dove into how to get started with the Places API web services, and the structure of requests and responses in the “Location Based App Development using Google APIs” session:

For web based applications the Places API has also been integrated into the JavaScript Maps API v3. The PlacesService class provides access to Places API Search directly from the web based Maps applications, while the Autocomplete class enables a HTML text field to predict autocompletions of Places as the user types:

To use the Places API classes in your Maps API applications you simply need to request the new places library when you load the API into your web page. To use the web services, you must first create a new project in the Google APIs Console, and then enable the Places API on that project. You can then use the APIs Console key for that Project to access the Places API.

Initially your key will offer courtesy quota of 1,000 requests per day. Once you are ready to launch the next great location based app, simply “Enable billing” on the project. You will be prompted to provide credit card details, in order to verify your identity. Once you have done so, your quota will increase to 100,000 requests per day, but the API will remain free to use. Note that you may be charged if you use the same key for other APIs, which you can avoid by creating a separate project for accessing other APIs.

For more information on how to use the Places API, check out the documentation for the Search and Autocomplete web services and Maps API v3 places library. You can also discuss the API with other developers on the Google Maps API Web Services forum, and request additional features you would like to see the API offer, or report any problems you find, using the Places API section of the Google Maps API Issue Tracker.

Our launch at Google I/O this year was just the beginning of the Google Places API story. We are looking forward to bringing you many more features in the future to help you build more innovative and compelling location based applications. So do get started developing your apps, but keep an eye on this blog for more to come!

Posted by Thor Mitchell, Product Manager, Google Maps and Places APIs

As with previous updates in countries such as the U.S.A., Australia, and parts of Europe, this update utilizes a wide range of authoritative sources such as the Institut Geographique National. In addition, the "Report a Problem" tool on Google Maps allows you to let us know if some aspect of the map that needs correcting, and we'll do our best to address it quickly (often within just a few days).

These map updates will roll out over the next 24 hours across all our Maps APIs and related services. As with previous updates we do ask that you refresh any data that you have previously obtained for these countries using Maps API Web Services, and cached for use in your Maps API application. If you have any questions or concerns relating to this, please post them to the Google Maps API forums.

Posted by Thor Mitchell, Product Manager, Google Maps API

At Google I/O this week, Simon Rogers of the Guardian joined me and Kathryn Hurley of the Geo Developer Relations team to present some examples of how the Guardian uses Fusion Tables to visualise data for their readers, and introduce some great new features:

Fusion Tables allows you to share large tables of spatial data and render them on a map in a way that performs consistently well across all browsers, on desktop and mobile. The way in which the data is styled on the map, the markers used for points, the colours and stroke widths used for polylines and polygons, can be defined by the owner of the table in the Fusion Tables application, or using the new Fusion Tables Styling and InfoWindows API. However only the owner of the table can define the styling in this way, and styling for any single table is fixed.

At Google I/O we introduced Dynamic Styling of Fusion Tables layers. This allows the styling rules used for displaying a table in a Maps API application to be defined from JavaScript, and changed dynamically. For example you can use this to switch between rendering different data sets in the same table, or giving users control over which subset of the data is highlighted, as in the below example based on a public table of Chicago Homicides data:

In order to ensure the continued reliability of the Fusion Tables layer, we are also introducing some limits on the number of layers that can be used, and the complexity of styling. The Maps API now permits up to five Fusion Tables layers to be added to a map, one of which can be styled with up to five styling rules.

For information and code samples of how to apply dynamic styling to Fusion Tables, see our documentation, and for further assistance I recommend the Google Maps JavaScript API V3 forum. It’s great to see the creative ways in which Fusion Tables Layer is being used, and we hope this new flexibility will drive even more inspiring and informative Maps API applications.

Posted by James McGill, Software Engineer, Google Maps API team

This represents the culmination of the Developer Preview launched last year, shortly after we introduced the Places API at Google I/O 2010. Interest in the Preview was overwhelming and we have been amazed by the innovative use cases suggested for the API. The developers we worked with provided a great deal of extremely valuable feedback on all aspects of the API, including features, performance, usability, and terms of use.

We’ve been working hard to implement the recommendations we received during the Preview. As a result the service launching today includes many new features, most of which are a direct result of this developer feedback:

• A globally consistent type scheme for Places, spanning more than 100 types such as bar, restaurant, and lodging
• Name and type based query support
• A significantly simpler key based authentication scheme
• Global coverage across every country covered by Google Maps
• Google APIs Console integration, which provides group ownership of projects, key management, and usage monitoring
• Instant reflection of new Places submitted by an app in subsequent searches made by that app, with new Places shared with all apps after moderation
• Real time reranking of search results based on current check-in activity, so that Places that are currently popular are automatically ranked higher in searches by your app

In addition to these changes we’re also adding a companion Autocomplete service to the Places API, which predicts the Places a user might be looking for as they type. This service is based on the same technology that powers the search field on the Google Maps website, and can dramatically reduce the amount of typing needed when searching for a known place by name, which is particularly valuable on mobile devices.

Both the Places API Search service and the Places API Autocomplete service are offered as XML/JSON REST based web services. These APIs are currently both in Google Code Labs, which means they are not yet included in Maps API Premier. However we are working to graduate the APIs from Code Labs in the near future, at which point the service will also be offered to Maps API Premier developers.

To get started, please follow the instructions in the documentation for obtaining an APIs console key, and enabling the Places API on that key. If you have joined us at Google I/O this year, come along to our session on "Building Location Based apps using Google APIs" at 3pm on Wednesday, in which our Tech Lead, Marcelo Camelo, will be diving into the API in more detail.

In addition to these web services we are also launching a new places library in the Google Maps API which includes:

• A PlacesService that allows Places API queries to be issued by Maps API applications
• A class that can attach Autocomplete behaviour to any text field on a web page, with the predicted places biased to a specific location or map viewport

The below demo uses the PlacesService to display Places on a map in response to changes in the map view port. An individual Place can also be mapped using the Autocomplete enabled search field:

If you would like to provide any feedback about the Places API or Maps API, or you have suggestions for improvements or new features, please let us know using the Maps API Issue Tracker. You can also discuss our APIs using the Maps API Developer Forums.

We’re very excited to make all of these great Places services available to all of our Maps API developers today. We know many of you have been eagerly awaiting access to the Places API, and we appreciate your patience. Places bridge the divide between the way that maps and computers represent the world, and the way that people relate to it. We believe that the launch of the Places API will spark a whole new wave of innovative location based application development, both on mobile and desktop, and we can’t wait to see how it is used.

Posted by Thor Mitchell, Product Manager, on behalf of the Google Maps API team

Thanks to the new Distance Matrix service, which we are launching today, I can now relive these moments from my youth. The Distance Matrix service is a simple and efficient way to obtain the travel distance and time between many locations when you do not need the full route details for any individual pair. The below applications generates a distance matrix for walking from major London railway stations to several London landmarks. Roll your mouse over the matrix cells, or tap a cell, to see the relevant route.

The Distance Matrix service is also useful for sorting or filtering search results. For example, let’s say your Maps API application enables users to find nearby grocery stores and you want to present the results sorted by drive time. The locations are stored in a spatial database such as Google Fusion Tables, which can return all stores within a given straight line distance. Using the Distance Matrix service you only need one more query to obtain the drive time from the user's location to each of those stores in order to sort them accordingly.

The Distance Matrix service is available for use directly in the JavaScript Maps API as well as a web service returning JSON or XML. To get started, take a look at the Maps API services documentation, and the Distance Matrix API web service documentation. If you need further assistance, you can also discuss this service with fellow Maps API developers in the Maps API forums.

Posted by Thor Mitchell, Product Manager, Google Maps API

Developers are now permitted to use the Static Maps API outside of a web browser, for example to add thumbnail maps to mobile applications, providing the map image is linked to Google Maps. Developers of mobile apps that are sold for a fee through an online store such as the Android Market and Apple App Store no longer require a Google Maps API Premier license. This brings the Terms of the web based Maps APIs into line with the Terms of the Android Maps API and iOS SDK.

There are also a number of changes that relate to advertising and usage limits. To ensure that we can continue to offer the Maps APIs to developers for free, we now require that any new Maps API applications going forward display any advertising delivered in the maps imagery, unless the site concerned has a Google Maps API Premier license. The opt-out from displaying such advertising that was offered in earlier versions of the Terms will continue to apply to any existing Maps API applications. Information on exercising this right of opt-out will be provided on this blog at least 90 days prior to the launch of any such advertising.

We are also introducing transaction limits on the number of maps that may be generated per day by commercial Maps API web sites or applications. These limits are documented in the Maps API FAQ and will take effect on October 1st 2011. Commercial sites that exceed these limits may be required to purchase additional transactions or a Maps API Premier license. Additional transactions will be offered online at an affordable rate which will be published on or before May 2nd 2011.

Commercial sites that consistently exceed these limits and do not purchase additional transactions online will be contacted by a Maps API Premier Sales Manager to discuss their licensing options. Not for profit applications and applications deemed in the public interest (as determined by Google at its discretion) are not subject to these limits. In addition, Non-profits are also encouraged to check out their eligibility for the Google Earth Outreach program.

In addition to the most notable changes detailed above, there are many other minor changes and clarifications, and we therefore recommend that you read the complete Terms and the Google Maps API FAQ. You can also discuss the Terms with other Maps API developers on the Google Maps API forum. Please note that Google’s Developer Relations team, who monitor the forums, are not able to offer legal advice. However any frequently asked questions or areas of confusion will be clarified in future FAQ and Terms updates.

Posted by Thor Mitchell, Product Manager, Google Maps API

Starting today you can bring that perspective to your Maps API applications with the launch of 45° imagery in select cities around the world. 45° imagery offers a superior perspective of city skylines than an overhead view. Tall buildings stand out from those around them, and iconic landmarks such as St. Mark’s Square in Venice are instantly recognisable. In addition you can rotate the map to look at buildings from all four sides:

You can track the cities where 45° imagery is currently available on this map. When 45° imagery is available a submenu option is added to the Maps API Satellite button. Right now the overhead imagery remains the default view for these areas. However in three weeks time this will change to match Google Maps, and the 45° imagery will become the default Satellite view where available. If you do not wish the behaviour of your Maps API application to change in this way, update your application now to add the following to your MapOptions object:

tilt: 0

In addition to 45° imagery we are also bringing the Overview Map Control to v3. This is a small interactive thumbnail map that shows an overview of the area around your map location and is attached to the bottom right of your map. The Overview Map Control can be minimized, which collapses it down to a small expand icon. To add the Overview Map Control to your map today in it’s opened state, add the following to your MapOptions:

overviewMapControl: true,
overviewMapControlOptions: {
  opened: true
}

In three weeks the Overview Map Control will be added by default to all Maps in its minimized state. If you do not wish the control to be added to your map at this time, add the following to your Map Options today:

overviewMapControl: false

We hope the addition of the Overview Map Control and 45° imagery to the API helps your users navigate around the world and see it from a new perspective. We’re continuously adding more 45° imagery, so keep an eye on the coverage map to see when it’s added for your city!

Posted by Thor Mitchell, Product Manager, Google Maps API

We want to ensure that applications using the Google Maps API are free to follow this recommendation. As such we are happy to offer free access to the Maps API v3, Static Maps API, and Maps API Web Services over HTTPS to all developers from today. To load the Maps API v3 over HTTPS, the API must be loaded from the hostname maps-api-ssl.google.com. For the Static Maps API and Web Services, please use maps.googleapis.com.

In addition to offering access over HTTPS, all of the Maps APIs (with the continuing exception of the Places API) will continue to be accessible over HTTP, and we recommend that sites that are using the API purely to display public data, such as store locations, continue to use HTTP for optimal performance.

Please also note that although SSL access is now available to all developers, the terms of the Maps API have not changed. If your site uses SSL because you charge for access to your application, or because your application is not publicly accessible to all users, you must still purchase a Maps API Premier license. For more information on Maps API Premier, please contact the Maps API Premier Sales team.

We hope this change assists in making your users feel safe and secure using your applications. If you have any questions or concerns about this change, please post to the Maps API v3, Static Maps API, or Web Services forum as appropriate for the service you are using.

Posted by Thor Mitchell, Product Manager, Google Maps API

For this reason we’re happy to make available the Photos layer from Google Maps to Maps API developers. The Photos layer adds thumbnails of geotagged photos to the map, which are sourced from Panoramio. They are a great way to add additional context to a map, and an on the ground perspective. Photos can be added to an API map using the PanoramioLayer class of the new Panoramio library. We have also added some additional flexibility to enable you to customize both the behaviour of the layer and the thumbnails shown by your application.

Firstly, applications can listen for clicks on the photo thumbnails and obtain information about the thumbnail concerned, which can then be used to load the photo using the Panoramio Widget API. Secondly, applications can also restrict the thumbnails shown to those of a particular user, or those with a particular tag. This allows you to only show thumbnails for photos that you have uploaded to Panoramio, or only show photos relating to a specific subject, such as beaches. You can try experimenting with different tags in the example below:

For more information on using the PanoramioLayer, please take a look at the Maps API documentation. As always, if you have any questions about using this or any other Maps API feature, we recommend the Maps API forum. We hope this new layer will help to brighten up your maps, and help your users get a better sense of the landscape you are mapping.

Posted by James McGill, Software Engineer, Google Maps API team

As the Maps API v3 continues to evolve we are keen to add more features, but as we do so we must be mindful of the impact they have on the size of the API. In response to this constraint we are kicking off 2011 by introducing a new concept to the Maps API v3, called a library.

A library is a set of Maps API features that are only loaded when explicitly requested by the application. By packaging features into a library, we can deliver them to applications that need those features without penalising the loading times of applications that do not. A library has its own child namespace under google.maps, and is a fully supported component of the Maps API.

The first library that we are launching is the geometry library. The geometry library provides a set of utility functions for performing distance, heading, and area calculations in a spherical geometry, such as on the surface of the Earth, and also provides functions for handling encoded polylines. To use these functions in your Maps API application you must request the geometry library when loading the API:

<script type="text/javascript" src="http://maps.google.com/maps/api/js?libraries=geometry&sensor=true_or_false"></script>

For more information on the geometry library, see the Maps API Documentation and Reference. If you think of additional spherical geometry functions you would like to see added to the geometry library, please log a feature request on the Maps API Issue Tracker. If you have any questions about using the geometry library, the Maps API v3 Forum is a great place to find help.

Posted by Thor Mitchell, Maps API Product Manager

Today we are therefore happy to welcome Samsung Bada and BlackBerry 6 touchscreen devices such as the Samsung Wave family and BlackBerry Torch 9800 to the fold. The full feature set of Maps API v3 is now available to users of these devices. We hope that as mobile browsers continue to improve across platforms we can continue to add new devices to our list of those we support.

Posted by James McGill, Google Maps API team

Maps API v2 had a built in animation that raised and bounced the marker when it was being dragged. When we looked into adding this feature to Maps API v3 we decided to go a step further and give developers more options for animating markers.

In addition to adding the drag animation offered in v2 we are today releasing two new marker animations that developers can trigger. Firstly there is BOUNCE which simply bounces a marker indefinitely to draw attention to it. The other is DROP which adds a marker to the map by dropping it from above with a small bounce.

We rely on a combination of JavaScript and CSS animations to ensure smooth motion across all devices, which was particularly challenging for the DROP animation, as it has a very short duration with a lot of movement. As a consequence this is the first feature we have launched that is not compatible with IE6 since we ended support for that browser (markers still appear in IE6 and can be dragged, but do not animate).

For more details on how to trigger animations check the documentation. While you are there you may notice that the MaxZoom service, which allows you to determine the maximum zoom level of satellite imagery available at a given location, is also now available in Maps API v3.

As always, if you have any questions about these features, or any other aspect of Maps API v3 development, we recommend that you post to the Google Maps API v3 Forum.

Posted by Jon Tirsen, Google Maps API team

http://maps.google.com/maps/mapplets?moduleurl=http://www.google.com/ig/modules/geoscratchpad.xml

In conjunction with this transition the Google Maps Directory will be closed, and links to Mapplets will be removed from the My Maps tab in Google Maps.

Bookmarks for existing Mapplets will continue to work. They will be automatically redirected to the new Mapplets page for the relevant Mapplet. The Mapplets page also has the minimum necessary UI elements so that it is better suited to embedding in third party sites using an iframe.

However because the Mapplets page is not part of the Google Maps application, Mapplets will no longer have access to Google Maps user profiles, which means that User Preferences will no longer be stored between sessions. Users accessing Mapplets will now always see the default behaviour when the Mapplet first loads.

The above changes will be made on or shortly after Wednesday December 8th 2010. If your web site recommends one or more Mapplets by linking to the Directory we recommend that you update your site to link directly to the Mapplets page, or embed the relevant Mapplets page in your site, as soon as possible.

Posted by Thor Mitchell, Google Maps API Product Manager

It is my pleasure to announce that Fusion Tables now offers spatial queries! Using spatial queries, developers can (1) find all features that are located within (or overlap with) a given distance from a location (2) find all features that are located within (or overlap with) a given bounding box, and (3) find a given number of features closest to a location.

To demonstrate some of the new syntax, let’s go through a potential use case of spatial queries: creating a store locator map. For this demo, I set up a table in Fusion Tables, 297050, containing the locations of a fictitious pizza restaurant chain in the San Francisco bay area. The table contains the name, location, and whether or not that location delivers.

Now let’s say we want to display all the restaurants that fall within a bounding box. To do so, use the syntax:

SELECT * FROM 297050 WHERE ST_INTERSECTS(Address, RECTANGLE(LATLNG(37.2, -122.3), LATLNG(37.6, -121.9)))

The map to the left shows this query in action using the FusionTablesLayer. The example shows all rows in the pizza table that fall within the bounding box specified with a lower-left coordinate of 37.2, -122.3 and a upper-right coordinate of 37.6, -121.9.

This is the code for the FusionTablesLayer:

map = new google.maps.Map(document.getElementById('map_canvas'), {
   center: new google.maps.LatLng(37.4, -122.1),
   zoom: 10,
   mapTypeId: google.maps.MapTypeId.ROADMAP
});
tableid = 297050;
layer = new google.maps.FusionTablesLayer(tableid, {
   query: "SELECT Address FROM " + tableid + " WHERE ST_INTERSECTS(Address, RECTANGLE(LATLNG(37.3, -122.3), LATLNG(37.6, -121.9)))",
   map: map   
});

We can also find the 10 features closest to a particular coordinate, such as the latitude, longitude coordinate of your house or a major city center. To find the 10 nearest features to Mountain View, CA at coordinate 37.4,-122.1., we use the syntax:

SELECT * FROM 297050 ORDER BY ST_DISTANCE(Address, LATLNG(37.4, -122.1)) LIMIT 10

These 2 examples demonstrate how to create a store locator-like map, but the possibilities are endless! You could create an application that finds the most popular bike trail routes in your area or enable crowd sourcing to identify roads that might need more street lamps.

To learn more about the full spatial query offering in Fusion Tables, please see the Fusion Tables documentation. You can also join the Fusion Tables User Group to receive announcements about new features or post questions you might have about Fusion Tables. Or follow us on Twitter: @GoogleFT. And, most importantly, have fun creating awesome apps!

Posted by Kathryn Hurley, Google Geo Developer Relations

Today we’re adding Australia, Austria, Belgium, Denmark, Liechtenstein, Netherlands, New Zealand, Norway, South Africa, and Switzerland to the set of countries in which this is possible. These map updates will improve our geocoding and directions, increase the accuracy and coverage of natural features such as forest and water bodies, and add walking paths and bicycling trails.

The updates will roll out over the next 24 hours, and will be applied automatically to existing Maps API applications. However we ask that you refresh any cached addresses, latlngs, or routes for these countries that were obtained using the Maps APIs before this update as soon as possible.

If you have any questions or concerns about how these updates affect your Maps API application, or for help refreshing your cached data, please post to the relevant forum. We look forward to lots of great map feedback from our users in these countries that will improve the maps experience both in Google Maps and in the Maps API.

Posted by Thor Mitchell, Google Maps API Product Manager

When the Maps Data API was launched in Google Code Labs last year, it provided developers with a scalable distributed platform for hosting geospatial data. Since then we have received a lot of valuable feedback from developers, such as the need for visualisation of hosted data in Maps API applications, easy migration of existing spatial databases into the cloud, and a familiar data model and query syntax.

Earlier this year we launched a feature in the Google Maps API v3 that renders data stored in Fusion Tables, a Google Research project for storing large structured data sets in the cloud, which has an SQL based API, and recently gained support for spatial queries. The response both at developer events and online has been overwhelmingly positive. We have seen an explosion of compelling Maps applications that use Fusion Tables to store and visualise data.

Given this developer enthusiasm, and the fact that Fusion Tables addresses many of the features requested by developers for the Maps Data API, we have decided to recommend Fusion Tables as our cloud storage solution of choice for geospatial data going forward, and to deprecate the Maps Data API.

The Maps Data API will continue to be accessible until January 31st 2011 and Maps created using the Maps Data API will remain accessible in Google My Maps beyond this date. During the deprecation period we are also providing a Maps Data API data liberation tool. This tool offers download of Maps from the Maps Data API in KML format, or transfer to Fusion Tables, by the user that owns the data. Both data transfer and download to KML will preserve all data for the vast majority of maps. There are some rarely used features (e.g. certain custom properties) that are not represented in the KML download. See the FAQ in the tool for more details.

If you have any questions or concerns about the deprecation of the Maps Data API please consult the Maps Data API Forum. If you have been working with the Maps Data API we understand that this announcement may be disappointing. However we encourage you to take a look at Fusion Tables. We’re excited by the possibilities offered by its ease of use and powerful search and visualisation features, and we think you will be too.

Posted by Thor Mitchell, Maps API Product Manager

One of the first questions we were asked following the Google I/O session at which we launched Styled Maps in the JavaScript Maps API earlier this year was whether the feature would also be offered in the Maps API for Flash.

Since then we have seen particular interest from the creative arts community, and from news organizations who use Flash because it enables rapid development in response to unfolding events, and who would value a simplified base map to quickly focus the reader's attention on the relevant facts of the story.

It therefore became quickly apparent that we should bring Styled Maps to the Maps API for Flash, and I'm happy to announce that today we are doing just that. To use Styled Maps, download the Maps API for Flash SDK 1.20 or later, and refer to the Styled Maps section of the Maps API for Flash documentation.

If you would like to experiment with Styled Maps in a Flash application take a look at ScribbleMaps, which allows you to draw on top of a map generated using the Maps API for Flash, and now offers the full set of map styling options. Just click Menu to access the Style Map option.

We have already seen many innovative uses of Styled Maps in the JavaScript Maps API, and look forward to seeing many more using the Maps API for Flash.

Posted by Thor Mitchell, Maps API Product Manager

For this reason I am delighted to announce that we have now also added the Elevation service to the Maps API for Flash, providing our ActionScript developers with the same opportunities. And just for completeness, and to distract me yet further, we have ported the elevation profile demo to 100% Flash, with an added 3D twist (mouse over the profile graph to see it).

The Elevation service allows you to obtain elevation for individual points, or sample elevation at equally spaced intervals along a path, such as that generated by the Directions service. To get started using the new Elevation service, check out the documentation in the Maps API for Flash Developer Guide.

In addition to Elevation we have also added the MaxZoom service to Flash. This allows you to determine the highest zoom level at which Satellite imagery is available at a given location. One other change to note is that the we have also introduced the sensor parameter in the Maps API for Flash, which is mandatory for any application built against v1.19 of the Maps API for Flash or later.

For assistance using these new features, or to discuss any other aspect of using the Maps API for Flash, be sure to join the Google Maps API for Flash Google Group.

Posted by Thor Mitchell, Maps API Product Manager

Draggable directions allow a user to modify the route suggested by the Maps API to suit their tastes, for example to avoid traffic, or to modify stop overs on a long road trip. If you haven’t had a chance to play with draggable directions, I’d encourage you to try it below. The API implementation closely follows that on Google Maps; existing markers can be dragged around the map, and moving your mouse near the path allows you to click and drag a new point.

The API makes it easy to turn an ordinary directions path into a draggable route. The DirectionsRenderer now has a draggable option, which when true causes paths to be draggable when rendered. Paths are not draggable by default, so existing v3 applications will remain unchanged. API developers can be notified of changes to a path by listening to the directions_changed event on a DirectionsRenderer. This makes it easy to implement additional features like the Undo button above. For more information, check out the Documentation.

We hope that you and your users enjoy experimenting with draggable directions as much as I enjoyed implementing them. I’d encourage you to start creating your own applications with draggable directions; when you’re done, post a link to your experiments in the Maps API v3 Google Group. We’ll keep an eye out for the most fun and innovative ideas, and add them to our Demo Gallery.

Once again, I’d like to thank the Google Maps API team for all their help, from getting this project off the ground, to making an American intern feel at home in a new country.

Posted by Izaak Rubin, Maps API team

We have been delighted with the enthusiasm we have seen for the Places API, and the innovative ways in which developers would like to use it. We have seen applications that offer check-in to places and need to identify an individual place at which a user is currently located, applications looking to show a user Places around them, and applications looking to offer a search and browse experience for Places similar to that offered on Google Maps.

We are going to focus initially on check-in applications. These are the applications that we feel the API currently caters to well, and we are excited to work with developers building these applications to understand their requirements, and ensure that we are offering them the best possible experience.

When we previewed the Places API back in May we indicated that we planned to begin processing applications in July. I’m happy to say that we have now begun reaching out to developers who have expressed an interest in building check-in applications using the API, including those working on client applications for the Buzz API.

If you have already applied to use the Places API and you feel that your use case fits this initial focus, please log back in to the Application Form and ensure that your description makes this clear. To manage usage we will be issuing credentials to developers in stages, so please do not worry if you do not hear from us immediately.

If your requirements extend beyond the check-in use case, please bear with us and we will be in touch once we are confident that the API can effectively meet your needs.

Posted by Thor Mitchell, Maps API Product Manager

There is however an unavoidable consequence of this consistency. No matter which Maps API site you are on, every map looks the same. If you want your map to stand out from the crowd, your options are limited to customizing the markers and controls, and if your brand has a particular colour scheme that is reflected on your site, Google Maps may not sit well with it.

From today, this all changes. You are now free to unleash your creativity on the base Google map itself, as we are delighted to launch Styled Maps in the Google Maps API v3.

Styled Maps offers you control over both the types of features shown on your maps, and the color scheme used to represent them. The possibilities are endless, as the examples below show:

For information on how to define a Map Style, check out the Maps API v3 documentation. Alternatively, you can use our Styled Map wizard to experiment with different styles, and generate the Styled Map definitions to use in your Maps API application.

We can’t wait to to see the creative ways in which our developers use Styled Maps, and the proliferation of new and interesting maps that will be created. For example, our friends over at NBC Local Media have created The Mood of our Cities Now, which surfaces the most emotional stories of the day. The map displays the location of the story with the color correlating to how the majority of users felt about that story. It’s a great way to see stories from across the nation and how they have been received by their individual communities.

We hope that this is the first of many equally compelling and innovative examples of the use of Styled Maps, and that you love this new feature of the Maps API as much as we do. May a thousand map styles bloom!

Posted by Thor Mitchell, Maps API Product Manager

If someone asked you where you are right now, how would you answer? Would you say that you are at home, or at work? Maybe you are in a foreign country, in the park, or at your favourite coffee shop. These are just a few of the many places by which we navigate through our daily lives. Maps applications may see the world in terms of latitudes and longitudes, but we think in terms of ‘Places’.

In September of last year Google launched Place Pages on Google Maps. Each Place Page consolidates together everything we know about a single Place, be it a business, point of interest, or geographical feature such as a city or neighbourhood. We believe that this unified concept of Places more accurately reflects the way that Maps users see the world, and are working to bring an awareness of Places to the Google Maps API. At Google I/O today we offered a preview of the first Place related features that that are coming to the Google Maps API in the near future.

The Nearby Places widget is a user interface element that will launch in the Google Maps API v3. It combines the W3C Geolocation API with location based Place search to present the user with a list of Places in their immediate vicinity. The user can select a Place which the Maps API application can use as a check-in, or to tag content supplied by the user about that place. The application can also obtain more detailed information about the Place, such as the address, telephone number, and Place Page URL.

The Nearby Places widget is built on top of the Places Web Service, a new addition to the family of Google Maps API Web Services. The Places Web service offers search for nearby places to native mobile applications through an XML/JSON REST interface. In order for us to manage demand and ensure that the Places Web Service is used appropriately, applications will be required to authenticate their requests. If you are interested in using the service, check out the Places Web Service documentation which outlines the usage guidelines and application process. We expect to begin processing applications when the service launches in July.

We are also very excited to be working with Booyah, developers of the hugely popular MyTown iPhone application. The broad international coverage and superior performance of the Places Web Service made it the logical choice to serve the growing community of over two million active MyTown users. We were delighted to invite David Wang, Vice President of Business Development at Booyah, to speak at Google I/O about the ways in which they are integrating the Places Web Service into the MyTown application.

The Nearby Places widget and Places Web Service are our first steps towards tightly integrated and powerful support for discovering and understanding Places using the Google Maps API. Keep an eye on this blog for more information about the availability of these services, and other Place related launches in future.

Posted by Thor Mitchell, Maps API Product Manager

However Google I/O is not the only way in which we engage with developers. The Google Maps API Google Groups are thriving communities and many of us on the Maps API team enjoy listening and engaging in discussions held on these Groups. In addition we also have the Google Maps API Issue Tracker, a tool with which any Maps API developer can report problems with the API, suggest new features that they would benefit from, or star existing issues or features.

The Google Maps API team takes the problems and ideas featured on the Issue Tracker very seriously, and although we can not always address every issue that is raised, we do consider any that attract a lot of stars. Recently one feature request in particular has been head and shoulders above the rest in terms of the number of stars it has attracted. It therefore only seems appropriate today, as we sit down with our developer community for a Fireside Chat, that we respond to that request by launching a Directions Web Service.

The Directions Web Service is a companion to the existing Geocoding and Elevation Web Services, and allows applications to obtain Driving, Bicycling, and Walking directions through an XML/JSON REST interface. All of the features of the Map API v3 Directions service are supported, including “avoid highways”, “avoid tolls”, and waypoint optimization (travelling salesman solver). For more information, check out the Directions Web Services documentation.

If you have a great idea for a new Maps API feature, please don’t hesitate to submit it to the Issue Tracker. If your idea proves to be popular, we’ll do our best to make it a reality.

Posted by Thor Mitchell, Maps API Product Manager

A year ago at Google I/O, we introduced the Maps API v3, a new JavaScript Maps API built from the ground up to offer a clean, fast, and powerful maps application development platform for both desktop web browsers and mobile devices.

The v3 API has come a long way since then, with regular updates to introduce new features. Some, such as polylines, polygons, driving directions, and KML were familiar from the Maps API v2. Others, such as elevation, bicycling directions, and optimised routing were completely new.

Now Google I/O is upon us again, and we feel our Maps API v3 is all grown up and ready to venture out into the world. Consequently we are delighted to announce the graduation of the Maps API v3 from Google Code Labs, and the passing of the title of principal Google Maps API from the Maps API v2 to the Maps API v3.

This means that the Maps API v3 is now the recommended version for all new Maps API application development. The Maps API v3 is now supported for use by Maps API Premier customers, and the Maps API Premier SLA has been extended to cover v3 applications. We are also rolling out a new versioning scheme for Maps API v3, that will allow applications to choose between using the very latest release, a release that is undergoing maintenance but no feature development, or a version that is completely frozen.

In order to ensure that existing Maps API v2 applications can be migrated to Maps API v3, we have also been striving to add all of the most popular v2 features to v3. As part of that effort we are also happy to announce that Street View is now available in the Maps API v3.

When you use Street View in v3 you will notice a number of differences with v2. The most significant change is that Street View is entirely implemented in HTML in order to accommodate all of the mobile devices on which v3 is supported. We have also added Pegman support to the map, and a number of new features, including markers, infowindows, and custom imagery.

In conjunction with the graduation of the Maps API v3, we are also announcing the deprecation of the Maps API v2 and Mapplets (which is based on v2). These deprecation announcements confirm that no further feature development is planned for these two APIs. However, we will continue to maintain and support applications using these APIs for at least three years consistent with the deprecation policy detailed in the Maps API Terms of Service.

Next month the Google Maps API celebrates its fifth birthday. With the firm foundation that the Maps API v3 provides, we look forward to another five years enabling incredible mapping applications across the web. We’d like to thank our entire developer community for all of their support in making the Google Maps APIs such a success, and we can’t wait to bring you many more exciting new features in Maps API v3.

Fortunately, we won’t have to wait very long...

Posted by Thor Mitchell, Maps API Product Manager

RouteBoxer is a new addition to the Open Source Utility Libraries for the JavaScript Maps API v2 and v3 that can help. It enables search along a route to be quickly and easily implemented against any spatial database that supports bounding box queries, such as the Google Maps Data API. The RouteBoxer class takes a Polyline object or array of LatLng objects and returns a set of non-overlapping bounding boxes that are guaranteed to encompass every point within a specified distance of the line.

You can use the below demo to evaluate the boxes that are generated for a given route.

For information on how to use RouteBoxer in your applications, see the RouteBoxer documentation for Maps API v2, and Maps API v3.

Posted by Thor Mitchell, Maps API Product Manager

The KmlLayer class is just one of several new layer classes we’re adding to Maps API v3 today. A layer class handles a collection of overlays that are added to the map as a single entity. In addition to the KmlLayer class, we are also adding a TrafficLayer class and a BicyclingLayer class.

The TrafficLayer class adds real time color coding of traffic speed on highways and major arterial roads. The BicyclingLayer class adds information about bike trails, lanes and recommended roads for bicyling onto the map:

• A dark green line indicates a dedicated bike-only trail;
• A light green line indicates a dedicated bike lane along a road;
• A dashed green line indicates roads that are designated as preferred for bicycling, but without dedicated lanes

If you generate bicycling routes using the DirectionsService class, and display them on the map using a DirectionsRenderer, the BicyclingLayer is now added to the map with the route.

You can use the map below to try out these new layers and check how your own KML files are rendered by the KmlLayer class:

If you have any questions about these new layers, or the Maps API v3 in general, we recommend that you join the Maps API v3 Google Group. For more information about KML, check out the KML Tutorial.

Posted by Thor Mitchell, Maps API Product Manager

In December, we announced spatial and attribute searching using the Maps Data API, which enables you to filter a large set of features by radius, bounding box, or text attributes, and sort them by their distance from a location. This means you can now create an interesting Maps API mashup (like our College Finder code sample), without running your own server or spatial database.

Today, we’re excited to make it much easier to import your geographic data as a single CSV file or KML file, instead of uploading many individual features.  You can now upload thousands of features using a single POST request, and then immediately perform scalable searches over your data (while controlling exactly who has access to your maps).

If you haven’t yet tried the Maps Data API, now is a great time to give it a spin, since uploading data just got a whole lot easier.

Posted by Matt Holden, Maps Data API Product Manager

However, it was while driving along the section of Lombard St west of Hyde that I was first introduced to the smell of a burning clutch. I was stuck in traffic in a car with manual transmission trying to drive up what is actually an incredibly steep hill, one of many in San Francisco. But apart from the shading in Terrain view there is no way to appreciate that on a map unless you switch to Street View.

We are therefore happy to introduce a new service to the Maps API family that enables applications to determine elevation profiles. Using either the new ElevationService Maps API v3 class or the Elevation Web Service you can request the elevation in meters for one or more sets of coordinates, or you can request a specific number of elevation samples equally spaced along a path. If any sampling points are over bodies of water, the service will return the depth relative to sea level as a negative number.

The below application uses the Google Visualization API to plot elevation profiles. You can add additional points by clicking on the map or entering an address, drag existing points arounds, and switch between different modes of travel. If you roll your mouse over the profile chart you can see on the map the point that the given sample relates to.

To facilitate easy generation of elevation profiles for routes generated for driving, cycling, or walking directions we have also added a new property to the DirectionsResult object called overview_path. This is a simplified path guaranteed to be short enough to pass to the Elevation Service.

As with all other Google Maps API services, the elevation service must be used in compliance with the Maps API Terms of Service which require that it be used in conjunction with display of a Google map. This means that if you display elevation information to your users that you have obtained using this service, or any data that you have derived from it, you must also show a Google map that indicates the points, path, or route concerned.

We think that this new elevation service is a natural complement to our recently launched bicycling directions. Now you can determine in advance just how painful your bicycling route is likely to be. In fact you’ll be happy to hear that the Maps API bicycling directions already factor in elevation, which is why if you ask for a route up Lombard Street you will be sent the long way round.

Posted by Thor Mitchell, Maps API Product Manager

We invite you to participate by adding notes, insights, or code examples to a particular doc. Your note may take up to 24 hours to appear after you submit it. All notes will be moderated to ensure they provide a useful contribution to the topic to which they are attached. Requests for help with the API should not be submitted as notes, but should continue to be posted to the Google SketchUp Developers Google Group.

Posted by Simone Nicolo, Google Sketchup Team

As we look ahead it is clear that HTML 5 offers us the platform we need to deliver on this vision. However as we develop features that exploit the potential of HTML5 it will not be possible to maintain our current level of support for older web browsers. For this reason we will be updating the list of supported browsers for the Maps API v3 on a regular basis. We are applying our first update today by removing Firefox 2, Internet Explorer 6, and Safari 3, while adding support for the Android browser and for Chrome on Mac and Linux.

We understand that many users work in environments in which they are not in control of the browser they must use. We will therefore do our best to ensure that users of browsers that we no longer support continue to have a good experience with Maps API v3 applications. If we develop a new feature that can be easily implemented in a manner compatible with these browsers we will do so, and we will continue to accept bug reports relating to them. We will also attempt to ensure that any features we launch in future that are not compatible with these browsers degrade gracefully for affected users.

The browsers that we no longer support for the Maps API v3 will continue to be supported for the Google Maps JavaScript API v2. We have no plans to change the list of supported browsers for the Maps API v2, and consequently if support for these browsers is important to you we recommend that you continue to develop your applications using the Maps API v2.

If however you are planning a new Maps API application or need to update an existing Maps API v2 application to offer improved support for mobile devices, we encourage you to consider using the Maps API v3. We are excited by the opportunities that HTML5 offers us and hope that you will enjoy using the Maps API v3 to develop the next generation of powerful and immersive Maps API applications.

Posted by Thor Mitchell, Maps API Product Manager

• Avoid highways and tolls. If you prefer to take the road less traveled you can now generate routes that avoid highways. Similarly, if you find yourself a little short of loose change, you can avoid tolls.
  
  
• Route optimization. Have many places to go but no preference as to the order you visit them in? We can now reorder the waypoints of your route to minimize the distance and time you must travel. Very useful for traveling salesman I hear.
  
  
• Bicycling directions. Prefer your vehicles of the two wheeled human powered variety? In conjunction with the launch of Bicycling directions in Google Maps you can now also request directions in Maps API v3 that are tailored to your Penny-farthing.

The Google Maps JavaScript API v3 introduced a new format for geocoding responses that offers a number of improvements over the format used in the v2 API:

• A flatter response format for address components that is easier to parse
• The ability to tag an address component with multiple types
• Both full names and abbreviations for countries and states
• Differentiation between rooftop and interpolated geocoder results
• Both the bounding box and recommended viewport for each result

The Geocoding Web Service is intended to enable precaching of geocoder results that you know your application will need in the future. For example, if your application displays property listings, you can geocode the address of each property, cache the results on your server, and serve these locations to your API application. This ensures that your application does not need to geocode the address of a property every time it is viewed by a user. However we do ask that you regularly refresh your cache of geocoder results.

Note however that it is a requirement of the Maps API Terms of Service that you use the Geocoding Web Service in conjunction with a Google map. This means that when it comes time to use cached geocoder results in an application, the application must display the results or any data derived from them on a map generated using one of the Google Maps APIs or Google Earth API.

If your application needs to geocode arbitrary addresses that are entered by your users while they wait we recommend that you use the classes in the appropriate client API. This ensures that the requests your application generates reach Google directly from your users, which will improve the performance of your application and ensure it is resilient to unexpected spikes in use. For more details, I highly recommend this excellent blog post by our very own Mano Marks.

In addition to an improved response format you will notice some other changes in the new Geocoding Web Service. Requests no longer require a Maps API key, and Maps API Premier customers must sign their requests. In addition CSV output is not supported because we found that the minimal amount of data in a CSV response makes it is difficult to identify false positive results.

2,500 requests may be sent to the Geocoding Web Service per day from a single IP address. This is independent of any geocoding activity generated by applications using one of the client Maps APIs for geocoding. Maps API Premier quotas remain unchanged.

A forward geocoding request to the new Geocoding Web Service with XML output looks like:

http://maps.google.com/maps/api/geocode/xml?address=sydney&sensor=false

A reverse geocoding request with JSON output looks like:

http://maps.google.com/maps/api/geocode/json?latlng=-33.873038,151.20563&sensor=false

Check out the Geocoding Web Service documentation for more details on the options available for language and biasing of results.

In conjunction with the launch of the new Geocoding Web Service we are also announcing the deprecation of the current service, now retroactively named the "Geocoding V2 Web Service". Existing applications using the V2 Web Service need not worry though. Deprecation indicates that we no longer intend to pursue any further feature development, but we will continue to maintain and support the service in accordance with the deprecation policy set out in the Maps API Terms of Service.

We hope that you find the new Geocoding Web Service easier to use and useful. As always we encourage you to check out the Google Maps API Google Group if you have any questions or comments relating to the APIs. We look forward to adding more great features to the Geocoding Web Service in future.

Posted by Thor Mitchell, Maps API Product Manager

Using the Google Maps API v3, I was able to create a mobile version of our map for use on smartphones. After showing it to my users, one of the first responses I got was, "Are you going to make this available as an application?". After spending many hours developing a feature-rich mobile web version, the thought of investing a large amount of time to code the same experience on multiple platforms was overwhelming. Then I began thinking of the maintenance headaches; even simple changes, such as adding a new sets of icons for custom markers, would be time consuming. All of a sudden the idea sounded much less appealing. I'd spent all this time on the mobile web version of my map, why couldn't I just use that?

All Wrapped Up

So instead of writing the maps application using the SDK of each phone platform, I wrapped my v3 Maps API site into a WebView inside a stub application. Now all the work spent on the web version automatically applies to the "native" application and my users never even know the difference. The Google Maps API team have even provided some great reference articles for Android and iPhone which help get the process started.

Optimization

Response time in this type of application was a big concern both within an app and within the browser. I saw significant performance gains by using Closure-Compiler on my JavaScript, using the CSS sprite support in v3 for markers and following most of the suggestions in the Web Performance Best Practices document. To improve the user's initial loading experience I also pre-load the WebView with static HTML that contains a "Loading..." message and use JavaScript to redirect them to the actual map page.

Popularity

I was initially skeptical of the usefulness of such a project. The mobile version of the map offers users the same functionality that they can get by simply bookmarking the map in their browser. So I was very pleasantly surprised at the both the usage and publicity the application has garnered. Within the first two weeks, the iPhone application was downloaded 1,200 times and the Android application almost 200 times. Both applications are receiving very positive reviews.

We consider this project a huge success. Going forward it will now be a priority to make sure new features work well both on the desktop as well as on mobile devices wherever possible.

Posted by Chad Killingsworth, Assistant Director of Web & New Media, Missouri State University

This being the case, it's always good to check the weather forecast, and no weather forecast is complete without a map. Now if you're looking for an interactive map, you are spoilt for choice, but if you would prefer a simple static map to print out or view on your phone it's not so easy. Weather maps need weather symbols, and until now the only choices for marker icons on Static Maps have been the regular Google Maps pins.

Although we love our map pins here at Google, we understand that there are times when you need something different, which is why we're happy to announce that the Static Maps API now supports custom marker icons. Just specify the URL of a PNG, GIF, or JPEG icon in the marker definition, and we'll fetch the icon and add it to your map. We'll cache the icons you specify to maintain performance, and even generate shadows for your icons if you wish:

markers=icon:http://maps.google.com/mapfiles/kml/shapes/sunny.png|shadow:false

You can use up to 5 different icons on a single map, each of which can be used for multiple markers, so come rain or shine you can always take the weather with you.

For more details check out the Static Maps v2 API Developer's Guide, and be sure to post any feedback on the Google Maps API Google Group.

Posted by Thor Mitchell, Google Maps Developer Platform team

P.S. Oh, and one more thing. Requests made to the Static Maps API v2 no longer need a Maps API key.

Which is nice.

Here's just a partial list of Geo sessions that are already listed on the I/O website:

• Unleash your map data: Cloud computing for geospatial applications
• Map once, map anywhere: Developing geospatial applications for both desktop and mobile
• Moving beyond markers: Advanced Maps API customization
• The World in 3D: Adding a new dimension to your geospatial applications

Over the next couple of months, we'll be adding additional Geo sessions and many more Geo Developer Sandbox participants to the I/O website. For updates on when new content is added, follow @googleio on Twitter.

Registration for Google I/O (at the early bird rate of $400) is open as of today. We hope to see the Geo Developer community in May!

Google I/O
May 19-20, 2010
Moscone West, San Francisco

Register at: http://code.google.com/io
Early bird rate: $400

Posted by Joyce Sohn, Google Developer Team