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
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
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
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! Weatherbug
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. Posted by Carlos Cuesta, Maps API Product Marketing Manager
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.
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.
Posted by James McGill, Google Maps API team
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.
Posted by Jon Tirsen, Google Maps API team
Earlier this year we announced the deprecation of Google Mapplets. As part of the deprecation plan for Mapplets we will shortly be switching from rendering Mapplets within Google Maps, to rendering them on a dedicated Mapplets page:
http://maps.google.com/maps/mapplets?moduleurl=http://www.google.com/ig/modules/geoscratchpad.xml
In conjunction with this transition the Google Maps Directory will be closed, and links to Mapplets will be removed from the My Maps tab in Google Maps.
Bookmarks for existing Mapplets will continue to work. They will be automatically redirected to the new Mapplets page for the relevant Mapplet. The Mapplets page also has the minimum necessary UI elements so that it is better suited to embedding in third party sites using an iframe.
However because the Mapplets page is not part of the Google Maps application, Mapplets will no longer have access to Google Maps user profiles, which means that User Preferences will no longer be stored between sessions. Users accessing Mapplets will now always see the default behaviour when the Mapplet first loads.
The above changes will be made on or shortly after Wednesday December 8th 2010. If your web site recommends one or more Mapplets by linking to the Directory we recommend that you update your site to link directly to the Mapplets page, or embed the relevant Mapplets page in your site, as soon as possible.
Posted by Thor Mitchell, Google Maps API Product Manager
Back in December of 2009, five leading scientists from the American Geophysical Union trekked to the remote Google office in downtown San Francisco. Lost until now, the video of their presentations have resurfaced. So, for the first time ever, we present, the Lost Archives of the Google Geo Developers Series
Jeffrey Cardille of Universitie de Montreal discusses GeoSearch, a new virtual globe application for the submission, storage, and sharing of point-based ecological data.
Thijs Damsma of Deltares discusses his use of KML to visualize coastal data.
Ross Beyer of NASA and SETI discusses his work visualizing Mars data and imagery using Google Earth.
Tyler Erickson of Michigan Tech Research Institute discusses his tools for to visualizing 4-D atmospheric carbon monitoring data using KML and Google Earth
Yaxing Wei of Oak Ridge National Lab discusses his Spatial Data Access Tool which enables visualization and access of geospatial data using OGC services and Google Earth.
I’m Kathryn Hurley, a Developer Programs Engineer for Fusion Tables, and I have to say, I really dig Fusion Tables. The power it gives you to visualize your data is amazing! Plus, the team is working hard to add new features that give even more power to you, the developer.
It is my pleasure to announce that Fusion Tables now offers spatial queries! Using spatial queries, developers can (1) find all features that are located within (or overlap with) a given distance from a location (2) find all features that are located within (or overlap with) a given bounding box, and (3) find a given number of features closest to a location.
To demonstrate some of the new syntax, let’s go through a potential use case of spatial queries: creating a store locator map. For this demo, I set up a table in Fusion Tables, 297050, containing the locations of a fictitious pizza restaurant chain in the San Francisco bay area. The table contains the name, location, and whether or not that location delivers.
Now let’s say we want to display all the restaurants that fall within a bounding box. To do so, use the syntax:
SELECT * FROM 297050 WHERE ST_INTERSECTS(Address, RECTANGLE(LATLNG(37.2, -122.3), LATLNG(37.6, -121.9)))
The map to the left shows this query in action using the FusionTablesLayer. The example shows all rows in the pizza table that fall within the bounding box specified with a lower-left coordinate of 37.2, -122.3 and a upper-right coordinate of 37.6, -121.9.
This is the code for the FusionTablesLayer:
map = new google.maps.Map(document.getElementById('map_canvas'), { center: new google.maps.LatLng(37.4, -122.1), zoom: 10, mapTypeId: google.maps.MapTypeId.ROADMAP }); tableid = 297050; layer = new google.maps.FusionTablesLayer(tableid, { query: "SELECT Address FROM " + tableid + " WHERE ST_INTERSECTS(Address, RECTANGLE(LATLNG(37.3, -122.3), LATLNG(37.6, -121.9)))", map: map });
We can also find the 10 features closest to a particular coordinate, such as the latitude, longitude coordinate of your house or a major city center. To find the 10 nearest features to Mountain View, CA at coordinate 37.4,-122.1., we use the syntax:
SELECT * FROM 297050 ORDER BY ST_DISTANCE(Address, LATLNG(37.4, -122.1)) LIMIT 10
These 2 examples demonstrate how to create a store locator-like map, but the possibilities are endless! You could create an application that finds the most popular bike trail routes in your area or enable crowd sourcing to identify roads that might need more street lamps.
To learn more about the full spatial query offering in Fusion Tables, please see the Fusion Tables documentation. You can also join the Fusion Tables User Group to receive announcements about new features or post questions you might have about Fusion Tables. Or follow us on Twitter: @GoogleFT. And, most importantly, have fun creating awesome apps!
Posted by Kathryn Hurley, Google Geo Developer Relations
We’re always looking to improve the accuracy of our maps and the value of the services we offer around them. To do that we need to have the best quality map data possible, and we believe that nobody knows the world around them better than our users. For this reason we’re always excited when we can update our maps and enable users to participate in improving them, as we have previously in the United States and Canada.
Today we’re adding Australia, Austria, Belgium, Denmark, Liechtenstein, Netherlands, New Zealand, Norway, South Africa, and Switzerland to the set of countries in which this is possible. These map updates will improve our geocoding and directions, increase the accuracy and coverage of natural features such as forest and water bodies, and add walking paths and bicycling trails.
The updates will roll out over the next 24 hours, and will be applied automatically to existing Maps API applications. However we ask that you refresh any cached addresses, latlngs, or routes for these countries that were obtained using the Maps APIs before this update as soon as possible.
If you have any questions or concerns about how these updates affect your Maps API application, or for help refreshing your cached data, please post to the relevant forum. We look forward to lots of great map feedback from our users in these countries that will improve the maps experience both in Google Maps and in the Maps API.
Last week at Google Developer Day 2010 in Sao Paulo, Brazil we launched support for Styled Maps in the Static Maps API. This comes on the heels of our launch of Styled Maps in the Maps API for Flash two weeks ago and now means that developers can use Styled Maps in the Maps JavaScript API, the Maps API for Flash and the Static Maps API. The Static Maps API is useful for those who want to display a map in a browser where Javascript or Flash isn’t supported or to create a lightweight thumbnail map.
To use it simply specify one or more “style” parameters in your query string, like this:
style=feature:featureArgument|element:elementArgument|rule1:rule1Argument|rule2:rule2Argument
Here’s an example creating a Halloween themed static map of Sao Paulo:
http://maps.google.com/maps/api/staticmap?sensor=false&size=500x300&zoom=9¢er=Sao+Paulo+Brazil&style=feature:water|saturation:100|hue:0xff5e00|gamma:0.58&style=feature:landscape|invert_lightness:true&style=element:labels|visibility:off&style=feature:poi|hue:0x0800ff|ligtness:-70&style=feature:administrative|element:geometry|visibility:off
Google Developer Days and DevFests are a chance to learn about Google’s developer products and meet the engineers who work on them. With GDD Brazil finished, I attended DevFest Argentina to give presentations on the Maps APIs, Earth API, KML and Fusion Tables. Following that we’ll have events in Munich, Moscow and Prague. Hope to see you on the (now more styled) road.
Posted by Ossama Alami, Google Geo Developer Relations
The Maps Data API is being deprecated and will no longer be available after January 31st 2011. For more information, including how to preserve your data and alternative solutions, read on...
When the Maps Data API was launched in Google Code Labs last year, it provided developers with a scalable distributed platform for hosting geospatial data. Since then we have received a lot of valuable feedback from developers, such as the need for visualisation of hosted data in Maps API applications, easy migration of existing spatial databases into the cloud, and a familiar data model and query syntax.
Earlier this year we launched a feature in the Google Maps API v3 that renders data stored in Fusion Tables, a Google Research project for storing large structured data sets in the cloud, which has an SQL based API, and recently gained support for spatial queries. The response both at developer events and online has been overwhelmingly positive. We have seen an explosion of compelling Maps applications that use Fusion Tables to store and visualise data.
Given this developer enthusiasm, and the fact that Fusion Tables addresses many of the features requested by developers for the Maps Data API, we have decided to recommend Fusion Tables as our cloud storage solution of choice for geospatial data going forward, and to deprecate the Maps Data API.
The Maps Data API will continue to be accessible until January 31st 2011, and Maps created using the Maps Data API will remain accessible in Google My Maps beyond this date. During the deprecation period we are also providing a Maps Data API data liberation tool. This tool offers download of Maps from the Maps Data API in KML format, or transfer to Fusion Tables, by the user that owns the data. Both data transfer and download to KML will preserve all data for the vast majority of maps. There are some rarely used features (e.g. certain custom properties) that are not represented in the KML download. See the FAQ in the tool for more details.
If you have any questions or concerns about the deprecation of the Maps Data API please consult the Maps Data API Forum. If you have been working with the Maps Data API we understand that this announcement may be disappointing. However we encourage you to take a look at Fusion Tables. We’re excited by the possibilities offered by its ease of use and powerful search and visualisation features, and we think you will be too.
Posted by Thor Mitchell, Maps API Product Manager
Inspired in part by Five Great Styled Maps Examples, I decided to write up an article, Styled Maps Using Google Maps API Version 3. In my article, I explore some of the power of Styled Maps, and some things to avoid in order to make your maps beautiful and powerful. I also link to the code for each style I used. From an example in the article, you can make a map that looks like this:
And this...
And even this...
It may not look it, but, trust me, these are all Google Maps. And now you make maps like these, too!
So check out my latest post “Styled Maps Using Google Maps API V3”. Your mashups will never be the same.
Posted by Justin O’Beirne of 41latitude.com
One of the first questions we were asked following the Google I/O session at which we launched Styled Maps in the JavaScript Maps API earlier this year was whether the feature would also be offered in the Maps API for Flash.
Since then we have seen particular interest from the creative arts community, and from news organizations who use Flash because it enables rapid development in response to unfolding events, and who would value a simplified base map to quickly focus the reader's attention on the relevant facts of the story.
It therefore became quickly apparent that we should bring Styled Maps to the Maps API for Flash, and I'm happy to announce that today we are doing just that. To use Styled Maps, download the Maps API for Flash SDK 1.20 or later, and refer to the Styled Maps section of the Maps API for Flash documentation.
If you would like to experiment with Styled Maps in a Flash application take a look at ScribbleMaps, which allows you to draw on top of a map generated using the Maps API for Flash, and now offers the full set of map styling options. Just click Menu to access the Style Map option.
We have already seen many innovative uses of Styled Maps in the JavaScript Maps API, and look forward to seeing many more using the Maps API for Flash.
63% of people like Polls
According to Wikipedia, the first known example of an opinion poll was a local straw poll conducted by The Harrisburg Pennsylvanian in 1824, showing Andrew Jackson leading John Quincy Adams by 335 votes to 169 in the contest for the United States Presidency.
Polling has become a lot more popular since then, and these days any major election will have many polls covering it. Most of the time, a news article will mention just one or two, and it can be hard to see the differences between one poll and another. So we’re happy to be providing a comprehensive Election Ratings Tracker for the 2010 U.S. Senate, Congressional, and Governor races.
This interactive map visualizes the latest data from a variety of the major national polling institutions, color-coding the polygons by projected winner, and letting you quickly see details for any jurisdiction.
We used the App Engine Cron Service to parse the data feeds into thirty separate Fusion Tables, styled the data with Fusion Tables' new styling options, and then built the interactive app you see in App Engine to call them all using the FusionTablesLayer class in the Maps V3 API. For the gory details on how to do this yourself, see our article on Election Ratings and Spatial Data with Fusion Tables.
Posted by Josh Livni, Geo APIs Team
One of my favourite new features added to the Maps API this year is the Elevation service in the Maps API v3. This was in part because I enjoyed playing with the launch demo far too much, but mostly because the service opened up opportunities for genuinely new and interesting applications that were not previously possible.
For this reason I am delighted to announce that we have now also added the Elevation service to the Maps API for Flash, providing our ActionScript developers with the same opportunities. And just for completeness, and to distract me yet further, we have ported the elevation profile demo to 100% Flash, with an added 3D twist (mouse over the profile graph to see it).
The Elevation service allows you to obtain elevation for individual points, or sample elevation at equally spaced intervals along a path, such as that generated by the Directions service. To get started using the new Elevation service, check out the documentation in the Maps API for Flash Developer Guide.
In addition to Elevation we have also added the MaxZoom service to Flash. This allows you to determine the highest zoom level at which Satellite imagery is available at a given location. One other change to note is that the we have also introduced the sensor parameter in the Maps API for Flash, which is mandatory for any application built against v1.19 of the Maps API for Flash or later.
For assistance using these new features, or to discuss any other aspect of using the Maps API for Flash, be sure to join the Google Maps API for Flash Google Group.
Over the past three months I’ve had the privilege of working as an intern on the Google Maps API team here in Sydney. In that time, I’ve had the opportunity to implement draggable directions in the Maps API v3 - a feature highly sought after by developers. It has been a joy to watch this project grow from design musings to a launched feature.
Draggable directions allow a user to modify the route suggested by the Maps API to suit their tastes, for example to avoid traffic, or to modify stop overs on a long road trip. If you haven’t had a chance to play with draggable directions, I’d encourage you to try it below. The API implementation closely follows that on Google Maps; existing markers can be dragged around the map, and moving your mouse near the path allows you to click and drag a new point.
The API makes it easy to turn an ordinary directions path into a draggable route. The DirectionsRenderer now has a draggable option, which when true causes paths to be draggable when rendered. Paths are not draggable by default, so existing v3 applications will remain unchanged. API developers can be notified of changes to a path by listening to the directions_changed event on a DirectionsRenderer. This makes it easy to implement additional features like the Undo button above. For more information, check out the Documentation.
draggable
directions_changed
We hope that you and your users enjoy experimenting with draggable directions as much as I enjoyed implementing them. I’d encourage you to start creating your own applications with draggable directions; when you’re done, post a link to your experiments in the Maps API v3 Google Group. We’ll keep an eye out for the most fun and innovative ideas, and add them to our Demo Gallery.
Once again, I’d like to thank the Google Maps API team for all their help, from getting this project off the ground, to making an American intern feel at home in a new country.
Posted by Izaak Rubin, Maps API team
We’ve just launched Tripline (http://www.tripline.net), and we’re excited to talk about how we’re using Google Maps. We’ve been laboring for months in solitude, so it feels great to finally talk about what we’ve built.
Tripline is all about maps. The Tripline concept goes back to 2005 when I started manually creating map-based plans to visualize upcoming trips. I’m one of those people who can stare at the moving map on an airplane for the duration of a long flight, so my desire to understand travel from a geographical viewpoint is inherent, and I think quite common. And, as we so often see in movies, a moving line on a map is a great way to tell a story.
The Tripline Player uses the Google Maps API for Flash and animates progression from point to point using a simplified KML-like data structure. We chose Flash primarily because it was the best platform to combine the maps, animation, and soundtrack elements that were part of the design. It also means that trips are shareable, as you can see from the example embedded above. We chose the terrain view because we think it best conveys the feeling of an adventurous journey. One of my favorite things to do is to press play, enter full screen mode and just sit back and watch a story unfold. The Google Maps API for Flash helps make that experience smooth and beautiful. It’s essential to our product.
The player represents the end-product of a created trip, but what about the creation process itself? Our goal was to make trip-creation as simple and flexible as typing a bullet list, and we spent a lot of time working towards that goal. We’re using many different Maps API components in our trip editor, including geodesic polylines, custom markers and custom infowindows. To add places, we’re using the Google AJAX Search API and the Geocoder API, and for trip thumbnails, we’re using the Google Static Maps API.
Speed and reliability are also essential. Users will forgive a lack of features and even bad design, but if your application is slow, you’re dead. The Google Maps APIs are always on and always fast, which is something that very few services can guarantee. That's one of the key reasons why we use Google services to support the core capabilities of our product. We’ve been live now for just under a month, and it’s been smooth sailing. We’re also hard at work on our next release, so stay tuned for more. Thanks Google.
Posted by Byron Dumbrill, Founder & CEO, Tripline
From the earliest days of Google Earth, (and even back when it was still called Keyhole,) developers have wanted control over the globe to create their own 3D Earth applications. In response to this need, the Keyhole team added a COM API to the Keyhole app, to allow further customization of users’ Google Earth experience. When Keyhole became Google Earth in 2005, this API was carried over. Though we never provided much support, developers discovered the COM bindings and a few intrepid developers sorted through the vagaries of COM programming. Eventually we had a small but committed development community demanding documentation, which we released in 2007. We saw some interesting uses for the COM API, particularly by Enterprise users and broadcasters. Mostly, though, people wanted to put Earth in their web applications.
In 2008, we released the Google Earth API and browser plug-in. This robust JavaScript API is more powerful than the COM API, and can be used on a variety of platforms to deliver compelling 3D applications over the web based on the Google Earth technology. At the same time, we stopped development on the COM API and began encouraging developers to migrate to the Earth API instead. Today, more and more apps are being written in JavaScript, and COM itself is no longer a widely used technology, so the time has come to retire the Google Earth COM API.
Today we’re announcing that the Google Earth 5.2 client will be the last version that supports the COM API. Earth 5.2 and older clients will continue to support the COM API while these versions are supported. Future releases will no longer have COM API bindings. We believe that the JavaScript API provides the best mechanism for reaching the most developers.
We realize that a few of you will be disappointed by this news, however we are happy to work with you to transition off of COM onto JavaScript. Please see the documentation for more information on how to work with the Earth API, and visit our active developer forum for support. Enterprise customers can also contact Enterprise support with any questions. If you have a feature from COM that you can’t live without, please let us know about it by adding it as a feature request in our issue tracker, and starring other requests.
Posted by Mano Marks, Geo APIs Team
[Note: The Places API is now generally available to all developers for use in any app. For more information please see the launch blog post - May 10th 2011]
At the Google I/O developer conference earlier this year we previewed the Places API, a new service that will allow applications to search for Places, and obtain detailed information about individual places selected by users. At that time we posted documentation and provided an Application Form that developers can use to indicate their interest in using the API.
We have been delighted with the enthusiasm we have seen for the Places API, and the innovative ways in which developers would like to use it. We have seen applications that offer check-in to places and need to identify an individual place at which a user is currently located, applications looking to show a user Places around them, and applications looking to offer a search and browse experience for Places similar to that offered on Google Maps.
We are going to focus initially on check-in applications. These are the applications that we feel the API currently caters to well, and we are excited to work with developers building these applications to understand their requirements, and ensure that we are offering them the best possible experience.
When we previewed the Places API back in May we indicated that we planned to begin processing applications in July. I’m happy to say that we have now begun reaching out to developers who have expressed an interest in building check-in applications using the API, including those working on client applications for the Buzz API.
If you have already applied to use the Places API and you feel that your use case fits this initial focus, please log back in to the Application Form and ensure that your description makes this clear. To manage usage we will be issuing credentials to developers in stages, so please do not worry if you do not hear from us immediately.
If your requirements extend beyond the check-in use case, please bear with us and we will be in touch once we are confident that the API can effectively meet your needs.
The release of Google Earth 5.2 had a lot of new features, so many that we had to write three different blog posts just to cover it all. Well, OK, four with this one. One of the most exciting features from a developer standpoint is the new KML extension, <gx:Track>.
We wanted a better way to represent movement on and above the globe. Time animation works well, but from a KML standpoint it required very bulky files. In order to “move” a <Point>, you created a new <Placemark> for each time segment. Your <Point> didn’t actually move, it merely was replicated at a different place. This made animating your path rather cumbersome. Instead, we wanted a smoother experience, and one that allowed you to truly animate a <Geometry>. So, we created <Track>. To get a real sense of the power of <Track>, check out this video.
As you can see, a <Model> (a <Model> is a <Geometry> in KML) of an airplane moves smoothly along the <Track>. Let’s take a look at some KML:
<Placemark> <name>My first track</name> <styleUrl>#mytrackstyle</styleUrl> <gx:Track> <altitudeMode>absolute</altitudeMode> <when>2010-04-07T23:30:55Z</when> <when>2010-04-07T23:31:13Z</when> <when>2010-04-07T23:31:32Z</when> <when>2010-04-07T23:31:52Z</when> <when>2010-04-07T23:32:11Z</when> ... <gx:coord>-83.671639 1.675732 7.827881000000001</gx:coord> <gx:coord>-83.67233299999999 1.675678 4.943848000000001</gx:coord> <gx:coord>-83.672904 1.67574 3.982666</gx:coord> <gx:coord>-83.67346499999999 1.675781 4.463257</gx:coord> <gx:coord>-83.67400600000001 1.675855 3.501953</gx:coord> ... <Model id="model_2"> ... <Link> <href>/Users/mmarks/Documents/track.kmz/files/mymodel.dae</href> </Link> </Model> </gx:Track> </Placemark>
Track is a parallel array. The first <when> element matches the first <gx:coord> element, the second with the second, and so forth. The <when> element identifies the point on the time slider, and the <gx:coord> the matching location. Google Earth draws a line between each position visible in the time slider. Track also supports <gx:angles>, which allows you to define the heading of a model at any point along the way. If not defined in <gx:angles>, Google Earth will change the orientation of the Model based on the direction between the current position and the one previous.
Since you’re only creating one Track element, instead of re-creating a bunch of <LineString> elements for every time segment, your KML files will be much smaller. In fact, the more coordinates you have, the more benefit you’ll see from it.
One more feature that is really compelling is that you can add <gx:SimpleArrayData> elements to <SchemaData>. <gx:SimpleArrayData> allows you to add a matching array of your own data. In the sample posted here heart rate, cadence and power are added to each point, and when Elevation Profile is turned on in Google Earth, it allows you to view that data as well, as you can see below.
Mano Marks, Geo APIs Team
Six months ago, we released a bevy of new articles to help with your coding through the dark winter months. OK, they were not so dark South of the equator, but here in Mountain View, well, it rained a few times. Anyway, now that it’s winter South of the equator, and for all of you developers in the North who can’t go out in the sun, we have released your summer reading list. These articles are hot off the digital presses, so enjoy them while they’re fresh.
This article presents a basic introduction to using MVC objects within V3. You will learn how to use the Maps Javascript API V3 MVC framework to create objects that automatically respond to state changes. You will build a resizable distance widget and by the end, you'll have a greater understanding on what MVC objects are, how to use them, and why they're just so "awesome".
Ever wondered whether you should use client-side or server-side geocoding? Actually, if you haven’t, you should and this article is for you. In it, you’ll learn why client-side geocoding is so cool, and when and even if you should ever use server-side geocoding.
A couple of years ago, we released an article on hosting KML on Google Pages. Well, Pages is no more, and has become Google Sites. This is an article for a beginning developer who just wants to put their KML up on the web.
Chad Killingsworth, who presented with me at Google I/O in our Map once, map anywhere session, has a great article up summarizing some of the lessons he has learned about developing Google Maps API applications for V3. We added a link to his article on our articles page for the Google Maps API.
So enjoy your summer reading! We’re doing our best to prevent your sun burn.
Today is an important milestone here at Google and we’re all pretty excited - the Google Maps API turns 5! It was five years ago today that we posted a brief announcement to let the world know about the JavaScript Maps API and now 5 years later more than 350,000 active websites make use of it. Uses have ranged from tools that have made it easier to find an apartment, track the Gulf of Mexico oil spill and even make an Earth sandwich! Many, many more examples have been chronicled on sites like Mashable and the Google Maps Mania blog.
In 2005, Adrian Holovaty launched the first crime mashup that overlaid Chicago’s public crime data onto online maps providing Chicago’s citizens and journalists with a true picture of crime in their city. The site won the 2005 Batten Award for Innovations in Journalism and was named by The New York Times as one of 2005's best ideas.
In honor of this very special birthday, we took a chance to check back in with Adrian to see what he thought about the journey of the Google Maps API over the past 5 years:
Of my 11 years of doing Web development, Spring 2005 was the most interesting and exciting time. When Google Maps launched -- with maps assembled client-side, in JavaScript! -- I was one of the band of tinkerers around the globe who poked at Google's obfuscated code until we figured out how to embed their maps in our own pages. It was a ton of fun, not only doing the reverse engineering, but seeing the various discoveries and hacks other people were making: embedding multiple maps in a single page, swapping out the map tiles, using custom map markers, making markers move, loading real-time data onto maps... New discoveries were being made on a seemingly daily basis, and the best ones built on the other ones, which led to a sense of a community contributing to a greater understanding. These days, it's hard to fathom a Web without embeddable maps. Wasn't it always that way? To Google's eternal credit, instead of shutting these hacks down, they recognized the demand and legitimized it in the form of their mapping API. And the rest is... well, kind of boring in its simplicity, now that reverse engineering isn't involved. There was something raw and pure about those original hacks, like hunting and skinning your own food, living off the land, a digital self-sustainability. I feel like an old man yelling at kids to get off my lawn: ‘Back in my day, I had to reverse engineer Google's obfuscated JavaScript to get embeddable maps on my pages!’ You don't know how good you have it.”
Of my 11 years of doing Web development, Spring 2005 was the most interesting and exciting time. When Google Maps launched -- with maps assembled client-side, in JavaScript! -- I was one of the band of tinkerers around the globe who poked at Google's obfuscated code until we figured out how to embed their maps in our own pages. It was a ton of fun, not only doing the reverse engineering, but seeing the various discoveries and hacks other people were making: embedding multiple maps in a single page, swapping out the map tiles, using custom map markers, making markers move, loading real-time data onto maps... New discoveries were being made on a seemingly daily basis, and the best ones built on the other ones, which led to a sense of a community contributing to a greater understanding.
These days, it's hard to fathom a Web without embeddable maps. Wasn't it always that way? To Google's eternal credit, instead of shutting these hacks down, they recognized the demand and legitimized it in the form of their mapping API.
And the rest is... well, kind of boring in its simplicity, now that reverse engineering isn't involved. There was something raw and pure about those original hacks, like hunting and skinning your own food, living off the land, a digital self-sustainability. I feel like an old man yelling at kids to get off my lawn: ‘Back in my day, I had to reverse engineer Google's obfuscated JavaScript to get embeddable maps on my pages!’ You don't know how good you have it.”
The Google Maps API has seen some significant milestones of its own during the past five years. Some of the announcements we’re most proud of are the Maps API for Flash, Static Maps API, our Enterprise offering Maps API Premier, and the new Maps API v3, built with mobile use cases in mind and recently graduated from Code Labs.
The Google Maps API has established itself as the most popular Google API and the most deployed service-based API on the web. We continue to be amazed by how popular this API continues to be for web and mobile apps being developed today. This ProgrammableWeb dashboard shows that of the apps built and submitted over the past 2 weeks, a quarter of them make use of the Google Maps API. Click the 'All Time' tab and you'll see that nearly half of the almost 5000 cataloged mashups use it.
Today, on this 5 year milestone, we really have all of you to thank for this incredible chapter in web and mapping development. The remarkable levels of innovation, creativity and interest have come from all of you. You saw the possibilities the Google Maps API held and what it could be combined with to create, and you built it. Now join us to celebrate! Keir Clarke from Google Maps Mania has created a mashup that we want all of you to contribute to. Since we can’t all share a giant cake, I think it’s fitting that we all build a giant mashup of mashups to mark this special API birthday. Please tag your Google Maps mashup or tool to the map wherever you are:
We’re looking forward to the next 5 years of mapping innovation together with all of you!
Posted by Mike Pegg
Last year, we launched the Google Qualified JS Maps Developer Program. This qualification, and your inclusion in the directory, will help interested parties contract with you for their geo development projects. Hot on the heels of the Maps API V3 graduation we are now announcing an update to the program which now includes JS Maps API V3 Developer Qualification. What does this entail, exactly? The Google Qualified Developer program uses a version release and points threshold strategy rather than setting an absolute term on earned qualifications. Instead of picking an arbitrary duration such as one year, developers have the opportunity to continuously earn points towards their qualification by resubmitting assignments and assisting with exam updates and testing. Current JS Maps API developers earned a minimum of 3000 out of a possible 5000 points in order to become qualified. To earn these points, they submitted practical evidence of their programming capabilities by writing applications, demonstrated their commitment to the developer community, supplied professional references, and passed the JS Maps API Exam. Now that JS Maps V3 has been released, the developers who did not participate in early testing have been notified of potential points expiration. Developers will have 30 days to take the new V3 exam, and submit new applications using the V3 API. To read more about the program, take a look at our site. We look forward to expanding our API support and growing the Developer Qualification program. Please reach out to us with questions and feedback at devqual-proctors@google.com.
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!
Give us feedback in our Product Forums.
Follow