|
Top-level
 That means: - data can be in the OpenStreetMap database but not yet rendered on the map - data can be still on the map but already fixed in the OpenStreetMap database and it's due to caching and re-rendering that the underlying OpenStreetMap database and the OpenStreetMap map can get of of sync. For example: vandalism can be fixed in the database but still need some time for re-rendering to update the map. 3/n 15 comments
Most production apps using OpenStreetMap (Komoot, Cycle Travel, Strava, etc.) take snapshots of the OpenStreetMap database and have mechanisms in place to run quality control, fix/update/revert snapshots and run their own modifications before end users will see a beautiful map. That means most end users will hopefully not see any vandalism except those who treat the OpenStreetMap website as a reasonably usable app. 5/n And that ends this thread on OpenStreetMap. In summary - Underlying OpenStreetMap is a database - The OpenStreetMap website is a demo only - To a lot of folks it's not obvious that the OpenStreetMap website is just a demo showcasing what could be accomplished with the data. Even here on Mastodon in our nerd bubble this is not obvious. - Communication around that could be improved; and communication around vandalism and what it means if you see it on the website's map could be improved. 6/6 @djh I *know* that the website is just a demo. However, I still use it a lot (and its my primary map to look at on desktop) @djh Hmm, I didn't realise OSM lacked checks. It's such a useful tool. I wonder if some sort of Wikipedia community type system could be implemented to at least mitigate some of the vandalism  @oceanoculus @djh it's just different. on Wikipedia, you can lock a page. But nothing is preventing you from creating a page like "[insert name of politician]'s dumb decisions list". @mihamarkic @djh Some of stuff is just easily visible to local mappers but tools like osmcha are pretty good at quickly analyzing changesets and noticing if some of them are weird  @thibaultmol @mihamarkic @djh Right, and to make vandalism (or innocent mistakes) "easily visible" it is a big help to have a frequently-updated and widely-used map. So it's hard to break that circle: to avoid users seeing vandalism, it might seem we need fewer people looking at the "live" (or demo) map. But that means fewer people giving feedback on vandalism which could mean that more of it makes it into "end user" maps... @alan @mihamarkic @djh exactly What I assume we need is just servers that don't shoke when they're getting spammed or when changes get reverted. And an improved rendering system for the tiles so that bad tiles can be more easily get wiped from the queue and force removed from caches  @thibaultmol @alan @mihamarkic @djh I was thinking that this time the vandalism was quite big. If, and that's a big if, we assume mappers are human, why not try to impose a human paced editions? iD already tries to keep changesets small and how many changes a human can make per hour? hmm.... but then it's just a matter of creating new user to circumvent it. :( @alan @thibaultmol @djh I think @mihamarkic's original question was "how do those companies do their own QA". Maybe we could provide them with a platform that lets them do their QA on the original data, taking advantage of the shared effort, but we all know companies will be more than reluctant to use it. @mdione @alan @djh @mihamarkic maybe this is just me, but the vandalism is mostly on roads. And realistically many providers are going to use Overture Maps which supposedly has some level of QA so wouldn't be affected by stuff like this |
Gregory's Server
But wait! Why don't we first get the OpenStreetMap database through quality control and then re-render the map?
And here is where user expectations and reality are clashing.
https://www.openstreetmap.org
is not meant as a user-friendly map or app or anything regular users are supposed to use.
It's simply a demo of what the OpenStreetMap data could produce but not meant for end users.
Turns out that's not what most users expect.
4/n