piebro/osm-data huggingface dataset:
BrummsLee (2024-10-14 12:20:27+00:00): Ich hab mir das jetzt noch einmal angeschaut. Bin zwar kein Profi, aber selbst Osmose meldet keine Flächenüberlagerungen. 
Die Überprüfung der History mit (achavi & OSMCha) ist für mich nicht so ganz geläufig und einfach. So richtig kann ich die Kritik trotzdem nicht nachvollziehen... 
Bitte wo habe ich das "gesamte Stadtbild" ruiniert?
Dass Grünflächen und Wohngebietsgrenzen nicht an die Mitte von Straßen gehören, dürfte logisch sein. 
Aber ich bin lernfähig...
kalupner (2024-10-14 19:07:41+00:00): 1. Es gibt keine Regel ways und areas zu trennen
2. ways und areas waren nie zusammen gemappt
3. das Abmalen von mehr oder weniger alten Satellitenbilder kann nicht die einzigste Grundlage sein
https://www.openstreetmap.org/changeset/157840702#map=13/51.47609/14.20103
streckenkundler (2024-10-14 20:33:28+00:00): Guten Abend,

beachtet beide bitte, daß in eurem Bereich ein User namens morjak vor längerem ganz exzessiv linienhafte  Wegesegmente als Teil von Flächen mitgenutzt hat! @kalupner: du hast da schon sehr, sehr viel  bereinigt! Dickes Danke!
@an beide: hier mal die Bearbeitungen: https://overpass-turbo.eu/s/1SEt Ich sehe alles als überprüfenswert an...

Grüße in den Süden,

Sven
BrummsLee (2024-10-15 09:56:17+00:00): @kalupner
Zu 1. 
Da widerspreche ich Dir.
Zitat Wiki: 
"Bei detaillierter Kartierung endet die eingezeichnete Landnutzung bei unterschiedlicher Nutzungsart in der Regel an der Grundstücksgrenze (Nutzungsgrenze)...
https://wiki.openstreetmap.org/wiki/DE:Key:landuse
Bedeutet für mich z.Bsp., `forrest` endet an der Grenze zum Begleitgrün vor Straßen und `residential` z.Bsp. an der Hecke vor dem Grundstück. Die Flächen gehören also nicht bis an die Mittellinien der Straßen.
Zu 2.
Da hast Du recht. Leider behindern auch nicht verklebte Nodes die Arbeit ungemein, wenn sie sich in der Mitte von Straßen befinden. Außerdem gehen durch die Farbgebung (1 cm farbiger Rand)
der Landuseflächen viele Details auf den Straßen verloren. Und wie schon zum oberen Punkt geschrieben, ist es einfach nicht richtig, wenn die Flächen bis zur Mitte der Straßen gehen.
Am besten sieht man das, wenn man sich Flächen in Carto anschaut.
Da geht dann der dicke orangene Strich der Flächendarstellung bis zur Mitte der Straße. So ist es aber in der Wirklichkeit nicht.
Zu 3.
Da magst du auch recht haben.
Aber mal ehrlich, wie oft fährst Du Wohngebiete oder Waldflächen mit dem GPS ab, um deren korrekte Größe oder Grenzen zu erfassen?
Dafür stehen uns nun mal die Satellitenbilder zur Verfügung.
Und da ich fast immer die Bilder von Bing nutze, sollte das Alter keine zu große Rolle spielen, da es meines Wissens die Aktuellsten sein dürften.

Entschuldige bitte, daß ich in Deinem Revier "gewildert" habe...
kalupner (2024-10-15 19:04:10+00:00): Das ist eine unendliche Diskussion. 
https://einklich.net/osm/osm-tutorial.pdf
Wir mappen die Rohdaten für die OSM tile server. Diese Daten werden werden als Objekte wie nodes, ways und areas hinterlegt, die durch tags ihre Attribute bekommen. In unserer Region gilt bei N 51° ungefähr 0,5 m/px. Da kannst du selbst errechnen, welchen Abstand du wählen kannst. Was der Renderer daraus macht sollte egal sein.
pitscheplatsch (2024-10-13 15:59:47+00:00): Hello maaxy_, welcome to OSM!

In my opinion, it is not necessary to add each way name along with the name-tag to some areas.

