as simple as possible, but no simpler

Questionable wisdom from someone building weird but wonderful web technology.

Wednesday, February 09, 2005

Mapping Google

By now, many of you will have gone and tried out the new Google Maps application. By and large, you have to admit that it's pretty damned slick for a DHTML web application -- even my wife was impressed, and that's not easy with geek toys. So, in the spirit of Google Suggest and GMail, I've decided to have a quick peek under the hood to figure out what makes it tick.



Not quite like GMail

The first thing I noticed is that it doesn't quite work like GMail. Whereas GMail uses XMLHttp to make calls back to the server, Google Maps uses a hidden IFrame. Each method has its benefits, as I'll discuss below, but this difference of approach does seem to imply that it may not be the same team doing the work.



The Graphics

Probably the most striking thing about Google Maps is the very impressive (for DHTML, anyway) graphics. Now, I'm sure that many of you old JavaScript hacks out there have known this sort of thing was possible for a long time, but it's very cool to see it (a) actually being used for something real, and (b) where normal users will see it.



For those to whom the implementation is less than obvious, here's a quick breakdown. The top and side bars are (more or less) simply HTML. The center pane with the map, however, is a different beast. First, let's address the map itself. It is broken up into a grid of 128x128 images (basically like an old tile-based scrolling console game). The dragging code is nothing new, but the cool trick here is that each of these images is absolutely positioned -- and the 'infinite' scrolling effect is achieved by picking up tiles that are off-screen on one end and placing them down on the other end. The effect is kind of like laying track for a train by picking up track from behind it.




Google map, with tiles outlined


The push-pins and info-popups are a different matter. Simply placing them is no big trick; an absolutely-positioned transparent GIF does the trick nicely. The shadows, however, are a different matter. They are PNGs with 8-bit alpha channels. Personally, I didn't even realize you could depend upon the browser to render these correctly, but apparently (at least with IE6 and Mozilla), you can. And they actually render pretty quickly -- for proof, check out the overlaid route image (at the end of the article), which is often as big as the entire map view.




The pushpin, with its two images outlined


Communicating with the Server

There are two ways in which Google Maps has to communicate with the server. The first is to get map images, and the second is to get search results. It turns out that getting map images is remarkably easy -- all you have to do is set an image tile's URL. Because the coordinate system is known and fixed (each tile represents a known area specified in longitude and latitude, at a given zoom level), the client has all the information it needs to set tile URLs. Each tile URL is of the following form:



  http://mt.google.com/mt?v=.1&x={x tile index}&{y tile index}=2&zoom={zoom level}


I'm not sure what the 'v' argument specifies, but it never seems to change. The others are fairly self-explanatory. One nice side effect of this is that the images have fixed URLs for a given chunk of the earth's surface, so they get cached. If you're doing most of your searches in one region, then the app can be quite snappy once everything gets cached.



Doing searches is another matter. Clearly, you can't 'submit' the entire page, because that would destroy your map and other context. Google's solution is to submit a hidden IFrame, then gather the search results from it. Let's say, for example, that you simply wanted to go to Atlanta. You type 'Atlanta' in the search area, and the following HTTP GET is made:



  http://maps.google.com/maps?q=atlanta&z=13&sll=37.062500%2C-95.677068&sspn=37.062500%2C80.511950&output=js


There are a couple of things to notice here. The 'question' is passed in the 'q' parameter (much like Google). The other arguments are 'z' for zoom, 'sll' for longitude & latitude (your current focus, I believe), and 'sspn' to specify the span/size of your viewing area. What's interesting is what comes back:




<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
<title>Google Maps - atlanta</title>
<script type="text/javascript">
//<![CDATA[
function load() {
if (window.parent && window.parent._load) {
window.parent._load({big chunk of XML}, window.document);
}
}
//]]>
</script>
</head>
<body onload="load()">
<input id="zoom" type="text" value=""/>
<input id="centerlat" type="text" value=""/>
<input id="centerlng" type="text" value=""/>
</body>
</html>


This HTML is loaded into the hidden IFrame which, when loaded, will punt a big chunk of XML back up to the outer frame's _load() function. This is kind of a cool trick, because it saves the outer frame from having to determine when the IFrame is done loading.



I mentioned before that there was some advantage to be had by using a hidden IFrame over making direct XMLHttp requests. One of these is that the IFrame's state affects the back button. So every time you do a search, it creates a new history entry. This creates an excellent user experience, because pressing the back button always takes you back to the last major action you performed (and the forward button works just as well).



Big Hunks of XML

Ok, so now the outer frame's code has a big chunk of XMl. What can it do with that? Well, it turns out that Google Maps depends upon two built-in browser components: XMLHttpRequest and XSLTProcessor. Oddly enough, even though it doesn't use XMLHttpRequest for making calls to the server, it _does_ use it for parsing XML. I'll get to the XSLT later.



Here's an example of the XML response that comes back from the 'Atlanta' request above:




<?xml version="1.0"?>
<page>
<title>atlanta</title>
<query>atlanta</query>
<center lat="33.748889" lng="-84.388056"/>
<span lat="0.089988" lng="0.108228"/>
<overlay panelStyle="/mapfiles/geocodepanel.xsl">
<location infoStyle="/mapfiles/geocodeinfo.xsl" id="A">
<point lat="33.748889" lng="-84.388056"/>
<icon class="noicon"/>
<info>
<title xml:space="preserve"></title>
<address>
<line>Atlanta, GA</line>
</address>
</info>
</location>
</overlay>
</page>


Nothing surprising here -- we have a title, query, center & span, and the location and name of the search result. For a slightly more interesting case, let's look at the response when searching for 'pizza in atlanta':




<?xml version="1.0" ?>
<page>
<title>pizza in atlanta</title>
<query>pizza in atlanta</query>
<center lat="33.748888" lng="-84.388056" />
<span lat="0.016622" lng="0.017714" />
<overlay panelStyle="/mapfiles/localpanel.xsl">
<location infoStyle="/mapfiles/localinfo.xsl" id="A">
<point lat="33.752099" lng="-84.391900" />
<icon image="/mapfiles/markerA.png" class="local" />
<info>
<title xml:space="preserve">Kentucky Fried Chicken/Taco Bell/<b>Pizza</b> Hut</title>
<address>
<line>87 Peachtree St SW</line>
<line>Atlanta, GA 30303</line>
</address>
<phone>(404) 658-1532</phone>
<distance>0.3 mi NW</distance>
<description>
<references count="9">
<reference>
<url>http://www.metroatlantayellowpages.com/pizzaatlanta.htm</url>
<domain>metroatlantayellowpages.com</domain>
<title xml:space="preserve">Atlanta<b>Pizza</b> Guide-Alphabetical Listings of Atlanta<b>...</b></title>
</reference>
</references>
</description>
<url>http://local.google.com/local?q=pizza&near=atlanta&latlng=33748889,-84388056,11825991348281990841</url>
</info>
</location>

{ lots more locations... }

</overlay>
</page>


Again, nothing too surprising when you think about the data that's going to show in the map pane. But how do the results get shown in the search result area to the right? This is where things get a little wacky. The JavaScript actually uses the XSLTProcessor component I mentioned earlier to apply an XSLT to the result XML. This generates HTML which is then shown in the right panel. We've come to expect this sort of thing on the server, but this is the first time I've ever seen it done on the client (I'm sure it saves Google lots of cycles, but personally I didn't even know XSLTProcessor existed!)



Driving Directions

There's one last case to discuss, and that's driving directions. This works just like other searches, including XSLT to show the results, with one exception: the result XML includes a <polyline> tag that two opaque values encoding the geometric route to be taken. This data appears to be base 64 encoded (or something similar, anyway). Remember the giant transparent PNG I mentioned earlier for rendering routes? This data is used to render that sucker. The data looks like this:




