piebro/osm-data huggingface dataset:
Connecticut (2019-07-14 11:44:34+00:00): wegen diesem Note:
"Fratelli Fontana Primo (eine ehemalige Pizzeria im Haus Koblenzer Str. 61), existiert seit mehr als 18 Mon. nicht mehr, "


https://www.openstreetmap.org/note/1832676
Supaplex (2019-08-09 17:07:37+00:00): 恭喜您透過 Maps.Me 完成第一次的地圖編輯！ 歡迎加入開放街圖，群眾共同參與，繪製生活週遭大家關心事物的共編地圖。Maps.Me App 採用開放街圖的地理資料，由社群而非商業公司建置的地理資料庫。以下是相關的參考資料，歡迎隨時指教與提問。

編輯須知
台灣的標示依循準則可參考 http://wiki.openstreetmap.org/wiki/Taiwan
常見的圖徵標示方式可參考 http://wiki.openstreetmap.org/wiki/Zh-hant:Map_Features
給Pokemon Go玩家的建議：https://wiki.openstreetmap.org/wiki/Tips_for_new_(Pokemon_Go)_mappers
組織性編輯指南：https://wiki.osmfoundation.org/wiki/Organised_Editing_Guidelines

由於Maps.Me隨著軟體更新更新最新地圖，App裡的地圖資料版本可能略舊，透過Maps.Me增添商家等資料時有可能開放街圖上已經有了，請到http://www.osm.org 網站看是否要加的商家有沒有人加上去了。

台灣社群網站
台灣 OpenStreetMap 網站  https://osm.tw/
臉書粉絲頁OpenStreetMap台灣 https://www.facebook.com/openstreetmaptaiwan/
台灣社群Facebook社團 https://www.facebook.com/groups/OpenStreetMap.TW/
郵件論壇 https://lists.openstreetmap.org/listinfo/talk-tw
Telegram OpenStreetMap Taiwan https://t.me/joinchat/Aqu2IgnTuIidMfREdNmomQ
Telegram OpenStreetMap Asia  https://t.me/OpenStreetMapAsia
Slack https://osm-tw.signup.team/

Happy Mapping!
aceman444 (2020-01-28 22:33:00+00:00): Zdravim, prosim nepiste do nazvu objektu jeho popis. Ked ste spravne uviedli typ objektu ako "tourism=viewpoint" tak jeho oficialny nazov urcite nie je "View point" ale asi sa vola nejako inak. Ak nazov neviete, nepiste do nazvu nic. Rovnako zle ste vytvorili zastavku s nazvom "Bus stop" a nieco s nazvom "Abandoned house", co asi nie je monument, aj ked ste to tak oznacili.
abakus_uploader (2019-07-14 22:30:32+00:00): (Wiadomość automatyczna)
Cześć!
Otrzymujesz ten komentarz, ponieważ dodałeś lub zmodyfikowałeś adres, który jest niepełny lub błędny.
Adres powinien zawierać minimum trzy znaczniki: addr:city=[nazwa_miejscowosci] + addr:street=[nazwa_ulicy] + addr:housenumber=[numer_porządkowy].
Wyjątkiem są miejscowości bez nazwanych ulic - wtedy stosujemy znaczniki: addr:place=[nazwa_miejscowosci] + addr:housenumber=[numer_porządkowy].
Bez poprawnego oznaczenia adresów, nie będą one brane pod uwagę przez wyszukiwarki, dlatego warto je dostosować do ww. schematu (w zależności od sytuacji).
Więcej informacji na forum: https://forum.openstreetmap.org/viewtopic.php?id=5632 - a pytania najlepiej zadawać tu: https://forum.openstreetmap.org/viewtopic.php?pid=681873
Pozdrawiamy!
Supaplex (2019-07-14 09:08:37+00:00): 是秀巒一帶
opendcc (2019-07-14 15:39:16+00:00): Hallo,