Thank you.
balint36 (2024-11-12 09:37:00+00:00): Szia!
A régi nyomvonalat is törölted, de jó lett volna, ha meghagytad volna, mert mi a megfelelő címkék megadásával jelöltük volna, hogy régen arra haladt.
Himké (2024-11-13 03:21:15+00:00): Dual carriageway is not a defining characteristic of a motorway
esemenko (2024-11-16 06:02:07+00:00): It is a defining characteristic for Canada.
https://wiki.openstreetmap.org/wiki/International_highway_classification_equivalence
pitscheplatsch (2024-10-13 15:58:00+00:00): Hello Nikaloz1, welcome to OSM!

In my opinion, it is not necessary to add the house number along with the name-tag to each house.

Thank you.
pitscheplatsch (2024-10-13 15:58:15+00:00): Hello Nikaloz1, welcome to OSM!

In my opinion, it is not necessary to add the house number along with the name-tag to each house.

Thank you.
pitscheplatsch (2024-10-13 15:58:25+00:00): Hello Nikaloz1, welcome to OSM!

In my opinion, it is not necessary to add the house number along with the name-tag to each house.

Thank you.
pitscheplatsch (2024-10-13 16:01:51+00:00): Hello Nikaloz1, welcome to OSM!

In my opinion, it is not necessary to add the house number along with the name-tag to each house.

Thank you.
pitscheplatsch (2024-10-13 16:01:57+00:00): Hello Nikaloz1, welcome to OSM!

In my opinion, it is not necessary to add the house number along with the name-tag to each house.

Thank you.
pitscheplatsch (2024-10-13 16:02:02+00:00): Hello Nikaloz1, welcome to OSM!

In my opinion, it is not necessary to add the house number along with the name-tag to each house.

Thank you.
pitscheplatsch (2024-10-13 16:03:41+00:00): Hello Nikaloz1, welcome to OSM!

In my opinion, it is not necessary to add the house number along with the name-tag to each house.

Thank you.
welzheimerwald (2024-10-13 16:22:16+00:00): landuse um Kirnbach, Labels und Adressen in Triberg und Schonach vervollständigt, div. Kleinigkeiten gefixt
ErikJ (2024-10-14 20:40:31+00:00): Ser bra ut.  Antar den kobles sammen med veiene ved sandtaket etterhvert?
            ---
            #REVIEWED_GOOD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/157842840
mini-me (2024-10-13 18:02:30+00:00): https://www.openstreetmap.org/node/11082471619
Тег highway=traffic_signals тут явно лишний. Скорее уж railway=tram_traffic_signals. А ещё лучше просто railway=crossing/traffic_signals ибо тип транспорта уже указан на самой железной дороге.
NorthCrab_upload (2024-10-13 16:41:02+00:00): 🗺️ Witaj na OpenStreetMap!

Zauważyłem, że Twoja zmiana zawiera adresy wymagające dodatkowej uwagi. Przygotowałem listę obiektów oraz dodatkowe informacje:

Nazwa ulicy nie istnieje w okolicy. Jeśli adres ma nazwę ulicy, upewnij się, że jest ona poprawna. Jeśli nie, usuń addr:street, a nazwę miejscowości przekaż w addr:place.
https://www.openstreetmap.org/way/1246351507
https://www.openstreetmap.org/way/1323655828

Dokumentacja adresów (po polsku):
https://wiki.openstreetmap.org/wiki/Pl:Key:addr:*

W razie problemów lub pytań, proszę pisać. Chętnie pomogę.
Pozdrawiam! 🦀
Mateusz Konieczny (2025-04-10 16:13:53+00:00): Hello!

You used
clothes=underwear;3
on https://www.openstreetmap.org/node/12248645159/history

Have you maybe meant
clothes=underwear
?

I am pretty sure that it is a typo, but not sure enough to just replace it (I edited some objects where situation seemed more clear to me).

Or have you used this value deliberately? In such case, what was the intended meaning?
Echtnurich (2024-10-15 15:41:16+00:00): Gibts nen Grund, dass du Fernbuslinien alle Tags wegnimmst?

Die https://www.openstreetmap.org/relation/10086752/ schmeißt auf https://ptna.openstreetmap.de/results/DE/HH/DE-HH-HVV-Analysis.diff.html#A5.1 jetzt Fehler, und ist nicht zuordbar.
maps4junkies (2024-10-25 15:25:20+00:00): Die Fernbuslinie Cuxhaven-Berlin von flixbus existiert nicht mehr seit paar Jahren. Das war mein Grund. Mit ist nicht bewusst, dass ich andere gelöscht hätte. Ich bin bereit, den Fehler zu erörtern.
Echtnurich (2024-11-02 17:32:05+00:00): Hättest du die Linie tatsächlich gelöscht, hätte ich nicht nachgefragt.
Allerdings liegt da jetzt eine namenlose Bus-Route rum, die so keinen Wert darstellt.

