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.
Posted by Thor Mitchell, Maps API Product Manager
One feature of the AJAX Image Search API that you might find useful is the ability to retrieve only the images which are visible on a specific website. For example, you could add a search box that allows people to search through just the images on your own site or you could create a slideshow which shows images from your favorite site.
To specify a site, use the setSiteRestriction method on an ImageSearch object. Here is a simple example:
http://code.google.com/apis/ajax/playground/#site_restrict
We can do more than just provide a site-specific image search box, we could also use the search results in a unique way. For example, we could create a slideshow which shows images which match our desired keyword and appear on a specific site. For this example, let's create a simple slideshow that displays images from nasa.gov.
var imageIndex = 0;In the above samples, there are three lines I'd like to call your attention to. The first line to note is the imageSearch.execute at the bottom, here we've entered the keywords that our slideshow images should be related to. Next we restrict the site to nasa.gov using imageSearch.setSiteRestriction. Lastly, we call setInterval once we receive the results of our search for images. The setInterval call tells the browser to run our nextImage function every five seconds.
Here are the two samples we've talked about in action:
The site restriction can also include a path within a website. For example you could do setSiteRestriction(
'http://www.flickr.com/photos/<username>') to search the photos that have been posted by a particular user on flickr.
To learn more about some other neat features of the AJAX Image Search API take a look at our code playground samples and documentation. For questions on this and other topics, drop us a line in the discussion group.
google.load("search","1"); function onLoad(){var searchControl=new google.search.SearchControl;var imageSearch=new google.search.ImageSearch;imageSearch.setSiteRestriction("nasa.gov");searchControl.addSearcher(imageSearch);searchControl.draw(document.getElementById("search-demo"));searchControl.execute("supernova");var imageSearch=new google.search.ImageSearch;imageSearch.setSiteRestriction("nasa.gov");imageSearch.setSearchCompleteCallback(this,searchComplete,[imageSearch]);imageSearch.execute("supernova")}var imageIndex=0; var images;function nextImage(){imageIndex++;if(imageIndex>=images.length)imageIndex=0;var imageContainer=document.getElementById("image-container");imageContainer.src=images[imageIndex].tbUrl} function searchComplete(searcher){if(searcher.results&&searcher.results.length>0){var contentDiv=document.getElementById("slideshow-demo");contentDiv.innerHTML="";var imageTag=document.createElement("img");imageTag["id"]="image-container";imageTag["src"]=searcher.results[imageIndex].tbUrl;images=searcher.results;contentDiv.appendChild(imageTag);setInterval("nextImage();",3E3)}}google.setOnLoadCallback(onLoad);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.
Posted by Shawn Shen, Developer Relations