diese Straße hatte ich als Gemeindestraße mit Oberfläche Kies getagged. Gemeindestraße deshalb, weil da keine Fahrbeschränkung wie bei Track (nur für Landwirtschaft) gilt. Aber der Zustand besonders im Anstieg im Wald ist richtig übel ,,, 

Siehe hierzu auch: https://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dtrack#highway.3Dtrack_oder_highway.3Dunclassified.3F

M.E. ist das ein ziemlicher Grenzfall ..

Viele Grüße

Wolfgang
CanyonMaxiMal (2019-07-14 15:49:51+00:00): Hallo!

Ja das stimmt, allerdings wenn das als Gemeindestraße auf anderen Plattformen (vor allem Routingseiten ala GPSies oder Komoot) erscheint ist nie wirklich ersichtlich ob geteert ist oder wie in dem Fall grober Kies. Wenn jemand eine Rennradtour plant steht er sprichwörtlich "im Wald". Für echte Rennradler nicht Fahrbahr obwohl es ja nur dieses kurze Verbindungsstück ist bis dir Teerstraße folgt. Darum der Verbesserungsvorschlag.

Grüße,
Maxi
opendcc (2019-07-14 16:00:16+00:00): Hallo,

ich weiß, ich bin da bei diesem Ansteig (der war durchweicht, zudem waren da Waldarbeiter mit schwerem Gerät zugange) schon mal durchdrehendem Hinterrad (622-25) verzweifelt. Andererseits müssen wir die Router einfach mal dazubringen, surface-Tags mit auszuwerten. Weiter in Niederbayern gibt es Ortsverbindungsstraßen mit dieser Güte - und die kann man nicht auf Track runtermappen. Übrigens, OpenAndroMaps macht es schon richtig - da kommt diese Straße 'braun'. 

BTW, ich bin da heute eh in Leoprechtung durchgekommen.

Viele Grüße Wolfgang
CanyonMaxiMal (2019-07-14 16:13:14+00:00): Ist alles ein bisschen schwierig... 

Wollte mich mal ein bisschen mehr damit beschäftigen, die Karten in der Umgebung aufzubessern, da ich auch viel unterwegs bin und viel per OSM plane (bin aus Massing). Wenn man dann Routen plant an die 100 km kann sowas stressig sein wenn man 5 mal auf der Tour umplanen muss 😁 

Grüße!
opendcc (2019-07-14 17:06:19+00:00): Hallo,

schau Dir z.B. mal https://www.openstreetmap.org/way/130869257 an: das ist klar eine unclassified, war aber noch ohne surface getagged. Deshald hat es die Routingsoftware genommen - und prompt bin ich da heute bei strömenden Regen reingeraten.
PT-53 (2019-07-14 17:30:17+00:00): Hallo,
kennt Ihr schon brouter?
http://brouter.de/brouter/

http://brouter.de/brouter-web/#map=13/48.3575/12.5914/standard

Surface und smoothness ergänzen, ein eigenes Profil erstellen und brouter weist Euch den perfekten Weg.
Ein brouter-Fan
opendcc (2019-07-14 17:50:31+00:00): Dito, brouter-Fan :-) Aber trotzdem: brouter beachtet surface ohne eigenes Profil nicht. Ich bettle da schon seit Jahren ...
PT-53 (2019-07-14 07:05:56+00:00): Änderungen zurückgesetzt
Siehe Forum
https://forum.openstreetmap.org/viewtopic.php?pid=755656#p755656
tux67 (2019-07-29 13:52:22+00:00): Hi, 
Hausnummer und Adresse hätte ich am Gebäude gelassen - nur das Amenity tag ans Gelände.
Gruß
tux67
            ---
            
            Published using OSMCha: https://osmcha.mapbox.com/changesets/72224016
