|
When I look at the main public OSM map I often see patches where the map suddenly stops, where bits are missing or the ways don't line up with each other between two tiles. This makes the map look pretty scrappy and unreliable - especially when demonstrating it to someone new to OSM. It is generally caused when one tile has been re-rendered to show recent changes to the map, but a neighbouring tile has not yet been rendered and still shows the 'old' image. It seems to me that map changes should be managed, so that a newly re-rendered tile is only ever published when each of its four adjacent tiles are either unchanged or have also been re-rendered and can be published to the tile server at the same time. Has there ever been any attempt to coordinate changes to the rendered map like this? (or is there perhaps already a solution to this that I don't know about?) |
|
The tiles are actually rendered on a 8x8 grid, so it's much rarer to have data changes noticeable in this way than it would be if the tiles were rendered individually. The more common problem is that your browser is caching individual tiles, and they expire at different times depending on when you first viewed them (along with other reasons that I won't go into here). So what you are seeing is a mixture of tiles of different ages, and a hard-refresh of your browser often cleans this up. The larger 8x8 grids of tiles ("metatiles") are re-rendered when the data changes, so there is some implicit synchronisation between adjacent metatiles. When the tileserver is quiet all the rerendering can be completed within a few seconds, but at some times of the day the queue can grow long enough that adjacent metatiles are re-rendered at significantly different times (i.e. more than a few seconds apart). However, this has a much smaller effect than the browser-caching that I've previously described. |