<polyline numLevels="4" zoomFactor="32">
<points>k`dmEv`naOdGC??EtD??@|DAxL??hEFjJ@ ...</points>
<levels>BBB???BB?BB??@??@?????BB??@?????@? ...</levels>
</polyline>


This polyline data is then used to request the route PNG from the server using a URL like so:



  http://www.google.com/maplinedraw?width=324&height=564&path=sRS?k@fB@?}As@e@CGAIA}@BwCEu@Bs@?E_@cACS@a@PaC ...



The route overlay


In Summary

That's about it. I hope that demystifies this application a bit; the real magic, of course, is all the work going on to enable this on the back-end. The fact that Google's servers can handle all of these images requests, route finding, line drawing, searches and the like so quickly is the real magic. I also want to point out that their map renderer (or the one they purchased) works _much_ better than all the other ones I've seen on Mapquest, Mapblast, and the like. That alone makes it worth using, if only so you can actually _read_ the map!



I also think it bears noting that Google is pulling out all the stops to build rich web apps, no matter how weirdly they have to hack the browser to make them go. And I strongly believe that this is a trend that is here to stay -- XHTML Strict/CSS/etc be damned. At the end of the day, what really matters to users is compelling apps that let them get their work done quickly.


163 Comments:

At 7:21 PM, Tin said...

An interesting fact: while most mapping systems available online utilize just one map data provider, Google seems to combine the two most complete data sets - NavTech and TeleAtlas.

 
At 7:22 PM, Anonymous said...

Given that there's a finite number of zoom levels, and individual blocks of the map are not redrawn when scrolling - isn't it likely that they've pre-rendered the entire map beforehand?

That would help to explain why it's so fast. Serving an image requires very little work on the part of the server.

 
At 7:30 PM, Anonymous said...

So, any idea what part of the code causes it to fail in Opera & Safari? The strange thing is that the Map itself works fine in Safari, but the searching interface is not drawn.

 
At 7:33 PM, Anonymous said...

Personally, I would like to see konqi/safari/Opera support.

 
At 7:34 PM, Darken Wilde said...

I think the v=.1 of the tile GET is a version number. Maybe so they can have different types of maps for different applications? I could see a Google AdSense application where you can pay for a locaion on the map, and having version numbers could conceivably aid with this.

 
At 7:39 PM, Anonymous said...

There's a swiss mapping app somewhere that uses the same tiling approach, so it's not completely new.

 
At 7:39 PM, Anonymous said...

I dare say that v (in the querystring) is likely to stand for version. It looks like it is currently set for v=.01

 
At 7:44 PM, Anonymous said...

It probably fails in Opera because Opera has no XSLTProcessor, and likley never well, as the Opera authors seem to be against it. However Opera should be perfectly capable of using javascript to manipulate and display XML, its just not as convienent as XSLT

 
At 7:44 PM, Anonymous said...

Keep in mind, we're still dealing with a beta...I'm sure that expanded browser support will come with time! For now, i'm just amazed at how they've managed to create a better product than mapquest, which has been around for years, so quickly.

 
At 7:45 PM, Anonymous said...

Very enjoyable analysis, thanks.

 
At 7:47 PM, Anonymous said...

I don't understand why this doesn't work with Opera 8.0 which implements XMLHTTP. Does it not have an XSLTProcessor?

 
At 7:47 PM, Anonymous said...

Google Maps almost supprts Safari, in the same way that Safari almost supports web standards. As soon as KHTML becomes a standards-compliant engine, Safari will work on a lot more sites.

Wouldn't be a problem if Safari had started with Gecko engine.

 
At 7:52 PM, Anonymous said...

Even if they pre-render all the images for the map - which would seem sensible, they will never pre-redner all the routes. This will require work server side, but I guess that will get hit a lot less...

 
At 7:55 PM, Anonymous said...

RE: 7:47 PM, Anonymous said...

KHTML is a lot less compliant than Gecko, true. The thing is that Safari has a branch of KHTML that is slowly getting better. It's still not there yet, but it's getting pretty close. I use Safari as my primary web browser, but I always check things I'm creating with Mozilla first and then Safari second.

 
At 8:02 PM, Anonymous said...

"At the end of the day, what really matters to users is compelling apps that let them get their work done quickly."

The advent of "new" browsers taking over market share is really making us (web developers) redo sites. We don't have the staff of Google.

This is why my Lyrics site had to be redone to the version it is now. The damned additino of mozilla to the market screwed up my xmlhttp calls.

I really think mozilla is hurting the web more than helping...

 
At 8:03 PM, Anonymous said...

I'd reccon it fails in other browsers because the XML parser isn't available to decode the XML Google sends. Google could've put the data directly into JS variables and not needed to go through XML at all, but that would probably require the server to transform the data from XML to JS. Serving it as XML and requiring the browser to decode it spreads the processing requirements out from the server to the client... thusly speeding up the server.

 
At 8:03 PM, Anonymous said...

Good analysis. I too was surprised by how well PNG works.

To answer one posters question, the map tiles are entirely static and prebuilt for the various zoom levels. Brilliant approach to an otherwise painful load problem.


-MB

 
At 8:05 PM, Noxious Ninja said...

The article said:

"I didn't even realize you could depend upon the browser to render these correctly, but apparently (at least with IE6 and Mozilla), you can."

Pretty much every modern browser besides IE does it out of the box with no problems (gamma is another issue...). Anyway, it can be made to work in IE, but it requires applying IE-only attributes to the image. Looks like Google has chosen to go this route.


Anonymous said:

"Google Maps almost supprts Safari, in the same way that Safari almost supports web standards. As soon as KHTML becomes a standards-compliant engine, Safari will work on a lot more sites.

Wouldn't be a problem if Safari had started with Gecko engine."

Gecko has plenty of quirks of its own, and having another rendering engine that strives to be standards-complaint is never a bad thing.

 
At 8:06 PM, Dejafu said...

Maybe v is for version.

 
At 8:07 PM, Anonymous said...

My guess is that Google has pre-rendered tiles for the whole country. Looking at the street map we guessed that the smallest tiles are about 1/10 of a mile on the side, and if the covered area is about 2000 x 3000 miles, that's 6 x 10^6 square miles or 6 x 10^8 tiles. An empty tile is about 150 bytes, complicated ones are around 3kb, but if we guess the average one is around 1kb, we're talking 6x10^11 bytes, or 600 GB.

That's a high number. My square footage is high and most of US and ocean around it is empty, but the point is that you could store it all on < $500 of hard drives.

The challenge then is serving millions of users -- one option is build a high performance disk I/O system and (ultimately) take advantage of the parallelism of the problem to scale it up. The other one, quite interesting, is to build a system that can keep it all in RAM. If you can get Opteron 1U's with 16GB of RAM for $5000, you need 38 machines to have that much RAM, and each one has a theoretical memory bandwidth of > 2GB/sec, so we're talking a total memory bandwidth of 76 GB/sec and costs $190,000... Much less than an entry-level IBM mainframe.

Even if you only get 1% efficiency at turning that memory bandwidth into output, you're talking about a system that can serve 19 million maps per second.

 
At 8:24 PM, Anonymous said...

How cool would this be if the Map function was connected interactively to the 'Map of the Internet'.

 
At 8:28 PM, Drew from Zhrodague said...

Rock-on, nice commentary. I wonder if we can hack-up our app to start using Google's maps, instead of our own locally-generated ones. http://www.WiFiMaps.com

 
At 8:32 PM, Anonymous said...

Well, it will be quite a bit more than 600GB, you forgot to account for all the zoom levels. That would probably double or triple your number, at least.

 
At 8:34 PM, Anonymous said...

The advent of "new" browsers taking over market share is really making us (web developers) redo sites. We don't have the staff of Google.

This is why my Lyrics site had to be redone to the version it is now. The damned additino of mozilla to the market screwed up my xmlhttp calls.