reigi (2019-08-01 15:59:36+00:00): Danke für den Hinweis. Habe ich so geändert
user_5359 (2019-07-14 14:59:05+00:00): Welcome to OSM! Did you see the way https://www.openstreetmap.org/way/229704899 ? I delete your enty because this is overlapping this area.
solohelp (2019-07-14 19:24:06+00:00): is it wrong because the top overlaps a street or because it is inside another residential area?
user_5359 (2019-07-14 19:35:45+00:00): The second reason...
solohelp (2019-07-14 19:43:08+00:00): ok sorry for the trouble.  I added that area for testing because in my simulator no houses are being generated in that area.  I will check for other problem.

thanks for the replies.
Adam Mościcki (2019-07-14 08:47:56+00:00): New waterfall found in Kyrgystan 
https://www.facebook.com/100000826373373/posts/2314342938603229/?app=fbl
dx125 (2019-07-15 16:56:45+00:00): Hallo yxcvbnmüäö,

ich habe Deine Einträge bemerkt und habe dazu ein paar Anmerkungen.
Grundsätzlich ist ja jeder konstruktiv Beitragende immer gern gesehen, denn davon gibt es viel zu Wenige.

Ich habe jetzt nicht jeden Deiner Änderungsätze bis ins letzte Detail geprüft, aber es ging Dir wohl um die straßenbegleitenden Geh- und Radwege am Grünauer Weg. Die sind zwar auf der Standardkarte nicht als extra Linie (way) zu sehen gewesen, aber cycleway=track und sidewalk=left (das ist der Gehweg) waren als Attribute schon an der Straßenlinie mit dran getaggt (klick die Linie an und schau nach den Eigenschaften, dann siehst Du es) 
Eine Navi-Routenplanung für Fußgänger bzw. Radfahrer funktioniert damit bereits, es ist also ausreichend. Jetzt sind die Wege doppelt - man kann nicht alles wissen.
Ich hoffe, ich komme nicht als Nervensäge rüber, ich kann Dir nur sagen, ich habe anfangs auch viele Fehler gemacht und mache heute auch noch Fehler, nur seltener.

Bei OpenStreetMap hat sich eine Praxis durchgesetzt, dass straßenbegleitende Wege nur dann als extra Linie gemappt werden, wenn zwischen Fahrbahn und straßengegleitendem Weg ein Grünstreifen liegt, oder der Verlauf zur Fahrbahn nicht parallel ist. Gehwege direkt am Bordstein mappen wir eher nicht, dass macht die Karte oft unnütz kompliziert und unübersichtlich. 
Ferner ist darauf zu achten, dass solche straßenbegleitenden Wege, wenn wir sie schon extra zeichnen, mit allen einmündenden Querstraßen-/Querwegen einen Verbindungspunkt haben müssen.

Als letztes möchte ich Dir diese Seite mal ans Herz legen: 
https://wiki.openstreetmap.org/wiki/Rathenow
dort gibt es was zum Thema Luftbildversatz in RN zu lesen, der ist dort nämlich krass, und man sollte vor jeder Bearbeitung den Hintergrund ausrichten.

Wenn Du möchtest, kannst Du Deine Wege jetzt nochmal selbst überdenken/ überarbeiten, ansonsten werde ich da irgendwann noch mal ran müssen ;-)

