👍

You did not indicate that you did.

The Washington Post and the New York Times are two very notable examples of actual use, as is use by government entities. Children learning about Asia in school are no longer taught about Burma either. Even Wikipedia uses the newer name. The shift is gradual, but already in favour of the newer name.

Why would you push a deprecated name obviously on its way out?

You don't use obsolete kana in readings, so the conversion between katakana and hiragana is lossless and reversible. That's why name:ja-Hira suffices.

But also: you don't need name:ja-Hira if name:ja contains only kana. It exists to provide the pronunciation of any kanji in name:ja. You don't need it for ペルー or any other name written in only katakana. It just introduces redundant data no one needs, which in turn increases the maintenance burden.

That acknowledgement is what the alt_name and old_name are for. They are there, and they won't disappear.

American media like the Washington Post and New York Times use Myanmar, and the White House uses Myanmar as well. No doubt people still use the old name, but the new name seems to have caught on too much to state that someone wanting to show a map with only American names should use Burma.

Source?

The White House uses Myanmar:

https://www.whitehouse.gov/fact-sheets/2025/07/fact-sheet-president-donald-j-trump-continues-enforcement-of-reciprocal-tariffs-and-announces-new-tariff-rates/

Burma is an alt_name/old_name for many languages. Those are already here. You are now claiming that someone writing American English should use Burma instead of Myanmar. I'm not seeing any consensus for that claim.

By the way, you used name:en=ADONIS MEN'S BARBERSHOP. What is the source of that name? They call themselves Adonis Men's Barber on their own website.

What is the source of all these names?

Providing translations of a local barber shop is not needed. The localised name tags are for proper exonyms, not for translations.

The shop's website only lists its name in one other language, 'Adonis Men's Barber' in English.

Je kan het hier voornamelijk zien aan de functie van de straat, maar ook het ontbreken van een eenrichtingsverkeer.

Bij een kruising of verkeersplein heb je geen huizen die daar aan liggen. Er bestaan uiteraard grote cirkelvormige kruisingen die geen rotonde zijn maar wel een kruising, maar bij gewoon tweerichtingsverkeer is dat zelden het geval.

Also note:

osm.wiki/Multilingual_names#Japan

By the way, if you look at the graph here:

https://taginfo.openstreetmap.org/keys/name%3Aja-Kana

You will note that name:ja-Kana has been introduced, and subsequently purged before.

What is the point of name:ja-Kana? The tag name:ja-Hira exists to be able to provide the reading of a name:ja when that contains kanji.

By the way, for a name:ja which contains only hiragana and/or katakana (like ヨーロッパ), name:ja-Hira is also not necessary at all. It does not add anything.

Dat is een ronde straat, geen kruising. Die junction=* tag hoort hier niet thuis.

Ja, logisch dat ze dan ook 'uit' moeten kunnen voor hulpdiensten.

maxaxleload:emergency=12 lijkt me correct als die waarde klopt.

Het is een nuance.

maxaxleload:emergency=default zegt eigenlijk dat de hulpdiensten volgens de wet niet zwaarder mogen zijn dan de standaardmaximumwaarde voor het Nederlandse wegenwet. Het overschrijft dan wel maxaxleload.

Met maxaxleload:physical=default zegt dat de fysieke beperking hier de standaardmaximumwaarde voor het Nederlandse wegenwet is. Ook hier wordt maxaxleload overschreven voor de hulpdiensten.

Dat laatste is iets logischer. Voor beide geldt dat emergency=yes dan niet meer nodig is.

Is maxweight=50 verder wel goed? Dat is hier nu de wettelijke beperking van het totaalgewicht. Die wordt ook voor hulpdiensten zo gebruikt (wanneer emergency=yes weg is) omdat we die niet overschrijven. Meestal wil je dat ook, want bij een brug staat die wettelijke beperking er niet voor niets.

Hier zou ik maxaxleload:physical=default en maxweight:physical=default doen en testen of dat werkt. Zo niet: meldt het dan bij LiveOp.

emergency=yes legt niet uit wat hier bedoelt wordt namelijk, en de kans dat die sleutel verwijdert wordt is groot.

Zie ook de discussie op het forum over het probleem met emergency=yes, en:

osm.wiki/NL:Hulpdiensten

Het is de verantwoordelijkheid van de mapper om de juiste bronnen te gebruiken. We kunnen niet zeggen dat we na april niets meer moeten wijzigen omdat het anders door mappers die niet even naar de bekende bronnen zoals satellietdataportaal willen kijken het anders weer aanpassen. Daar is geen draagvlak voor in de OSM-gemeenschap, en het lijkt me ook niet wenselijk.

Je hoeft satellietdataportaal niet te gebruiken. Je moet dan wel kijken naar andere signalen, zoals de geschiedenis van ways. Je had hier trouwens ook al iets kunnen vermoeden bij die rotonde, want je zette daar een informatiebord neer. Die rotonde zie je ook niet op de PDOK-beelden (hij ligt er wel).

Herstel je de situatie?

Dat kan met de WMTS uit satellietdataportaal niet eenvoudig. Je kan die wel zelf toevoegen (zie forum), en je kan er altijd even in de viewer naar kijken zonder hem in JOSM te zetten.

Er is niks mis met de PDOK-beelden, maar waar je ook bezig bent: kijk naar de geschiedenis voor je iets weggooit. Je loopt nu in augustus al een maand of vier achter op de werkelijkheid.

Heb je gekeken naar de recente
beelden? 8 augustus bijvoorbeeld?

Dit gebied is in fases opnieuw ingericht. Je gebruikt nu de beelden uit het voorjaar waar de laatste fase nog mist (die complete rotonde ten noorden van de sluizen bijvoorbeeld).

PDOK geeft een keer per jaar 8-cm-beelden uit het voorjaar. Als er daarna iets verandert zie je dat dus niet.

Kijk als je een way verwijdert even naar de geschiedenis; je had hier dan gezien dat deze recent toegevoegd waren.

Ik denk dat deze beter teruggedraaid kan worden. Ik zie meerdere ways versleept naar hun vroegere locatie.

Tip:

https://satellietdataportaal.nl