Thank you Bratliff and Marcelo! This is exactly the information and ideas I was looking for.
To summarize, I see four things needed to work with tiled overlays: 1. detect when a new element/tile is needed 2. attach to the right element to move with the map 3. position the element 4. recalculate when the map is re-centered or zoomed in/out For #1 there are several options: 1. use getTileURL; only available in v2 for now. Works well for new tiles, but the "active" tiles still need to be tracked to keep the number of active objects small 2. monitor DOMAttrModified/DOMNodeInserted events; this requires DOM level 2 support, which IE6 doesn't have 3. check boundary on "move", which seems to be what bratliff suggested. 4. anything else I missed? For #2 I can simply use addOverlay. There is also EInsert, ProjectedOverlay, SparseTile and others. For #3 I can use the algorithm suggested by bratliff in this thread For #4 I need to track "recenter" and "zoom" events. For zoom, there is zoomend, but there is no zoomstart and zoomend comes too late in the process after all the tiles are already loaded (or at least after all getTileURL calls are done). I couldn't find anything that tracks re-center events. There is movestart/moveend, but I didn't see these changing the tile offsets I calculated for #3. Right now I'm just relying on getTileURL and side stepping this issue, but I'm not sure if I need to do more than that. > offsetX=pixelX-(pixelX>>8<<8); is this significantly faster than pixelX % 256? Paul. On Aug 29, 7:44 am, bratliff <[email protected]> wrote: > On Aug 28, 9:26 pm, Paul Kulchenko <[email protected]> wrote: > > Both V2 & V3 provide a "fromLatLngToDivPixel" method. V2 also > provides a "fromLatLngToPixel" method expecting a zoom level. V3 does > not have a "fromLatLngToPixel" method but the arithmetic is fairly > simple for a Mercator projection. It is also quicker to do it > directly if you have to do it repeatedly. > > With the two methods, determine the pixel position of the same point. > I like to use the center of the map because it is reliable. The > corners can be unreliable at low numbered zoom levels if the map wraps > around. The X & Y pixel differences are the map offset. It will not > change during dragging but both "setCenter" & "setZoom" will cause it > to be recalculated. Why it was not simply set to zero is unclear to > me. In a home grown tile stitcher I never have to reset it. It is > always zero. > > Once you know the global pixel position of the center of the map, you > can determine its top & left tile offsets by shifting both pixel > coordinates: > > offsetX=pixelX-(pixelX>>8<<8); > offsetY=pixelY-(pixelY>>8<<8); > > The difference between the pixel position & the normalized tile > position is the pixel offset relative the top left of the tile. Every > other tile is positioned some positive or negative multiple of 256 > pixels from the center tile. A simple bounds check will determine > which tiles are visable. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
