https://tile.openstreetmap.org/18/158479/81957.png
downloaded for example using curl
1 Like
Looking into this, you’ll get a random server based on the DNS lookup. This might be a different cache server for different domains. You can see this in the X-Served-By header. They’re still all treated the same, so it’s luck if one server has older content than another.
5 Likes
Would be a good moment to help promote: Use preferred tile.openstreetmap.org URL · Issue #737 · openstreetmap/operations · GitHub 
6 Likes
I wanted to comment that but was distracted… anyway.
Wikipedia has some mechanisms, and most of the are not easy to apply to OSM.
- Some Wikipedias (including my home Hungarian) has flagged revisions, which is a “delaying method”: there are two “views” of the articles: final and unrevised; and there are two kinds of editors: established and rookie . Rookie edits go to unrevised, and they are not visible in final unless an established editor acknowledges it. The unrevised version can be freely viewed by anyone but it is not the default view for the unregistered mass readers. Editors (people who try to edit the article) always see the unrevised version, so they edit the latest version.
- there are two results from that:
- the vandalism has a lowered incentive, since - by default - it is not visible to the mass population;
- when there are not enough reviewers the articles accumulate undisplayed edits, and rookies start to make angry noises.
- there are two results from that:
- Wikipedia generally use a fix-after-the-fact Q&A: edits get accepted and reviewers easily check all edits, and easily revert malevolent ones.
- Some Wikipedias (notably English) use a machanism to seriously limit new editors in creating new articles; basically they can only create new articles in a staging area where they require high-effort reviews. The result is that new users cannot create worthless articles and new users cannot easily create normal articles either, this strongly alienates new users.
Now, we are OSM, let’s see the applicability.
Flagged-revs is a serious change in workflow, and OSM is not easily separated into multiple views. In theory we could consider rendered images as “final view” and the database as “unrevised view”, and renderers may filter changesets which are flagged “created by an untrusted party and have not been reviewed by a trusted party”, basically giving the same mechanism as WP. But, with the same problem: these must be reviewed, otherwise the renders will be delayed from the db state. (Edits work fine, since editors always see database.) This could be done, requires lot of development power on various points of the system.
Fix-after-fact what we do now, but it is far from “easy”. Reviewing GIS data is hard, our review tools are imperfect and scattered. Reverting problems is also not that simple, especially when people started making conflicting changes. This definitely should be fixed: tools harmonised and offer easy path for community review and revision. Needs lot of coordination work and also siginifcant development to be smooth.
Limiting new editors is a very sensitive topic, since it is extremely hard to differentiate between good intent and malevolence, and it is a very-very bad idea to limit new users indiscriminately. OSM needs new editors, this is a crowdsourcing project, without that it will be gone. Apart from creating smart flagging mechanism to flag bad edits and a mechanism to help editors to find that I don’t think blanket rejection is a good idea. (No, I think it would be a very bad idea instead.)
3 Likes
Indeed, the Articles for Creation process is controversial, with some Wikipedians of the view that it has significantly contributed to the decline in the English Wikipedia’s vibrancy. It’s bureaucracy at the front door. But I don’t think AfC is relevant anyways: it’s designed to defend against a plague of low-quality contributions (read: unsquared buildings and abbreviated street names), whereas the more acute problem we face is vandalism.
MediaWiki has many technical solutions to vandalism that don’t burden content creators with bureaucracy:
1 Like
I would say that many of these are already implemented and in use in OSM.
(With these the problem is that they are implemented in a dozen different tools, in a dozen different ways, and often not organised well enough. But both DWG and people present here from the anti-abuse heroes utilise many of these every day, and keep [politely] reminding people not to give out advices that they have already been doing for many years.)
That’s flaggedrevs is all about. (AbuseFilter is really not easy to implement for OSM, apart from our present problem where the patterns seem to be obvious.)
My list was meant to be an overview for those unfamiliar with the MediaWiki landscape. Indeed, many of these technical measures have partial analogues in the OSM ecosystem, and I don’t want to diminish the tireless efforts of those who’ve developed these tools and use them constantly. Even so, there’s still room for improvement.
For example, consider the radical accessibility of MediaWiki’s undo/rollback feature. Combined with built-in change visualization, it deputizes the vast majority of editors in the fight against vandalism. (The tradeoff is that overzealous editors often escalate banal content disputes into an edit war.) We effectively limit this functionality to those who are savvy enough to learn two or three external tools. Maybe that’s a consequence of our much more complex content model, but I think it’s premature to write off reverts as a solved problem.
More importantly, usage of this built-in feature is tracked by the system, so the community has a much clearer picture of the database’s health based on good and bad edits. Tools like HDYC have only begun to track reverts, but they’re at a disadvantage because they can only guess based on diffs without any knowledge of the intent.
Overall, system integration is a major factor in effectively harnessing the community’s energy against vandalism and other abuse.
2 Likes
That is an important point: changeset metadata of reverts shall be formailsed to be easily parsed by machines.
Not just to count or follow it but often we have to undo the reverts and it is useful if the metadata contains the background (and I am intentionally vague here: I haven’t thought about whether there is any machine-parseable metadata required to undo reverts with the least damage).
(Which reminds me to mention that OSM reverts are extremely more risky and harder than Wikipedia: apart from really experienced editors (who can handle various kinds of conflicts) reversion is really not for the masses. Even I (with about 15 years of experience) often choose manual fix instead of reverting a changeset which had overlapping future edits (and trusting the tools to guess right what’s in and what’s not).)
2 Likes
That is an important point: changeset metadata of reverts shall be formailsed to be easily parsed by machines.
I find this idea interesting! The amount of software that perform reverts is small, and the number of people that do it is also small, so there is a chance of being formalized. It seems less complex than a recent idea in another post about formalizing imports changesets tags.
Would you write more about it? Maybe a OSM diary on the topic, very focused on this part (not the other points) ? Or if you still not sure, can try just write on this thread (if become a problem or too long, mods just split the thread).
(By the way, quite interesting analogies with Wikipedia written in this post)
Very possibly those parts should be moved into a separate thread…
Possibly, but I am not deeply involved in global edit moderation, so probably @Mateusz_Konieczny could be in better position to share what they would like to see in metadata.
As for the simplest form there would be a reverted key with some value helping useful categorisation, for example categorising it as good or bad intent (mistakes vs. vandalism). Probably reverted_changeset would be in the top5 of the useful metadata, provided the tools would fill it (it automagically linked to the problematic user, the bbox, the posisble changeset discussion etc.).
In the details it could contain useful associative information like problem_type=spam, distrubuted, botnet, and semantic information like related_user (for multiple accounts of the same main user), related_forum_thread (details) etc. either to help humans looking at it or help machines in automagically analysing.
Ok. Even if there aren’t many comments, I think it’s worth sharing in a new topic from this post Horrors are written on the maps of Russia - #73 by grin (i.e., do not include the previous comments about Wikipedia comparison, as that would be another broader and less trivial matter) with a title focused like " Discussion for proposal of metadata of reverts or equivalent. But if you want split even the starting ones, ok. My point is that this thing about changesets metadata seems viable.
By viable, I meant that even considering that there are few tools used, therefore fewer developers to talk.
I think that one good reason to have a thread on this would means 1) start compiling proposals of tags=values for changesets, 2) then be open to criticism, 3) then actually try to test with tools, 4) then think endorsement (which is why better discussion upfront). One good practice of standards related to technology is only formalized after it has already been proved that it works, preferable by different people/organizations. So, think like 6 months (maybe more if developers, even if liking the idea, do not have time to change their software in 2-3 months).
Ok, separate also the Wiki introduction could be done, just not sure how would be the title. But since started from that, ok, maybe split from Horrors are written on the maps of Russia - #68 by grin
There seems to be some other problem besides the CDN cache problem.
For example, here tiles were not updated after two months.
I’ve seen a few other places like this recently and managed to fix it by making some minor edits in this place.
It feels like for some reason this tile was not marked as outdated and redrawn.
curl request for more insight.
curl -v https://tile.openstreetmap.org/15/19112/9304.png >tile.png
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 151.101.129.91:443...
* Connected to tile.openstreetmap.org (151.101.129.91) port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
} [327 bytes data]
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* (304) (IN), TLS handshake, Unknown (8):
{ [19 bytes data]
* (304) (IN), TLS handshake, Certificate (11):
{ [2839 bytes data]
* (304) (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* (304) (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* (304) (OUT), TLS handshake, Finished (20):
} [36 bytes data]
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server accepted h2
* Server certificate:
* subject: CN=tile.openstreetmap.org
* start date: Jun 3 21:45:11 2023 GMT
* expire date: Jul 4 21:45:10 2024 GMT
* subjectAltName: host "tile.openstreetmap.org" matched cert's "tile.openstreetmap.org"
* issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign Atlas R3 DV TLS CA 2023 Q2
* SSL certificate verify ok.
* using HTTP/2
* h2 [:method: GET]
* h2 [:scheme: https]
* h2 [:authority: tile.openstreetmap.org]
* h2 [:path: /15/19112/9304.png]
* h2 [user-agent: curl/8.1.2]
* h2 [accept: */*]
* Using Stream ID: 1 (easy handle 0x149812e00)
> GET /15/19112/9304.png HTTP/2
> Host: tile.openstreetmap.org
> User-Agent: curl/8.1.2
> Accept: */*
>
< HTTP/2 200
< server: Apache/2.4.54 (Ubuntu)
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< etag: "76a4c7cb55b3fe06acda40c91ee6fea2"
< cache-control: max-age=604800, stale-while-revalidate=604800, stale-if-error=604800
< expires: Mon, 23 Oct 2023 08:23:22 GMT
< access-control-allow-origin: *
< x-tilerender: culebre.openstreetmap.org
< content-type: image/png
< accept-ranges: bytes
< date: Mon, 16 Oct 2023 08:25:01 GMT
< via: 1.1 varnish
< age: 99
< x-served-by: cache-hel1410032-HEL
< x-cache: HIT
< x-cache-hits: 1
< x-timer: S1697444701.205696,VS0,VE1
< alt-svc: h3=":443";ma=86400,h3-29=":443";ma=86400,h3-27=":443";ma=86400
< content-length: 9590
As mentioned above, I think that that’s because relation changes alone don’t trigger the “tile is dirty” process. I don’t see a report of that here (and I’m not even sure that that is the right repository, but I’m sure that @Firefishy would know).
Edit: For the avoidance of doubt, in the UK a new private browser still shows vandalism at https://tile.openstreetmap.org/15/19112/9304.png and so does curl -v https://tile.openstreetmap.org/15/19112/9304.png >tile.png.
2 Likes
which ones? what kind of vandalism?
curl -v https://tile.openstreetmap.org/15/19112/9304.png >tile.png gives
Is it with vandalism?
If you’re seeing an updated tile from somewhere but I and TrickyFoxy are not, then that suggests that the tile dirty process isn’t the culprit here, but the CDN perhaps is (although I have no actual knowledge of how that is set up).
For completeness, the DNS that I’m currently using via BT residential broadband in the UK shows tile.osm.org as:
Name: dualstack.n.sni.global.fastly.net
Addresses: 2a04:4e42:f::347
146.75.73.91
Aliases: tile.openstreetmap.org
Everything at my end supports ipv6 so I’d expect the ipv6 address is the one used.
how can I obtain such info? (If that would help in tracking down the problem)
Try now. I have:
- Edited a node in the region (forces a re-render)
- Purged some cache entries from Fastlu.
2 Likes
curl -v https://tile.openstreetmap.org/15/19112/9304.png >tile2.png
still got me the old file a minute or so ago, but doing that again now gets me the correct one:
On most PC operating systems, a command prompt will allow you to type “nslookup tile.openstreetmap.org” and you’ll get information back about which server is responding and what addresses are returned to you for thoae names.
On a phone you’ll basically get what you’re given by the provider of your SIM card or a wifi network you connect to, subject to any APN settings you may have changed or VPN software you may have installed.