I really think mozilla is hurting the web more than helping...
Was this post a joke? If you had made your site standards compliant to begin with you wouldn't have a problem. It's web designers like you ignoring standards and only coding for IE that cause the problem, not a standards compliant browser.

 
At 8:36 PM, Anonymous said...

Since Google acquired Keyhole, I wonder what the likelihood is that they'll eventually expand this map software to include satellite images for more detail?

 
At 8:36 PM, Justin Mason said...

'Whereas GMail uses XMLHttp to make calls back to the server, Google Maps uses a hidden IFrame. Each method has its benefits, as I'll discuss below, but this difference of approach does seem to imply that it may not be the same team doing the work.'

hmm; IMO, it may not be the same team, but I doubt that's why it uses an IFrame over the XMLHttp object. I would guess that the hidden IFrame approach is being used here entirely in order to support the back button. One of the most widely-voiced technical criticisms of Gmail is its lack of back-button support.

 
At 8:41 PM, Anonymous said...

"I really think mozilla is hurting the web more than helping..."

You are wrong.

And I am a web developer.

You always should write ANY product with as many people in mind as possible. With about 3 or 4 browsers you can test for 99.99% of the internet population.

 
At 8:45 PM, Chris said...

Could you provide a link to your previous article on Gmail? I'm really interested in that one, but cant seem to find it in your blog.

 
At 8:51 PM, cayblood said...

All they need is a hardware load balancer and plenty of off-the-shelf servers. No big deal. Google's whole approach to hardware has been to buy cheap commodity servers rather than big iron. What makes this possible is their excellent backend systems.

 
At 8:56 PM, Anonymous said...

This is a map of Switzerland that acts like the google map, but with photo data as well as roads:

http://map.search.ch/index.en.html

Been around for a few months at least. I like how when you zoom in closer it scales the lower res images up while it loads the high res ones. Makes it feel much faster.

 
At 8:57 PM, Anonymous said...

And they use Akamai to serve those millions of images from the edge as fast as possible... It's really smart way.

 
At 8:59 PM, Abhay Kulkarni said...

Pretty good analysis. Did anyone try if this works ok on a dial-up connection? I wonder how long the multiple round-trips would take on a dial-up connection.

 
At 8:59 PM, Anonymous said...

At 8:02 PM, Anonymous said...

I really think mozilla is hurting the web more than helping...

----------

So let me get this straight - Microsoft plays fast and completely loose with all standards, screws java, deploys vbscript, deploys activex, and mozilla is hurting the web? Thanks! That's the funniest thing I've read all day!!

 
At 8:59 PM, Yakov Shafranovich said...

The reason why Google Maps doesn't work in alternative browsers is because XSLTProcessor is an invention of Microsoft which was picked up by the Mozilla team at some point, just like XmlHttpRequest. It is not defined in any public standard what so ever.

 
At 9:01 PM, Anonymous said...

Regarding potential for Google to link the keyhole satellite imagery to google maps: They have more of a business problem than a technical problem. And its not that this is technically trivial, but Google's a giant-killer when it comes to programming. They charge a $30 subscription for useing keyhole right now. I'd bet it is more likely they start placing keyhole ads and links on their google map when you view it.

 
At 9:01 PM, Anonymous said...

Have any of you taken a look at the mapping technology at www.sandcodex.com?

Go to Technology -> Demos, and click the Map Demo. This is what I'd really like to see in future mapping utilities.

 
At 9:02 PM, Anonymous said...

v=.1 -- most likely version = 0.1
I think you are missing 'y=' part of name=value parameter for the coordinate in one of your URL examples.

Otis
--
http://www.simpy.com/simpy/User.do?username=otis

 
At 9:10 PM, Anonymous said...

hmm; IMO, it may not be the same teamJust what i was thinking. even though google aparently likes its employees to be working on many things at once, including pet projects, thats has to be a seperate team.

Space would never be a problem with google. Even if this project took 2 terabytes, all they do is add more cheap motherboards w/decently large hard drives and they get increased power. Remember, they CACHE the web with google cache. How much space do you think they have?

 
At 9:10 PM, Anonymous said...

"The fact that Google's servers can handle all of these images requests, route finding, line drawing, searches and the like so quickly is the real magic."

I guess the magic ended by the time I got there. Tried a couple different machines using both IE and FireFox and neither even rendered the whole map. Many tiles were missing, labels would disappear and scrolling just left blank patches. Maybe their servers are overloaded, I have no idea, but I won't be using this service if it stays like this.

 
At 9:13 PM, Anonymous said...

Try adding "&output=xml" to any google map url. Gives you the same results (map, local search, directions) in XML format. Now that's cool.

 
At 9:15 PM, Anonymous said...

I had a brief look at the Javascript - and it seems to use VML - Microsoft's proprietary Vector Markup Language used in IE. Any idea why?

In addition to the Google and OddPost style DHTML interfaces, take a look at betfair.com which uses a similar (frame-based) DHTML interface.

 
At 9:15 PM, Anonymous said...

Downsides: No center crosshairs. It's possible to launch a map just by knowing the lat & lon coordinates, but those coordinates can't be pinpointed on the map. They're *somewhere* in the middle, but that's not really good enough. Likewise, there's no way to add you own pushpins, which most on-line maps have.

It's still a beta, so maybe those concerns will be addressed.

 
At 9:15 PM, Anonymous said...

Of course, you are missing the interesting part in all of this.. the tile based approach is pretty obvious, what I want to know is how they are mapping the lattitude and longitude to the x and y grid request they are making to the mt.google servers.

I stared at the Javascript for a bit and didn't see where that was being done and it's the real heart of the issue to me. At least in order to do something interesting for me (tm) with the data. :)

 
At 9:20 PM, Anonymous said...

I was impressed about the popup you get when you click on a stickpin or a # on the driving directions... Very clever zoomin with a dropshadow as well. I'm surprised it wasn't mentioned in the article?

 
At 9:22 PM, Anonymous said...

It's definitely a beta, but thanks for shedding some light. I think I might be able to shed some light on the 'v=' tag - I believe that this is a version tag for the map protocol/server request. This will allow google to start to integrate the logical services on the next version, like local.google.com and others.

 
At 9:28 PM, Anonymous said...

About the 600*num_zoom_level Gb storage and access speeds, they use (like google) the incridible GFS, so preformance is really _not_ a problem :)

More on the GFS here: http://labs.google.com/papers/gfs.html

 
At 9:30 PM, Anonymous said...

I tried using this last night. When you print the map, the line showing your route is gone! I know it is still "beta" blah blah blah, but isn't that a pretty big omission?

It also wastes paper when printing... do no evil?

 
At 9:35 PM, Anonymous said...

That polyline data is cool. You didn't touch on how the center method works, but I imagine if you could de-encode the polyline data to get the points out of them, you could then enter a series of "center" commands that would take you from point to point as though your driving directions were animated for you right there in the browser. With the zoom level set to street this would be a real nice feature.

 
At 9:37 PM, Anonymous said...

Thank you for the great review! I wonder if Google will offer the possibility of mapping several locations for FREE. I know mapquest has this as a pay service, but I don't want to pay it for a do-it-yourself web site. Or do you guys know of some kludge to accomplish it?

 
At 9:40 PM, Anonymous said...

The comment about the size of all the pre-rendered tiles being about 600GB is mostly correct. The total amount of all the zoom levels depends mainly on the zoom difference between adjacent levels. If the difference is 2 (that is, the area represented by 1 tile on level N is represented on level N-1 by 4 tiles) then the total disk of all levels is 800GB or 4/3 x 600GB. The 4/3 is just the sum of 1 + 1/4 + 1/16 + 1/32 = 4/3

The key is that the number of tiles in any level of lower resolution is less than the number of tiles at a level of higher resolution.

If the zoom difference between adjacent level is sqrt(2), the the total disk requirement is 1.2TB since we have 1 + 1/2 + 1/4 + 1/8 = 2.

 
At 9:42 PM, Anonymous said...

