FYI, our attempt to fix this problem is now live. Changelog update is coming, but in the meantime, please report back if you're still experiencing tile issues.
On Dec 1, 5:55 pm, bratliff <[email protected]> wrote: > On Dec 2, 12:07 am, Ben Appleton <[email protected]> wrote: > > > On Wed, Dec 2, 2009 at 11:03 AM, Ben Appleton <[email protected]> wrote: > > > On Wed, Dec 2, 2009 at 2:54 AM, bratliff <[email protected]> wrote: > > > >> The group interface is clobbering URLs. > > > > What is a "group interface"? > > > Oh, sorry I misunderstood: you mean that the Google Groups user interface is > > destroying URLs that you paste into threads? > > Yes. I did not know what else to call it. > > It appears to be happening just to my links. It looks like a > redirector is being used for tracking purposes. It attempts to > redirect to a URL which itself is redirected to another host. > Apparently, double redirection fails. I suspect it will work if I use > the real URL. It means a lot of old links of mine will not work. It > means I cannot easily move to another ISP. > > With regard to lazy tiles, a screen shot is not very useful. Imagine > a map with a few big gray squares in place of tiles. Imagine staring > at the map for five minutes with no change. In Firefox 2.0, click on > Tools/Page Info/Media. Scattered among the real tile URLs are several > occurrances of "whatever.transparent.png". > > The frustrating thing is not being able to repair it legally. If I > could just reset the "src" property, I could fix it but the "src" > property still points to "whatever.transparent.png". If I could do a > "map.setZoom(map.getZoom())", I could fix it but your optimizer > ignores it & does nothing. Please add something to the API to force a > reload of all tiles even if the API thinks all tiles are already > loaded properly. > > You guys ought to set up a "mine sweeper" on a long delay. If it > actually does fire because no "onload" event handler has reset it for > a full minute, it ought to cycle through all in progress images. If > it encounters any "whatever.transparent.png" images, it would attempt > a reload. It it encounters all "whatever.transparent.png" images, it > would assume an unsupported zoom level. > > For what it is worth, I built a little toy tile stitcher a few years > ago. It does not play games with transparent place holder files. It > just toggles the "style.display" property in the "onload" event > handler. It also manages a prioritized queue to prevent dozens of > tile requests from occurring simultaneously. It is very reliable with > your tiles. It is very fast with your tiles. It enables a user to > change pan/zoom directions quickly without ever having more than four > pending requests in the pipline. Out of view tiles are quickly > expunged from the queue. In flight tiles are not aborted due to > browser reliability & potential backtracking. I use it to run full > screen flight simulation with aerial tiles. -- You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" 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-js-api-v3?hl=en.
