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.

Posted by Ken Hoetmer, 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 Photospheres 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.

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.

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

Our digital lives are increasingly connected. We research on our laptops, look up directions on our phones and even navigate with our watches. And by creating maps unique to each user and offering features such as saved places, Google Maps has been making it easier to continue these tasks as we move from device to device.

However, although maps embedded from Google Maps are now built uniquely for every Google user, most of the now two million active sites and apps using the Maps APIs are still islands. When I look for a place to eat on Zagat, I can’t see how far away it is from work. When I look at a travel map in the New York Times, I can’t save those places in order to navigate to them later.

Today we’re taking a step towards connecting these two million sites and apps by introducing a signed-in JavaScript Maps API experience and a feature called attributed save. To help illustrate, we’ve partnered with the New York Times to bring this experience to their 36 hours travel column.

A connected JavaScript Maps API

When you add &signed_in=true to the Google Maps JavaScript API source url, your end users will have the option to sign into the map with their Google account. When they do so, your users will receive a map built for them, in the context of your app. Their saved places — including home and work addresses (if set by the end user) as well as other relevant places — will appear automatically on their map, providing a layer of context that anchors your content and makes it stand out even more.

Attributed save

Once users are signed into the Google Maps in your app, we can together create an integrated experience between your map content and Google Maps. With attributed save, signed-in users can save places from your app to be accessed later, with attribution and linkbacks, on Google Maps for the web, Android and iOS.

What’s more, you can also enable deep links into your mobile applications. For instance, users can save a place from your desktop app (such as Zagat.com), open up the place on Google Maps on their Android device, and deep link directly into your Android app.

Enabling attributed save is easy — just specify your app name, a link and a place search string or place ID when creating a marker and info window. Or use our SaveWidget to enable attributed save in your own custom info window.

In addition, we’re also launching attributed save across all embedded maps today. Attribution and linkback parameter will be inferred automatically from the domain and referrer of the host site, so if you’re using our embedded maps, you don’t need to do anything! If you’re using the Google Maps Embed API, you may customize the source and link back parameters yourself.

One final point: we’ve stated in the past that the JavaScript Maps API is cookieless if loaded from maps.googleapis.com. As of today, to enable the signed in maps experience on sites across the web, the signed-in version of the JavaScript Maps API now does rely on cookies to detect the end user’s signed-in state. Please review our documentation for further details.

That’s all for now. Go try it out. And remember, no map is an island, entire of itself...

Posted by Ken Hoetmer, Product Manager, Google Maps APIs

For years, we’ve hosted the open source utility libraries for the Google Maps JavaScript API on Google Code. These libraries provide additional functionality that developers can add to their maps applications. They also show best practices for techniques like marker clustering:



Putting labels on a map:



And much more.

Over the last few years the developer community has increasingly used GitHub for hosting code. In order to make these libraries more useful to developers, we will be moving the utility libraries maintained by Google to our Google Maps GitHub repository, where they will join the Android utility library, the iOS utility library, our new Java Client for Google Maps Services and various code samples we’ve published. There they will be easy to fork and use in your own projects, as well as make pull requests to add new features and fix problems.

We have frozen the existing project on code.google.com. Future updates will be made only in the GitHub repositories. We encourage developers to get their code from the GitHub repositories instead.

For a complete list of the utility libraries on GitHub, check out our directory.

Posted by Mano Marks, Google Maps API Team

Matt Cooper is a Computer Science student at the University of Sheffield. He spent the past summer interning in the Google Maps for Work team in London. He worked on ways to help our partners implement our Maps API and display large amounts of data.

Google Maps is great for displaying data. Whether you’re using the Google Maps Javascript API’s Data Layer, Google Maps Engine, or My Maps, you’re able to display a pretty impressive amount of data on top of Google Maps. But don’t you always wish you could display a bit more?

I’ve been working on a way to use new web technology to make some really great, scalable and awesome tools to use with Maps. There’s one new technology that’s pretty good at displaying graphics on the web - WebGL. Using WebGL you can access a user’s graphics card and perform some speedy and big rendering operations. There are some open source libraries that are currently working to bring WebGL and maps closer together and I’ve made something that helps to bring WebGL and Google Maps closer together too.

Currently you can use CanvasLayer.js that Brendan Kenny developed to integrate WebGL and Maps. He showed that off last year at Google I/O but even with CanvasLayer, there’s a bit more work to do to help developers use WebGL with Maps.

That’s where WebGL Layer comes in. It’s an experimental extension I wrote for Google Maps that gives you simple and extensible access to WebGL on a map and it’s really easy to get started. Simply include WebGL Layer and its dependencies on your web page, make a Google Map like you normally would, and then you can add your WebGL Layer.


Just like you’d expect from a Maps Layer you can now load in data. WebGL Layer uses GeoJSON as a data source, but you can extend this as you wish. You can use GeoJSON from your application or GeoJSON from an external source.


There’s also support for Vector Tile Servers. As WebGL Layer is designed to display huge amounts of data you’ll often run into problems with bandwidth and file size. A great way to get around this is to use Google’s Compute Engine to host your own tile server. One of the builds I liked is a PostGIS database with TileStache in front providing a UWSGI HTTP server for GeoJSON tiles. Once you have your tile server, adding it in is easy.


After you’ve added all your data in, you’re going to want to do something with it, right? WebGL Layer uses an onAddFeature callback that lets you grab a feature after it enters the layer and do some cool things with it.
Let’s say you want to build a robust frontend GIS (Geographic information system). You can integrate with JavaScript Topology Suite to let you do some spatial indexing and querying on your points. You can also use powerful libraries like Crossfilter to do speedy filtering and queries on your data or you can make your own data structure. Once you’ve got your data back you can use the index properties attached to the feature to change some of the internal features.


There are a lot more more examples on the Github repo. Feel free to play around and tinker with WebGL Layer to make your own awesome new maps projects. And as always, we’d love to hear about the new and exciting maps apps you’re building.

Posted by Mano Marks, Developer Relations Team