Viele Grüße vom Beetzsee
dx125 (2019-07-17 06:37:54+00:00): Du hast es selbst wieder zurück geändert.
Vielen Dank!
SomeoneElse2 (2022-09-25 00:38:40+00:00): This changeset has been reverted fully or in part by changeset 126599332 where the changeset comment is: Reverting some names from a suspect source; see https://www.openstreetmap.org/user_blocks/6295
DomKZ (2024-01-23 14:25:42+00:00): Хозяйн кафе "Максим" сменил название на "12 стульев". 
Также изменён график работы с 11:00 до 00:00
Описание: 12 Стульев. Очень вкусно и большие порции! Цены ниже остальных.
Leo Slager (2019-07-14 11:16:34+00:00): Probeer zo concreet mogelijk te omschrijven wat je hebt toegevoegd/verwijderd.
hier bijv: fietspad verbonden met T Oversteegenstraat,
Gino-52 (2019-08-06 17:23:56+00:00): Hallo aMa-MiH,
lobenwert, dass Du die Änderungen auch in den Busrelationen aufgenommen hast. Es ist aber nicht ausreichend, die neuen Straßenabschnitte am Ende der Relation aufzunehmen. Die neuen Straßenabschnitte müssen in der Relation an die richtige Stelle, sonst ist die Relation nicht in Ordnung.
Bitte bei Deinen nächsten Änderungen beachten.
Danke und Gruß
Gino
aMa-MiH (2019-08-07 08:55:31+00:00): Hi Gino,
"lobenswert, dass Du die Änderungen auch in den Busrelationen aufgenommen hast"

Freut mich, wenn das schon mal so gepasst hat und ich durch meine Änderung keine Lücken in "Deine" Relationen gerissen habe ;-)

Du meinst dann im Detail, dass die Reihenfolge der Mitglieder einer ptv2-Relation nicht sortiert war?

Ich denke das ist ein Konstruktionsbug von ptv2. Denn für lange Zeit konnte der iD-Editor[1] die Reihenfolge von Relationsmitgliedern gar nicht ändern. Erst vor kurzem kam durch ein Update die Funktion dazu, dass die Reihenfolge nun manuell geändert werden kann. Bei Relation die eine geringe Anzahl von Mitgliedern hat, lässt sich dann sogar unter iD eine Sortierung vornehmen (dann mach ich das auch), aber bei den grossen ptv2-Relationen macht das derzeit noch keinen Spass und ich lasse das mit Absicht weg. Von daher überlasse ich diese Arbeit gerne der "OSM-ÖPNV-AG". ;-)

Falls Du mir und Dir einen Gefallen tun möchtest, könntest Du unter [2] (iD-Funktionswunschecke) mal eine Anfrage/Ticket aufmachen, mit der Bitte eine Autosortierfunktion (so wie es sie in JOSM gibt) implementieren zu lassen :-)

Viele Grüsse!
aMa-MiH

PS: Nebenbei, ich finde es spannend wie Du darauf gekommen bist, daher mal eine neugierige Frage. Womit & wie hast Du eine nicht sortierte ptv2-Relation ausfindig gemacht? 

[1] nicht wundern, ich editiere zu 99% mit iD und in seltenen Fällen lade ich dann einen fertigen CS nicht mit iD hoch, sondern mit JOSM, so wie hier geschehen. Das geht indem am beim iD den CS als „osmChange“-File abspeichert und diese Datei dann im JOSM öffnet und dann damit hochlädt.

[2] https://github.com/openstreetmap/iD/issues/new
https://github.com/openstreetmap/iD/issues
aMa-MiH (2019-08-07 08:57:11+00:00): Sehe gerade: Du hast es wohl hier:
https://www.openstreetmap.org/changeset/73077804
bereits geändert.
Gino-52 (2019-08-07 12:09:23+00:00): Hallo aMa-MiH,
ich arbeite gar nicht mit dem ID. Wenn der aber keine Relationen "sortieren" kann, dann ist das wirklich schlecht.
In einer PTV2 Relation müssen alle Wege in der Reihenfolge in der der Bus fährt eingetragen sein. 
Deshalb ist es auch besser einen Weg nicht zu löschen und die neuen Teilstücke neu aufzunehmen sondern den vorhanden Weg zu teilen.

Geprüft wird das hier:
http://tools.geofabrik.de/osmi/
View: Public Transport - Routes
aMa-MiH (2019-08-07 14:44:08+00:00): Wie gesagt, man kann jetzt mit der aktuellen iD-Version grundlegend sortieren, aber ausschliesslich manuell per Hand. Damals als ptv2 erfunden wurde, ging das definitiv nicht. Deswegen und weil er iD der Standardeditor auf der www.osm.org Webseite ist, wundert mich sehr wieso damals der ptv2-Vorschlag (proposal) überhaupt von der Allgemeinheit angenommen wurde...

