piebro/osm-data huggingface dataset:
Mundilfari (2021-06-21 00:19:42+00:00): Did you actually check the NSI link? Or review the wikidata item? Q41171672  is being used with both, brand=ALDI and brand=ALDI Süd, based on the country (see NSI link above). In the US, all stores are branded as ALDI (not ALDI Süd). That's what the name and brand tags reflected after my change.
Q1250054  doesn't have a brand entry anymore in NSI - For a very good reason - There is no such thing as a single "ALDI". There are two completely independent companies (different shareholders, different management, different headquarters, different product on the shelves, different markets), both calling their stores "ALDI" in one country or another. Capturing both under the same brand tag is semantically incorrect (and has been handled in this incorrect fashion for a long time). They are not the same brand. 
None of this has anything to do with the parent holding company, your Yum brands example is not equivalent.

If I decided to open a store tomorrow and call it Walmart, I'm sure you sure wouldn't tag it as Q483551 either...

You may be interested in the discussion that led up to the split of the aldi brand in NSI (it wasn't me proposing this split): https://github.com/osmlab/name-suggestion-index/pull/5109

I don't know why ID is using an outdated set of brand presets in this case - my assumption is that it isn't updated from NSI on the fly but only periodically. I'm sure you'll see the updated presets in a couple of days.
Until then, I'd respectfully ask you not to change Q41171672  back to Q1250054 - as explained above, Q1250054  is a hodgepodge of two completely different brands that coincidentally happen to have the same name.

Interesting thought on the google/apple pay. They are listed as valid values on the wiki though, and removing them is a loss of information (because, no matter what cc's the store accepts, they may or may not have terminals that are ready & enabled for mobile payments through google pay/apple pay, so I'd argue that removing them without a replacement is a disimprovement).
MxxCon (2021-06-21 01:43:37+00:00): Then perhaps it should be tagged with generic payment:contactless=yes, since there there's also samsung pay and huawai pay, and every other big brand of smartphones have their own wallets. Plus many credit cards themselves have nfc chip builtin.
Mundilfari (2021-06-21 02:30:12+00:00): Tagging the generic "payment:contactless" in addition certainly won't hurt; I'll do that going forward (and, looking this up on the wiki, at least the apple entry explicitly says to also tag payment:contactless).
Are you 100% sure that a place accepting contactless payments (the generic) necessarily implies that they accept both, google pay and apple pay though (and any custom wallet app somebody may have thrown out there)? That seems counterintuitive - the payment provider clearing the transactions on the merchant's behalf could accept the one but not the other, no?
MxxCon (2021-06-21 02:52:19+00:00): You can't pay with just google/apple pay by itself. They are nothing but empty digital wallets. You need to add credit/debit cards into them before you can use them to pay. Both google/apple pay support industry standard EMV protocol. See https://en.wikipedia.org/wiki/Contactless_payment
Mundilfari (2021-06-21 05:18:15+00:00): Yeah, I get that the app alone isn't enough, but you also have to link a credit/debit card or other payment form to apple/google pay.
The reason I'm struggling is something I read about Walmart not too long ago - I don't regularly shop there myself, so this is just hearsay: Apparently they have something called Walmart Pay - However: Their system appears to be incompatible with google pay and apple pay. In other words: You can pay with WalmartPay in their stores, but not with ApplePay or GooglePay. Now this may not be a perfect example since I believe it is based on QR codes (technically still contactless, I guess; but in a different way for sure).
I believe that SamsungPay is special too since they use MST in addition to NFC.
Are you saying that a merchant accepting any form of contactless payments is guaranteed to definitely accept both google pay and apple pay? If a place supports MST transactions only (no NFC), payment:contactless=yes would seem appropriate (bc of Samsung), but neither applepay nor googlepay would work. What am I missing?
And, in addition, doesn't the payment provider decide what they process vs what they don't? Similar to both Visa and Discover using EMV, but some places only accepting the one or the other, depending on the agreements they have with their payment providers?
Sorry for asking so many questions, this is super interesting.

One more thing on the brand tags in ID - I found this comment dating back to January, stating that the list just appears to be shipped as part of a new ID release (that would explain why you don't see the updated tags right away):
https://wiki.openstreetmap.org/wiki/Talk:Name_Suggestion_Index#How_soon_will_iD_receive_data_updates.3F
MxxCon (2021-06-21 06:03:22+00:00): There are no Walmarts near me so I don't remember the last time I've been to one, so I don't have recent first hand experience with it. From what I read about Walmart Pay, yes it does look like its own proprietary thing. It seems they do not support standard EMV NFC payment protocols. It seems like Walmart Pay saves your credit card as a whole on their servers and when you "pay", you authorize their servers to do transactions. (One of the benefits of nfc and "chip" payments is that the store doesn't see your full credit card number, so there are less chances of compromise.) I suspect Walmart does it that way because it's cheaper for them on credit card transaction fees and they are big enough to muscle in such a proprietary method.

I really wouldn't consider MST to matter or worry about anymore. It seems like it's a dying technology in phone hardware and banks are trying to phase out magnetic stripe on cards and card readers. MST was a transitional technology, a crutch, to enable "mobile" payments while readers still didn't support NFC.

A few years ago when NFC was still a bit rare, I encountered maybe 2-3 times terminals that showed that they accept only Apple Pay, but I just told clueless cashiers that yes, I have iphone and paid with my Android w/o any problems.🙄

I've never seen a place that accepts NFC only for specific credit cards. Afaik if they accept swipe or chip for x,y,z brand cards, these same cards should work as NFC transaction too. Pretty sure merchant agreements with their payment processors forbid them to have preference for one method vs another or one card brand vs another. Afaik they are not allowed to ask you to swipe with Visa when you wanted to do NFC with Mastercard.
Maybe some other huge players are exception to all of this..like Disney resorts but I have no knowledge of that.
VA00 (2021-06-21 16:39:15+00:00): Chodziłem tam dziś piechotą, bywałem na rowerze, żadnych zakazów nie widziałem.
Ars-UA (2021-06-20 19:03:52+00:00): Одиночные гаражи не нужно.
MrUtopia (2021-06-20 19:22:10+00:00): А почему так? Правила?
Ars-UA (2021-06-20 19:39:52+00:00): Это замусоривает карту. Хотя прямого запрета нет. Добавьте, если он вам важен.
Karthoo (2021-06-22 09:38:06+00:00): Hallo Rosty,

Ich bin im Moment dabei, die MTB-Touren bei Baiersbronn zu erfassen. Bist du die T2 abgefahren und hast zufällig einen GPX-Track davon aufgezeichnet? Dann könnte ich auch die Tour ein bisschen erweitern (oder du machst es natürlich selbst): https://www.openstreetmap.org/relation/12850132#map=16/48.5169/8.3810

Grüße Karthoo/Leon
Negreheb (2021-06-21 10:02:19+00:00): Hi Happymonday, sieht soweit gut aus, bei phone vielleicht noch die Ländervorwahl und die Leerzeichen dazu, damit die Anwendungen die Daten auch korrekt und einfach auswerten können. Siehe auch https://wiki.openstreetmap.org/wiki/Key:phone

Falls du Fragen hast, kannst du dich gern an mich wenden :)
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/106673756
Happymonday (2021-06-21 11:38:04+00:00): Wäre folgendes gewünscht?
+43 50321 927837
Oder sollte es, da 503 eine typische VOIP vorwahl ist folgendermaßen formatiert sein?:
+43 503 21 927837
Negreheb (2021-06-21 11:55:54+00:00): Das ist mir neu, dass das eine typische VOIP-Vorwahl ist, wieder was gelernt :)
Ich würde da nach der Webseite gehen, da steht "+43 (0) 50321-4998" und ich würde das als "+43 50321 4998" eintragen.
Happymonday (2021-06-21 12:05:34+00:00): Zumindest nach https://areaphonecodes.com/austria/ ist es eine VOIP Nummer.
Danke
eggie (2021-06-20 18:24:43+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht. 

MVG, 

Eggie 

Namens de OSM Community
eggie (2021-06-20 18:29:20+00:00): De info heb ik samengevoegd met de adresnode.
MVG
eggie
nw520 (2021-07-21 12:15:52+00:00): Hello Mario Quinta, with this changeset you've edited the route master https://osm.org/relation/11888292/ of "GR 5G". Typically, route masters don't contain way segments but rather routes so could you please have a look at it again?
Mario Quinta (2021-07-21 17:10:08+00:00): nw520, Mais detalhes da GR-5G está neste Link: https://www.gr-infos.com/gr5_G.htm . Eu só limite-me a fazer como está lá...
nw520 (2021-07-23 12:17:00+00:00): Thank you for your reply, Mario Quinta. I have no problem with the fact that you mapped the route. I'm more concerned about the route master (https://osm.org/relation/11888292) also containing paths of a route. This leads to error messages in Osmose. [1]
I assume that all routes in the route master relation should rather be mapped in a new separate relation, which is then added as a member in the route master, while the route master contains only other route relations as members but not ways.
---
(traduction informatique)
Merci pour votre réponse, Mario Quinta. Je n'ai aucun problème avec le fait que vous ayez cartographié l'itinéraire. Je suis plus préoccupé par le fait que le route master (https://osm.org/relation/11888292) contient également des chemins d'un route. Cela entraîne des messages d'erreur dans Osmose. [1]
Je suppose que tous les chemins de la route master devraient plutôt être cartographiés dans une nouvelle relation distincte, qui est ensuite ajoutée en tant que membre dans la route master, tandis que la base de données des chemins ne contient que d'autres relations d'chemins en tant que membres, mais pas de chemins.


[1] http://osmose.openstreetmap.fr/fr/map/#zoom=18&lat=49.234355&lon=6.98989&item=xxxx&level=1%2C2%2C3&issue_uuid=f25b6f22-b117-7352-6f02-30db8fccbeb0
goodidea (2021-08-06 15:07:34+00:00): Hi everybody!

I hope it's OK if I only write in english ... you can use Google translator or something like that.

I was also surprised of the editing (because of Osmose warnings in Saarbrücken where I live). 
I checked it now, and I think there is some kind of chaos in these routes and the route master … Here are my results of the checks:

--- Problem 1 ---
Mario Quinta added segments to the route master "GR 5G" (https://osm.org/relation/11888292) instead of the sub-route with the SAME NAME "GR 5G" (https://www.openstreetmap.org/relation/11856184).

This sub-route ends now north of Cocheren in France. And the new elements added to the route master starts there and end in Saarbrücken.

--- Problem 2 ---
This sub-route "GR 5G" was missing some segments in France which were contained in the route „GR 5G Nord“ (https://www.openstreetmap.org/relation/11894631)

--- Conclusions ---
• The sub-route "GR 5G" should indeed be "GR 5G Nord" (which also has more details keys as the sub-route "GR 5G“. e-g. „osmc:symbol=red:white:red_lower:5:black“. So these two routes should me merged in one ("GR 5G Nord")
• The route master should only contain 3 elements at the end: GR 5G Nord, GR 5G Sud, GR 5G (Nord) variante

---

So I made the correction just now ... because it's clear what has to be done.

--- Other fixes: ----

• I also closed some other gaps of the route in France.
• One path in Saarbrücken was part of the route which is certainly a PRIVATE way: https://www.openstreetmap.org/way/215304828. I removed it from the route and added the shortest allowed ways instead (I am living there and know theses places).
• Mario Quinta added a footway in Saarbrücken which definitively does NOT exist: https://www.openstreetmap.org/way/956356777 (there is only wood there and an embankment and so on ...). It started here: https://www.openstreetmap.org/node/2182626891. I removed this way and added the shortest allowed ways instead.
• Optimisations of the route in Saarbrücken (e.g. added separate footways instead of street segments with no sidewalk)
Ars-UA (2021-06-20 19:02:08+00:00): Приват закрылся.
MrUtopia (2021-06-20 19:25:24+00:00): Проверил, действительно. А недавно был...
Ars-UA (2021-06-20 19:05:51+00:00): Остановка недействующая и отмечена правильно.
MapperMudkip (2022-05-06 06:37:33+00:00): Why did you delete grass features where grass exists simply because they weren't a park? You can only delete features if the feature no longer exists. You need to put back the grass you deleted
Basstoelpel (2021-08-18 17:29:29+00:00): Hallo e1440s,

warum bist Du der Meinung, an eine pipeline müsse ein layer=-1?

Gruß,

Baßtölpel
user_2066394 (2021-06-20 20:58:20+00:00): Vermutlich zweimal amenity=bench :-)
BeKri (2021-07-01 13:41:39+00:00): Die Schuttbergbank hat aber gute
Konditionen für Kleinaktionäre ;-))
-> ausgebessert
tohi (2021-07-01 14:29:06+00:00): @wurzelast,
genau das sollte es sein.
Habe leider in einer App das falsche Objekt erwischt und habe bisher nicht herausgefunden, wie ich es wieder löschen kann.
user_2066394 (2021-07-01 15:53:19+00:00): Kein Thema, mir ging's da weniger drum, kleinlich auf Fehler hinzuweisen, sondern eine Anregung zur Korrektur zu geben (im Zweifel kurz iD anschmeißen).
tohi (2021-07-01 19:16:37+00:00): Ok, vielen Dank für den Hinweis, an iD habe ich gar nicht gedacht.
comfyquiettree (2021-06-21 17:18:51+00:00): Your changeset covers quite a large area, notifying a large amount of mappers. Please divide it into smaller areas (typically, one per country) next time.

You should also always add comment to your changeset's, see https://wiki.openstreetmap.org/wiki/Good_changeset_comments
opendcc (2021-06-20 20:07:58+00:00): Smaller changesets please and consider https://wiki.openstreetmap.org/wiki/Good_changeset_comments
skquinn (2021-06-21 03:37:28+00:00): Hi,

Changeset comments should be at least nominally descriptive of the actual content of that changeset. "Various corrections" only tells us what we already know and adds nothing. It's as useful as an empty changeset comment.

Also, please confine each changeset to smaller areas than this. There is no reason for one changeset to span multiple countries/continents.

---

Salut,

Les commentaires de l'ensemble de modifications doivent être au moins nominalement descriptifs du contenu réel de cet ensemble de modifications. "Corrections diverses" ne nous dit que ce que nous savons déjà et n'ajoute rien. C'est aussi utile qu'un commentaire d'ensemble de modifications vide.

Veuillez également limiter chaque ensemble de modifications à des zones plus petites que celle-ci. Il n'y a aucune raison pour qu'un ensemble de modifications s'étende sur plusieurs pays/continents.
SekeRob (2021-06-21 09:01:21+00:00): What I think is minimal is, that those cross-border comments are made in English or the language of the country where the edit is made, and I fully agree, like here locally some editors have countless multi change CS to their name and all they write is fix A fix B fix C or sistemazione di... meaningless. What they've changed can only be found out by comparing history. This set touches on an area from Alaska to Angola, latter they could understand Portuguese, not French,
My 2 Euro cents.
user_8101879 (2021-09-12 22:09:07+00:00): Hi,
I have changed what ID tells me when I open the tab "problems" and I checked "everywhere" and all the rules. So not a specific change but many various to improve openstreetmap everywhere I look at.
And yes, there are a lot of problems in some areas, I save a lot of corrections in one time (sometimes more than 500) because it is useless to create 500 changesets for these kind of changes.
Best regards
user_8101879 (2021-09-12 22:34:21+00:00): But ok, next time, I will change only one country at a time and I will write 'corrections of problems indicated by ID" if you prefer : but I will still change 500 various problems in one changeset if needed because when 2 points of a building are very close and I delete one and then a gaz station need a wikidata to improve a node, I will not create 2 changesets with 2 comments : there are too many problems, we need to correct them as quickly as possible.
Best regards
mueschel (2021-06-24 16:36:19+00:00): Hi,
you used several tags here that are not used in any other place:
maxHeight
minHeight
videos

Please use only tags that are described in the Wiki or are available as presets in your editor. This is necessary so that other people and apps can understand them.
Thomas_84 (2021-06-25 19:45:59+00:00): Yea but I couldn't find any tag that was fitting the need... I am using the cliff_diving tag to display the spots on a website and idk if other people will use them but they are pretty comprehensible I think
eggie (2021-06-20 18:51:05+00:00): Poging 2 is wel gelukt. Ik heb alleen de info naar de adresnode verplaatst.
OSM-Format phone is eigenlijk aaneengesloten zonder spaties.
vleefzwieg (2021-06-26 15:31:06+00:00): Hallo eggie, fijn dat je even meekijkt, en bedankt voor je tips.

Het nummer zal ik nu maar zo laten, aangezien het technisch niet fout is, maar in de toekomst dus zonder spaties. (Tenzij de software die ik gebruik die invoegt, daar kan ik weinig aan doen.)
fudsnottica (2021-06-22 14:52:56+00:00): Hey Asher, appreciate you updating the map. However your changes to the phone number and the website are incorrect. Phone numbers should use dashes, no spaces or parenthesis (see [the wiki](https://wiki.openstreetmap.org/wiki/Key:phone)). And the URL now has an extra "http://" at the beginning. Let me know if you have any other questions as you edit things, happy to help!
tesp (2021-07-05 09:02:45+00:00): Hei, voisitko ihan oikeasti olla sotkematta noita käyttöoikeus-tägejä tällä tavoin? Karttatyylit ja pyöräilyreititys menee ihan sekaisin. En jaksa kauheasti kumoilla näitä muutoksiasi.
qqdr (2021-06-21 14:09:59+00:00): Hola. En la importación que has hecho de los barrios hay un desplazamiento importante con la realidad, principalmente hacia el norte. En esta imagen se puede ver con facilidad. Mirando uno a uno los barrios, no cuadran: https://i.imgur.com/Ip6sNy8.png
user_177389 (2021-06-21 14:26:38+00:00): This import was also carried out extremely poorly: the rings overlap, a large number of points are duplicated, the tagging is unprocessed, no ring is closed.

In addition, the import guidelines were not followed: https://wiki.openstreetmap.org/wiki/Pt:Import/Guidelines

I will reset the changesets involved.
user_177389 (2021-06-21 14:49:55+00:00): sorry, import guidelines: https://wiki.openstreetmap.org/wiki/ES:Importaci%C3%B3n/Directrices
user_5359 (2021-06-21 04:55:52+00:00): Welcome to OSM! Please move your node from the street to main building!
charl3s (2022-01-07 23:03:32+00:00): construction zostawiłeś https://www.openstreetmap.org/way/956386152
maraf24 (2022-01-09 17:42:02+00:00): Nie ma to tutaj żadnego znaczenia:)
charl3s (2022-01-09 17:56:52+00:00): W przypadku tracka to może i nie, że względu na małe używanie, ale normalnie routingi nie nawigują gdy jest construction=*
maraf24 (2022-01-09 19:07:19+00:00): Dokładniej to tu był ślepy track.
Tylko OSRM nie nawiguje po construction i należy to uznać za błąd z jego strony. Wyjątkiem jest construction=minor, to nie przeszkadza.
iWowik (2021-06-21 08:17:34+00:00): На самом деле совершенно не ясно, улицу вы добавили или проспект. А может аллею или площадь?
Соблюдайте, пожалуйста, принятые правила именования улиц.
Не вынуждайте других участников ваши правки за вами исправлять или откатывать.
Jan Olieslagers (2021-06-21 08:56:20+00:00): Allow me to strongly protest: the aerodrome is mentioned in the AIP so that legally it does exist. Removing it is far too radical, better might be to add some tag to indicate non-operational status.
Stephan Purser (2021-06-21 10:14:23+00:00): Dag Jan, in bijlage vindt u de nodige info https://www.telesambre.be/l-hydravion-n-amerrira-plus-au-lac-de-la-plate-taille 
met vriendelijke groeten.
Stephan
Jan Olieslagers (2021-06-21 10:43:01+00:00): OK, d'accord, je ne suis pas surpris. Je vois seulement confirmation qu'il ne fallait pas enlever la mention de l'aérodrome, bien mieux serait de le mentionner avec un 'tag' de fermé ou pareil; et d'ajouter une petite note explicative.
Báv, (et toute mon appréciation pour votre Néerlandais! :) ),
Karel ADAMS
Stephan Purser (2021-06-21 18:22:08+00:00): Inderdaad.
En voor uw frans ook ;-) 
P.S. Ik werk in Vlaanderen.
Hungerburg (2021-06-21 09:39:32+00:00): Hallo rhhd, zumindest der untere Weg 73097372 ist auf dem Luftbild streckenweise sehr gut sichtbar, wenn er auch im untern Teil anders verläuft, zum Mittelleger. Da sind nicht nur Schafe unterwegs.

Gefährliches Terrain kann ich bei dem auch keins sehen, zu 100% Almwiesen - und überhaupt ist das kein Grund fürs Löschen ;) Nicht vorhanden freilich schon.
rhhd (2021-06-21 10:04:20+00:00): Ja, "gefährliches Terrain" bezieht sich nur auf den ostwärts verlaufenden Weg unterhalb vom Zotenjoch. Weg vor Ort nicht zu sehen, führt mitten ins Steilgelände mit teilweisen Erdrutschen, usw. Der musste definitiv weg, erst recht weil er als T3 gelistet war. Absurd und gefährlich.

