Neo Geo Blog

Wednesday, May 28, 2008 at 5:20:00 PM

I have good news and bad news. Let's start with the bad.

The bad: After 2 years, 6 months, and 14 days of dedicated developer community service, the Official Google Maps API Blog is being retired. That's right... the blog you're reading right now, right here, is no more, starting today. No more news will be posted here.

The good: All is not lost! A new blog is taking this blog's place: The Google Geo Developers Blog. Hop on over there to see the first post and get the full story on the change.

So if you're reading this post in an RSS reader, be sure to subscribe to the new blog's feed. And if you're reading this post right on blogger itself, be sure to update your bookmark. Because there will still be plenty of continued Maps API news... you just won't be able to catch it here.

See you all over at the new blog!

App Engine, Local Search, & Maps: Making Static Maps... Interactive?

at 10:50:00 AM

JavaScript and Flash are great for putting Google Maps on your website, but sometimes they just won't do. For mobile browsers or users with dial-up connections, simpler is better. So I wrote an open source non-JavaScript version of Google Maps which is designed to show how easy it is to write an application on App Engine that makes use of two new APIs from Google: The Static Maps API and the Local Search API's REST interface. It doesn't have advanced features like street view and public transportation, but it gives you a searchable map that you can zoom in/out on as well as save locations. It also automatically saves your last map view so that every time you go back to the site it will show you what you were last looking at. Check out the source code.

It uses App Engine to store saved points, the AJAX LocalSearch REST API for search functionality, and the Static Maps API to display maps. App Engine is easy to learn and the data store is useful for this kind of application. The REST API for LocalSearch is also very simple. For more information on it, go here.