Statt zu löschen ist auch das Lifecycle-Mapping eine option.
So entsteht jetzt allerdings eine Karteileiche.
Magst du dich darum nochmal kümmern?
limes11 (2024-10-13 21:53:57+00:00): Moin, 

dieser Weg ist seit 5 Jahren mit abandoned:highway ausgestattet. Hier wird behauptet, dass er seit Jahren nicht mehr existiert:

https://www.openstreetmap.org/note/4477381

Ist es vor Ort tatsächlich so, dass er nach 5 Jahren wieder zu einem Pfad geworden ist ?

access=no reicht übrigens, es braucht kein foot/bicycle

Viele Grüße
m8ichael (2024-10-14 04:07:12+00:00): Moin,

Ja, so ist es. Wobei: Es ist fraglich, ob er in der Praxis jemals verschwunden war.

Viele Grüße!
HugoC01 (2024-10-13 17:15:03+00:00): L’attribut "désign" de ce poteau électrique est égal à "one-level" car les 3 isolateurs sont aligné sur une barre droite.
Lien vers la page sur l'attribut "désign" du wiki: https://wiki.openstreetmap.org/wiki/FR:Key:design?uselang=fr
bxl-forever (2024-10-13 22:04:00+00:00): It’s better that shops are mapped as nodes, please do this and no longer mix shop information with the container building itself.
We redid your edit.
https://www.openstreetmap.org/node/12249171955
giubar (2024-11-27 11:14:12+00:00): Buongiorno, ho notato che il percorso https://www.openstreetmap.org/way/1323661279#map=18/45.518429/10.316650&layers=Y, non è collegato alle altre vie e non ci sono dettagli sul tipo di percorso. Scrivo solo per segnalazione, se serve una mano a sistemare qualcosa sono disponibile. Grazie mille buona giornata
demon_box (2024-11-27 11:21:54+00:00): Ciao, grazie mille per la segnalazione. E' un percorso inesistente e lo elimino immediatamente. Credo sia il frutto errato della sovrapposizione di più livelli in Josm.
Grazie ancora, BuonMapping!
giubar (2024-11-27 11:58:28+00:00): Che velocità! Grazie a te, è un piacere collaborare così!
A presto
Giulio
silversurfer83 (2024-10-13 19:51:46+00:00): Hallo und herzlich willkommen bei OpenStreetMap :)

danke, dass du zur freien Weltkarte beitragen möchtest.

Zu deiner ersten Änderung hätte ich direkt eine Frage: Warum willst du "Waldeck-West" in "Waldeck-See" umbenennen?

Grüße
silversurfer83
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/157844520
Mtbiker_0815 (2024-10-15 15:27:56+00:00): Hallo silversurfer83,
 
deine Frage ist nicht ganz unberechtigt, da überall von Waldek-West geschrieben wird. Ich war jetzt vor Ort und auf dem Ortsschild steht Waldeck-See (habe leider kein Foto gemacht). Postalisch laufen alle Anlieger am See in "Waldeck-West" nur unter Waldeck. Selbst auf der Webseite von Waldeck sind nur die Ortschaften als Stadtteile gelistet, ein Waldeck-West, Waldeck-See oder auch Waldeck-Ost taucht nicht auf. Um jetzt hier mehr Klarheit zu erlangen, habe ich die Stadt Waldeck direkt angeschrieben. Ich melde mich wieder, wenn ich eine Antwort erhalten habe.
 
Schönen Gruß
Mtbiker_0815
silversurfer83 (2024-10-15 16:11:43+00:00): Moin mtbiker_0815,

danke für die schnelle Rückmeldung mit der für mich erstmal neuen Information. Sachen gibt's!

Bin sehr gespannt, was die Stadt sagt.

Wenn du eine Antwort hast überlegen wir uns, was wir damit tun.