The missing line when you print is actually a known Firefox printing bug (that used to be so uncommon that it hasn't been a priority to fix, I guess) -- it doesn't render transparent images when you print.

 
At 9:42 PM, Anonymous said...

What would be really cool with this is if they were to integrate contour maps with the street maps and made the map system allowed to show elevations as well. Maybe even some sort of 3d view. That would require a lot more space and power though.

 
At 9:43 PM, Anonymous said...

This just gave me a great idea - they could support the addition of ANY data - and any server could feed extra tiles that are transparent overlays.

For instance, you have an option that says overlay 1 is "satmaps.com/webservice/" Every time it requests a tile, it ALSO requests a tile from each active overlay (beginning of url = overlay setting, rest of url = whatever that tile normally is) Then IF the satmaps site wants to provide you satellite images, they can, but google doesn't have to make the business arrangement themselves.


BUT anybody can put up their own maps, because you only need to sparsely support the tiles. I could make google maps show a completely custom picture of my house for anyone who puts my overlay in the URL - and I need to create one tile for each zoom level - what's that, 8? and return transparent for everything else.

I'm a flash programmer, not a DHTML guy, but it might be possible to suppress errors for 404'd tiles, in which case I could make my own "webservice" to provide this by simply arranging 8 static images on my server.

And anyone using the system still has to see google's ads. And it costs them nothing on the server side (the client just requests additional images from a 3rd party server...)

ben.slash A T xig D O T net

 
At 9:49 PM, Anonymous said...

What's hurting the web is that 99% abuse stylesheets and LOCK fonts in a tiny size which you can't adjust (at least not in MSIE which most people). In countries like Great Britain and Australia this is seen as discrimination against visually impaired people, and is actuall illegal.

So lets hope those lazy bum web designers are going to take 5 minutes more and design a site where you can ADJUST THE FONT SIZE!

 
At 9:57 PM, Anonymous said...

Downsides: No center crosshairs. It's possible to launch a map just by knowing the lat & lon coordinates, but those coordinates can't be pinpointed on the map. They're *somewhere* in the middle, but that's not really good enough. Likewise, there's no way to add you own pushpins, which most on-line maps have.I'm running Windows, and on both Mozilla Firefox 1.0 and IE 6, double clicking will center to that point on the map.

 
At 10:01 PM, Anonymous said...

Unfortunately for many residents of Canada, there is no real detail above the 50th parallel. You can see this best when zooming in to Medicine Hat, Alberta. I noticed it when I was trying to locate my house in Calgary, Alberta.

I'm sure however that they will expand the data in these areas eventually.

 
At 10:04 PM, Anonymous said...

The images are not 8 bit, they are 24 bit PNG. IE supports 8 bit out of the box, but needs DXImageTransform to draw 24 bits PNG. The reason why, is that only the 24 bits version has alpha transparancy :)

 
At 10:08 PM, Anonymous said...

'The reason why Google Maps doesn't work in alternative browsers is because XSLTProcessor is an invention of Microsoft which was picked up by the Mozilla team at some point, just like XmlHttpRequest. It is not defined in any public standard what so ever.'

What? XSLT is a w3c standard. Microsoft just happens to have a client side XSLT processor. Most XSLT processing is done on the server side but it doesn't have to. M$ simply embeds a processor in it's browser. no problem with that surely?

 
At 10:11 PM, Anonymous said...

You CAN de-encode the polyline data. The JS function to do it is in maps.1.js and is called, not surprisingly, Lb.prototype.decodePolyline. I translated it to Perl and ran it for my own test data, then imported the results into Street Atlas 2003 and they matched nearly perfectly (the Google route was actually more true to the streets as they actually exist than the SA route.)

 
At 10:13 PM, Anonymous said...

I, personally, can't wait to see them integrate this with satellite imaging data. You know it's coming.

-Pavel

 
At 10:23 PM, Anonymous said...

nice job on the analysis and write-up. google obviously has some tricksy folk when it comes to these interfaces. nice to see someone pushing the browser so far yet doing it in ways that will work for so many people.

 
At 10:29 PM, Anonymous said...

I think the technology behind GMaps is from KeyHole http://www.keyhole.com

KeyHole developed an amazing application to search aerial and satellite maps in 3D. And Google acquired KeyHole Corp last October: http://www.google.com/press/pressrel/keyhole.html

You can download a 7day-free-trial from http://www.keyhole.com/body.php?h=downloadKeyhole

Gus

 
At 10:30 PM, Anonymous said...

wow... this is what DHTML should have been a long time ago! DHTML has been around for a while - but compatibility differences have scared off anyone big from doing anything other that mouse overs, and the ocassional drown down menu. maybe google will prove to the world that the DHTML 'platform' is now stable enough to start doing some cool stuff!

 
At 10:35 PM, Anonymous said...

"What would be really cool with this is if they were to integrate contour maps with the street maps and made the map system allowed to show elevations as well. Maybe even some sort of 3d view."

As a bike commuter, this would be a really nifty option...I wouldn't be as surprised by hills in a new area.

 
At 10:38 PM, Anonymous said...

Thanks for the analysis. I disagree somewhat with your distinction between hidden iframes and xml http requests. The back button does work with GMail. I thought (and correct me if I am wrong), that GMail also uses the hidden iframe trick.

-Dylan Schiemann

 
At 10:51 PM, Anonymous said...

"Unfortunately for many residents of Canada, there is no real detail above the 50th parallel. You can see this best when zooming in to Medicine Hat, Alberta. I noticed it when I was trying to locate my house in Calgary, Alberta."

I was actually noticing the exact same thing myself; curiously enough, I was zooming in around Medicine Hat too, and then in around Calgary . . . for such a sparsely populated province, we certainly do seem to have a web presence...

 
At 10:53 PM, Anonymous said...

google maps is only 2D, i have been working on a 3d/isometric mapping system for maps/games etc running on dhtml, and php+gd to do the rendering of the tiles from a grayscale heightmap.

check it out:
http://www.pc-gamers.com/webgamex/iso_js_clean.php

Oh, and beware because of the large amount of tiles i use (2500) your browser WILL have a hard time comming the next minute.

using just 50 larger tiles, and ghostframes to fetch more tiles onScroll from the server decreases the load a few hundred times.

 
At 11:00 PM, Anonymous said...

Using keyboard arrow keys to navigate the map is way cool!

 
At 11:02 PM, Anonymous said...

What's hurting the web is that 99% abuse stylesheets and LOCK fonts in a tiny size which you can't adjust (at least not in MSIE which most people).While the web designer in question probalby shouldn't have made the fonts so small to begin with, the problem with resizing them falls squarely on IE. Don't blame broken software on people who have nothing to do with it.

 
At 11:10 PM, Anonymous said...

They use Akamai for the DNS of mt.google.com, not for serving the actual HTTP traffic as someone else mentioned.

 
At 11:27 PM, Anonymous said...

...Was this post a joke? If you had made your site standards compliant to begin with you wouldn't have a problem. It's web designers like you ignoring standards and only coding for IE that cause the problem, not a standards compliant browser.You don't do much web development do you? The standards aren't implemented entirely correctly in any browser. So if you think you can just do it exactly by the standards and its going to display correctly in every browser on every platform, you're smoking crack or something. Or more likely you haven't actually tested this mysterious working cross platform standard. The reality is that the "standard" isn't really going to look nice without painful tweaking for each browser.
I like to think of this "problem" as job security.

 
At 11:28 PM, Anonymous said...

As to why the site uses IE's proprietary (and unsupported) VML to render the driving route, it's presumably to reduce the load on the server for creating big transparent PNGs and then shipping them back to the client.