Danke auch für den Tipp bzgl. "nicht löschen / neu aufnehmen / Vorhandenes teilen", war mir bereits teils bewusst. Ja man kann sicherlich paar Tricks anwenden, um das Risiko einer Vermischung der Reihenfolge zu minimieren. Aber das ist m.E. auf lange Sicht zu fehleranfällig. Eine automatische Sortierfunktion wäre schon recht nett, damit die JOSM-ÖPNVler nicht immer den iDlern hinterher editieren können. 

Danke für den Verweis zum Prüftool :-)
aMa-MiH (2019-08-07 14:48:15+00:00): PS: Bzgl.: "damit die JOSM-ÖPNVler nicht immer den iDlern hinterher editieren können." 
Wie gesagt, von daher wäre es ganz gut, wenn auch mal bissl mehr Nachfrage zum neuen Autosortier-Feature aus der JOSM-Gemeindschaft aufkommt und hier unter* fleissig die Wünsche geäußert werden :-)

*https://github.com/openstreetmap/iD/issues/new
SomeoneElse2 (2022-09-25 00:40:36+00:00): This changeset has been reverted fully or in part by changeset 126599332 where the changeset comment is: Reverting some names from a suspect source; see https://www.openstreetmap.org/user_blocks/6295
aceman444 (2019-07-29 20:40:13+00:00): Hi, why did you rename e.g. tollbooth of Zadar 1 to Zadar zapad?
The toll company still lists it as "Zadar 1" (at http://hac.hr/en/cjenik_autocesta/A1?c=Zagreb) and those names are also displayed on toll tables at the various toll booths along the motorway in reality.
Also, "Zadar zapad" isn't located west of Zadar so the name does not make much sense.
Badojo (2019-07-29 20:59:48+00:00): The naming on some of the websites is incosistent because some say Zadar I, some say Zadar zapad, and some even Zadar I, zapad.

From what I've learned Zadar I and Zadar II are names of the interchanges and Zadar zapad and Zadar istok are names of the tool booths. It's not uncommon that the interchanges and toll booths have different names

Also I think east-west refers to the positions between the two tool boths and not Zadar itself since Zadar I is west of Zadar II.
aceman444 (2019-07-29 21:12:55+00:00): But in reality the toll tables and also the toll boths are also labeled "Zadar 1". Maybe there is also Zadar - zapad" as alternate name. See e.g. https://www.mapillary.com/app/?lat=44.19026302&lng=15.42812304&z=17&menu=false&focus=photo&pKey=xhC_wxUdHtZcLMl4dKZ3uQ&x=0.4946147173517026&y=0.49973733221375594&zoom=0 (and https://www.mapillary.com/app/?lat=44.11487&lng=15.437308&z=17&menu=false&focus=photo&pKey=yHe179hSniZfuamheap1gQ&x=0 for Zadar 2). Maybe we should put both names, one in "name" and the other one in "alt_name" tag so that people know it is the same booth.
Badojo (2019-07-29 21:21:48+00:00): Makes sene to me. Also I'm not sure about Roman numerals since the toll booth says Zadar 2, but the interchange says Zadar I. Since OSM recommends the "on ground" mapping I think that it's best that the interchanges have the Roman numerals and the toll booths Arabic.
aceman444 (2019-07-29 21:31:08+00:00): Yes I'm fine with using Roman and Arabic numerals in the names as you say.
mbethke (2019-07-23 08:44:48+00:00): Thanks, updated the road and removed the viewpoint. You can add map notes for stuff like this as well.
SomeoneElse2 (2022-09-25 00:40:03+00:00): This changeset has been reverted fully or in part by changeset 126599332 where the changeset comment is: Reverting some names from a suspect source; see https://www.openstreetmap.org/user_blocks/6295
Jeff Underwood (2020-02-03 18:32:51+00:00): Hi 8212,

My team is mapping in this area and saw you added a few cycleways.

We've been adding similar looking roads as highway=path as we figured that they probably support motorcycles and pedestrians as well.

Since you seem to have local knowledge of the area, can you confirm if these are strictly for cycling or serve other purposes as well? We are new to Vietnam and want to map according to local tagging conventions.

Thanks for the help!
Jeff
marc__marc (2019-07-17 04:41:58+00:00): Bonjour,
le changement a fait l'objet d'une discussion dont le lien est documenté.
ne serrait-il pas un minimum de venir en discuter sur le fil en question ?
par ailleurs je ne comprend pas la raison de votre changement. le rôle label n'a pas été modifié, uniquement le nom. car dans les données actuelles, il ya un gros soucis, le noeud est à la fois le centre géodésique, à la fois la france et à la fois la france métropolitaine, ce qu'il n'est évidement pas. il n'est que le centre géodésique et le label de 4 relations.
je me demande quel bug vous essayé de résoudre en rétablisant cette confusion.
un effet de la confusion est https://github.com/openstreetmap/Nominatim/issues/1420 et tous les outils qui en dépendent (par ex une requête sur overpass turbo avec "in France métropolitaine" bascule sur "France" puisque alt_name="France métropolitaine" + name=France + place=country dit explicitement mais erronément que les 2 noms sont la même chose et décrive le pays France au complet
Cordialement,
Marc
althio (2019-07-17 09:30:19+00:00): @Joxit: This is a blatant tagging and data error. Your revert is not welcome.

Your changeset source (=survey) is a joke.

Your changeset comment "This node was used by some apps as France label."
This is wrong on many levels.
First specify clearly which apps.
These apps should use a proper point as label.
The label is only "useful" for its coordinates, it should not duplicate all the tags, all the information already hold on the relation.
This "center" is not even the optimal place for rendering the label.

Last but not least: Please do join the discussion, here or on talk-fr and do not revert without prior discussion.
Joxit (2019-07-17 09:45:11+00:00): Bonjour,
Désolé je n'ai pas eu le temps de venir en discuter, mais on peut le faire ici si vous le voulez bien.
J'ai vu ce changement sur les cartes de Jawg (si vous connaissez, on fait parti des providers listés sur switch2osm.org). Nous utilisons les noeuds pour positionner directement les label au lieu de prendre les relations (car le placement n'est pas des plus judicieux pour certains pays via la relation).
Je ne pouvais pas me permettre de perdre la France sur nos cartes (surtout que nous sommes français), donc en attendant d'avoir une solution pour ne plus perdre ce genre d’éléments, j'ai préféré le revert.
Après ne vous inquiétez pas, on pourra remettre votre changement par la suite, il n'y a pas de problème à cela, il me faut juste un peu de temps...
Donc pour répondre à votre question, le bug que j'essaie de résoudre c'est de ne pas faire disparaître la France sur certaines cartes

