Slow rendering of some tiles of Openstreetmap Standard


8 days ago I improved a very simple wetland multipolygon: an outer closed way with a water inner area. All the elements (the 2 ways and the relation) already existed, I didn’t change geometry, I didn’t change the ways, I just put back some tags on the relation.

  • at zoom 18, rendering was updated in a few minutes : Relation: 11143425 | OpenStreetMap
  • at zoom 17, rendering is still outdated 8 days after my changeset: Relation: 11143425 | OpenStreetMap
  • same thing at zoom 16 to 14
  • but rendering is ok at zoom 13, 12 and 11 (at 10 or smaller zoom the area is almost invisible on my screen so I don’t know).

Same thing with this big multipolygon:

  • at zoom 13 all is ok /relation/11979428#map=13/50.3531/44.1880
  • at zoom 14 a part is outdated /relation/11979428#map=14/50.3502/44.1449
  • worse at zoom 15 /relation/11979428#map=15/50.3431/44.1279
  • very bad at zoom 17 /relation/11979428#map=17/50.34552/44.12372 (if you move the map at this zoom you will see that the outdated part is more than half the area of the entire multipolygon)
  • but better at zoom 18 /relation/11979428#map=18/50.34547/44.12408

Why it doesn’t work at highest zooms but work at lowest zooms ? A few months ago it was the contrary, renderings at highest zooms were updated quite quickly and we needed a few days at lowest zooms to see the updated renderings: it was better in my opinion, 8 days and no rendering at zoom 17 for the first relation looks strange, no ?

Best regards|

Always the first question in these cases:

Did you clear your browser cache?

Ctrl-R or Ctrl-F5 or so …

once or twice.

Aleady answered here:

I opened this subject here because of the answer in this issue
I will continue to talk about this problem on the

As has already been explained in the answer on changes to relations do not trigger automatic re-rendering - the reason for that is that analysing relations to work out what tiles they affect is hard to do and potentially very expensive and in the worst case you might wind up marking very large numbers of tiles as dirty and having to re-render them.

Low zoom tiles (zooms 1-12) are never dirtied anyway and are instead just re-rendered once a week.

Zooms above that are re-rendered when we think a node or way that impacts them has changed - strictly speaking they are marked as dirty at that point, and we will try to re-render them the next time somebody asks for them.


Ok, thanks, very clear answer.

Good news, after 17 days of waiting, rendering is now ok for both relations (first relation: since today. The other: I don’t know, I did’t look at it for a while).

Yesterday I was a little scared that the rendering was “out of order”. In the area of the first relation, nothing has been changed by anyone for my own change and probably it will be like this for a while. But the rendering is ok now so I imagine that there is an automatic rendering from time to time like for lowest zooms, good work.

Just a last comment : sometimes I look at the rendering of what I have done to be sure that the relation is ok (not broken) because OSM relation analyser doesn’t work with multipolygons: I don’t know if there is another tool to control them (I mean an immediate control because we can control them with osm inspector after one day).

I deployed an update to the style today, which will cause all tiles to be considered dirty and eligible for re-rendering though they may not be re-rendered immediately if the servers are busy.

I use the relation editor of JOSM. It shows whether outer elements are in a good sequence, …

JOSM’s validator works fine with multipolygons - it’ll tell you if a segment is missing, or missing a role, etc.

Do you mean that the rendering of the tiles involved in the first relation was updated only because of this general update to the style ?
And therefore, do you mean that without this (exceptional) update, the rendering would be still outdated ?