To use the Static Maps API, you just need to create a URL with the proper parameters for your desired map view. Keep in mind that you need to set the zoom level (unless you are specifying multiple points — then it's calculated for you). In the vast majority of cases, this is completely fine. In my case, though, I needed to know what the zoom level was, so that I could give the user the option to zoom in/out. That meant coming up with calculations of the zoom both for the multiple points and single point case, and that was the trickiest part of the app.

If you use the AJAX Local Search and it returns one result then there will be a viewport object returned with it. This viewport contains the Northeast and Southwest latitude/longitude bounds that are optimal for displaying this point. However, Static Maps only accept zoom levels and center points. Here's the Python to generate that information:

viewport = json['responseData']['viewport']
mercator_projection = MercatorProjection(18) # Checkout the MercatorProjection class
southwest = [float(viewport['sw']['lat']),float(viewport['sw']['lng'])]
northeast = [float(viewport['ne']['lat']),float(viewport['ne']['lng'])]
bounds = [southwest, northeast]
zoom_level = mercator_projection.CalculateBoundsZoomLevel(bounds, MAP_SIZE)
At this point you will have everything you need to construct the map: the center point (the Local Search point), zoom level, marker point.

Then there's the case where you have multiple points returned by the AJAX Local Search. Since we will have a collection of latitudes and longitude points that we want to display we can just find the min/maxes, do some rounding, and voilĂ  you get a bounding box. With a bounding box and a calculated center point, you can repeat the same steps as before.

mercator_projection = MercatorProjection(18)
bounds = CalcBoundsFromPoints(lats, lngs)
center_point = CalcCenterFromBounds(bounds)
zoom_level = mercator_projection.CalculateBoundsZoomLevel(bounds, MAP_SIZE)

From line 121 to about 285 you'll find all the necessary functions for the situations described above. Try using this code to create your own interactive version of Static Maps, and let us know in the forum if you have questions or just want to show off your nifty app.

geo search 2.0: Data In, Data Out

Thursday, May 22, 2008 at 10:05:00 AM

Last week during the geo madness of Where2.0 and WhereCamp, we announced two enhancements in geo search to make it both easier for developers to get their data into our geo search index and easier for developers to get data back out of the index:

  • Geo Sitemaps: Sitemaps are a protocol that bots use to index content from websites. Last year, we announced the ability to include KML/GeoRSS files in regular sitemaps just like a normal web resource. This year, we announce a special extension for sitemaps that adds geo-specific tags and makes it easier for us to index. To get your geo content indexed as fast as possible, just submit the sitemap to Google Webmaster Central. For more information on creating a KML file to include in a sitemap, read this article in the KML documentation. An example geo sitemap listing a KML and a GeoRSS file is shown below:
  • <urlset xmlns=""
  • Geo search in the API: The Local Search API has traditionally been used to return business listings and address geocodes. As of last week, it can now be used to retrieve any of the content we have in our geo index. There are a couple different ways to do this, depending on how you use the API. If you're using the LocalSearchControl, here's some sample code (and live example) that will return blended results:
  • var options = {
      listingTypes : GlocalSearch.TYPE_BLENDED_RESULTS
    map.addControl(new google.maps.LocalSearch(options));
    If you're using the Local Search API from Javascript, here's some sample code to return only results from indexed geo files:
    var ls = new GlocalSearch();
    ls.setRestriction(GSearch.RESTRICT_TYPE, GlocalSearch.TYPE_KMLONLY_RESULTS);
    And finally, if you're using the Local Search API from somewhere other than Javascript - for example, with our new nifty Maps API for Flash - here's some sample AS3 code (and live example) to return only results from indexed geo files PLUS add a site restrict operator to limit it to results from
    service.url = '';
    service.request.q = "site:" + " " +  address.text;
    service.request.mrt = "kmlonly";
    service.addEventListener(ResultEvent.RESULT, onServerResponse);

There are (atleast) two really cool consequences of this news: 1) you'll be able to enable users of your mashups to instantly find international results where previously none existed, and to be able to find results for non-standard searches (e.g. "dog parks"), and 2) by indexing your content, waiting a few weeks, and then using the local search with a "" appended to the query, you get to leverage the power of google search on your own content with barely any code of your own.

So what are you waiting for? Give us your geo sitemap, use our API calls, and let us know what you think in the Maps API, KML, or AJAX API forums.

libkml Marches On!

Monday, May 19, 2008 at 5:04:00 PM

Google has released version 0.2 of libkml, an open source library for serializing and deserializing KML files. libkml now uses a memory management scheme based on "smart pointers", and has deprecated the use of SCons. On Linux and Mac OS X it now use the traditional automake, and on Windows Microsoft Visual Studio. The "smart pointer" scheme presently restricts support for some alternate language bindings, so libkml 0.2 can only be called from C++, Java, and Python. Version 0.1 also supported PHP, Perl, and Ruby, and is still available in the subversion repository if you're interested. We plan on restoring the those bindings as soon as we can.

Check out the User Guide, and particularly the future development list.

Here's an example of what the code looks like:

// This program uses the KmlFactory to create a Point Placemark and
// prints the resultant KML on standard output.

#include "kml/dom.h"

// libkml types are in the kmldom namespace
using kmldom::CoordinatesPtr;
using kmldom::KmlPtr;
using kmldom::KmlFactory;
using kmldom::PlacemarkPtr;
using kmldom::PointPtr;

int main() {
  // Get the factory singleton to create KML elements.
  KmlFactory* factory = KmlFactory::GetFactory();

  // Create .
  CoordinatesPtr coordinates = factory->CreateCoordinates();
  // Create -122.0816695,37.42052549

  // Create  and give it .
  PointPtr point = factory->CreatePoint();

  // Create  and give it a  and the .
  PlacemarkPtr placemark = factory->CreatePlacemark();
  placemark->set_name("Cool Statue");

  // Create  and give it .
  KmlPtr kml = factory->CreateKml();

  // Serialize to XML
  std::string xml = kmldom::SerializePretty(kml);

  // Print to stdout
  std::cout << xml;

The engineers who worked on it put a lot of thought into making it fast and light weight. However, it is an alpha release. We really would love to have comments and feedback on it, both in the KML Developer Support forum and in the libkml issue tracker.

Love My Maps? Use its Line and Shape Editing in your API Apps!

Friday, May 16, 2008 at 4:30:00 PM

When we launched the map editing tools in Google Maps, the reaction of developers was "This is cool, but how can I use it on my own site?" As someone who was originally drawn to Google in part because of the Maps API and the great developer community around it, I committed to making the My Maps tools useful for developers on their own sites.

Today, I'm pleased to announce that our user interface functionality for editable polylines and polygons is now part of the Maps API.

Say, for example, that you have a GPolygon you want users to be able to edit. Simply call GPolygon.enableEditing() and the poly will have draggable edit control vertices when the user mouses over it. To later make it non-editable, call GPolygon.disableEditing().

We've also exposed additional events for GPolygon and GPolyline so that you can easily mimic the MyMaps behavior (in mashups or Mapplets) by calling enableEditing on "mouseover" and disableEditing on "mouseout". To find out when the user makes an edit, listen for the "lineupdated" event. And if you want users to be able to draw a new GPolyline completely from scratch, just use enableDrawing as shown below:

var polyline = new GPolyline([]);

Every click on the map will add a new vertex to the polyline until the user double-clicks or clicks again on the last vertex. You can also call enableDrawing to lets users append vertices to either end of an existing polyline. And just because everyone likes pretty colors, we exposed methods to let you change the style of a polyline or polygon: setStrokeStyle and setFillStyle. Have fun, and let us know what you think in the forum.

View example in its own window.

Introducing the Google Maps API for Flash

Wednesday, May 14, 2008 at 5:40:00 AM

Here at Google, we receive a lot of feature requests - and it feels great every time we fulfill one of them. The ability to utilize the power of Google Maps from Flash is one of those requests that has been popping up on blog posts and other forums since the beginning of time (or more accurately, the beginning of the Javascript Maps API). Over the past few hours, I've had the enjoyment of finally seeing this particular feature request - a Maps API for Flash - come to fruition. Tiredness will grab me soon, no doubt. If you're one of the first readers of this post, rest assured that I'm unlikely to still be awake: long hours have been worked; pre-launch nerves have jangled. Now it's time to let our baby loose into the world and see how the developer community will embrace it.

So, what do I like about the API for Flash? Smoothness and speed are a big part of it. We've designed it so that Flash graphics can be used for each tile layer, marker and info window - opening up possibilities like dynamic shading, shadowing, animation, and video. When the user zooms the map, magnification changes happen smoothly and place names fade in. After the user drags a marker, it gently bounces to a halt. Generally, Flash allows for much greater embellishment, and, well... "flashiness." I get excited just thinking about the creative ways developers might take advantage of having a Flash API for Google Maps.

What was one of our main design decisions for this project? We knew that version 1 of any software project is not perfect, so we opted to split the interface and implementation. As a result, you can build against the current version of the API, and as we add enhancements and tweaks, your website benefits automatically from each update. When you wish to take advantage of new API functions, only then do you need to download the latest API and rebuild.

What does it look like? We've played with it, thrown our ideas in, and also worked with outside companies to see how they use the API. It's been a pleasure to see some of the demos that have come back. Here's one from AFComponents that shows some of the possibilities:

When I first joined Google in Sydney, I got to hear about the experience of the Maps team when they first watched the traffic and the buzz build for the launch of Google Maps. Well, now I'm ready to experience that with this new API. Do send us feedback, we're looking forward to it.

What remains? Over to you.

Upcoming Events

Friday, May 09, 2008 at 1:49:00 PM

There's four big Geo events in the San Francisco Bay Area this month, and Mano and I will be at all of them. Here's the details:

Where2.0: May 12-14th

Sharing Your Content on the Google Maps API

In this session, you'll roll up your sleeves and learn about publishing and sharing using the Maps API. Then we’ll hear from Google partners about what constitutes “great” content and how they expose it.

Searching the Geoweb: Exposing Your Geo Data to Search Engines

Have you been wondering how to drive traffic to that cool maps mashup you created recently? We’ll show you how to get your maps mashup crawled and indexed, and how best to optimize your content for user discovery via search using KML.

WhereCamp: May 17-18th

No sessions planned! This is an unconference - that means the participants do the session planning on the spot. So if there's a Maps API or KML topic you want to talk about, come on by and propose it! (And stay for the slumber party, there'll be lots of hacking and coffee). And, it'll be at the Googleplex! And it's free!

Web 2.0 Mapping and Social Networks Group: May 20th

Communities + Google Maps: Harder, Better, Faster, Stronger

Pamela Fox will talk about the various ways of using Google Maps & the Maps API to create user-contributed maps, covering the spectrum from no-coding solutions to full custom databases and code, and showing examples of sites successfully using each technique.

Google I/O: May 28-29th

There's lots of Geo sessions at Google I/O, here's just 3:

Harnessing StreetView, Static Maps, and other New Additions to the Google Maps API:

Ben Appleton will review some of the recent additions to the Maps API including how to use Static Maps for fast page loads and printable maps, and how to incorporate Street View imagery in your app.

Hosting Your Geo Data, an Overview of Design Options:

Mano Marks will discuss the various options for hosting your Geo data, including Google App Engine, and explain how to choose the right data model for your project.

The World's Information in Context:

Michael T. Jones will discuss new product directions and key trends of importance to geo developers.

Be sure to visit the Google I/O website to see the complete list of sessions and to register. For those coming from out of town, we've arranged discounted room rates at nearby hotels. Read the details on the website to take advantage of the discount, but move fast because the hotel discount ends May 13th.

We're looking forward to seeing you at some of these events soon.