Excellente journée à vous
Joxit
Joxit (2019-07-17 10:10:05+00:00): Bonjour @althio (je crois que vous parlez aussi français ?)
Vous avez été plus rapide que ma réponse.
Vous avez raison que le label est extrêmement utile pour avoir les coordonnées, et c'est pour cela que je le préfère.
Avoir le Label en tant que Noeud et toutes les traductions + la relation est une façon de faire qui est présente depuis des années.. (8 ans pour la France, 10 ans pour les USA...).

D'après moi, ce genre de changement (quand on touche à des pays par exemple) n'est pas à prendre à la légère non plus. Il faudrait plutôt voir avec OSM au niveau Monde pour être sur la même longueur d'onde et ne pas faire comme on veut dans son Pays (si vous voyez ce que je veux dire).

Il n'y a peut être pas de spécification claire sur comment gérer la donnée OSM, mais il y a certaines choses où il est préférable d'avoir un accord commun pour être en harmonie, et la gestion des Pays en fait parti.

Donc oui il y a de la duplication de tag entre la relation et le nœud, mais c'est un peu le cas dans tous les pays du monde. Souhaitez vous changer tous les pays du monde pour faire la même chose que la France ? Si oui il n'y a pas de problème, mais il faut se mettre d'accord avec tous les autres :)