Zu dem nach Südosten verlaufenden Weg: Ja, einen abwärts führende Weg gibt es, aber der verläuft völlig anders, als der bisher in der OSM eingetragene. Ich bin da gestern völlig weglos über die Wiesen abgestiegen, hätte diesen angeblichen Weg mehrmals kreuzen müssen. Es war ein völlig unberührter Wiesenhang. Auch am Südostende, wo er auf die Straße treffen soll: nichts.  Wie gesagt, es stimmt, dass es da irgendwo grob in der Ecke ein Weg verläuft. Aber der muss komplett neu erfasst werden, weil die bisherige Eintragung NICHTS gemein hat mit dem wirklichen Verlauft.
Hungerburg (2021-06-21 10:31:20+00:00): Ich hab den untren nach Luftbild wiederhergestellt, bevor der nächste wieder irgendetwas einträgt, wo sein GPX track meint dass er entlang ist. Dass es sich auf der Weide verläuft ist nicht weiter verwunderlich. Die Verbindung Mittel- zu Hochleger macht sogar Sinn, nicht?
rhhd (2021-06-21 10:40:24+00:00): Danke, die Version die du hinzugefügt hast, sieht mehr oder weniger plausibel aus, vor allem weil sie sich am unteren Ende nach Süden wendet (das Stück habe ich gesehen, es existiert und ist sogar markiert). Die bisherige Wende nach Osten war wie gesagt Quatsch, da ist nichts.