The page request downloads the polyline data in the big chunk o' XML. If the browser is IE, it just takes that data and inserts the appropriate < v:shape / > elements to draw the line. If the browser is Firefox, it has to send all that polyline data back to the server and ask for a 32-bit PNG (not 24-bit, as some have said, as 24-bit PNGs don't have transparency). So IE is a lot more efficient in this case, as the server doesn't have to do anything further to render the route. I wouldn't be surprised if at some point they start checking for the existence of an SVG plugin on non-IE browsers (assuming SVG plugins can cleanly overlay HTML).

--JD

 
At 11:41 PM, dkjariwala said...

Wow! Great analysis!

Btw, can I quote you on this:
"And I strongly believe that this is a trend that is here to stay -- XHTML Strict/CSS/etc be damned. At the end of the day, what really matters to users is compelling apps that let them get their work done quickly."

You nailed it right, baby! :)
JD

 
At 11:49 PM, osierra.com said...

Thanks a lot for this excellent analysis!

 
At 11:57 PM, Anonymous said...

a) I wrote a quick Firefox extension to open the current Google Maps location in Keyhole. You need to have Keyhole installed, but the trial version works fine. Install Google Maps to Keyhole 0.1b) "Of course, you are missing the interesting part in all of this.. the tile based approach is pretty obvious, what I want to know is how they are mapping the lattitude and longitude to the x and y grid request they are making to the mt.google servers."

The magic happens in "gb.prototype.getBitmapCoordinate=function(Ka,Pa,J,e){" in http://www.google.com/mapfiles/maps.1.js . The gb object contains all the code for transforming lat/lon to bitmap coordinates. It's not a hard problem, it's a simple affine transformation. They just create a lookup table by zoom level, and then do some subtraction and multiplication. Not too comlicated, just hard to piece together from their obfuscated js.

 
At 12:05 AM, Bj� said...

A similar (used loosely here) kind of map is available for Europe at www.map24.com. It uses Java, quite well actually, to display and update the map in real time. Zooms are real time as well, and as you zoom out more details are loaded in the background and added onto the map.

Combines data from Navtech, Teleatlas and a bunch of other providers.

 
At 12:05 AM, Anonymous said...

"Since Google acquired Keyhole, I wonder what the likelihood is that they'll eventually expand this map software to include satellite images for more detail?"

Seems like the folks at Redmond are looking at combining street maps and satellite images too. Check out the Longhorn Commercial Real Estate Concept Video.

For what it's worth, here's another recent gee-whiz mapping site that uses java for incredible zooming effects.

 
At 12:18 AM, Anonymous said...

Is there any way to use google's maps through your own web site? I.e., set up an interactive google map frame for use in your own page, or even just access the images so you can set something like this up yourself? Anyone know? Please email me at ario521@yahoo.com if anyone knows how to do this.

 
At 1:10 AM, nothingman said...

I have found Google maps to work much better on IE so far. Rendering in Firefox 1.0 is much slower, compared to IE6. Firefox needs to fix their image rendering for printing - the traced route disappears completely when trying to print from Firefox.

Another great Google service, but it needs A9-like street imaging and the ability to print a "printer-friendly" version of a route.

 
At 1:24 AM, Anonymous said...

