The main map is provided for the benefit of mappers anyway, making it “more stable” is treating it like a product for general use, which it isn’t. If commercial or “public facing” tile servers want to implement a policy that an edit must survive intact for a week before being rendered then that would probably be sensible as a crude vandalism filter. The logic for that probably gets a bit involved with the way our elements all reference each other, but it seems fairly reasonable on the face of it.
5 Likes
I hear that assertion a lot on this forum, but is it really true? Looking at osm.org I see no indication that it’s merely a tool for mappers. Instead the welcome message on the website says “OpenStreetMap is a map of the world, created by people like you and free to use under an open licence.” So the standard layer is not just a tool for mappers, it absolutely is public facing, in fact the OSM Carto maintainers describe their style as “a major part of the public face of OpenStreetMap, for many people the map on osm.org rendered with this style is OpenStreetMap”
If the public face of OSM gets vandalised that’s a much bigger problem for us than some internal mapper feedback tool getting vandalised.
I am not suggesting any sort of complicated QA logic. Just something like a separate set of tiles that is generated weekly from the planet dump. The dumps are released on Fridays, but only contain changes up until Monday, so by that time it should be clear if they contain vandalism. If they do, just skip that weekly update.
6 Likes
This is what a lot of downstream data processors and/or tile providers do in one way or the other to not have the vandalism in their systems or tiles. The misuse of the QA layer (OSMF minutely updated tiles as a mapper feedback tool) as a map tile provision elsewhere where this would not be needed is the mayor problem of giving a vandal actor the exposure he wants. But this has been discussed elsewhere here to no avail. It’s probably best to keep that question in mind but not to open it up here again. I think a lot of people in the OSM community just need some stress-level rest before the community of OSM goes into any strategic decisions (also in regard to the upcoming vector tiles).
The OWG (and others from the community that help them through pull requests or code improvements) is doing a tremendous job of lessening the impact of vandalism waves every time they occur through analysis and finding solutions post-incidient but this is a cat-and-mouse game. We can all be glad that e.g. the methods used in last year are not available anymore for those vandalism acts because of the improvements in APIv06 and in the rendering/updating toolchain used by the OWG.
1 Like
and this is why waze is a crappy project with crappy people. Basically the whole map is locked, and only the cabal can edit it, and on one hand they keep cryping that they need more editors and on the other they tell newbies how stupid they are and they shall beg for edit anything.
I have tried to help them (despite Google above) several times but gave up due to the arrogant elitist closed circle approach.
I am definitely against the general idea.
3 Likes
I did explore that suggestion in a different topic here (although it’s not something that I’m personally in favour of - OSM already makes map data available to everyone; why should it also provide free map tiles to big commercial organisations too stingy to run their own servers?).
In reality OSM is a large project and the people that are part of it hold many different views, including “the main osm.org website shoudn’t have a map on it (or at least not be mostly map)” and “osm.org should try and replace Google as an end-user maps website, but without the advertising revenue”. My personal view (see e.g. here) is closer to the first of those than the second.
I think we should continue to remind the people misusing OSM’s standard map tiles in their commercial products what it says in the tile usage policy:
OpenStreetMap data is free for everyone to use. Our tile servers are not.
9 Likes
Or like I would say: if providing mapper feedback is a “milk bottle” and serving tiles to third party commercial sites/apps/software is a “sledgehammer”, the OSMF tile layer is a perfect milk bottle but it is not a good idea to offer that milk bottle as a sledgehammer substitute. (Let’s say that “milk” is “osm reputation”).
I’m noticing that while almost all the tile layers on openstreetmap.org currently look free of large scale vandalism to me, the CyclOSM layer is still massively vandalised on every zoom level. Are those tiles not being rebuilt? Or rebuilt slower? Or is that a different dataset that is still vandalised? “Query features” doesn’t show any of the vandalism. Ctrl+F5 or clearing my cache doesn’t help.
Edit: thanks for the answers. I didn’t know those tiles came from a different organisation.
Their tileserver got totally overloaded by the vandalism and choked. They do use the data diff streams of OSM to automatically update. This happened to other downstream diff users that do automatic updates from diff stream as well depending on how the downstream data processor handles this and how powerful the systems are. Remember: CyclOSM is run by a local chapter (OSM FR) that is also build on volunteers.
1 Like
If you mean that when someone wants to implement a rendering delayed by a week they could configure their own server by their own taste - then I fully agree. OSM is a freely available database and people are free to configure their own rendering engine as they please.
Otherwise: no, OSM does not offer a free generic public rendering service. There are many providers where people can buy that, with whatever delay amount available.
Or they can use Facebook’s Daylight Map Distro (filtered planet). (I don’t know how actual MaRS is, but you may have that as well.)
1 Like
@SomeoneElse by the way do we have any profanity based alerts on edits? Seems pretty useful in the current situation to automagically alert DWG, and it’s highly unlikely that someone genuinely need to add name=<CENSORED> street anywhere. 
(In general alerting is the soft alternative of rejection, if you let me to state the obvious here.)
The cyclosm project is (a) independent of OSMF and (b) aware of the problem. They’ll need to sort it out at their end.
3 Likes
No ****ing comment
7 Likes
Should a tile provider which is unable to deal with sufficiently fast wiping of vandalism still be featured on the OSM home page? Should such a requirement be added to the criteria for inclusion of layers?
Open whatever map is independent of the OSM and aware of the project. “They’ll need to sort it out at their end”.
OSM has a long history of genuine and small projects showcasing our data. These projects prides themselves to keep their data minutely up to date. Yet they don’t necessarily have the manpower to handle data filtering upstream.
Filtering minutely diffs for vandalism, is it even a thing, I mean a thing happening, not theoretically?
Maybe those days are over when anybody could invent new stuff on OSM data with their flaws here and there, but trusting they’re good overall. But I think the OSMF should try to take a stand and explore alternatives to patching data after the fact, and propose them to the community to choose a direction.
I’m no friend with the current tile layer criteria as I think that some of those criteria (or the pride of minutely updated data as @yvecai describes) even fosters the occurrence of vandalism in layers provided by third parties like OSM FR (e.g. the CyclOSM layer or the HOT layer).
I do not think that minutely updating a tile layer is needed for anything but mapper feedback. So this is good for the standard layer by OSMF as that is used as mapper feedback, but not the other layers that are a showcase of what OSM data can be.
It is also no good idea that the OSMF mapper-feedback layer is spilling the milk by trying to also serve a purpose it is not useful for (at least in times of vandalism waves or even with smaller problems like a drained lake Erie etc.)
I rather think that a monitored and controlled update of data is a better solution for not-for-mapper-feedback tile layers that are used for viewing a map to not let the vandalism creep in.
After the vandalism bad press disaster in 2018 some Mapbox maps needed many months to show updated data from OSM as QA got and is forever since then way more important than actuality. This is too long (and different today as their QA pipeline got faster) but finding the right balance is the key in running a useful tile layer for a map to be viewed.
It’s totally different for a map that has to provide mapper feedback (and gratification) like the OSMF provided tile layer does.
Maps should update for sure but it is always better (for a not-for-mapper-feedback map) to show either an outdated tile without vandalism or no tile at all than to show a tile full of vandalism and foster the bad actor in his doings.
I managed OK with this. The actions that I’ve had to take have been:
- Speccing the tile server so that on-demand tiles can be rerendered while the user waits.
- Manually deleting some cached metatiles when a vandalism incident corresponded to non-on-demand tile creation.
- Checking that source data for one-off created maps (Garmin, in my case) was clean.
You could argue that I’ve got “inside information” in that I’m actively fixing the problems as they come in, and perhaps we should report “known vandalism activity times” more clearly, but other than that CyclOSM could do the same as I did (particularly, delete invalid cached metatiles).
4 Likes
Hi, I’m using the Nominatim-API, yesterday Germany was referenced as “Nazi-Staat” for a short while - related?
That was a small copycat offender, see here: Achtung: weiterer Vandalismus im Gange... :(
For geocoders etc. that uses OSM data everything I said above in regard to tile layers applies as well. The Nominatim instance by the OSMF used for www.osm.org should update minutely for mapper feedback/usefulness, others should not but do QA. But for geocoders vandalism is not that much a problem in comparison to tile renderers as updates are fast and you do not have the overloaded toolchain that a tile-renderer may have (or depending on the system, overloading is less likely for a geocoder, it still is a bunch of work (manual, by perfect tools and also in compute power) to e.g. update while “overjumping” the vandalism state).
2 Likes
We’re investigating exactly this for Americana. Thankfully the render server’s failing disk controller saved us, ironically, from rendering the vandalism. I anticipate that it would be quite straightforward for “planet as a whole” render pipelines to keep one or two prior planets to fall back to.
7 Likes