Last week we opened the Chrome Web Store, an online marketplace where users can discover thousands of web apps, extensions, and themes for Google Chrome. With millions of people already using Chrome, the Web Store is a great platform for developers to generate both exposure and revenue for their applications.

Many of these Chrome Apps are utilizing our Geo APIs. Here we’ve highlighted 5 great Chrome apps using Google Maps API.


TripTrace organizes all the important places that you’ve been to or think you might want to visit; perfect for local exploration or vacation planning. Photos, events, and news are merged with your personal address book, check-ins, bookmarked web pages and more.


Wikihood World Browser gives users with a unique way to browse and discover knowledge. By organizing Wikipedia articles geographically, users can quickly find information about a given location on the map. Wikihood makes browsing even easier by providing a short synopsis of an article on the left side when the article’s geolocation is selected on the map.


Breadcrumbs is a great GPS management tool. Users can visualize, organize, edit, and share GPS data collected from any GPS enabled device (including Android devices!). Breadcrumbs is also integrated with the Google Earth API for 3D visualizations.

Delta Embark

Whether you’re planning your next vacation, trying to find a restaurant on your next business trip, or just looking for some travel inspiration this Chrome optimized travel guide is a delight to use. Travel planning made fun and easy, brought to you by Delta Airlines!


Don’t be late to Grandma’s this holiday season! Weatherbug let’s you view your weather and get the latest local current conditions, forecast, traffic information, and more for thousands of locations around the world.

To learn more about adding your apps to the Chrome Web Store, check out our developer documentation about apps and the store.


In today’s guest blog post, Greg Gould of Geodesic Development) talks about how he created a unique Google Earth Hurricane Visualization using a custom .NET application to turn NOAA storm track data into a visually exciting KML animation of the 2010 hurricane season.

Geodesic Development was formed after several years of nights and weekends working on code and custom applications specifically designed to generate KML for Google Earth visualizations. Fascinated with the potential for developing new presentations in the 3D world of Google Earth, I’m focused on the “non-traditional” areas and visualizations which aren’t seen often or at all in Google Earth, especially in the main stream media. I hope that our visualizations will affect people’s perceptions of what’s possible in Google Earth.

I decided to create a Google Earth hurricane visualization to test ideas and explore the creative possibilities of animating ground overlays in ways I had not seen before in Google Earth. Hurricane data is readily available in KML from many different sources, but the static track lines and colored icons don’t present the storms in a visually exciting or dynamic way. I thought it was a perfect opportunity to develop an application to take seemingly unexciting data and highlight some new possibilities for presenting it with Google Earth.

The application I developed uses a custom .NET class library to handle the calculations, data processing, and KML text generation for each storm track, which was obtained from the National Oceanic and Atmospheric Association's (NOAA) National Hurricane Center website. Each storm data file is processed and exported to its own KML file and combined to visualize the entire season. It’s really a cool way to see how the storms developed and the track each one took for one of the busiest seasons on record.

Currently, NOAA provides storm track data in several formats, i.e. Shapefiles, XML, and DBF. For this application the DBF data is manually downloaded as a separate file which contains all the feature information needed to create the KML animation. This file is processed locally as a simple database table with known storm data for each track point, e.g. Name, Dates, Intensity, Category, and Position. These data points will determine which overlay to use and how it gets displayed.

Because this data inherently contains varied amounts of time (from 3 hours to as many as 72) and distance between track points, I had to control the display and transitions of the overlays with a series of loops which interpolate position, heading and rotation to fill in points between each segment of track data. This was an important step for creating a smoother animation and seamless overlay changes. I then use a pre-defined set of overlays, size settings, spin rates, and track icons to create a consistent look and feel for the whole presentation when animating the different layers and files together.

There were definitely some issues with creating a complex visualization like this, having it run smoothly, and all without overwhelming the cache in Google Earth. It took several iterations to find a good compromise between smooth animation and too many overlays (since <GroundOverlay> elements don’t contain the Track element). I think the bigger challenge was to coordinate the overlays, transitions, and track icons with the frequently changing storm data, and get them all to play nice together.

I learned a lot from this project and I think it demonstrates some new possibilities for interesting visualizations that are not typically seen in Google Earth. I hope you like this one, it was fun doing it and hopefully we’ll have some more to show off soon.