While the web designer in question probalby shouldn't have made the fonts so small to begin with, the problem with resizing them falls squarely on IE. Don't blame broken software on people who have nothing to do with it.You are wrong. The fault lies with web designers for not knowing the difference between px and pt. Ideally, pt should scale, while px should not. The Mozilla approach to zooming is just a recognition of the fact that web designers are generally morons. (I'm a web designer myself, as it appears many, many other readers of this article are).

The other "valid" approach to zooming is to do it like Opera does - i.e. zooming everything, not just the text. This has its drawbacks as well and isn't 100% perfectly implemented.

 
At 1:48 AM, qwiki said...

Someone already mentioned that the transparencies in the dropshadows are using 24-bit PNG images that are not currently supported in IE. There's an excellent tutorial here that shows how to do a browser check and implement DXImageTransform if it finds IE. Excellent article!

 
At 2:04 AM, Anonymous said...

Quick -- somebody code up a screen saver that uses their map data! I'd run it.

 
At 2:14 AM, Anonymous said...

"...web designers are generally morons."

Well, I'm not a moron, and quite frankly I have better things to do than study a thick book of so-called "standards" that are unevenly implemented and mostly not there. If I start with w3c purity, I get nowhere. So my site ends up being a bunch of ugly hacks just like yours, genius boy.

The Google people have done the best they can -- it's only a beta, after all -- and that's pretty damn good given the fragility and inconsistency of the underlying browser framework. I agree with their decision to support FF and IE, and damn the rest. Same decision I made.

 
At 2:30 AM, Anonymous said...

When getting directions, Google Maps lets your browser request the little line drawing connecting the two points.

So, Google Maps will draw you anything, as long as you know how to encode it. I wrote a little Perl program for that, google-draw.pl.

Here it is drawing a little spirograph-like pattern.

-- Neil K

 
At 2:33 AM, Anonymous said...

Thanks for the tip on where to find the mapping, I disected it and it's this:

x = (-98.35 - lng) * 2^(zoom) * 0.77162458338772
y = (39.5 - lat) * 32

Have fun.

-Nic

 
At 2:34 AM, Anonymous said...

Err, on the above, the multiplyer for Y is obviously (2^zoom) as well, doh.

 
At 2:56 AM, Anonymous said...

actually, it's "navteq" not "navtech" - the company changed names about a year ago - rumour has it that the 'q' stands for "Quality Engineer Wesley Torres" but that's unsubstantiated at the time of publication ...

 
At 3:00 AM, Anonymous said...

Maps... whatever... just made today 48% on GOURT google puts. Now that's something useful from them folks...

 
At 3:14 AM, Ryan said...

I'd be interested in learning how to add multiple "pins" to the map for specific addresses.

I'd like to ultimately apply it to MetroFreeFi. More specifically, I'd apply it to maps like this: http://california.metrofreefi.com/city.php?city=San%20FranciscoAny help?

 
At 3:15 AM, Anonymous said...

You don't do much web development do you? The standards aren't implemented entirely correctly in any browser. So if you think you can just do it exactly by the standards and its going to display correctly in every browser on every platform, you're smoking crack or something. Or more likely you haven't actually tested this mysterious working cross platform standard. The reality is that the "standard" isn't really going to look nice without painful tweaking for each browser.
I like to think of this "problem" as job security.
Cut the crap. While it is true, that browsers do have some nuances of their own it is not "painful" to get site look nice in pretty much any minstream browser, event IE5+.
And yes, I do a lot of web development, I earn my living this way since 1996. Never had too much problems with cross browser rendering.
And yes, that is because I was standards cautios since the very begining. If you do not know neither standards nor browsers, then yes, it will be painful for you.

 
At 3:23 AM, Anonymous said...

Kudos to Google for a nice new service. And kudos to you for this nice "under the hood" review. It's a pity though that it's only USA (and Canada?). I wonder if they'll ever add European maps?

Regards,
rydel.net

 
At 3:33 AM, Anonymous said...

Does anyone know what IE security and advanced settings are required for Google Maps? Even though I can reset to default security to make it work, I have not yet been able to determine what settings that I normally have changed/disabled that is keeping the map from working completely. Also, the zoom tool doesn't work for me at home under IE 6 XP SP2 even though it does at work under IE 6 on Win2k.

 
At 3:39 AM, Anonymous said...

Weird border errors. Hotels in Warren, MI:

http://maps.google.com/maps?q=hotels%20in%20warren%2C%20miZoom in about halfway. One hotel in Warren, the rest are in Canada.

 
At 3:53 AM, Anonymous said...

As noted in above post:

...Try adding "&output=xml" to any google map url. Gives you the same results (map, local search, directions) in XML format. Now that's cool ...

From a few tests that I did, this means we now have
a "free" geocoding web service ... lots of companies charge big bucks for this! Working on Python hack.

 
At 4:55 AM, Anonymous said...

"I really think mozilla is hurting the web more than helping..."
Since the rest of your comment wasn't incoherent babbling, I can call you neither a troll or a dumb-@ss. However, I would like to hear you back this up with even the smallest semblance of fact or rhetoric. How could the presence of additional standards compliant browsers possibly be bad for the web or even specfically, great web apps like this one ? What the frock is your point ?

 
At 4:56 AM, Anonymous said...

Eat Boca Burger - you will understand the secrets of technology

 
At 5:27 AM, Anonymous said...

do people know if their implementation violated patent #6,724,382? The two applications drive pretty similar, but I don't know enough about Google's to hazard a guess.


http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=1&f=G&l=50&co1=AND&d=ptxt&s1=6,724,382.WKU.&OS=PN/6,724,382&RS=PN/6,724,382

 
At 6:10 AM, Anonymous said...

"I really think mozilla is hurting the web more than helping..."

You might as well try to claim Google is hurting the web too. As much as their mapping is superior to Yahoo/Mapquest/Microsoft -- Mozilla is playing the same role with IE.
And if you haven't heard, Google may well be making their own version on top of Firefox... imagine what new innovations they may add, you may find yourself converting...

 
At 6:17 AM, Anonymous said...

Not to mention Microsoft's latest stupid patent application: 20050023524. Looks like google is doing a similar base N encoding of lat/longs in a URL. Tsk tsk.

http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220050023524%22.PGNR.&OS=DN/20050023524&RS=DN/20050023524

 
At 6:47 AM, Kyle Mulka said...

Ha! I found a corner!

This might indicate that google renders the map pieces ahead of time.

If you zoom in a few times, you will see that its not finding some of the images.

http://maps.google.com/maps?ll=28.999207%2C-84.000907&spn=0.005714%2C0.009620

 
At 6:56 AM, Anonymous said...

Nic: close, but no cigar. This works for sure, given lat, lng, zoom (in javascript):

x=Math.floor(Math.floor((lng + 98.35) * (131072 >> zoom) * 0.77162458338772) / 128);
y=Math.floor(Math.floor((39.5 - lat) * (131072 >> zoom)) / 128);

url = "http://mt.google.com/mt?v=.1&x=" + x + "&y=" + y + "&zoom=" + zoom

 
At 7:30 AM, Lucas Wyrsch said...

Isn't it Google's logical move after having introduced Google local to complete the picture synergistically with Google maps? It shows that Google labs is doing an excellent visionary work and that they clearly invest in services that will be needed in the future!

 
At 8:23 AM, Anonymous said...

An image of the whole of mainland USA leeched from google maps zoom level 11. 448 tiles leeched and stitched together via perl.

the (0,0) tile is located at about the centre of Kansas.

Each zoom level increases the resolution by 2 (and hence the number of tiles goes up by 4).

Zoom - Number of tiles for mainland USA
13 - 28
12 - 112
11 - 488
8 - 28672
1 - 469762048 (at 1 tile per second, this will take about 14 years to leech off the site. The final image, if I had the time to leech it, would have a resolution of about 7million * 4million pixels)

 
At 9:42 AM, Anonymous said...

But at that high resolution, Google has no need to store huge numbers of tiles - it turns out that the US isn't a densely populated country and therefore lots of the tiles are simply blank. It would be very easy for Google to optimize this out. Perhaps then the total size of the images would be enough to store in RAM?

 
At 10:24 AM, Anonymous said...

http://www.uk.map24.com/

 
At 10:27 AM, Anonymous said...

http://map.search.ch/

 
At 10:35 AM, Anonymous said...

Hi,

Map24.com is also available for the US, including
US map data.

Check it out. It's much faster than Google...but for me it is very hard to be objective... ;-)

So, we are expanding our team! Please send your
application to: jobs-us@mapsolute.com.

Alex (Co-founder of Mapsolute/Map24 ;-)

 
At 10:37 AM, Anonymous said...

Using that Javascript (thx), here's a little lat/lon/zoom tile grabber.

http://brainoff.com/geocoder/gmaps.html-mikel

 
At 10:48 AM, Anonymous said...

Instead of just pulling tiles... can you figure out how to add the "pins" to the mix? showing multiple locations of, let's say, all dunkin donuts in the usa?

based on a feed of some sort of consistent addresses?

 
At 12:48 PM, Anonymous said...

Well, I'm not a moron, and quite frankly I have better things to do than study a thick book of so-called "standards" that are unevenly implemented and mostly not there. If I start with w3c purity, I get nowhere. So my site ends up being a bunch of ugly hacks just like yours, genius boy.

You really are a troll, aren't you? This is "divert the topic when getting cornered 101". The issue I was commenting on was clearly pt vs px and how most web devs are morons for not using them correctly.

While I disagree with you for on the larger topic as well, this was not what was commented about.

 
At 1:40 PM, Anonymous said...

http://maps.google.com/maps?ll=42.346558%2C-71.096092&spn=0.013214%2C0.030216

NO Cincinnati! No Gary, Indiana either. Could this be on purpose?

 
At 2:26 PM, Anonymous said...

WHAT!?!?!???
YOU MEAN THIS ISN'T VECTOR!!?
NOOOOOOOOOOOOOOOOOOOO

 
At 2:58 PM, Anonymous said...

I'd like to point out that since each block of map data is structured as a query, most caches won't in fact cache the data at all. The map data would be served much faster if it allowed caching and was in fact static.

http://images.google.com/mapping/(zoomlevel)/(x-y).png for example.

I'll let Google figure that one out on their own -- some nice URL tricks let you make your URI's look that way but function as queries anyway of course; good for semi-static data (maps that might be updated someday, but not tomorrow).

I got all excited though, thinking about the possibilities of my handheld tracking me by GPS and automatically moving the Google map around to match, instead of needing map downloads on it in the first place.

 
At 3:32 PM, Anonymous said...

I think Google knows a thing or two about caching. They serve all those images from Akamai anyway, so it probably doesn't matter if anyone else is caching them.

 
At 4:05 PM, Anonymous said...

why didnt they use SVG? everything would be great, it would be pretty easy to port on cell phones for example =]

 
At 4:12 PM, Anonymous said...

Okay, I've been playing around with sending requests to Gmaps via a Python proxy and manipulating the files returned on the fly.

As a result I've created a bookmarklet that loads the required XML file into the page:

javascript:(function() {window.parent._load('<?xml version="1.0"?><page><title>Somewhere</title><query>Somewhere</query><center lat="49.275428" lng="-123.116856"/><span lat="0.017998" lng="0.027586"/><overlay panelStyle="/mapfiles/geocodepanel.xsl"><location infoStyle="/mapfiles/geocodeinfo.xsl" id="A"><point lat="49.286428" lng="-123.116856"/><icon image="/mapfiles/marker.png" class="local"/><info><title xml:space="preserve"></title><address><line>Somewhere</line></address></info></location></overlay></page>', window.document)})();

If you save this book marklet and click on it when on any (?--certainly the home page) Gmaps page it should move you to a location in Vancouver, Canada.

By changing various values you can do some more experimenting... For example, I have successfully added another "location" tag with an id "B" and new coordinates. Also I changed the marker image to be a random png from the Google site--but discovered the image dimensions seem to be hard coded so it was distorted.

--Follower.

 
At 4:15 PM, Anonymous said...

Yeah! I am curious about that too!
Could it be because they got everything else in javascript... and if they can do this in JS then why not?

 
At 4:24 PM, Anonymous said...

The ability to add another marker/pushpin would be great. Surely there's a web genius out that who can reverse engineer this ?!

 
At 4:51 PM, Cap'n Ken said...

Nice piece.

Of couse, if Google were REALLY slick, they'd render the marker shadows according to the current position of the sun in relation to the spot on the map.

 
At 5:21 PM, Anonymous said...

So the Coffeyville Country Club in Kansas is in the exact centre of the United States? Cool!

"The Heart of America!"

 
At 5:42 PM, Anonymous said...

Great work. Thanks!

Check out: www.terrafly.com

