Tuesday, January 20, 2015

Transit Directions Improvements

Today we released a set of improvements to transit directions in the Google Maps APIs. If you use transit directions in your app, you can now show fare info and give your users the same mode and routing options as the Google Maps Android app.


blog01.pngblog02.png

Specifically, the changes are as follows:
  • Transit is now available in the Google Maps Distance Matrix API and the Distance Matrix service in the Google Maps JavaScript API v3. Previously it was only available in the Google Maps Directions API and the Directions service.
  • Transit directions will now return fare information where available, same as the Google Maps Android app. In the Distance Matrix API, this enables developers to find routes that minimize either the travel time or the fare.
  • Transit directions now accept transit options, same as the Google Maps Android app. Options include mode preferences (transit_mode=train|tram|subway|bus) as well as routing preferences (transit_routing_preference=less_walking or fewer_transfers).
  • Developers can now set departure_time=now in Directions API queries instead of specifying a timestamp. The departure_time parameter is now optional and will default to departure_time=now if not specified.

These changes are also available in the Directions service and Distance Matrix service in the Google Maps JavaScript API v3.

Posted by Elena Kelareva, Product Manager, Google Maps APIs

Wednesday, January 7, 2015

Save Time with Easy Maps API Integration from Java and Python


The Google Maps API provides a rich set of web services that allow developers to integrate them into connected applications. We've been making developers lives easier by making these services available in the JavaScript Maps API as tested code that simplifies interfacing with mapping services for quite a while now.

Recognizing that developers use different languages for their applications, we've developed client libraries to make integration of Maps API services easier, and we're happy to announce availability of libraries for both Java and Python. The bottom line is fewer lines of code are needed to integrate the Maps APIs, and let's face it, less code means less work which means faster time to market!

The libraries support these Maps API services:

Here's an example of how you'd use the Geocoding API with the Java client library:

// Replace the API key below with a valid API key.
GeoApiContext context = new GeoApiContext().setApiKey("AIza...");
GeocodingResult[] results =  GeocodingApi.geocode(context,
    "1600 Amphitheatre Parkway Mountain View, CA 94043").await();
System.out.println(results[0].formattedAddress);

By taking advantage of these client libraries, developers will save time integrating these services. Developing robust code that handle all the details of interfacing to these services can be left to our client libraries whilst the developer can concentrate on value added features in their applications.

Depending on which language you're using, some of the best features of the libraries include:

  • Simple interface
    • enables you to get started quickly and easily
  • Authenticated requests
    • handles the nitty-gritty of authentication keys and enterprise signing
  • Retry on failure
    • transparently deals with intermittent connection to server errors
  • Rate limiting
    • throttles the number of requests to the Maps API for quota management
  • Native objects
    • the interfaces are in your host language so no bridging code needed
  • Asynchronous or synchronous
    • you choose what style of interface to use, as we support both
  • Open source
    • easy to check out, understand, and contribute to if you like

If you're a Java developer, head on over to our github repository to get the code and browse the examples. If you develop in Python you'll find the Python specific code and samples here.

We've built these libraries to save you time and make it even easier to put Maps API services into your next world-changing app, let us know if you like them!

Posted by Alex Danilo, Developer Advocate

Friday, December 12, 2014

Announcing deprecation of the Google Earth API

Over six years ago we introduced the Google Earth API, enabling developers to build rich 3D mapping applications in the browser, using JavaScript. And over the years, developers have built quite a number of fascinating applications.

However, the Earth API is built on a technology called the NPAPI plugin framework, and recently, for security reasons, both Chrome and Firefox have announced they’re removing support for this framework. These security reasons, combined with dwindling cross-platform support (particularly on mobile devices), had made building applications that leverage the Earth API untenable for developers.

Therefore, after careful consideration, we have decided to retire the Google Earth API. Per our deprecation policy, the API will be supported until one year from today and will be turned off on December 12, 2015.

For the duration of the deprecation period, the set of supported browsers is as follows. Because of the recent Chrome and Firefox announcements, support on those browsers extends only to the latest browser version that supports NPAPI.

  • Microsoft Windows (XP, Vista, 7, and 8)
    • Google Chrome 5.0-39.0 (32-bit)
    • Internet Explorer 7-9, and 10-11 with Compatibility View (32-bit) (Note that the Windows 8 browsing mode with Internet Explorer does not support plugins.)
    • Firefox 11.0-34.0
  • Apple Mac OS X 10.6 or later (any Intel Mac)
    • Google Chrome 5.0-39.0 (32-bit)
    • Safari 3.1+
    • Firefox 11.0-34

Google Earth has a proud legacy, which continues with the new Google Earth for Android, powered by a brand new renderer. 3D is in our blood, and while we can’t announce anything just now, we look forward to sharing more exciting product news in the future.

Thursday, November 20, 2014

Localization of Street Addresses in the Google Maps APIs

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

Wednesday, November 19, 2014

Introducing Street View and Photo Spheres in the Maps Embed API

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!

Monday, November 17, 2014

Google Play services 6.5

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.

Friday, November 14, 2014

A few updates to the Google Maps / Google Earth APIs Terms of Service

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!