Question

Ever noticed that when you go to maps.google.com and do a search (say, car wash), it renders a lot of results (represented by small circles) and a few prominent ones (seen as regular-size pins)?

Notice how quickly it does this?

From what I can tell from analyzing this in Firebug, much of this is generated on the server and sent to the client as a static image.

However, it’s still dynamic. You can still zoom in and out, or click on a result and see a dynamic InfoWindow rendered.

Google have made the map quick and smooth using static images, while still making it flexible.

Is there a way to do this kind of ‘pre-loading’ with my own Google Map (implemented with the Google Maps API)?

Answer 1

The technology that maps.google.com uses is similar to that used in a GLayer. The server dynamically builds tiles and “hotspot” info. The GLayer tiles are also constructed dynamically (and possibly cached) even though the underlying data is fairly static. From the client side, the searched dots technology is identical to the Wikipedia or Panoramio GLayer. The only new trick is that the dot information is generated dynamically on Google’s big fast servers.

The API does not (yet) provide any tools for creating custom GLayers. If you want to do the same sort of thing yourself, using your own database of locations, there are three steps that you need to code:

1. Create your own custom tileserver
   which searches your database for
   items in the tile area and uses a
   graphics library like gd or
   imagemagic to place dots on the
   tile. Use those tiles to create a
   GTileLayerOverlay on the client.

2. When the user clicks on the map,
   send the location of that click to a
   second server. That server should
   check your database and return the
   infowindow text for the dot at that
   location, if any. Returning all the infowindow contents from all the dots imaged by the tileserver would be unacceptably slow, so you have to fetch them one by one, as needed.

3. Changing the cursor when the mouse
   is over a dot is more tricky. What Google
   do is return a list of hotspot
   coordinates for all the dots on each
   tile. Whenever the mouse moves, the
   API determines which tile the
   pointer is over and uses a quadtree
   algorithm to see if the pointer is
   over a hotspot, and change the
   cursor if necessary. If you only
   have a modest number of hotspots per
   tile, then a linear search would
   probably be acceptably fast. If you might have thousands of dots per tile, then you’ll probably need to write your own quadtree algorithm. The Google quadtree code is not exposed, so you can’t use it.

Here’s a page where somebody has done all that. In this case the hotspots are calculated as circles, by comparing the distance from the centre point, even though the dots are square. On maps.google.com the hotspots are calculated as rectangles, by using GBounds.containsPoint(), even though the dots are round.