groldan
commented
13 years ago The idea when re seeding based on the Atom/GeoRSS feed is that it provides both the old and new shape of changed geometries. So it could be the case that tiles were generated for places where there's no data anymore in order to override old tiles where data used to be. That could be the case as long as the feed is providing the location of features that were either deleted or moved. Could you confirm is that is the case?
When using GeoRSS as the (only) source for seeding a layer's cache and having (3x3) metatiling enabled at the same time for that layer, generated tiles are missing for the target envelope area. When disabling metatiling (setting it to 1x1) tiles are generated OK, covering the correct envelope area.
As my tiles from the backend WMS were all transparent overlays with sparse (GPS) data, it was hard to investigate what/where actual tiles were generated as I could see the seeding doing its work. When replacing the transparent overlay with a non-transparent map, the effect was clearly visible: tiles were generated at odd places outside the seeding envelope and at some zoom-levels not at all. It looked like that the tiles were generated mostly at the outer tiles of the metatile 3x3 matrix. But this did not seem to be consistent. When disabling meta tiling, tiles were generated for the expected areas, i.e. covering the seeding envelope area. Without metatiling the seeding process offcourse would take a proportional larger amount of time, so having GeoRSS-triggered seeding plus metatiling is still a very desirable option.
As for a solution: I can see that GeoRSSPollTask in launchSeeding() creates a DiscontinuousTileRange object which is only used in GeoRSS-triggered seeding. Possibly there is some mismatch in tile-lookup when the SeedTask interacts with the DTR object. I have a fork at https://github.com/justb4/geowebcache so if I find out and/or fix something I'll keep you posted.