The Google Maps APIs have been making maps universally accessible to developers and users for over 10 years. With over 50 supported languages, almost everyone can view the map in their own language.






But sometimes an address translated to your language isn’t the most useful result. Whether your map says London, Londres, Лондон or 伦敦, only the first of these will match local street signs or help you communicate the address to locals.






If you view geocoded addresses in locations with different local languages, today we launched a change that will make life easier for you. Street-level addresses returned by the Google Maps Geocoding API now favor the local language, while keeping the address understandable as much as possible for both a user who only reads the requested language as well as locals.






sf.png






If the local language and user language both use the same alphabet, the Geocoding API will now return the local names for the streets and localities. For example, searching for an address in Brazil with user language set to English now returns “Avenida Paulista” rather than “Paulista Avenue”.






If the local language and user language use different alphabets, the Geocoding API will return the local name, transliterated into the Latin alphabet. In some cases, an English translation may be returned, for example if no transliteration is available. For example, searching for El Tahrir Square with user language set to Japanese now returns “El-Tahrir Square, Ismailia, Qasr an Nile, Cairo Governorate, エジプト” rather than “エジプト カイロ県 Qasr an Nile, タハリール広場” (the old result) or “ميدان التحرير، قصر النيل، محافظة القاهرة‬، مصر” (the local name). The Latin result is more likely to be readable by both a Japanese traveler and an Egyptian local, whereas the Japanese traveler is unlikely to be able to read the Arabic address, and Egyptian locals are unlikely to be able to read the Japanese characters.






Queries where the requested language is the same as the local language are unaffected. Note that the requested language can be specified either using the language= parameter, or the browser’s Accept-Language header. If neither of these is provided, the native language of the Google domain is used as a default (for example, English for maps.googleapis.com).






This change also applies to addresses returned by the Directions API and Distance Matrix API, as well as services in the Google Maps JavaScript API v3. The Places API is not included at this time.






To learn more about localization in the Google Maps APIs, see the Google Maps JavaScript API v3 documentation. To learn more about the Geocoding API, see the Geocoding API documentation.



Posted by Elena Kelareva, Product Manager, Google Maps APIs

Several months back we released a new Google Maps Embed API which enables developers to generate HTML snippets that embed Google Maps within their own website. At that time, the astute reader may have noticed that Street View and Photo Spheres were missing. Until now ...
Several months back we released a new Google Maps Embed API which enables developers to generate HTML snippets that embed Google Maps within their own website. At that time, the astute reader may have noticed that Street View and Photo Spheres were missing. Until now!



Today, we added the ability to easily embed the Street View and Photo Sphere images you find in Google Maps and we’re also enabling the same capabilities programmatically in the Google Maps Embed API. These embeds use the new imagery viewer technology that powers Street View in the new Google Maps.



Embedding a Street View or Photo Sphere works similarly to the Street View Service in Google Maps JavaScript API v3 - specify a lat/lng or panorama ID to pick your location, plus heading and pitch to determine direction of the scene and angle of the camera.



Lastly, since this feature is part of the Google Maps Embed API, embedded Street View panoramas are also free of usage limits. So go forth and embed!



Posted by Ken Hoetmer, Product Manager, Google Maps APIs

Cross-posted from Google Developers Blog



 Posted by Ian Lake, Developer Advocate



To offer more seamless integration of Google products within your app, we’re excited to start the rollout of the latest version of Google Play services.
Cross-posted from Google Developers Blog



 Posted by Ian Lake, Developer Advocate



To offer more seamless integration of Google products within your app, we’re excited to start the rollout of the latest version of Google Play services.



Google Play services 6.5 includes new features in Google Maps, Google Drive and Google Wallet as well as the recently launched Google Fit API. We are also providing developers with more granular control over which Google Play services APIs your app depends on to help you maintain a lean app.




Google Maps


