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
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.
I'm Gary Little, a realtor in the small town of Sechelt, British Columbia, located about 40 minutes by ferry from Vancouver. Before returning to Canada a few years ago, I worked for many years in Silicon Valley at Apple Inc. and Sun Microsystems, Inc.
I'm known around here as "Map Guy", not only for my numerous interactive maps but also my collection of antique paper maps of the west coast of North America. I've even got a car with MAP GUY plates!
My most prolific mapping project to date has been an interactive map application that shows the locations of all MLS-listed properties for sale on the Sunshine Coast (an area about 50 miles long with Sechelt at the center). You can see the application at map.garylittle.ca. I recently rewrote and simplified this application so that it works well on iPhone and Android phones. This meant migrating to theV3 Maps API. One problem I faced was that there was no easy way to create and display a custom info window when a property's marker was clicked.
To solve this problem I created a class called InfoBox. You use it just as you would a google.maps.InfoWindow but it supports several additional properties for controlling the styling of the box. You can also use an InfoBox as a map label, so it's useful for identifying landmarks that are not on the base map. InfoBox is now part of the google-maps-utility-library-v3.
The image below shows an InfoBox from my V3 real estate map at imap.garylittle.ca. It's a simple yellow box with a small arrow pointing to the property's location. A flashier box could easily be displayed through creative use of CSS styles.
To learn more about InfoBox, read the class reference and check out the examples.
Lombard Street, San Francisco is featured on a million postcards as "the crookedest street in the world" due to the 8 hairpin bends on the block between Hyde and Leavenworth Streets. The famous turns are clearly visible on a map, but it is not obvious why they are necessary. And the rest of Lombard St looks like an innocent section of straight road from above.
However, it was while driving along the section of Lombard St west of Hyde that I was first introduced to the smell of a burning clutch. I was stuck in traffic in a car with manual transmission trying to drive up what is actually an incredibly steep hill, one of many in San Francisco. But apart from the shading in Terrain view there is no way to appreciate that on a map unless you switch to Street View.
We are therefore happy to introduce a new service to the Maps API family that enables applications to determine elevation profiles. Using either the new ElevationService Maps API v3 class or the Elevation Web Service you can request the elevation in meters for one or more sets of coordinates, or you can request a specific number of elevation samples equally spaced along a path. If any sampling points are over bodies of water, the service will return the depth relative to sea level as a negative number.
The below application uses the Google Visualization API to plot elevation profiles. You can add additional points by clicking on the map or entering an address, drag existing points arounds, and switch between different modes of travel. If you roll your mouse over the profile chart you can see on the map the point that the given sample relates to.
To facilitate easy generation of elevation profiles for routes generated for driving, cycling, or walking directions we have also added a new property to the DirectionsResult object called overview_path. This is a simplified path guaranteed to be short enough to pass to the Elevation Service.
overview_path
As with all other Google Maps API services, the elevation service must be used in compliance with the Maps API Terms of Service which require that it be used in conjunction with display of a Google map. This means that if you display elevation information to your users that you have obtained using this service, or any data that you have derived from it, you must also show a Google map that indicates the points, path, or route concerned.
We think that this new elevation service is a natural complement to our recently launched bicycling directions. Now you can determine in advance just how painful your bicycling route is likely to be. In fact you’ll be happy to hear that the Maps API bicycling directions already factor in elevation, which is why if you ask for a route up Lombard Street you will be sent the long way round.
Posted by Thor Mitchell, Maps API Product Manager
When we launched the Google Maps JavaScript API v3 last year our goal was to develop a framework in which we could deliver compelling and innovative features to our developers that cater to the new breed of location-aware mobile internet devices.
As we look ahead it is clear that HTML 5 offers us the platform we need to deliver on this vision. However as we develop features that exploit the potential of HTML5 it will not be possible to maintain our current level of support for older web browsers. For this reason we will be updating the list of supported browsers for the Maps API v3 on a regular basis. We are applying our first update today by removing Firefox 2, Internet Explorer 6, and Safari 3, while adding support for the Android browser and for Chrome on Mac and Linux.
We understand that many users work in environments in which they are not in control of the browser they must use. We will therefore do our best to ensure that users of browsers that we no longer support continue to have a good experience with Maps API v3 applications. If we develop a new feature that can be easily implemented in a manner compatible with these browsers we will do so, and we will continue to accept bug reports relating to them. We will also attempt to ensure that any features we launch in future that are not compatible with these browsers degrade gracefully for affected users.
The browsers that we no longer support for the Maps API v3 will continue to be supported for the Google Maps JavaScript API v2. We have no plans to change the list of supported browsers for the Maps API v2, and consequently if support for these browsers is important to you we recommend that you continue to develop your applications using the Maps API v2.
If however you are planning a new Maps API application or need to update an existing Maps API v2 application to offer improved support for mobile devices, we encourage you to consider using the Maps API v3. We are excited by the opportunities that HTML5 offers us and hope that you will enjoy using the Maps API v3 to develop the next generation of powerful and immersive Maps API applications.
Geocoding - finding the geographical location of a given address - is one of the most popular features of the Google Maps API. Both the JavaScript Maps APIs and the Maps API for Flash include classes that enable applications to perform geocoding, and there is also a RESTful web service that offers the option of making geocoding requests from server side applications with output in both XML and JSON.
The Google Maps JavaScript API v3 introduced a new format for geocoding responses that offers a number of improvements over the format used in the v2 API:
The Geocoding Web Service is intended to enable precaching of geocoder results that you know your application will need in the future. For example, if your application displays property listings, you can geocode the address of each property, cache the results on your server, and serve these locations to your API application. This ensures that your application does not need to geocode the address of a property every time it is viewed by a user. However we do ask that you regularly refresh your cache of geocoder results.
Note however that it is a requirement of the Maps API Terms of Service that you use the Geocoding Web Service in conjunction with a Google map. This means that when it comes time to use cached geocoder results in an application, the application must display the results or any data derived from them on a map generated using one of the Google Maps APIs or Google Earth API.
If your application needs to geocode arbitrary addresses that are entered by your users while they wait we recommend that you use the classes in the appropriate client API. This ensures that the requests your application generates reach Google directly from your users, which will improve the performance of your application and ensure it is resilient to unexpected spikes in use. For more details, I highly recommend this excellent blog post by our very own Mano Marks.
In addition to an improved response format you will notice some other changes in the new Geocoding Web Service. Requests no longer require a Maps API key, and Maps API Premier customers must sign their requests. In addition CSV output is not supported because we found that the minimal amount of data in a CSV response makes it is difficult to identify false positive results.
2,500 requests may be sent to the Geocoding Web Service per day from a single IP address. This is independent of any geocoding activity generated by applications using one of the client Maps APIs for geocoding. Maps API Premier quotas remain unchanged.
A forward geocoding request to the new Geocoding Web Service with XML output looks like:
http://maps.google.com/maps/api/geocode/xml?address=sydney&sensor=false
A reverse geocoding request with JSON output looks like:
http://maps.google.com/maps/api/geocode/json?latlng=-33.873038,151.20563&sensor=false
Check out the Geocoding Web Service documentation for more details on the options available for language and biasing of results.
In conjunction with the launch of the new Geocoding Web Service we are also announcing the deprecation of the current service, now retroactively named the "Geocoding V2 Web Service". Existing applications using the V2 Web Service need not worry though. Deprecation indicates that we no longer intend to pursue any further feature development, but we will continue to maintain and support the service in accordance with the deprecation policy set out in the Maps API Terms of Service.
We hope that you find the new Geocoding Web Service easier to use and useful. As always we encourage you to check out the Google Maps API Google Group if you have any questions or comments relating to the APIs. We look forward to adding more great features to the Geocoding Web Service in future.
Over the last couple of years, my office has been working on using the Google Maps API to display the Missouri State University campus map. The map is used by campus faculty, staff, students, and visitors and includes buildings, parking and transit system information. Beginning this summer, we started work on incorporating live GPS tracking of our campus buses into the map. Both the idea and GPS application on the buses came from one of our computer science students who wanted more information on the campus transit system.
Using the Google Maps API v3, I was able to create a mobile version of our map for use on smartphones. After showing it to my users, one of the first responses I got was, "Are you going to make this available as an application?". After spending many hours developing a feature-rich mobile web version, the thought of investing a large amount of time to code the same experience on multiple platforms was overwhelming. Then I began thinking of the maintenance headaches; even simple changes, such as adding a new sets of icons for custom markers, would be time consuming. All of a sudden the idea sounded much less appealing. I'd spent all this time on the mobile web version of my map, why couldn't I just use that?
So instead of writing the maps application using the SDK of each phone platform, I wrapped my v3 Maps API site into a WebView inside a stub application. Now all the work spent on the web version automatically applies to the "native" application and my users never even know the difference. The Google Maps API team have even provided some great reference articles for Android and iPhone which help get the process started.
Response time in this type of application was a big concern both within an app and within the browser. I saw significant performance gains by using Closure-Compiler on my JavaScript, using the CSS sprite support in v3 for markers and following most of the suggestions in the Web Performance Best Practices document. To improve the user's initial loading experience I also pre-load the WebView with static HTML that contains a "Loading..." message and use JavaScript to redirect them to the actual map page.
I was initially skeptical of the usefulness of such a project. The mobile version of the map offers users the same functionality that they can get by simply bookmarking the map in their browser. So I was very pleasantly surprised at the both the usage and publicity the application has garnered. Within the first two weeks, the iPhone application was downloaded 1,200 times and the Android application almost 200 times. Both applications are receiving very positive reviews.
We consider this project a huge success. Going forward it will now be a priority to make sure new features work well both on the desktop as well as on mobile devices wherever possible.
Posted by Chad Killingsworth, Assistant Director of Web & New Media, Missouri State University
For Australia Day this year I took a trip with some friends to the beautiful city of Melbourne, Australia. World renowned for the arts, world class sporting events, and a relaxed cafe culture, it's also well known for what Wikipedia tactfully calls "its changeable weather conditions". Or, as Crowded House described it, "Four Seasons in One Day".
This being the case, it's always good to check the weather forecast, and no weather forecast is complete without a map. Now if you're looking for an interactive map, you are spoilt for choice, but if you would prefer a simple static map to print out or view on your phone it's not so easy. Weather maps need weather symbols, and until now the only choices for marker icons on Static Maps have been the regular Google Maps pins.
Although we love our map pins here at Google, we understand that there are times when you need something different, which is why we're happy to announce that the Static Maps API now supports custom marker icons. Just specify the URL of a PNG, GIF, or JPEG icon in the marker definition, and we'll fetch the icon and add it to your map. We'll cache the icons you specify to maintain performance, and even generate shadows for your icons if you wish:
markers=icon:http://maps.google.com/mapfiles/kml/shapes/sunny.png|shadow:false
You can use up to 5 different icons on a single map, each of which can be used for multiple markers, so come rain or shine you can always take the weather with you.
For more details check out the Static Maps v2 API Developer's Guide, and be sure to post any feedback on the Google Maps API Google Group.
Posted by Thor Mitchell, Google Maps Developer Platform team
P.S. Oh, and one more thing. Requests made to the Static Maps API v2 no longer need a Maps API key.
Which is nice.
Opening ceremonies for the 2010 Winter Olympics are just days away and the city of Vancouver glitters in festivity. Its nightly sky has been adorned with 20 robotic searchlights thanks to Rafael Lozano-Hemmer at “Vectorial Elevation” powered by Google Maps and Google Earth APIs.
The user interface for personalization is very intuitive, consisting of an interactive Google Maps view of an overlay of search lights in Vancouver and a 3D view of Vancouver in Google Earth. User selections and configuration of search lights are adjusted using the jQuery JavaScript library and Maps API, and are dynamically reflected in the 3D Earth view using the Earth API.
Find out more on the Google Blog about Google's other offerings like Street View snowmobile for fans of the Games. Or personalize your own Vancouver nightly skyline and let your imaginations and Olympic spirits soar!
Just in time for your holiday coding enjoyment, we have three new articles to get you started on adding maps to mobile and using App Engine for spatial search.
Overview of Mobile Development Options for the Google Maps API Putting a map on a phone seems natural these days. This article goes over the options for developing a Google Map for a mobile application.
Loading a Maps API site in a Native Android Application Google Maps API Version 3 was designed to be used in a mobile environment. If you want to include a V3 page in a native Android application, this is how to get started.
Geospatial Queries with Google App Engine using GeoModel Many developers are moving their applications to cloud computing. Here's how to get started with geospatial queries building on Google App Engine.
So enjoy your holidays, and I look forward to seeing your apps in January!
When we first announced the Google Maps Data API in May, we were excited to provide developers with free scalable hosting of geographic content. The idea was simple: to create an awesome maps mashup, you focus on creating a great user experience and Google will provide scalable hosting and bandwidth. Moreover, your data should be accessible from any platform (like desktop, iPhone, or Android) using your language of choice (including JavaScript, Python, Java, or Objective-C).
Today we're launching several exciting new features based on all the great feedback we've gotten from developers. First, we're adding geospatial and attribute search to your maps. To see these features in action, play around with this College Finder demo (you can download and modify the source code here). I created a Google My Map consisting of approximately 3000 U.S. 4-year colleges, and wrote a JavaScript app to search over this map (with no need to run my own server or database!).
Using the new search features, you can easily request "all colleges within 5km of San Francisco" and apply attribute filters like "[Type:public]". You can also sort the results by proximity to a point (in this case, the center of the map). The results are updated whenever the map is dragged or zoomed, or when the search criteria change.
In addition to search, many developers have requested the ability to enable API access to a public map without requiring users to be signed into a Google account. We've also enabled this today: you can indicate (using the API) that you would like a map to be accessible by others via the API. You can also programmatically control access to the maps you own, by making them public/private or adding specific collaborators. Our official docs will be updated soon but, in the meantime, check our forum for updates about this.
To get started writing your next awesome geo app, you can download and modify our sample code, or refer to our documentation. We look forward to seeing all the great collaborative mashups, store locators, and mobile apps you'll come up with.
If you have questions or feedback, or would like to tell us about your new creation, please visit our developer forum, tweet about #mapsdata, or file a feature request. We have some other great features on the way, so stay tuned and keep mapping!
We're really excited to announce two upcoming hackathons for our Google Geo APIs. The first will be held in New York City on November 20th followed by a second one in Mountain View on December 15th. This will be a great learning opportunity for any developer interested or currently involved in building Geo-enabled applications using our APIs. Come join us for a great session where you'll be able to hack away on your own projects alongside our engineers who'll be readily available to provide support. Below is a list of the various Google Geo APIs you'll learn about:
Registration for these events are completely free, and space is limited. Reserve your spot now using the following links below!
Bring your laptops, your brains, and we'll see you soon!
Calling all Bay Area coders! We've just finalized another hackathon for late September! On September 24th, 2009, from 1:30 to 8, Google will host a hackathon for our Geo APIs in our San Francisco office. At the hackathon, Google engineers will give one or two API overview presentations and then will be on hand to answer all your geo related questions. You can work on suggested codelabs, or just bring your own project and we'll lend you a hand.
The hackathon will cover the following APIs:
Space is limited, so register now! And remember, this will be a code-heavy event, so bring your laptop and come ready to code!
Posted by Roman Nurik, Geo APIs team
So bring your laptops, and your brains, and be prepared to code.
Space is limited, so register now!
Last week at Google I/O we released the Google Maps API (JavaScript version) addition to the Developer Qualification program. Designed for professionals who currently develop or want to develop applications based on Google and Google-sponsored Open Source APIs, the Google Qualified Developer program will help promote developers to the Google community, provide credibility, and leverage the wisdom of the masses in rating and recognizing best in class developers. In this program, we assess developers in four areas, each of which provides a score towards an overall total required for qualification. Developers must maintain a minimum number of points to remain qualified within the program. Points are awarded for examples of development work, community participation, professional references, and scores on examinations.
With the addition of the Google Maps API to the available qualifications, the program landing pages and registration have been moved to the Google Code site at http://code.google.com/qualify. The new landing pages provide information on the program and available APIs, details about qualification requirements, answers to frequently asked questions, and an opportunity to apply as a candidate in the qualification program.
We've also recently partnered with 3rd party training vendors who can help you get ready to qualify. The Developer Qualification program provides a mechanism by which Google can evaluate and promote the best developers in the community, but does not provide training in preparation for qualification. With the success of the program there exists a business opportunity for 3rd party training vendors to develop and deliver this training. In order to stimulate the growth of this ecosystem, several vendors have been identified and are working closely with Google to develop initial training efforts for the Google Maps API qualification.
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.
Posted by Shannon Madison, on behalf of the Developer Qualification team
Give us feedback in our Product Forums.
Follow