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

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

This map illustrates how WebGL Layer can display a high density of data on a single map by showing the Postcode records of London (~120,000 points).

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.