Google Maps pushes the envelope

The instant Google Maps appeared, a lot of us knew right away that we'd never use MapQuest again. Google's mapping and direction-finding service is a stunning improvement. The maps are gorgeously readable, and they fill as much of the screen (or the printed page) as you give them. Scrolling the map works in the most natural way, by dragging the image. The mapping service dovetails with, which finds businesses by city or ZIP code. In direction-finding mode, each step along the route offers a link that, when clicked, pops up an enlarged view of the intersection.

What rich and smart client technologies enable this magic? DHTML, JavaScript, CSS, XML, and XSLT. As is the tradition when Google launches a new service, curious hackers immediately took Google Maps apart to see how the magic was done. The best early analysis came from Joel Webber, who worked out the details of image tiling, dynamic updating, and route plotting. Among other interesting discoveries, he found that the application uses the browser's built-in XSLT engine to transform packets of XML received from the server into search results, displayed as HTML.


The W3C can bless this approach or not, but with Google Suggest and now Google Maps, Google has thrown down the gauntlet. The modern browser is an XML-aware client. Savvy Web developers have known about these features for a while, but now Google has legitimized them and pushed them squarely into the mainstream. My guess is that we'll see an explosion of pent-up creativity as more Web developers discover, and begin to exploit, the full power available to them.

But wait, there's more. If you append the term "output=xml" to any Google Maps URL, the server will send back an XML packet. APIs? We don't need no stinking APIs. In 20 minutes I was able to build a proof-of-concept app -- made from snippets of HTML, JavaScript, and XSLT -- that accepts city names or ZIP codes and displays information about local businesses. [Full story at]
Events moved a bit too quickly for this column. By the time it hit print, the output=xml party was over, but another one had started as people dug into the JavaScript capabilities exposed by Google Maps. The screencast I made to demonstrate the route animation hack described here has proved so popular that I wish I'd cleaned it up a bit better. If you've watched it, you know that the audio is sketchy. For the record, here's what happened. I recorded the video in Camtasia and then, following the procedure described here, I rerecorded a playback so I could fast-forward and rewind while laying down the audio. All went well until I produced the Flash output. Normally Camtasia's encoder does a great job with screen videos, compressing them down to well under a megabyte a minute. But this four-minute video turned into a 50MB .SWF file! I guess the encoder doesn't do well with the irregularity of maps.

It always helps to have more than one tool in your kit and, in this case, I reached for the Blue Pacific Flash encoder. After produced the Camtasia movie as QuickTime, I used Blue Pacific to turn the QuickTime into Flash. It did compress the movie down to a manageable 8MB, but along the way the audio got munged. Here were my two mistakes. First, I shouldn't have let Camtasia compress the audio that I fed to Blue Pacific. Second, I shouldn't have deleted the AVI that contained the uncompressed audio -- that was just an unfortunate slip. I guess I could redo the audio track but, well, life is short, and lesson learned.

A final note about this column: Google Maps' client-side wizardry is way cool, but the real heavy lifting -- as Wil Rivers wrote me to point out -- happens on the back end. "The product underlying Google Maps is the Drill-Down Server from Telcontar, along with associated mapping software," Wil writes. "For a description of Google's implementation of this product, see, and for a description of the server itself, see"

Amazing stuff. Thanks for the pointers, Wil!

Former URL: