The Google Maps Data API is a great way to host your geographic data on Google’s scalable, high-performance servers, making your data accessible across platforms using HTTP or one of our client language libraries.
In December, we announced spatial and attribute searching using the Maps Data API, which enables you to filter a large set of features by radius, bounding box, or text attributes, and sort them by their distance from a location. This means you can now create an interesting Maps API mashup (like our College Finder code sample), without running your own server or spatial database.
Today, we’re excited to make it much easier to import your geographic data as a single CSV file or KML file, instead of uploading many individual features. You can now upload thousands of features using a single POST request, and then immediately perform scalable searches over your data (while controlling exactly who has access to your maps).
If you haven’t yet tried the Maps Data API, now is a great time to give it a spin, since uploading data just got a whole lot easier.
Posted by Matt Holden, Maps Data API Product Manager
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
Google Code is running a pilot on user-contributed notes to the API documentation. This feature is currently enabled for the documentation of a handful of products, including the Google SketchUp Ruby API! The ultimate goal of this feature is to provide a richer documentation experience for our developers, similar to that offered in open source projects such as php.net.
We invite you to participate by adding notes, insights, or code examples to a particular doc. Your note may take up to 24 hours to appear after you submit it. All notes will be moderated to ensure they provide a useful contribution to the topic to which they are attached. Requests for help with the API should not be submitted as notes, but should continue to be posted to the Google SketchUp Developers Google Group.
Posted by Simone Nicolo, Google Sketchup Team
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.
Social networks came into existence thanks to our instinctive need for sharing. Facebook grew out of college campuses by allowing students to share photos or "faces", while Twitter grew by enabling users to share short and quick "tweets" or status updates. As smartphones like iPhone and Android led to the rise of the mobile web, location signature of GPS-enabled devices added a new twist. Users could share locations and activities, opening up a wide range of possible applications, and creating brand new specialty social networks.
As I recently moved from OpenSocial to the Geo APIs, I'm very excited to see that Google Maps is the default platform to power this fast growing segment of what I call the Geo Mobile web. In this post I'm going to highlight this emerging trend by sharing a few of my favorite examples.
Let's start with FourSquare, which is all about sharing the location and activities of users. When a user signs in from a mobile device, FourSquare detects the current location of the user, performs a reverse geocode to fetch a list of places nearby and sends them back to the user, who can opt to check in at one of the places and share it with others. In this snapshot the Google San Francisco office is shown on Google Maps using the Google Maps JavaScript V2 API. Users can check-in to a place, see check-ins by others, explore places nearby, and build up social contacts by adding friends, all the while having fun by earning badges.
Gowalla by Alamofire is another application building on this same concept of user check-in and sharing location and activity. When a user chooses a place of interest, activities by others at that location are shown and the user can choose to add people as friends, discover new places, pick up, drop off, and trade items with others.
Gowalla's web app version uses the Google Static Maps API to show a map view of a place while the iPhone native app uses the MapKit framework to render a map.
It is interesting to note that users of these apps initially start out without a built-in social graph but can gradually build them up by sharing their own whereabouts and discovering the location and activities of others.
This kind of viral sharing has boosted the growth for Facebook and Twitter in the past and it is once again driving the creation of these specialty social networks on the new frontier of the Geo Mobile web.
Established social networks like Twitter have taken notice. They recently enhanced their APIs by offering geotagging for tweets and local trends, which have spawned innovative mash-ups like Trendsmap.
The rise of these specialty social networks on the Geo Mobile web is predicated on the introduction and wide adoption of smart mobile devices, the viral spread in user sharing check-ins, as well as the availability of geo data sources and services. Google Maps is the developer solution of choice for many of these applications in regards to data source of tiles and places and services like geocoding, and I'm looking forward to seeing more innovations in this exciting arena.
Give us feedback in our Product Forums.
Follow