Posted by Greg Gould of Geodesic Development


From the day the Maps API v3 was first announced we placed a special focus on it’s suitability for use on mobile browsers. Being able to develop a single maps application that works across all major desktop browsers and also on mobile devices is a key benefit of the Maps API. We are keen to make Maps API applications as accessible as possible, which is why we’re always excited to test new devices to determine if they meet our requirements for support.

Today we are therefore happy to welcome Samsung Bada and BlackBerry 6 touchscreen devices such as the Samsung Wave family and BlackBerry Torch 9800 to the fold. The full feature set of Maps API v3 is now available to users of these devices. We hope that as mobile browsers continue to improve across platforms we can continue to add new devices to our list of those we support.


Maps API v2 had a built in animation that raised and bounced the marker when it was being dragged. When we looked into adding this feature to Maps API v3 we decided to go a step further and give developers more options for animating markers.

In addition to adding the drag animation offered in v2 we are today releasing two new marker animations that developers can trigger. Firstly there is BOUNCE which simply bounces a marker indefinitely to draw attention to it. The other is DROP which adds a marker to the map by dropping it from above with a small bounce.

We rely on a combination of JavaScript and CSS animations to ensure smooth motion across all devices, which was particularly challenging for the DROP animation, as it has a very short duration with a lot of movement. As a consequence this is the first feature we have launched that is not compatible with IE6 since we ended support for that browser (markers still appear in IE6 and can be dragged, but do not animate).

For more details on how to trigger animations check the documentation. While you are there you may notice that the MaxZoom service, which allows you to determine the maximum zoom level of satellite imagery available at a given location, is also now available in Maps API v3.

As always, if you have any questions about these features, or any other aspect of Maps API v3 development, we recommend that you post to the Google Maps API v3 Forum.

Editor’s note: Today we have Peter Batty from Ubisense to talk about how the company is using Google Maps API Premier to make sense of complicated GIS data. This is cross-posted on the Google Enterprise blog.

Large utilities and telcos have very large amounts of geospatial data about their network assets, typically hundreds of tables and millions of records, and complex rules for how these should be displayed on a map. Ubisense myWorld is a Software as a Service (SaaS) product that brings the ease of use and performance of Google Maps to the challenge of presenting these complex network maps in a way which is simple to use. myWorld uses the Google Maps JavaScript API V3 with Google Maps API Premier.

The data for these network maps is stored and maintained in a Geographic Information System (GIS). These systems have been around a lot longer than Google Maps, for 30 years or so, and tend to be powerful but complex to use. We have focused on working with data from GE Smallworld for utility GIS, but can also work with data from ESRI and others. We render the network data from the GIS to raster map tiles to create an image map overlay that is displayed on top of the Google Maps basemap. The advantage of this approach versus using a vector data format is that it is much easier to match the cartographic design of the network maps used in the GIS, and the users expect consistency between the systems.

All features on the map need to be clickable so that users can display information about any of the network items such as cables, poles, transformers, etc. To handle this we just define a click event that queries a server to find items close to that point. We use a system called Arc2Earth Cloud, which stores spatial data in Google App Engine.

One cool feature of our application is its tight integration with Google Street View. You can click on an object on the map, such as a pole or a building, and see a Street View of that object. This gives the user additional information that they can't get from their existing GIS database. We calculate the right bearing for the Street View automatically, and this works surprisingly well, given the potential for mismatches between the Street View and GIS location data. When necessary, the user can adjust and save the view, over-riding the automatic view. We can display markers in the Street View and click on them to display attributes of poles or other characterisitcs - this is a great feature of the V3 API.

The JavaScript API gives us great portability across multiple platforms. Mobile applications are very important in utilities, as access to and update of map data is often done by field workers. Being able to access the same functionality not only in desktop browsers but on smart phones such as the iPhone or Android, or tablets such as the iPad, is a major benefit. Our main application runs really well on the iPad without any change, and we also provide the same functionality but with modified layout on smart phones. We take advantage of the GPS devices in the phones and link to the built-in maps applications for routing.

I've developed geospatial applications on many platforms over the past 20 years, and have been really impressed with how quickly we were able to develop a pretty sophisticated application with Google Maps V3 JavaScript API, while keeping everything very simple for users. We have a lot of ideas for further enhancements, we are just scratching the surface!