Have you tried a hard refresh with Ctrl-F5 to update your tile caches?
2 Likes
Whilst I’m sure that most of the problems that people are seeing** are due to local browser cache, from where I’m sitting anything that you can do to improve the CDN cache invalidation would be gratefully received 
** at least 30 DWG tickets at the time of writing.
Edit: 34 now I think…
3 Likes
Surprising, since this is a classic easy, long-since-solved problem in computer science! Step up your game guys!
16 Likes
What would also be useful would be something written by the people in charge of the OSM infrastructure** explaining what actually happens between someone editing something in OSM and it appearing as the “standard” layer in their browser.
We (the DWG) are still getting lots of new tickets coming through for “vandalism”. In some cases in a new private browser I can see it too, but of course a shift-refresh loads new data that was generated behind the scenes and things are “fixed”.
** Not just a wiki page. Lots of people write wiki pages and not all of the wiki page authors are particularly familiar with what they’re writing about or are very good at communicating; I mean something like a blog post that we can link to that is (a) correct and (b) going to stay correct. Maybe someone from the CWG could help?
7 Likes
The changes are published in the minutely replication feed which is consumed by each of the eight (currently) render servers which update their databases and mark any tiles which are affected as dirty - all that will normally happen within a few minutes of the change being made.
Once a day the low zoom tiles (zooms 1 to 12) are re-rendered by each server regardless of whether they are dirty or not.
Everything else is actually driven from the client when you browse an area - your browser makes a request to a fastly CDN node and that will either return a cached tile or will ask a render server for it.
If it’s a low zoom tile, or a tile that exists and is not marked as dirty, then the render server will just return what it has.
If it’s a zoom 13 or higher tile that the render server doesn’t have a copy of or which is marked as dirty then it will queue it for rendering and then wait for a few seconds - if after that time the render has not finished then it will return the dirty tile or a 404 response for a missing tile.
The rendering continues in the background though so the next time a CDN node asks it will likely get the new version unless the render server has been so busy that it has been dropping render requests - missing tiles take priority over dirty ones so are less likely to suffer from being dropped.
9 Likes
Thank you for the detailed explanation.
However, there must be some fine print.
curl 'https://tile.openstreetmap.org/19/272529/174905.png' >a.png
delivers as of now a rendered ugly spike in the footway that has been
fixed in changeset 149801286 on 2024-04-10T03:41:50Z.
Could be that a dropped tile never returns to the rendering queue or
that marking tiles dirty work comprehensive but not entirely immaculate.
Or something else.
Given that Vector Tiles are under way, I do not this is worth busting an
arcane bug somewhere. But before people getting nuts seeing dirty tiles
even after having cleared out all browser caches, it might be fair to
say that most likely some corner cases simply exist.
Well that will depend on which combination of servers you are hitting - it is fine for me for example:
Rather than using curl you’d better testing in a browser where you use shift+reload to force the CDN cache to refresh - either than or figure out the switches to curl to do that because that example is likely just going to get a cached version.
https://odin.openstreetmap.org/19/272529/174905.png/status - marked as expired (2004):
Last rendered at Sun Apr 11 12:56:52 2004.
https://nidhogg.openstreetmap.org/19/272529/174905.png/status - rendered just recently:
Last rendered at Fri Apr 12 11:48:42 2024.
You can see what render server and cache the tile is served from in the custum x-* response headers, e.g. (or F12 > “Network” tab in the browser):
curl -sI https://tile.openstreetmap.org/19/272529/174905.png | grep -E '^x-'
x-tilerender: nidhogg.openstreetmap.org
x-served-by: cache-muc13967-MUC
x-cache: HIT
x-cache-hits: 1
x-timer: S1712926946.195807,VS0,VE1
The renderers odin and ysera are overloaded during daytime, see also #22.
@SomeoneElse I can help with this. I can write it up for the blog and make sure it’s posted on all social media and we can send it to the weekly OSM, too.
Can you give me the basic info? Or is there someone else who can? I don’t have a clear enough grasp to gather the most meaningful information, but I can absolutely make it coherent and clear for the general audience, both OSM’ers who might not know the nuance and people outside of OSM who notice the issue.
If you give me some paragraphs and send them to the CWG list, I can go from there. Or start a HackMD document. Or tell me someone I can quickly talk to who can explain it all to me.
1 Like
It’s basically what people including Tom wrote above, which was in answer to a question along the lines of “I noticed some vandalism in OpenStreetMap map tiles. People say the data is fixed, but I still see a problem in my browser. Why is that?”.
1 Like
Is there someone who can translate this slightly more into lay man’s terms? For this to be effective in the way that I think we want it to be effective, it needs to be more generally understandable. It’s fine if the person wants to tell me verbally. I can quickly hop on a zoom meeting.
2 Likes
I’d prefer to hold fire. We are investigating on a technical solution.
1 Like
In my area someone extended a Scarborough Terrace all the way through. Maybe related to socira/IOospa/kziessen vandal?
I was wondering, is there a way to prevent such large scale and disruptive vandalism?
I just resolved another dozen notes regarding the fake and abusive streets.
1 Like
Thanks for resolving the notes. If you think that any of them need hiding due to the content, please report them to the DWG so that we can hide them.
Edit: Just for completeness, no related notes have turned up in the DWG’s queue at the time of writing.
Yes, I suspect that that is exactly what happened. To make sure, can you run though the steps above to make sure that no problem data is left? You may find that it disappears as soon as you reload the data.
I’ve been reporting quite a few as well indeed. Apparently plenty of people don’t know this Andy guy and that he might take offense…
Edit: also for completeness, that dozen notes did quote the street names but they were self censored, so I didn’t report any of those.
From where I am,
tile.openstreetmap.org/16/36599/21586.png shows OK,
a.tile.openstreetmap.org/16/36599/21586.png shows vandalized.
No amount of shift-reload will change anything.
The headers are as follows:
HTTP/2 200
server: Apache/2.4.54 (Ubuntu)
strict-transport-security: max-age=31536000; includeSubDomains; preload
etag: “433d2d10a32639d3cc7d86e14ab1b64a”
cache-control: max-age=5448, stale-while-revalidate=604800, stale-if-error=604800
expires: Sat, 13 Apr 2024 11:55:43 GMT
access-control-allow-origin: *
x-tilerender: nidhogg. openstreetmap. org
content-type: image/png
accept-ranges: bytes
age: 2133
date: Sat, 13 Apr 2024 13:48:13 GMT
via: 1.1 varnish
x-served-by: cache-fra-etou8220075-FRA
x-cache: HIT
x-cache-hits: 0
x-timer: S1713016094.657364,VS0,VE1
alt-svc: h3=“:443”;ma=86400,h3-29=“:443”;ma=86400,h3-27=“:443”;ma=86400
content-length: 27508
HTTP/2 200
server: Apache/2.4.54 (Ubuntu)
strict-transport-security: max-age=31536000; includeSubDomains; preload
access-control-allow-origin: *
etag: “1afcec5277cf7764f0872ed501fd880b”
cache-control: max-age=604800, stale-while-revalidate=604800, stale-if-error=604800
expires: Wed, 17 Apr 2024 05:23:14 GMT
x-tilerender: nidhogg. openstreetmap. org
content-type: image/png
accept-ranges: bytes
age: 289541
date: Sat, 13 Apr 2024 13:48:55 GMT
via: 1.1 varnish
x-served-by: cache-fra-etou8220033-FRA
x-cache: HIT
x-cache-hits: 0
x-timer: S1713016135.435605,VS0,VE1
alt-svc: h3=“:443”;ma=86400,h3-29=“:443”;ma=86400,h3-27=“:443”;ma=86400
content-length: 28645
Please note the difference in cache-control/expires headers. It seems we are stuck with vandalized tiles till Wednesday.
I see, but they are still used by many sites (not mine).