Cheers
silversurfer83
Mtbiker_0815 (2024-11-01 15:20:14+00:00): Hallo silversurfer83,
leider hat auf meine E-Mails niemand geantwortet. Heute hatte ich eine nette Dame von der Stadt Waldeck am Telefon. Auf dem Ortschild steht Waldeck See, die Waldecker bezeichnen den Ortsteil aber weiterhin als Waldeck West. Um jetzt keine Konfusion auszulösen, schlage ich vor, alles so zu belassen oder Waldeck See in Klammern hinzuzufügen. Die Tortenfee sollte geändert werden, sie ist umgezogen, wovon ich mich 2mal überzeugen konnte.
Mit freundlichen Grüßen
Mtbiker0815
silversurfer83 (2024-11-01 18:35:06+00:00): Moin :)

Danke für deinen Einsatz.

Mit Klammern für Alternativen arbeiten wir hier eher ungern, daher würde ich folgendes vorschlagen:
name=Waldeck West
official_name=Waldeck See

Das Wiki hat dazu Details
https://wiki.openstreetmap.org/wiki/Names

Diese Variante halte ich für passend, da alle Welt von Waldeck-West spricht und halt nur das offizielle Schild Waldeck-See nutzt.

Einverstanden?

Grüße
silversurfer83
Mtbiker_0815 (2024-11-02 17:54:12+00:00): Hallo,

sehr guter Vorschlag. Bin dafür. Vielen Dank für Deine Nachfrage und Deinen Einsatz.