Java applet tiling US satellite imagery + a ton of meta data.

 
At 5:53 PM, Anonymous said...

I've located probably the most interesting object ("_m") on the page, which is demonstrated with this bookmarklet which pans the map:

javascript: (function() {_m.map.pan(100,0)}) ();

The available properties and methods are as follows (care of the handy JavaScript Shell bookmarklet):

props(_m)

Fields: map, mapContainer, panel, metaPanel, permalink, feedbackLink, urlMaker, vpage, vpageDoc, lastSearchSpan
Methods of prototype: beforePrint, afterPrint, loadMap, createMapControl, onMapStateChanged, resizeMapView, getWindowSize, loadIconClasses, loadXML, loadVPage, showOverlayPanel, showDirectionsPanel, search, clearSearchState, getPageURL, email, print, initSafari, loadSafari
Methods of prototype of prototype: setTimeout, _setTimeoutDispatcher, eventHandler, trace

props(_m.map)

Methods: onzoom, onmousedown, onresize
Fields: container, disablePopups, disableDragging, zoomLevel, topLeftTile, currentPanOffset, centerBitmap, tilePaddingOffset, tableSize, overlays, locations, panDistance, panKeys, spec, viewSize, div, infoWindow, directionsDiv, dragObject, tileImages, onpan, onspecificationchange, oninfowindowclose, stateListeners, lastPageCenter, lastPageZoom, directions, centerLatLng, lastLatLng, openLocation, panSiner, panStart, panTimeout
Methods of prototype: createMapDiv, loadTileImages, deleteTiles, initializeMap, getSpanLatLng, getCenterLatLng, getBoundsBitmap, getBoundsLatLng, calculateTileMeasurements, configureImage, onDrag, onMove, rotateTiles, rotateLeft, rotateRight, rotateUp, rotateDown, getTotalOffset, onDragStart, onDragEnd, onDoubleClick, onClick, getRelativeClickPoint, reconfigureAllImages, pan, doPan, cancelPan, recenterOrPanToLatLng, recenterOrPanToBitmap, centerAndZoom, centerAtLatLng, centerAtBitmap, addStateListener, onStateChanged, onResize, getCurrentOffset, switchSpecification, setSpecification, zoomTo, toggleTileBorders, addOverlay, createLocalMarker, createLocationMarker, clearOverlays, getDivCoordinate, repositionOverlays, setMarkerPosition, loadVPage, registerKeyHandlers, onKeyPress, onKeyUp, ignoreKeyEvent, startContinuousPan, doContinuousPan, onWindowBlur, onIconMouseDown, clearInfoWindowArgs, infoWindowNavigate, showInfoWindow, addMarkersToInfoWindowMask, addMarkerToInfoWindowMask, showSizedInfoWindow, showMapBlowup, createSpecChangeLink, onInfoCloseClick, closeInfoWindow, panToInfoWindow, repositionInfoWindow, getVMLPathString, createRawVML, getBitmapVectors, getVectorPath, getEncodedImageSource, createVectorSegments, createImageSegments, drawDirections, drawDirectionsMarkers, showDirectionsStart, showDirectionsEnd, showDirectionsStep, getDirIndicatorAngle, getDirIndicatorPath, hideDirectionsMarkers, directionsMarkersAreVisible, createMapControl, createZoomControls, createPanningControls, createZoomSlider, getRelativeZoomSliderPos, getZoomFromRelativeCoord, showCopyright, createCopyright
Methods of prototype of prototype: setTimeout, _setTimeoutDispatcher, eventHandler, trace

_m.map.viewSize
(684, 516)

This should allow specifying things like a pan from one place to another, and adding additional markers, via Javascript bookmarklets. This approach is probably more practical than intercepting the XML/JS retrieved from the server (which is still possible & could be interesting).

--Follower.

 
At 7:15 PM, Anonymous said...

The tiling is nothing new, Terraserver has been doing it for years and Topozone.com did it also until they switched over to UMN Mapserver so they could offer richer content.

Tiling has the advantages that it is significantly cheaper to server precomputed images than to compute them on the fly. Especially, when the content is relatively static. If there is one thing that google knows how to do well it is having TONS of cheap disk spread out all over the place and lots of servers. This makes it easy to server lots of map tiles quickly and has the advantage the the image tiles get cached along the way and so they probably don't have to server half the requests anyway.

 
At 7:48 PM, Anonymous said...

Last thing for the moment...

The following bookmarklet will follow a plotted route from start to finish, moving the map as appropriate:

javascript: (function () {mv = function(i) { c = _m.map.directions.polyline.getPoint(i);_m.map.recenterOrPanToLatLng(c); if (i < _m.map.directions.polyline.numPoints - 1) {window.setTimeout("mv("+(i+1) + ")",500)}}; mv(0)})();

It works best when you've zoomed in pretty closely. It has no error checking so ensure you have actually got directions currently listed. It takes no notice of the zoom level nor how many points there are in the route, so it could take a long time if the route is long. Obviously there are improvements that can be made along those lines.

I've tested this under FireFox 1.0 on Mac OS X, I'd be interested to know if it works successfully elsewhere.

--Follower. (follower@myrealbox.com)

 
At 8:58 PM, Anonymous said...

What would be really neat is for aerial photgraphy, but with the a-z style mapping overlayed as well, like at Multimap(The images on there are a few years out of date, the building site is now an entertainment complex, and a tram line has been built as well - must be from about 1999-2000)

Kev

 
At 9:28 PM, Anonymous said...

Follower, how do i add the bookmarklets? Can you link them?

 
At 9:47 PM, Anonymous said...

with regard to multiple locations on one map...

If this is the general query:
?q=1600 Amphitheatre Parkway Mountain View, CA 94043I'm not aware of any strategy for making an array out of url variables.

perhaps there's a way to reverse engineer the local google listings to include a specific data set.

 
At 9:53 PM, Anonymous said...

When I tried printing, I got the line but it was displaced off the route by about 3/4' page units. Someone earlier mentioned that the missing line when printing was a known Foxfire bug, but my line showed up -- it was just in the wrong place. What is causing this displacement?

 
At 12:34 AM, Anonymous said...

Syntax for the PNG .htc behavior file would be
behavior: url(png-opacity.htc);

NOTE: Have seen very recent report of WinXP sp2 not working with this hack.

 
At 12:41 AM, Anonymous said...

Just curious if the push pins were really 8bit or 24bit PNG. Don't kwow how you'd get the transparent/translucent shadows with 8bit PNGs.

I wonder if Google did the .htc file hack? IE/Win can recognize and handle the alpha channel with an HTC file, known as a behavior file. By using a PNG-opacity behavior file called from a CSS statement (yep, CSS), you can get transparent PNG on WinIE.

Syntax for the PNG .htc behavior file would be
behavior: url(png-opacity.htc);

NOTE: Have seen a very recent report of WinXP sp2 not working with the png-opacity.htc file hack.

 
At 2:42 AM, Anonymous said...

Following the Follower's lead, I extended the bookmarklet to move the start marker along as we follow the trail:

javascript: (function () {mv = function(i) { c = _m.map.directions.polyline.getPoint(i);_m.map.recenterOrPanToLatLng(c); _m.map.setMarkerPosition(_m.map.directionsStart, N.get("local"), c); if (i < _m.map.directions.polyline.numPoints - 1) {window.setTimeout("mv("+(i+1) + ")",750)}}; mv(0)})();

Kinda drags on my 3yo G4 Tb, would be nice to have a stop button.

-matt

 
At 3:53 AM, Anonymous said...

Heh Matt,

I had just been thinking of doing exactly that! (I knew I shouldn't have had that shower... :-) )

It should also be possible to create a new marker (using the createMarker or similarly named function) using a custom image. I'm not sure if the image dimensions can be changed, but if not probably a simple person icon would work...

If no one beats me to it, I might try it later...

Your change worked okay on my 800MHz iBook under Firefox--and looked pretty cool! :-)

