I have read these, thanks. But working as a quality manager in a larger IT operation here I wanted to point out that there is a method for DB admins to find these fakes even if no one reports them. There can be no cyrillic street names in Germany, so ALL cyrillic street names in Germany are fake and can be found by search on DB level with an apropriate SQL SELECT statement. Also, with this method the DB IMHO could be “immunized” against future vandalism.
4 Likes
Does your “larger IT operation” uses OSM data or sth. like e.g. tiles from OSM(F)?
2 Likes
I don’t know precisely (not a member of that project), but to my knowledge they use Google (which also has problems with incorrect user input, but so far I know no vandalism issue. In Google it’s mostly that companies add their company and wildly misplace the coordinates 
) And Google just can’t get house numbers correct 
Yes, both true 
But about the problems in OSM: be assured that a lot of developers with a lot of expertise are working on this vandalism problem and on how to get more resilience against vandalism into this open project. Also a lot of developers of some of the biggest names in global IT.
So while we welcome anyone that wants to strengthen the project, you as a quality manager might understand that a thorough expertise and insight into the peculiar IT systems might be needed to improve those and this is not a “one small idea thrown into the ring solves the problem” situation.
11 Likes
That could be a very useful thing to do : today, one would need a serious investigation to find a timestamp “just before the wave”.
I have no idea why I got an overly sarcastic reply on my original post, and the post then closed so I could not comment on that. I consider this to be really rude.
In ITIL, everyone is encouraged to report problems and supply every bit (!) of information that the reporter has. Including ideas on ways to fix this. Experts will simply ignore redundant information, but not comment on that.
Of course the choice of methods lies in the people implementing the resulting RfC! I absolutely assumed that OSM is run like that and I in no way shape or form want to belittle the efforts or the skills of the team, rest assured. I find the sarcasm written to me offensive.
Which is why I wonder why it is even possible to add cyrillic street labels in countries where cyrrilic letters cannot be used (at all). Street names with cyrillic letters cannot exist in Germany, so every (!) entry with that is by definition fake and could be easily, and automatically, detected.
If you do not want to throttle user input, then refrain from writing offensive comments. Sometimes even “developers with a lot of expertise” don’t listen to ordinary users when they report a problem. I learned this with an OSM related project, OsmAnd, where I reported several years ago (!) that an entire lake (a larger recreational area) in my neighbourhood is missing on one of their maps, which does appear on OSMs web interface (so the DB is correct). They didn’t see the problem, even with screenshots supplied, so after some years I gave up and this map is still incomplete.
While I do not condone the tone of that reply, please have in mind that your report was about 50th about the same issue. The problem was visible in the whole world, and reverberated in several “mirror” (i.e. map rendering) sites down the chain. Everyone in the know is a bit frustrated by now by the combination of repeated vandalism, apparent flaws in our whole ecosystem to detect and prevent propagation of vandal edits, and by a slew of problem reports by well-meaning newcomers who, however, often fail to read the FAQ about the issue…
But you don’t realize that those weren’t “Cyrillic streets in Germany”. Those were “Cyrillic superhighways connecting central Greenland with South Sudan” that only intersected Germany, and there were thousands of similar ones worldwide. As the FAQ explains, those fake entries were detected and reverted from the database “easily” and within an hour. However, the shortcoming of our whole ecosystem is that those data are almost immediately replicated by hundreds of tileservers and other data consumers, which do not have very good algorithms to refresh the rendered maps (itself a complex problem) to get rid of those “ghost” lines.
So we have this thread of 442 posts (and counting) containing a mixture of problem reports, suggested solutions, and explanations why those solutions would not work (in one aspect or another).
16 Likes
We already have street signs with Arabic and Japanese characters and Cyrillic characters will also be installed at some point. Therefore, such a filter rule makes no sense, especially not in an international project.
4 Likes
" We already have street signs with Arabic and Japanese characters"
No, we don’t. Look at your own link. I see a standard street signpost that conforms to the law (official texts in Germany have latin characters mandatory, with the only inclusion of umlauts and the ligature of s and z). In your link, you see an additional label, which is just a service like those labels that explain e.g. who a certain celebrity was, whose name that street bears.
“and Cyrillic characters will also be installed at some point. Therefore, such a filter rule makes no sense, especially not in an international project.”
IMHO Wrong. There is one official street name, and this what has to be displayed. There are no non-latin characters in Germany. As a service, OSM could offer transliteration (not to be confused with translation), but this is highly problematic. In the case of cyrillic, there just is no letter “H” in cyrillic. Does not exist, and nothing to take it’s place phonetically. In the official russian transliteration rules, H shall be substitued by the cyrillic letter for G, which of course leads into loads of problems, disambiguities and misunderstandigs… Therefore, the official transliteration of the German city Hannover ist Gannover… (official meaning: According to official russian transliteration rules. By German law, Hannover is only Hannover.
First: Do I have to realize this when looking at a map of traffic jams in Munich?
Second: The fake street in the screenshot I supplied perfectly(!) fits to the existing airport road, which does not have highway status at all. And then it runs straight across the airport’s apron. But it does not intersect.
Third: I’m not familar with Greenland laws, but I bet they don’t use cyrillic letters.
No, but if you have found your way to this topic you could probably have read some of it to find out what was going on.
6 Likes
My I respectfully suspect that you take a step back and ask yourself how best you can help, rather than continuing to just argue?
Perhaps start by rereading this.
10 Likes
I did that, and all I got was sarcasm. IMHO OSM could be immunized by not allowing illegal (!) characters upon entry, and sanitized by finding those who already exist. IMHO “oh, we’re international and therefore we allow every input” is not a successful strategy. I do not want to offend anyone with that statement.
So: thank you for your suggestion how to validate map input. However, this validation can be trivially bypassed by vandals creating ultra-long lines named in Latin characters, which actually happened about a month ago. Or by creating ultra-long lines without a name at all.
And if you’re going to suggest next that we introduce validations preventing creation of ultra-long lines, we have also discussed that, and found that it’s hard to detect without blocking legitimate changes.
11 Likes
I accept that you did not intend to offend anybody, but sometimes it can still come across as slightly offending when a new contributor pops up with a simple solution and thereby insinuates that everyone else must be somehow dumber than him (“why didn’t you think of this simple solution before”). Now that we have explained to you that your simple solution won’t work, I hope the matter is settled. There’s no shame in proposing a simple solution that doesn’t work; it would however not be wise to insist on that non-working solution.
29 Likes
Add the ability to limit changeset size by tomhughes · Pull Request #4908 · openstreetmap/openstreetmap-website · GitHub got merged! It is one of steps toward new user being blocked from globe spanning edit.
Now we will get questions “why I cannot add name of USA in my language? Edits gets rejected as it has too large bounding box, whatever it is”. But sadly we will need to accept this tradeoff given increase in vandal activity within recent months.
Note: it will limit this specific type of vandalism. It will not eliminate fully possibility to vandalise OSM and new tools/protection methods etc are welcome. Especially in form of working code where design was discussed with relevant parties.
Thanks to everyone who worked on countering various vandals, in various ways.
EDIT: as pointed out in Maybe rate limit changeset size? · Issue #4805 · openstreetmap/openstreetmap-website · GitHub this is initial step, not full deployment
24 Likes
" The “OSM Standard tile layer” looks wrong…", in that no matter what, in whatever zoom, no matter the browser used, caches/cookies cleared, my edits of at least the last 18 hours do not show up in Carto S. A simple typo correction of Vwnti to Venti over 18 hours ago in max zoom 19 (is where the square name only shows up).
Either the tile renderer is on longer raincheck, I missed the big announcement of suspension of the render engine service for longer which makes it look like the sabotage has succeeded,
(Yes, the data in ID edit mode does look it is in).
It looks fine here, and has your edit from six hours ago:
I never stated that my method cannot be bypassed. But it would prevent many vandalisms. Not all. But many. It will never be possible to prevent all of them, but IMHO that should not lead to not preventing those who could be prevented. Don’t you think?