Schönen Gruß
Mtbiker0815
afgb1977 (2024-12-07 15:43:42+00:00): Hello.
What is the mapping source that you used to map land uses, highway=track and leisure=pitch?
The aerial images used in the CS do not show any of the features you mapped on Cayo Roncador at all.
highway=track is used for agricultural and forestry ways. The island is an enclave of the Colombian National Navy for maritime and environmental research, not for agricultural or forestry use.
IGAC orthoimages (Instituto Geográfico Agustín Codazzi) don't show any of the elements mapped by you, I mean leisure=pitch, palm trees AND natural=wood.
Bing, ESRI and MapBox do not have enough resolution in this area to display the items you mapped. That's why I ask what source of images you used to map Cayo Roncador.
Do you have a first-hand source? Any orthoimage from IGAC or another cartography provider or entity?
Lyokoï (2024-12-07 20:27:13+00:00): Hello ! I made some research on Wikipedia : https://es.wikipedia.org/wiki/Roncador. The pitch is due to US military use (It's really common). You can change the nature of way if you want. :)
AgusQui (2024-10-17 11:33:10+00:00): "Beldent" es una marca de chicles, "Milka es una marca de alfajores, son publicidades, no el nombre de los kioskos.
vng_me (2024-10-17 13:37:48+00:00): Ok, will fix it. I was testing a new editor in OM.
habi (2024-10-14 20:50:56+00:00): Mersi bisch ga luege!
mavl (2024-11-13 05:46:40+00:00): This changeset has been reverted fully or in part by changesets 159076666, 159076665, 159076660 where the changeset comment is: The changesets are reverted [DWG has the request to revert the changesets. Reason: incompatible sources - https://www.openstreetmap.org/user_blocks/16857].
mavl (2024-11-13 08:01:59+00:00): This changeset has been reverted fully or in part by changesets 159079861, 159079853, 159079862 where the changeset comment is: The changesets are reverted [DWG has the request to revert the changesets. Reason: incompatible sources - https://www.openstreetmap.org/user_blocks/16857].
emersonveenstra (2024-10-14 10:41:15+00:00): Hi there,

All the buildings you created are already mapped. Can you please remove your buildings? Thanks!
DomiAr (2024-10-21 10:30:06+00:00): Hi emersonveenstra,
I'm Domi, Project Manager from TomTom. I would like to tell you, that my team corrected these buildings created during event. Thank you for valuable feedback and helping us detecting & solving issues in OSM. Regards!
joost schouppe (2024-11-05 12:37:04+00:00): Vind je het de moeite om billie yoga als winkel naast billie yoga het sportcentum te zetten? https://www.openstreetmap.org/node/6552236591/
BartHanssens (2024-11-05 21:14:25+00:00): Hmz, wellicht een beetje van het goede teveel... had het niet gezien in de shops view van MapComplete (kan ze nu wel naast elkaar zien in sports)

De "shop" mag dan in feite weg, dan wordt de onwheels opmeting van het sportcentrum behouden ?
joost schouppe (2024-11-06 15:12:36+00:00): OK, ik pas het zo aan
Warin61 (2024-10-14 23:29:20+00:00): relation 18159674 has only outers..looks like many of them should be inners.
Warin61 (2024-10-15 20:36:17+00:00): See https://tools.geofabrik.de/osmi/?view=areas&lon=114.67982&lat=-25.63163&zoom=14&baselayer=Geofabrik%20Standard&overlays=duplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways%2Cduplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways
Kovoschiz (2024-10-14 07:02:41+00:00): Can you please discuss this first, as you have been warned before? HK has `yue` which makes `zh` unclear.
Kovoschiz (2024-10-14 07:03:46+00:00): `zh` would mean Cantonese or Standard Written Chinese in Hong Kong. It's not reliably treated as Mandarin.
Kovoschiz (2024-10-14 07:15:50+00:00): Also I still don't see your wiki page?
Kovoschiz (2024-10-14 07:27:45+00:00): For reference "Each encompassed language's subtag SHOULD be used as the primary      language subtag.  For example, a document in Mandarin Chinese      would be tagged "cmn" (the subtag for Mandarin Chinese) in      preference to "zh" (Chinese)." https://www.ietf.org/rfc/bcp/bcp47.html#section-4.1.2
I don't oppose using `zh` for PRC and Taiwan. But this would be different in HK and Macau.
Kovoschiz (2024-10-14 07:29:07+00:00): That being said, I believe if more subtags from `*-Latn` to `*-Latn-pinyin` is specified, using `cmn` would be wise anyway. `zh` is only needed for compatibility at a simple level.
Winston Sung (2024-10-14 07:29:28+00:00): Negative.
The standard written Chinese "書面語"/"书面语" in Hong Kong is actually the same writing system of written Mandarin with some Cantonese terms even when reading them in Cantonese, and the written Mandarin place names are actually the same Simplified/Traditional Han characters used in Cantonese, which makes them written identically.
Also, using `yue` in `zh` would broke across lots of sites/apps including Wikimedia Maps, Android as none of the Mandarin websites use lang=cmn-* and all of them use lang=zh-*/values-zh-* including OSMAnd, Wikipedia, Wikidata, other Wikimedia websites, the Taiwanese Goverment websites, and more.
Winston Sung (2024-10-14 07:34:40+00:00): > language = 2*3ALPHA ; shortest ISO 639 code

The "shortest" ISO 639 code also made `zh` being used instead of `cmn`.

> Content in Cantonese might **historically** have used a tag such as "zh-HK"

Context: this is when ISO 639-3 was not being introduced.
Winston Sung (2024-10-14 07:39:10+00:00): > Similarly, an application already using tags that start with the 'ar' (Arabic) subtag might continue to use this more general subtag even for new data, which could be more precisely tagged with 'arb' (Standard Arabic).

This is what actually happened across the world wide web.
Winston Sung (2024-10-14 07:43:21+00:00): > Also I still don't see your wiki page?

Are wiki pages still required even when checking and editing them one by one?
Winston Sung (2024-10-14 07:51:09+00:00): > That being said, I believe if more subtags from `*-Latn` to `*-Latn-pinyin` is specified, using `cmn` would be wise anyway. `zh` is only needed for compatibility at a simple level.

Negative. BCP 47 only allow either `bo-Latn` or `zh-Latn` to be the prefix of `pinyin`

%%
Type: variant
Subtag: pinyin
Description: Pinyin romanization
Added: 2008-10-14
Prefix: zh-Latn
Prefix: bo-Latn
%%

https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
Kovoschiz (2024-10-14 07:54:24+00:00): I don't see what's your argument for the situation in HK and Macau. I didn't talk about `zh-HK` either. 
`zh` means Standard Written Chinese or Cantonese in OSM here. We already have enough work with `name=` , `name:en=`, and `name:zh=` . Then people like to add `name:yue=` further because they think `name:zh=` means Mandarin, which is worsened by iD.
Kovoschiz (2024-10-14 07:59:46+00:00): `Prefix` is a "SHOULD", not a "MUST". When there are multiple encompassed language as seen here, using the encompassed language is clearer. OSM is also starting fresh for scripts, not burdened by any compatibility which only existed as non-compliant `name:zh_pinyin` .
Kovoschiz (2024-10-14 08:02:07+00:00): Please read the rest 
"


   o  Each encompassed language's subtag SHOULD be used as the primary
      language subtag.  For example, a document in Mandarin Chinese
      would be tagged "cmn" (the subtag for Mandarin Chinese) in
      preference to "zh" (Chinese).

   o  If compatibility is desired or needed, the encompassed subtag MAY
      be used as an extended language subtag.  For example, a document
      in Mandarin Chinese could be tagged "zh-cmn" instead of either
      "cmn" or "zh".
"
"


   As noted above, applications can choose to use the macrolanguage
   subtag to form the tag instead of using the more specific encompassed
   language subtag.  For example, an application with large quantities
   of data already using tags with the 'zh' (Chinese) subtag might
   continue to use this more general subtag even for new data, even
   though the content could be more precisely tagged with 'cmn'
   (Mandarin), 'yue' (Cantonese), 'wuu' (Wu), and so on.  Similarly, an
   application already using tags that start with the 'ar' (Arabic)
   subtag might continue to use this more general subtag even for new
   data, which could be more precisely tagged with 'arb' (Standard
   Arabic).
"
Winston Sung (2024-10-14 08:03:14+00:00): If Cantonese being included in `zh` in OSM here, then its arguably this creates problems for, at least, Wikimedia sites using OSM.

If we use a separate `cmn` for Mandarin, then the problem would be more, including the duplicated work and the side affect to places like OSMAnd.
Kovoschiz (2024-10-14 08:11:16+00:00): It seems you are basically asking everything in HK to be retagged to `name:yue=` ? 
That was partly my personal opinion. What I'm saying is `name:cmn=` should be used in HK.
Kovoschiz (2024-10-14 08:16:11+00:00): That is,  `name:cmn-Latn` and `name:cmn-Latn-pinyin` to be used. Otherwise, you cause an awkward situation where there is `name:zh-Latn=` and `name:yue-Latn` .
The international standards can also be read critically. Viz `jyutping` has `Prefix: yue` , but `zh-Latn-pinyin` is used instead of `zh--pinyin` for some reason. This doesn't serves the aim of consistency.
Kovoschiz (2024-10-14 08:23:02+00:00): If you suggest "If Cantonese being included in `zh` in OSM here, then its arguably this creates problems for, at least, Wikimedia sites using OSM." , then it seems you need to discuss a proposal with HK and Macau to redefine `name:zh=` to mean Mandarin, and start using `name:yue=` by standard. However, redefinition of such standard usually doesn't work.
Winston Sung (2024-10-14 08:29:43+00:00): I'm not asking everything in HK to be retagged as yue.

The name in standard written Chinese "書面語" in Hong Kong is basically the name used in BOTH Mandarin and Cantonese. There's no reason for us to introduce `cmn` for Mandarin in Hong Kong while using `zh` for Mandarin accross the globe and other websites/applications.

This is the same practice that the Taiwanese/Taigi language (Taiwanese Hokkien) would simply use nan-* instead of tagging them under zh (example: zh-Hant=板橋, nan-Hant=枋橋).

For the `Prefix: yue`, it means the language subtag of the language tag should be `yue` rather then specifying the "immediate-prefix".

Also, I'm pretty sure we need compatibility for Wikimedia/MediaWiki at least, with the fact that `zh-cmn` is being marked as deprecated and both `cmn` and `zh-cmn` is not commonly used both anywhere across the internet and in OpenStreetMap entities (nodes/ways/relations).
Winston Sung (2024-10-14 08:35:25+00:00): I would also ask Ietf-languages whether the `Prefix` of  `jyutping` should be corrected/updated.
Kovoschiz (2024-10-14 09:26:17+00:00): How is the comparison the same? `name:zh=` is perfect in Taiwan, as Mandarin is dominant. But Cantonese is what's used in HK. 
`name:zh=` is practically interpreted as Mandarin, as seen in iD. This causes more work in HK when people keep adding `name:yue=`, and even not adding `name:zh=` at first. The easiest solution is to interpret `name:zh=` as Cantonese in HK. 
`zh` is a macrolanguage. The situation in HK calls more "precise" differentiation, which is "valid reasons in particular circumstances to ignore a   particular item, but the full implications must be understood and   carefully weighed before choosing a different course."  .   
As `name=` is the most common name, `name:zh-Latn=` is best be equivalent to `name:yue-Latn=` . This doesn't fit `name:zh-Latn-pinyin=` .
If people see `name:zh-Latn-pinyin` , this will reinforce the image that `name:zh=` means Mandarin. The use of `name:yue=` will be encouraged, and this risks more `name:zh=` not being added.
Kovoschiz (2024-10-14 09:27:51+00:00): And don't forget, there is `operator:zh=` , `brand:zh=` , `addr:*:zh=` is etc. That's the amount of work that has to be dealt with here.