--Follower

 
At 8:00 AM, Anonymous said...

Opera support isn't coming anytime soon.

See the section titled XSL and XSLT and an explanation.

 
At 8:51 AM, Anonymous said...

"This just gave me a great idea - they could support the addition of ANY data - and any server could feed extra tiles that are transparent overlays."

[...]

"And anyone using the system still has to see google's ads. And it costs them nothing on the server side (the client just requests additional images from a 3rd party server...)"


Sure, they COULD do it this way.

Or ANYONE could write their own front end to take advantage of all the features of Google Map, plus ad their own overlays to do whatever they want, with a completely customized interface that didn't even have Google's logo on it.

The technical way they've accomplished that means hacking the client application (before Google's recent tricks, I never would have called anything written in Javascript a 'client application')--means hacking the client application is relatively easy. Although there are a few important details that haven't been reverse engineered yet; maybe Google has tried to make it dificult, maybe not.

But the way this is implicated makes that kind of customization technically possible. Which is really damn cool.

Whether it would be legal or whether Google would let you get away with it, another question. One we will probably see the answer to soon.

--Nil

 
At 9:22 AM, Anonymous said...

output=xml thats a interesting choice of words. Try this, do a search on google and on the results page, enter &output=xml to the end of it.

I got different thing depending where I started the code from, if it was from google search toolbar in firefox the message was plain but from the home page I got the following;

Forbidden
Your client does not have permission to get URL /search?hl=en&q=admin+console&btnG=Google+Search&meta=&output=xml from this server. (Client IP address: 150.xxx.35.xxx)

Also note that if you do not send us the entire code below, we will not be able to help you.

Best wishes,
The Google Team

/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/+/
Nrja28oXD ..... and the rest

So does anyone know why this error page, because other random words I tried got me my search results and hence must have been ignored.

 
At 2:24 PM, Anonymous said...

I have put my research up on http://libgmail.sourceforge.net/googlemaps.html and included the bookmarklets in a form that they can be dragged onto a bookmark bar.

I'll put additional information there as it is discovered.

--Follower.

 
At 3:26 PM, develOOp said...

You should check out the european map service www.map24.com..
Their using a java applet to do amazing things with maps.
Some juicy detail.. the company has a partnership with Google for displaying maps when you search for a city in Google.
Due to the new cooperation between Google, Inc, and Mapsolute GmbH, maker of the unique mapping portal Map24.com, it is now possible to search for city maps in all European Google search engines. If you enter a city name into Google.nl, the first result list entry is a special link to Map24.com that brings up the corresponding city map. On the result page, for sure, the full set of the rich Map24 options is available to the users.

 
At 3:58 PM, Anonymous said...

I've posted posted a sparsely commented and partially de-obfuscated listing of Google Maps' JavaScript source here. Required reading for all who want to know what you can do with a browser and lots of JavaScript!

 
At 5:14 PM, Anonymous said...

I have added Part 4 which shows how to have a custom marker move along the route:

http://libgmail.sourceforge.net/googlemaps.html

--Follower.

 
At 9:13 PM, Anonymous said...

Ok, which one of you brought gmaps down?

 
At 10:57 PM, Anonymous said...

Hey, look, people are trying to have a useful conversation here...

 
At 11:40 PM, Anonymous said...

Hmmm....doesn't seem to work with IE 5.5 under Windows 95. Map doesn't render at all, instead get javascript error "this.map not defined". Funny ... the Swedish map works fine.

 
At 1:50 AM, Anonymous said...

Well isn't that interesting. Google seems to have made a change and gotten rid of the &output=xml option. The page always comes back in HTML now. The XML document is still in there however. Just look for:

window.document.vpage = '<big chunk of xml>';

Go figure.

-matt

 
At 2:08 AM, Anonymous said...

I too just discovered that output=xml no longer works. The odd thing is -- as Matt noted -- the XML is still in there! So if they were trying to thwart people trying to get free geocoding info, all they did was add to the bandwidth going out of their server. Weird.

-- Adam

 
At 4:48 PM, Anonymous said...

Pretty good analysis. Did anyone try if this works ok on a dial-up connection? I wonder how long the multiple round-trips would take on a dial-up connection.You can try it yourself. Use Sloppy - a slow proxy to simulate a dial-up line. Keep in mind to clear your cache, or go to areas you haven;t been before.

To answer your question, this works pretty well even over a 28.8K line.

I wonder when I can access this on my cell-phone/in my car? Combined with GPS and traffic information. This becomes the navigation system of my dreams.

K<o>
Teach software with Animated Manuals from Conficio

 
At 6:49 PM, Anonymous said...

Syntax for the PNG .htc behavior file would be
behavior: url(png-opacity.htc);

NOTE: Have seen very recent report of WinXP sp2 not working with this hack.
I found a fix (and explanation) for this not working in SP2 (look for the mime-type headline)K<o>
Teach software with Visual Help from Conficio

 
At 10:57 PM, Anonymous said...

Whoa! It found a route from JFK to San Francisco in under 10 seconds!

 
At 8:28 PM, Anonymous said...

Any word on the missing continents? Is anybody 'Searching' for them?

 
At 3:27 AM, Anonymous said...

i still like map24.com better

 
At 6:42 AM, Anonymous said...

output=js strips out most of the content, much closer to what I assume output=xml offered. any tips on getting this to excel for geocoding would be helpful

 
At 9:24 AM, Anonymous said...

for reference, this works:
http://www.bazily.com/geocode

 
At 7:30 PM, bernard said...

Idea: What about achieving a smooth zoom transition effect by just playing with the width and height of the images?
Maybe a bit complex, but it could be done with a bookmarklet...

-- bernard

 
At 2:35 AM, Anonymous said...

I have worked on a similar mapping system applet in the past -- one that supports continuous panning *and* zooming. Before I post the link, I just wanted to give a disclaimer -- we're having some temporary problems with the applet in IE, so use Mozilla or Firefox. Anyway, the project is here. Comments would be most welcome.

 
At 6:45 PM, Anonymous said...

How can one find the lat/lon of the queried point from google maps?

 
At 10:04 PM, Anonymous said...

Really Slick.

Takes Lat,Lon, input (e.g.
43.5, -80.4 - needs the comma), but (like a previous poster asked), can I get lat,lon back out?

 
At 7:33 PM, Anonymous said...

"can I get lat,lon back out?"I made a bookmarklet that will tell you the coordinates of the current map centerpoint.

 
At 3:15 AM, Anonymous said...

How do they manage to make just the pushpin images (not including the transparent area) clickable? It's not a square boundary..it's actually in the shape of the pushpin..that's neat

 
At 8:24 PM, Anonymous said...

The product underlying Google Maps is the "Drill-Down Server" from Telcontar along with associated mapping software. For a description of Google's implmentation of this product, see What's Under the Hood?, and for a description of the server itself, see Drill Down Server.

 
At 9:55 PM, Anonymous said...

now if we can just get google maps to participate with flickr groups like in my neighborhood. (drool.)

 
At 1:13 PM, Rob said...

I think its a real shame Google with the effort Google have put into this, they didn’t take the opportunity to promote standards...ECMA script, SVG and true cross browser support. An SVG rendering engine on every computer thats been used to view Google Maps or installed with a Google toolbar would have taken the web so much further forward.

 
At 11:45 PM, ytt said...


The mappping/routing/searching/geocoding technology behind Google Map is from a company called Telcontar (http://www.telcontar.com)

 
At 8:08 PM, Anonymous said...

So if they are using VML for IE why don't they use SVG for mozilla? As I understand mozilla natively supports the SVG namespace. Or does one need a special SVG build to get that to work?

 
At 9:22 PM, Anonymous said...

So if they are using VML for IE why don't they use SVG for mozilla? As I understand mozilla natively supports the SVG namespace. Or does one need a special SVG build to get that to work?

 

Post a Comment

<< Home