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).
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.
" 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.
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.
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.
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.
" 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).
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?
Really? Is that a supported feature? That I rename the US of A? Why ?? Labels in other languages should IMHO only be done by the OSM team with quality checked translations, otherwise you risk that someone uses foul words or propaganda, just in a langage only few people will understandâŚ
First, I never wrote (or meant) you are dumber than me. I am always polite and try to be helpful.
Second, so far I did not see an explanation why my suggestion wouldnât work. When it comes to labelling objects, there is one and only one official wording. IMHO that is the only one that should be supported. If you start with individual (!) labels, then please bear in mind that sometimes labels are language dependend, some languages miss certain letters (like russian), sometimes labels are politically motivated (think of China or Myanmar) etc. pp.
Even some harmless names like Germanyâs Frankfurt is FrĂĄncfort in Spanish⌠Regensburg in Bavaria is Ratisbona! I guess you will never have the manpower to keep track of all of these ambigueties. Or think of Beijing, which only recently gets called like this in German, before it was always Peking.
And when we are in China - there is more than one âChineseâ. Which one do you want to support? Simplified Chinese, Chinese Traditional, Mandarin, etcâŚ
Japanese know three different sets of glyphs.
China, Japan and Russia have official English translations of names. So a default English seems plausible, with the addition of local language (but, again, only the official wordings should count). Possibly with a user option switch for âEnglishâ or âLocal languageâ or, âEnglish and localâ.
Yup, thatâs the monument I mapped this morning at centre of that square. Switched to personal hotspot on mobile, getting the same stale data served in Carto. Went to the mobile browser never used, same same, so wonder which tile server group is not refreshing that feeds Italy.
I intentionally mentioned âaddedâ not ârenameâ. It is welcome to add names (as long as these are accurate and real names and not copied from source of incompatible or unclear license) in various rare languages.
Renames are also fine, as long as they improve data.
I have also noticed this. Iâve added a number of buildings over the past 36 hours and havenât seen any show up in the standard layer tiles.
Maybe an issue on some render servers but not others, or different CDN nodes? I just used a VPN to pretend Iâm in the UK and did a hard refresh of osm.org. This brought in fresh tiles showing my recent edits. After disconnecting the VPN another hard refresh brought back the stale tiles without my recent edits. Iâm in the northeastern US.