We’re making it easier to get directions to places from your app! The Google Maps Android API now offers a map toolbar to let users open Google Maps and immediately get directions and turn by turn navigation to the selected marker. This map toolbar will show by default when you compile against Google Play services 6.5.







In addition, there is also a new ‘lite mode’ map option, ideal for situations where you want to provide a number of smaller maps, or a map that is so small that meaningful interaction is impractical, such as a thumbnail in a list. A lite mode map is a bitmap image of a map at a specified location and zoom level.



In lite mode, markers and shapes are drawn client-side on top of the static image, so you still have full control over them. Lite mode supports all of the map types, the My Location layer, and a subset of the functionality of a fully-interactive map. Users can tap on the map to launch Google Maps when they need more details.



The Google Maps Android API also exposes a new getMapAsync(OnMapReadyCallback) method to MapFragment and MapView which will notify you exactly when the map is ready. This serves as a replacement for the now deprecated getMap() method.



We’re also exposing the Google Maps for Android app intents available to your apps including displaying the map, searching, starting turn by turn navigation, and opening Street View so you can build upon the familiar and powerful maps already available on the device.




Drive


You can now add both public and application private custom file properties to a Drive file which can be used to build very efficient search queries and allow apps to save information which is guaranteed to persist across editing by other apps.



We’ve also made it even easier to make syncing your files to Drive both user and battery friendly with the ability to control when files are uploaded by network type or charging status and cancel pending uploads.




Google Wallet


In addition to the existing ‘Buy with Google’ button available to quickly purchase goods & services using Google Wallet, this release adds a ‘Donate with Google’ button for providing the same ease of use in collecting donations.




Google Fit


The Google Fit SDK was recently officially released as part of Google Play services and can be used to super-charge your fitness apps with a simple API for working with sensors, recording activity data, and reading the user’s aggregated fitness data.



In this release, we’ve made it easier for developers to add activity segments (predefined time periods of running, walking, cycling, etc) when inserting sessions, making it easy to support pauses or multiple activity type workouts. We’ll also be adding additional samples to help kick-start your Google Fit integration.




Granular Dependency Management


As we’ve continued to add more APIs across the wide range of Google services, it can be hard to maintain a lean app, particularly if you're only using a portion of the available APIs. Now with Google Play services 6.5, you’ll be able to depend only on a minimal common library and the exact APIs your app needs. This makes it very lightweight to get started with Google Play services.




SDK Coming Soon!


We’ll be rolling out Google Play services 6.5 over the next few days, and we’ll update this blog post, publish the documentation, and make the SDK available once the rollout completes.



To learn more about Google Play services and the APIs available to you through it, visit the Google Play Services section on the Android Developer site.

Today we posted a few minor updates to the Google Maps / Google Earth APIs Terms of Service. These changes should impact very few developers and customers, but are designed to provide clarification for recently launched advertising-supported and connected APIs.

Today we posted a few minor updates to the Google Maps / Google Earth APIs Terms of Service. These changes should impact very few developers and customers, but are designed to provide clarification for recently launched advertising-supported and connected APIs.

The changes are broadly as follows:

Advertising

  • Similar to the Adsense Terms and Conditions, if you use an API that serves ads, you grant Google the right to index your site for the purpose of better ad targeting.

  • A restriction on using Places API results to create or augment an advertising product.

Sign-in and cookies

  • A restriction on obscuring the Google sign-in button, similar to the existing restriction on obscuring the Google logo and copyright notice.

  • A clause that states certain APIs use cookies, and that developers using these APIs may be required by law to disclose such on their own site.

Other changes

  • Clarifications on what sorts of use cases constitute asset tracking.

  • Removal of references to specific data providers.

We continue to believe in providing a set of tools that help you meet your maps and location related goals, and these updates are designed to make the terms of our offering more clear and sustainable. We look forward to seeing what you build next!

Posted by Ken Hoetmer, Product Manager, Google Maps APIs