If you have ever tried to plot a very large number of overlays on an API map you have probably reached a point at which the performance of your application begins to suffer. With one hundred or so markers, most browsers cope just fine, and clustering solutions like Fluster can help support more. But if you have thousands of overlays that you wish to show, rendering them individually can be problematic.
The Maps API v3 now offers two solutions to this problem. If you have a large volume of geospatial data that can be served as KML, the KmlLayer class can render up to 50,000 features as an overlay that does not impact performance on any browser. To support data sets that are structured as tables, such as a database or spreadsheet, we have also now added the FusionTablesLayer class for rendering data stored in Google Fusion Tables.
Google Fusion Tables is a fascinating new experimental Google Research project offering storage, search, and management of large structured data sets in the cloud. Up to 100MB of data can be stored per table, and each row in a table can have an associated location, line, or polygon feature. Using the FusionTablesLayer class you can render features on an API map as a clickable overlay. When a feature is clicked, the application can access a copy of the complete row of data associated with the feature.
Fusion Tables also supports an SQL like query language, which you can use to filter the features shown on a map. The below map visualises mountain biking trails uploaded to Fusion Tables by mtbguru.com. The slider allows you to filter trails by their length, and the trails shown on the map are updated accordingly. If you click on a trail a custom dialog is shown which indicates the elevation profile for the trail concerned.
The FusionTablesLayer also supports rendering data sets as a heatmap. The below map of beaches in Brazil illustrates the benefit of this. When rendered as point features it is difficult to tell the relative density of the beaches without zooming in further. However once you switch to displaying the data as a heatmap the high density of beaches west of Rio de Janeiro becomes immediately clear.
The combination of Fusion Tables with the Maps API makes it easy to host large sets of data in the cloud, and visualise them in your Maps API application. It is quick and simple to get up and running with Fusion Tables, and the addition of the FusionTableLayer class to Maps API v3 enables Maps applications to be tightly coupled with data hosted in Fusion Tables. Give it a try, and let us know what you think of this experiment in the Groups!
Google Maps are instantly familiar to millions of Internet users worldwide. The user interface and the look and feel of our maps combine to ensure that when a user sees a Google map on any web site, they instantly know how to interact with that map, and find their way around.
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
[Note: The Places API is now generally available to all developers for use in any app, and has also been integrated into the Maps API v3. For more information please see the launch blog post - May 10th 2011]
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.
Google I/O is always a fantastic opportunity for the Maps API team to meet face to face with some of the many Maps API developers worldwide. We believe our developer community is one of the biggest strengths of the Google Maps API, and with over 350,000 web sites actively using the Maps API, there is no shortage of skilled and helpful expertise to tap into.
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.
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...
A common operation in Maps API applications is to search a spatial database for locations within a certain distance of a point. It can also be useful to offer search along a route, for example to find hotels, restaurants, or service stations on a long journey. However if your spatial database does not support corridor queries this can be difficult to implement efficiently. For example searching around every vertex of a route will generate a large number of queries which overlap, while also leaving gaps in coverage between widely spaced vertices.
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.
Polyline
LatLng
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.
Since being formalized as an Open Geospatial Consortium standard, KML has become something of a lingua franca for geospatial information. From humble beginnings in Google Earth, KML support can now be found in a wide variety of mapping products and services. Today we’re happy to add Maps API v3 to this list with the introduction of the new KmlLayer class. The KmlLayer class enables KML or GeoRSS files that are hosted on publicly accessible web sites to be rendered in a Maps API v3 application.
KmlLayer
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.
TrafficLayer
BicyclingLayer
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:
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.
DirectionsService
DirectionsRenderer
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.
Hi, my name is Björn Brala. In the last two years, I've been working on GeoStart, a framework based on the Google Maps API. In that time, the developer community has been an invaluable source of information and help.
When the Google Maps API V3 was released, we were asked to port V2 utility libraries over to work with V3. Since I enjoy challenges, I decided to port over the MarkerManager library. After some rigorous testing and help from Daniel Lee, one of Google's Developer Programs Engineers supporting Geo APIs, I succeeded!
For those who are not familiar with MarkerManager, it's a class originally created by Doug Ricket that manages the additions and removals of many markers when the viewport changes.
Since real code can sometimes speak a thousand words, here's a basic Weather Map example which uses the MarkerManager class. This map creates a random collection of weather markers. When you zoom in, more weather markers are displayed to show more detailed local weather.
If you want to see more examples coupled with detailed explanations on how to use the code, visit the examplespage and the reference guide, which are both hosted in the Google Maps Utility Library V3 project.
This post from the Google Code Blog is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. This guest post is written by Adrian Graham, co-founder of nextstop.com who will give us a demo inside the Developer Sandbox.
When building nextstop's HTML5 mobile app, we were able to leverage a powerful combination of HTML5 and Google API's to build a mobile web experience that we believe rivals what we could have built natively. For more on our mobile app, check out this post -- here we will just focus on the technologies that made this experience possible.Lately HTML5's video features have gotten a lot of attention, but it's three other HTML5 features that we've found most useful for mobile web development.
1. Prefetching using LocalStorage: It's no secret that mobile data networks are slow but by putting a bit of thought into what users will tap on next, and prefetching that data in the background you can build a dramatically faster user experience. It's possible to do limited forms of prefetching using plain old JavaScript, but using the localStorage key/value storage built into HTML5, we're able to store much more data and therefore prefetch more aggressively.If you're using a recent version of Chrome or Safari or on an iPhone 3 or Android 2 phone and want a sense of what prefetching feels like, try clicking the left and right arrows here (you can ignore the warning you will see in Chrome and Safari).
2. Geolocation: Using the geolocation features built into HTML5 (and available on iPhone 3 and Android 2), we're able to connect you with local information based on the GPS in your phone, so all you have to do is launch the app to see nearby recommendations. I wish it were a bit faster, but it sure beats entering an address or zip code -- and it's super easy to hook into as a developer.
3. App Caching: The last HTML5 feature that we heavily rely on is the application cache. If a cache manifest file is specified, the browser won't re-download files unless the content of the manifest file has been updated. This may not sound like a big deal, but the latency of cellular networks can be long enough that requesting multiple files at startup can slow down your app by 10 or 20 seconds. Ideally, you'd put all your static JavaScript, CSS, and image files in the manifest file, so users never have to wait for them to be downloaded more than once.As excited as we are about HTML5, things get even more interesting when you combine these technologies with Google APIs.1. Google Maps API V3: Google Maps V3 has been rewritten from the ground up to better support modern mobile web browsers, and it shows. We were able to build a map interface into our mobile app that is nearly as full featured as our main site, including support for dynamic updates when the user pans and gestures like pinch to zoom on the iPhone. Coupled with the Geolocation support in HTML5, we can easily show users where they are in relation to the recommendations on the map. A year ago, this would have required writing a fair amount of native code. Today it can be done in the browser and works on both Android 2 and iPhone 3 devices.2. Google Analytics: Since we prefetch most of our content, we end up rendering mobile pages using JavaScript. This makes tracking things like page views a little more tricky than a typical website, since we're not requesting an HTML file for each page view (and the App Cache can further complicate matters). We planned on building a custom mobile analytics system, but we decided to try running Google Analytics in the mobile web browser instead. Using the _trackPageview method (with a URL corresponding to each mobile "page" generated by Javascript) has worked surprisingly well and has had minimal performance impact. Best of all, if you're already using Google Analytics on your main site, you see all your mobile analytics in the same place. This lets you do things like easily compare the time on site for a mobile visitor and a desktop visitor. (Here's one data point if you're wondering whether or not to build a mobile web version of your site: visitors spend over twice as long using our mobile HTML5 app as they do on our website.)3. Google Local Search API: Coupled with HTML5 geolocation, the Google Local Search API becomes even easier to use. For instance, the nextstop app lets users add places that they like to nextstop's database. In a desktop browser, we have no choice but to ask the user to type in some words and do a local search. However, on the phone, we can show users a list of nearby places by passing the local search api the user's current position. More often than not, no typing is required to locate the place you'd like to add.
If you can't already tell, we're pretty excited about the future mobile apps running inside a browser. As mobile web browsers and web APIs continue to evolve, we expect more and more people to hop on the HTML5 bandwagon as a cross-platform way to build powerful mobile apps.We'll be at Google I/O in May and would love for you to stop by our demo station in the Developer Sandbox and share any questions, tips, or tricks you have related to HTML5 mobile development. And in the meantime, if you have a great idea for an HTML5 app based on nextstop's data, we encourage you to check out our API.
Give us feedback in our Product Forums.
Follow