Berry, There is still an issue that I can't easily fix. The page is available at the same URL (http://my-test.dreamhosters.com/gmap.html); I only added x/y offset as calculated by the script and as calculated by Google for their tile images.
When the page is loaded, everything looks correct: This is what I calculated for up/left tile 773x1642: -192x-39 -192x-39; window 500x300; up-left 773x1642 and down-right 776x1644 this is confirmed by Google (same offset): http://mt1.google.com/vt/v=ap.106&hl=en&x=773&y=1642&z=12&s=G at -192pxx-39px Now drag the map so that the left top corner is closer to the center to make one new group of tiles to render: me: -192x-39; window 500x300; up-left 772x1641 and down-right 775x1643 google: http://mt2.google.com/vt/v=ap.106&hl=en&x=772&y=1641&z=12&s=Galil at -448pxx-295px you can already see the difference by 256 in both x/y offsets. I compensate for this difference by storing *original* tile number (773/1642) and applying the diff to the offset to get -448x-295. I'm essentially ignoring all calculations of the offset except the first one (with few exceptions, for example zoom changes). Now click "zoom in" button once: me: -166x-52; window 500x300; up-left 1546x3283 and down-right 1549x3285 google: http://mt0.google.com/vt/v=ap.106&hl=en&x=1546&y=3283&z=13&s=G at -422pxx-308px as you can see, I again get different results, but no way to compensate for it as I don't know that this result is different by one tile. Is there a way to adjust the algorithm to calculate the same offset Google is calculating for its tiles? Right now the offset that the algorithm you suggested earlier in this thread calculates is going to be always less than 256, but it seems like in some cases it may be larger that that. I didn't notice any discrepancies in the examples on your website, but since the code is a bit obfuscated I couldn't see where your calculations are different from mine. Thank you. Paul. On Sep 1, 4:44 am, bratliff <bratl...@umich.edu> wrote: > On Sep 1, 6:26 am, PaulKulchenko<paulclin...@gmail.com> wrote: > > > Bratliff, > > > it all makes sense and it seems to work, but there is one small detail > > that bothers me. This is the link:http://my-test.dreamhosters.com/gmap.html > > > I've implemented the logic as described in this thread and seem to be > > getting the correct results, but they are still slightly different > > from what gmap is doing. For example, this is what you'll see when you > > load the map above: > > > Should I simply ignore the difference or is there a bug in my > > calculations? > > If you look at: > > www.polyarc.us/experimental > > you will see the same tile discrepency. It is entirely off screen. > It does not really matter. I have not really tried to figure out what > is causing it. > > I recycle tiles which means I must allocate enough tiles for the worst > case: > > (pixelwidth>>8)+2 > (pixelheight>>8)+2 > > I believe Google allocates an extra tile along each edge also. If you > measure from the center pixel rather from the top-left pixel, tile > replacements will occur at different points. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Maps API" group. To post to this group, send email to google-maps-api@googlegroups.com To unsubscribe from this group, send email to google-maps-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-maps-api?hl=en -~----------~----~----~----~------~----~------~--~---