Ich denke, so kann das erstmal bleiben, bis jemand den Weg wirklich geht und ggfs. verfeinert.
Hungerburg (2021-06-21 11:00:53+00:00): Freut mich, hab noch ein wenig am Wald geschoben, für die Orientierung, und ein "T2" Schafgangl gelöscht ;)
Geo-Tobi (2024-10-03 10:08:54+00:00): Hier wurde surface compacted gesetzt, aber tracktype blieb auf grade5. Das klingt äußerst unplausibel. Absicht?
https://www.openstreetmap.org/way/40241520
smt (2024-10-03 10:16:09+00:00): Nein, die Kombination ist tatsächlich nicht korrekt. Passender wäre surface grass. Es handelt sich um einen von Traktoren befahrenen Teil einer Wiese.
goedegazelle (2021-06-20 21:19:37+00:00): Hier is iets misgegaan, het fietspad ligt over de kerk.
eggie (2021-06-20 21:32:45+00:00): De schade heb ik hersteld. 

Hier kun je het nog zien.
https://overpass-api.de/achavi/?changeset=106677228

Bij JOSM krijg je dit soms als je een node hebt geselecteerd en vervolgens afsluit.
MVG
eggie
aceman444 (2023-07-25 21:39:53+00:00): Zdravim, dakujem za pridanie garaze.
Preco je ale v budove Konventna 8, ak pisete, ze ma adresu Konventna 6? A operator asi nebude webstranka, ale nejaka firma.
eggie (2021-06-20 20:25:39+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht. 

MVG, 

Eggie 

Namens de OSM Community