Excellente journée à vous en tous cas
Joxit

PS: Le survey c'est une mauvaise manip de ma part, désolé :)
althio (2019-07-17 10:14:34+00:00): Bonjour et merci de venir en discuter et pour les informations.

Il faudrait, à moins avis, utiliser les coordonnées du point label (ou à défaut un algo automatique qui donnerait presque la même chose) et le nom de la relation.

C'est, il me semble, une mauvaise idée de prendre le nom du point utilisé en role label.
Mais c'est à rediscuter, je n'ai pas vérifié comment c'était fait pour tous les pays, toutes les relations, et les roles label.
Joxit (2019-07-17 10:33:07+00:00): Mais c'est normal, je ne suis pas un BOT, de plus je participe à la communauté OSM également comme SOTM par exemple.

En réalité, il y a eu un problème similaire en Pologne et au Canada, cette fois ci le contributeur avait complètement supprimé les noeuds du label.... Depuis d'autres contributeurs l'ont fait revenir et revivre (suppression https://www.openstreetmap.org/changeset/70672217 puis revert  https://www.openstreetmap.org/changeset/70886483)
Ceci me mène à penser que les labels des pays sont quand même des objets critiques.

Depuis l’événement de la Pologne j'avais commencé à réfléchir pour ne plus avoir ce genre de problème, mais on a pas encore eu le temps de le mettre en oeuvre.
marc__marc (2019-07-17 17:46:38+00:00): Bonsoir,

Que vous utilisez le rôle label pour positionner le label d'un pays, soit.
Ce qui m'étonne c'est que vous utilisez le name=* présent sur le label.
cela semble indiquer que vous n'utilisez pas le rôle label mais qu'au contraire vous ignorez totalement les pays mapé sous forme de way et relation pour ne garder que les noeuds.
Pour la France, cela peux fonctionner vu que le label était en plus renseigné comme étant un pays (ce qui est la cause du soucis signalé dans le ticket nominatim vu que alt_name="France métropolitaine" présent sur le noeud géodésique n'est PAS le nom d'un pays) mais cela ne vous fait que 220 pays sur les 319 renseigné dans osm.
Mais si c'est bien cela ca, cela rend votre revert de la relation canada incompréhensible. ou soit j'ai raté une subtilité soit vous ne savez plus exactement vous-même ce que vous utilisez :)

Pour la coordination internationale, osm-carto n'utilisant pas le rôle label (pour cause d'information non géographique et subjective), cela donne une certains direction.
je note d'en parler sur tagging, même si j'avoue que ma priorité absolue est de mettre fin du "pays France métropolitaine".
Je ne veux pas rentrer dans une guerre d'édition mais je ne vois aucune raison pour laquelle vous avez rétablit cette erreur qui ne semble pas utile pour contourner la limitation/choix de votre rendu.
Faire un revert dans l'urgence n'aurait pas du empêcher de regarde cela calmement le lendemain pour faire la part entre l'utile-pour-contourner-la-limitation-du-rendu et l'erreur-inutile-a-maintenir.
Pourriez-vous expliquer pourquoi "pays France métropolitaine" vous est nécessaire et si ce n'est pas le cas, faire un revert partiel de votre revert sans attendre de résoudre l'autre partie du problème ?
Parce que d'autres sont impactés par l'inexactitude des données que vous avez rétablies.

Cordialement,
Marc