Thanks for the help, One thing Im not clear about is your mention of a quadtree scan; you say google doesn't expose their code/method, but yet shouldn't that point scan be something that is performed on the client (during all of the mousemove scanning) ???
- I started playing with the panoramio layer with firebug enabled, and I noticed something interesting... Mousing-over a given tile for the first time will cause four ajax requests to be fired... It *appears* that the API divides each tile into quadrants, and will fire a separate ajax request for data points (hotspot 'features') for each quadrant as soon as the mouse 'arrives' to that quadrant... So, if this is correct, it seems that in reality the API doesn't need to worry about simultaneously handling thousands of points; it just needs to update its internal list for only the actual tile & tile quadrant that the mouse is currently over... (Im *guessing* that it tries to re-request on each new 'tile quadrant mouse entrance' and the browser simply caches the json responses, not sure though) if one thinks about it, this makes sense. the panoramio layer uses a 'limited view' method; it only exposes a limited number of image icons per tile at each zoom level. Assuming that a typical, small image 'hotspot' is about 10x10 pixels, and breaking each tile quadrant up into a 128x128 pixel space, it imposes a theoretical maximum of approx. 160+ image 'hotspots' per tile quadrant....handling mouse movements for a list of only 160+ points doesn't seem too bad... And, the 160+ number is completely theoretical & not realistic...since it basically implies a map tile quadrant that's *completely* covered with a uniform grid of 10x10 pixel panoramio icons, rendering that portion of the tile useless...this obviously doesn't happen in the real world... Anyway, I found this interesting & I felt compelled to share... Please keep in mind that all of this is just speculation on my part.... I welcome feedback & corrections, since I'll be trying to implement the same method I described above, and any help or advice that could help to optimize this would be greatly appreciated... Thanks again, P.R. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mike Williams Sent: 2009-08-17 1:41 AM To: [email protected] Subject: Re: clickable regions in custom tile overlay Google certainly don't add any objects to the DOM to catch the mouse movements. So the only thing that they could be doing is continually listening for mouse movements and comparing the mouse position to the list of hotspot boxes that come back from the layer server. The Google code is somewhat opaque, but I reckon that they use quadtree to make the processing efficient. If you were to continually compare the mouseover position to a list of thousands of hotspots by scanning a list one by one, then that would be unreasonably slow. Using a quadtree strategy dramatically reduces the number of comparisons that need to be performed on each scan. See: http://en.wikipedia.org/wiki/Quadtree The Google quadtree code is not accessible, so if you want to do the same, you'd need to write your own. The code at http://www.usnaviguide.com/ws-2008-02/demotilecookies.htm effectively performs a two-pass comparison. It has a list of hotspots for each tile, and scans that list linearly. I guess that's fine if you only have a modest number of hotspots per tile, but I guess it would become sluggish if there were hundreds of hotspots on a tile. -- Mike Williams http://econym.org.uk/gmap --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Maps API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Maps-API?hl=en -~----------~----~----~----~------~----~------~--~---
