views:

566

answers:

3

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)?

+1  A: 

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.

Mike Williams
A: 

I'm doing something similar - but instead using a tile layer, I just send server-clustered markers to the browser whenever the view changes. If your data is static, you can pre-cluster your markers and it would be incredibly fast with tens of thousands of markers.

Our site can't use pre-clustering because the markers can be searched and filtered, but it's still pretty fast up to about 20,000 markers. Still working on it...

Chris B
Hey Chris, sounds like an awesome site. Do you have any of it up on the web yet? Could you send me a link?
jonathanconway
A: 

can i download it?

Adam