Which version of OpenLayers are you using? Both issues you describe here should be fixed in master.
Andreas. On Mar 20, 2013 1:24 AM, "Chris Berkhout" <chrisberkh...@gmail.com> wrote: > Hi All, > > I've been trying to get offline (localStorage) tile caching to work > like the example > http://openlayers.org/dev/examples/offline-storage.html > and I've run into a couple of problems. > > I'm restricting myself to a single layer, same origin via proxy and I > always set read from cache first (fall back to network). > > The first problem is that after populating the cache and going > offline, failed tile fetches continue to populate the cache. These > appear as black squares in the example (non-cached failures are pink). > Manually turning off "Write to cache" in the example resolves this. > I've been able to avoid this by patching OpenLayers.Control.CacheWrite > to not write failed tiles to the cache, by checking the condition: > !evt.tile.imgDiv.classList.contains("olImageLoadError") > I guess there's probably a better way to do that. > > The other problem I found is that after populating the cache and going > offline, then panning away to non-cached areas and back to the cached > area, things around the edges of the cached areas are disappearing. > This was more obvious when working with my own layer (at detailed > zoom), but could also be replicated using the openlayers example. The > problem seems to be variation (rounding errors?) in the bbox > parameters of the WMS tile request. > > For example, this URL was a cache miss: > > http://m1.pozi.com/geoserver/gwc/service/wms?LAYERS=VicmapClassic&FORMAT=image%2Fpng8&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&SRS=EPSG%3A900913&BBOX=16133716.431963,-4554423.89271,16136162.416867,-4551977.9078052&WIDTH=256&HEIGHT=256 > > Even though the tile it refers to was cached with a URL of: > > http://m1.pozi.com/geoserver/gwc/service/wms?LAYERS=VicmapClassic&FORMAT=image%2Fpng8&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&SRS=EPSG%3A900913&BBOX=16133716.431963,-4554423.89271,16136162.416868,-4551977.9078052&WIDTH=256&HEIGHT=256 > > That's a maxx (3rd bbox value) with last digit 7 instead 8. > > I could avoid this by patching the cache read/write code to use an > optional URL normalization function, which the user could set to trim > off the last digits of the bbox parameters. > > So, I think I've straightened out what's going on, but the only > solutions I can see involve various hacks in the openlayers code. > > Has anyone else run into these issues or got some advice? > > Cheers, > Chris > _______________________________________________ > Dev mailing list > d...@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/openlayers-dev >
_______________________________________________ Dev mailing list d...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/openlayers-dev