piebro/osm-data huggingface dataset:
NorthCrab_upload (2024-03-21 15:50:45+00:00): Zauważyłem, że Twoja zmiana zawiera niepoprawne adresy. Przygotowałem listę obiektów do poprawy oraz dodatkowe informacje:

Duplikat adresu w okolicy.
https://www.openstreetmap.org/node/11750675538
https://www.openstreetmap.org/way/701390778

Pozdrawiam! 🦀
G_P_J (2024-03-22 08:00:54+00:00): Poprawione.
alexey_zakharenkov (2024-03-22 08:05:53+00:00): Опять неверные адреса. Вы обратили внимание на тег addr:region=Москва? Москва здесь - регион, а не город.
Сравнитесь с ЕГРН и исправьте, пожалуйста.
Frans S (2024-03-22 10:10:21+00:00): Hello. Thanks for mapping on this project.
A remark about mapping highways
How to decide when a trace is a path or an unclassified highway
First, look what they connect.  Houses, settlements, villages. Then measure the width of that trace.
In iDeditor 

Shortcut : Ctrl+⇧ Shift+M – toggle  opens measurement panel
Draw a line between the shoulders of a trace (zoom in very far) and read the distance.
If a trace is max 2 meters wide, tag it as a path.
Wider and connect hamlets, houses and villages should be tagged as unclassified.
Tag residential in urban areas (villages, towns)
In JOSM, use the measure tab, or draw a circle (round building, shortcut Alt-Z when the building plugin is installed)) between the shoulders of a trace and read the distance on the lower toolbar. (remove the circle after that)

https://wiki.openstreetmap.org/wiki/East_Africa_Tagging_Guidelines
This is mentioned about tracks on the
https://wiki.openstreetmap.org/wiki/Routing#Routing_considerations

Quote: Tracks are roads of agricultural purpose. They usually connect fields to farms. The surface sometimes makes them inaccessible for regular cars, or at least limits the speeds to a very slow pace. Tracks should always be avoided for through-going traffic or within urban areas.
Best regards
alexey_zakharenkov (2024-03-22 08:09:41+00:00): Опять неверные адреса. Согласно ЕГРН, здесь деревня Мостовское.
alexey_zakharenkov (2024-03-22 08:16:21+00:00): Опять неверные адреса. Да, город Балашиха, но мкр Северный тоже входит в адрес.
dreua (2024-03-21 19:58:49+00:00): Danke :)
danieldegroot2 (2024-03-22 12:59:35+00:00): Hey BrieQ,

What is your source for removing the note this POI may be permanently closed?

Also, please properly describe your changes in the changeset comment when saving, instead of solely using ambiguous hashtags. Changes could be additions, modifications or deletions to/of objects or certain details, where needed with explicit reason. This will help other mappers identify and verify your changes.
https://wiki.openstreetmap.org/wiki/Good_changeset_comments

Your changes
https://overpass-api.de/achavi/?changeset=148971650

Regards,

Daniel
alexey_zakharenkov (2024-03-22 08:40:06+00:00): Согласно кадастру, СНТ Лангерево не относится к д. Пеники, а подчиняется сельскому поселению Пекинское. Надо тегировать addr:city=СНТ Лангерево. Исправьте, пожалуйста.
alexey_zakharenkov (2024-03-22 08:41:13+00:00): То же самое, СНТ Лада не входит в д. Пеники.
alexey_zakharenkov (2024-03-22 08:42:18+00:00): То же самое, СНТ Медведь не входит в д. Пеники.
alexey_zakharenkov (2024-03-22 08:53:23+00:00): Опять неверный адрес.
Здесь "Москва" в адресе - это субъект федерации, а не город. Поэтому если он и заносится, то в тег add:region. Населённый пункт (addr:city) - Марушкино.

Исправьте, пожалуйста.
alexey_zakharenkov (2024-03-22 08:56:35+00:00): Тег addr:city исправили, а улицу Советскую потеряли. Исправьте, пожалуйста.
alexey_zakharenkov (2024-03-22 11:37:24+00:00): Линии 1201732017  и 1201086057 находятся с Чите, а не в Черново. Исправьте, пожалуйста.
traveleditor (2024-03-21 16:54:59+00:00): Trying to get the deleted road back, my bad
kfoisnet (2024-03-25 09:24:09+00:00): Bonjour,
Merci de ne pas modifier le secteur de l'ec'eau port à Creil. Les modifications ont été réalisées en début d'année après relevé topographique de l'existant.
taxi301 (2024-03-21 20:25:08+00:00): droga jest teraz w przebudowie , było wyrysowane zgodnie rzeczywistością , zdjęcia z sierpnia 2023
https://mapy.gis.kolobrzeg.pl/imapclient/?gpmap=gpOrto
taxi301 (2024-03-21 20:30:12+00:00): i tak było od 05.2018 . 
teraz jest tu zmieniana organizacja co kilka dni
Marek-M (2024-03-21 21:01:41+00:00): Czyli została wybudowana wysepka na tym odcinku drogi https://www.openstreetmap.org/way/250522425 ? Tylko to zmieniłem względem poprzedniego układu i ewentualnie skróciłem odcinek z dwoma pasami ruchu tylko do tego odcinka https://www.openstreetmap.org/way/585978698

Reszta zmian była niewpływająca na układ drogowy, tylko redukcja zbędnych węzłów na liniach highway.
taxi301 (2024-03-22 12:38:00+00:00): jest tak jak na zdjęciach lotniczych na mapy.gis.kolobrzeg , więcej punktów było dlatego że jest wyrysowane area:highway , teraz to nie ma sensu ( do skasowania) droga jest w przebudowie docelowo będzie 2x2 , układ drogi całkowicie się zmieni
Marek-M (2024-03-22 13:01:17+00:00): area:highway staram się nie ruszać, czasami symbolicznie coś koryguję. Tutaj wyrzuciłem nadmiarowe węzły z linii highway, bo ich duże zagęszczenie utrudnia upilnowanie takiej drogi a dodatkowo aplikacje nawigacyjne wykonują zbędne obliczenia.

W tym changesecie https://www.openstreetmap.org/changeset/148973622 wywaliłem chyba ponad 90 węzłów z highway (większość na rondzie Patana) i mapa nie straciła na jakości.
Nakaner (2024-03-22 14:32:51+00:00): Hi,

I reverted your changeset by changeset https://www.openstreetmap.org/changeset/149016409 due to following reasons:

1. We keep the demolished buildings to avoid that other mappers without on-the-ground knowledge add these "missing" buildings from aerial imagery.

2. Your changeset comment did not explain your changes. OSM is a community project. Community means respect to other users, i.e. properly describing what you did. Just using "akt." is not a meaningful changeset comment. https://wiki.openstreetmap.org/wiki/DE:Good_changeset_comments

Best regards

Michael
Mateusz Konieczny (2024-04-04 09:39:22+00:00): Hello!

What you wanted to map by mapping https://www.openstreetmap.org/way/1264864584 ?

It looks like building is visible here on aerial imagery but it was marked as "beacon".

It has "Batiment" meaning (from what I checked) "building" in French.

Have you wanted to map it as a building?

If yes - can you edit it to match better its shape visible on aerial imagery?

Feel free to ask for help if you need it! Note that it much better to draw 1 accurate building than 1000 badly drawn ones.
BCNorwich (2024-03-23 07:40:39+00:00): Hi, Sorry to have to say that there's lots of mapping around here that is not to OSM best practice.

Incorrect house names, duplicated highways, highways not connected, Incorrect car park tagging, and many unnecessary nodes.

Regards Bernard.
Thibault Rommel (2024-06-23 09:18:36+00:00): Hello
Tragging parts of the N382 and N382b as highway=trunk goes against our conventions. https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Highways
I've changed them back to highway=primary.
Soniacataldi-1981 (2024-03-25 16:31:35+00:00): Ich mochte meine Wohnort bitte stellen sie mir das lenzburg und nicht winterthur
Tjuro (2024-03-25 11:01:51+00:00): Beste GRi,

Je hebt in deze changeset twee landgoederen toegevoegd, één door een naam te geven aan een stuk gras. En de ander door een multi polygon te maken met alleen maar outers. Hoewel ik het heel creatief vind 😂, is dit niet handig.

De mp is op deze manier niet valide, en leisure=nature_reserve wordt alleen gebruikt voor beschermde gebieden.

https://www.openstreetmap.org/relation/17370361/history

Een stuk gras hoort alleen een naam te krijgen als dat stuk gras een naam heeft, dat komt maar heel zelden voor.

Ik heb er voor nu place=locality van gemaakt omdat er zover ik weet niet echt tagging is voor landgoederen.

Met vriendelijke groet,

Tjuro
mcliquid (2024-03-21 18:59:39+00:00): You are no doubt already aware of the advantages of smaller changesets. Was it not possible for you to upload the changes in smaller packages or did you simply not want to? Thanks for your answer.
VARVAR8 (2024-03-25 16:44:57+00:00): Hi mcliquid.
Here is my answer to your question:
https://www.openstreetmap.org/changeset/149024785
Thanks for the reminder. Happy mapping!
maraf24 (2024-03-31 23:59:20+00:00): southern
Alanantos (2024-04-01 14:17:34+00:00): W większości przypadków oficjalnych nazw dzielnic w krajach anglojęzycznych używa się kierunku geograficznego bez "ern" jak np

https://en.wikipedia.org/wiki/South_Chicago%2C_Chicago?wprov=sfla1

Nazwy jak southern są używane w takim kontekście jak: "mieszkam na południu Chigago" - "I live in southern Chigago", ale jeśli chodzi już o nazwę dzielnicy to już South Chigago
maraf24 (2024-04-01 16:27:11+00:00): Czyli tworzysz własne angielskie nazwy na podobieństwo tych z krajów anglosaskich?
Alanantos (2024-04-01 18:49:57+00:00): Tak
maraf24 (2024-03-31 23:57:54+00:00): A nieoficjalny gdzieś też jest?
Alanantos (2024-04-01 15:18:35+00:00): To jest najbardziej prawidłowa nazwa, ale również mogło by być "Clerk Żoliborz"
maraf24 (2024-04-01 16:30:37+00:00): Chyba Clerical Żoliborz.
Czy masz jakieś doświadczenia w tłumaczeniu z polskiego na angelski?
Yunkers (2024-04-01 17:06:45+00:00): Angielska wiki pokazuje jakieś nazwy "The names of its estates: Żoliborz Dziennikarski (Journalists’ Żoliborz), Żoliborz Oficerski (Officers' Żoliborz), Żoliborz Urzędniczy (Clerks’ Żoliborz) are derived from the former inhabitants professions."
Niestety brak jest źródeł tych nazw. Nie wydaje się też żeby autor zadał sobie trud sprawdzenia czy dane miejsca posiadają nazwy.
Xvtn (2024-03-22 14:31:05+00:00): Can I ask, what service are you using to see the address? Is it a smartphone app or a website? If you're just looking at the map on openstreetmap.org, it seems like your address is showing up correctly there already.
Kunal-N (2024-03-22 19:13:55+00:00): I am seeing it on Rivian map service which uses Mapbox. The problem is that when I park in my lot - now marked as parking - it shows my neighbor's address - 1024 Ardmore Avenue and not my address which is 1012 Ashmount Avenue.
Xvtn (2024-03-22 19:46:33+00:00): I marked your lot as parking. (You had tagged it as a park, like as in a public area with trees and grass.)

One thing to consider is that updates may take a while to trickle down to the end consumer, in this case your truck's display. This can take quite some time (or almost none at all) depending on the infrastructure in between. Since the data has to get through Mapbox's system, then Rivian's servers, then a map update to your truck itself, it might be a while. 

Anyway, regarding the core issue, perhaps the spot you park is just ever so slightly closer to your neighbor's house than your own. How about this: We add your address to the parking area. Then the closest feature to your parking spot would have the right address. That depends on how Rivian interprets OSM's data, but it's worth a shot I think.
Kunal-N (2024-03-22 19:59:33+00:00): That makes sense. Could we add address to the parking area and the ADU on the back side cause I am sure there will be issues there at some point. the flip side of having a large lot, I guess

Thanks for the help!!
Xvtn (2024-03-22 20:58:17+00:00): Nice!
Also, it did just occur to me that they might not even be using OSM for the *address* part of the car's maps. Addresses are basically non-existent in lots of areas in OSM, so this whole thing might be an issue with whatever additional address data source they might be using (combined with OSM's streets or whatever). If any.
I guess we'll find out! Haha. You'll know your truck got an update when you see that parking area shape!
Kunal-N (2024-03-23 05:39:08+00:00): Yeah, it may end up being a case of that. I will check in about two weeks on the mapbox side to see what they are showing as 1012 Ashmount. 

Cheers!
mcliquid (2024-03-21 19:04:12+00:00): Hi, please upload before switching a region / continent :) thanks!
michel60 (2024-03-29 10:30:59+00:00): Bonjour,
Je ne comprend pas pourquoi je ne retrouve pas ces numéros de lignes dans le référentiel IDF:
https://data.iledefrance-mobilites.fr/explore/dataset/referentiel-des-lignes/information/?disjunctive.transportmode&disjunctive.transportsubmode&disjunctive.operatorname&disjunctive.networkname
Avez-vous une explication ?

Petite remarque, elles sont en erreur dans GEOFABRIK OSM Inspector ...
https://tools.geofabrik.de/osmi/?view=pubtrans_routes&lon=2.76594&lat=48.86807&zoom=14&baselayer=Geofabrik%20Standard&opacity=0.94&overlays=ptv2_routes_valid%2Cptv2_routes_invalid
Cordialement Michel
€liz (2024-03-29 13:37:54+00:00): Il s’agit des lignes du réseau de Marne-la-Vallée renumérotées selon l’indice 22xx durant le mois. Vous pouvez retrouver l’information sur les différents canaux de diffusion.
Cordialement.
michel60 (2024-03-30 10:01:31+00:00): Ok Merci. Alors ça devrait arriver dans le référentiel au 1er avril peut-être
Cordialement Michel
totera (2024-03-22 12:28:53+00:00): Ciao dp7, i nomi erano corretti prima, come si può verificare dalle targhe in loco (Piazzale San Savino sull'angolo sud-ovest del piazzale, Via del Cascamificio di fianco alla scuola Federico II, ecc.) e dal SIT del Comune di Jesi (https://datiterritoriali.comune.jesi.an.it/cs/).  
Quello che mi pare più grave però è che i nomi ora errati sono uguali a quelli di Google Maps… Con più di 5000 gruppi di modifiche all'attivo dovresti sapere che non è il caso di copiare dalle mappe di Google, e non solo per gli ovvi motivi di copyright ma perché spesso, come in questa zona, inaccurate.
dp7 (2024-03-22 13:21:36+00:00): Mi scuso se ho sbagliato qualcosa in questo changeset e ti invito a fare le correzioni, se hai informazioni più corrette delle mie. Consentimi però di dire che trovo fuori luogo, poco costruttivo e un po’ troppo supponente il tono con cui mi bacchetti e mi accusi, tra l’altro non mi è ben chiaro di cosa e con quali prove. Il mio obiettivo è sempre quello di migliorare la qualità delle mappe, poi purtroppo l’errore ci può stare e in un progetto collaborativo come openstreetmap il valore aggiunto è proprio questo, ovvero la possibilità di condividere e risolvere i problemi per migliorare la qualità del servizio (attività per la quale nessuno ci paga, peraltro, o almeno non a me).
totera (2024-03-28 08:52:34+00:00): Condivido tutte le tue considerazioni sul progetto, quindi mi scuso anch'io se dal tenore il commento non risultava improntato a un atteggiamento collaborativo.  
Ho visto che avevi già ripristinato la maggior parte dei nomi, ho sistemato il resto.
maraf24 (2024-03-23 21:13:30+00:00): Kolejna nieprzedyskutowana i błędna zmiana.
Podobieństwo nie ma tu żadnego znaczenia, a wikipedia to nie jest dozwolone źródło.
pavvv (2024-03-24 14:07:42+00:00): Tag name:de zawiera nazwę obiektu w języku niemieckim. Te nazwy były tłumaczeniem oryginalnych nazw słowiańskich i były używane do II wojny światowej. Przykładowo taką nazwą jest Schottwitz, które jest prawidłowym tłumaczeniem Sołtysowic, w przeciwieństwie do Burgweide, które było nazwą stworzoną przez III Rzeszę i kompletnie niezwiązaną z poprzednią.

Na stronie wikipedii jest napisane, że treści podlegają licencji, która pozwala na kopiowanie i rozpowszechnianie danych (https://creativecommons.org/licenses/by-sa/4.0/deed.pl). A dawne niemieckie nazwy, które już były na obiektach, to skąd zostały wzięte? Chyba nie z terytu 😉. Sama zmiana, która dodała niemiecką nazwę Sołtysowic ma w źródle wikipedię. https://www.openstreetmap.org/changeset/61930625

Zmiany, które wycofałeś miały też dużo poprawek m.in. tagowania członków relacji, usunięcie nieużywanych tagów i uzupełnienie wikipedii oraz wikidata.
maraf24 (2024-03-24 17:43:26+00:00): " i były używane do II wojny światowej. "

Czyli old_name. Nie są używane dzisiaj.

>Na stronie wikipedii jest napisane, że treści podlegają licencji, która pozwala na kopiowanie i rozpowszechnianie danych

Czyli gdy ktoś skopiuje do wikipedii jakąś treść objętą prawami autorskimi, to potem możesz ją dowolnie i bezkarnie rozpowszechniać, bo będzie już na innej licencji? Tak to nie działa.
A CC-BY-SA 4.0 jest niekompatybilna z ODbL i dlatego danych nie można kopiować danych z wikipedii do OSM.
maraf24 (2024-03-24 17:49:05+00:00): Btw nie wiem skąd pochodzą informacje o tłumaczeniu nazw, szczególnie Sołysowic. Nazw własnych się generalnie nie tłumaczy. Polskie nazwy na dawnych terenach niemieckich po II WŚ były tworzone na kilka sposób. Tłumaczenie to był tylko jeden z nich i to ten rzadziej używany .
Alanantos (2024-04-01 10:43:50+00:00): Dawne nazwy niemieckie powinny być dalej używane jako name:de, ale tylko wtedy kiedy polska nazwa się nie zmieniła z tej przetłumaczonej. Bo jeśli się zmieniła jak np jak dzisiejsza Bardzka która kiedyś była Strzelińską (Strehlener Straße ) to wtedy tak można dodać Strehlener Straße ale jake old_name:de. 
 
Zmiana pavv była absolutnie poprawna.
maraf24 (2024-04-01 16:24:32+00:00): "Dawne nazwy niemieckie powinny być dalej używane jako name:de,"

To twoja opinia czy ustalenia społeczności OSM? Jeśli to drugie, to podaj link.
szydzio (2024-04-01 17:23:25+00:00): Dawne niemieckie nazwy z definicji powinny iść do old_name:de , względnie old_name:de:-1945.
Nieliczne z nazw historycznych miast potrafią oczywiście funkcjonować nadal jako nazwy obcojęzyczne (typu Breslau, Krakau) ale już na pewno nie w stosunku do dzielnic bądź pojedynczych ulic.
SomeoneElse (2024-03-22 21:57:24+00:00): Sigh.  Would it really be _that_ difficult to contact consumers of tags that you're replacing, here https://taginfo.openstreetmap.org/tags/shop=guns#projects ?
No one's going to object that the replacement here is similar but without a message that a consumed tag is going to go away I have to hunt down why it has gone.
Mateusz Konieczny (2024-03-23 18:31:10+00:00): In case you have not seen my response on Discord where you raised it: all of this projects support shop=gun and shop=guns with nothing indicating that they differentiate between them.

Are you aware of any? If yes then I would need to look into what went wrong with my taginfo parsing.
SomeoneElse (2024-03-24 12:50:07+00:00): If a tag disappears and I'm not expecting it to I still need to see why it's gone.
Mateusz Konieczny (2024-03-25 12:15:06+00:00): I guess I can write to some of others listed as supporting specifically this value.

(some, not all at start - as I am not sure would such message be actually welcome)
Mateusz Konieczny (2024-03-26 14:45:50+00:00): First contact attempted in https://github.com/osm-search/Nominatim/pull/3375
SomeoneElse (2024-03-27 00:41:43+00:00): I'm not sure what a pull request to nominatim has to do with anything?
Mateusz Konieczny (2024-03-27 09:57:14+00:00): My comment in PR included

> BTW - would it be useful to notify about retagging such as shop=guns to shop=gun before they happen (or after they happen?). It was suggested to me in https://www.openstreetmap.org/changeset/148979715 that doing it would be useful but I am not entirely sure about it.

> Or would it be useful in cases where specific tag value is reported as supported, and not useful when key in general is supported?


and reply was

> The entry is for shop=<anything> . A change from 'gun' to 'guns' is not relevant.


as expected given that declared support was not for specifically shop=guns but for shop=* (with exception for shop=no, as described in freeform text)
SomeoneElse (2024-03-27 10:08:37+00:00): That PR was a format change only: https://github.com/osm-search/Nominatim/pull/3375/files - I'm not sure what that has to do with the suggestion that you, as the person changing OSM data, should look and see how tags are used before making changes.
The actual software used to display "who uses what" is irrelevant to that.
Mateusz Konieczny (2024-03-27 18:45:17+00:00): I used description field of this PR also to ask Nominatim maintainer whether they would welcome such notifications (as quoted above)

And they replied that they are not interested at all (as quoted above)
SomeoneElse (2024-03-27 19:05:20+00:00): Perhaps there has been a misunderstanding.
I was suggesting that _you_, as the person who is changing the tags, would as part of the processs where you ask yourself "is this a sensible change and should any other tags be changed" also ask yourself "which applications consume these tag/value combinations and who do I need to notify".
Mateusz Konieczny (2024-03-28 19:18:16+00:00): And I did it. As I described on Discord where you proposed it - I contacted one developer who had listing distinct for entry being removed compared to a new entry (it turned out their taginfo listing had a mistake).

But if app lists shop=* catchall rather than using specific tag values then contacting them is very unlikely to be useful.
SomeoneElse (2024-03-28 19:48:35+00:00): > And I did it.

Where was this?  I don't remember seeing a message about this change here.

> But if app lists shop=* catchall rather than using specific tag values then contacting them is very unlikely to be useful.

Indeed - but I don't think that anyone is suggesting that?

To be clear, until https://github.com/SomeoneElseOSM/SomeoneElse-style/commit/73f06e837d4792a4d9da939cb0e661472e595772 that repository was listed as an explicit consumer of "shop=guns" (not just "shop=*").
Mateusz Konieczny (2024-03-29 07:15:44+00:00): And it had "Shown as a generic shop" exactly like shop=gun.

Though I guess in future it would make sense to contact project in case where they list older and newer that with the same description not indicating special handling?
Mateusz Konieczny (2024-03-29 08:34:51+00:00): > Where was this? I don't remember seeing a message about this change here.

https://discord.com/channels/413070382636072960/790139356903505951/1215014042406486098

I contacted one developer at https://www.facebook.com/groups/historic.place/posts/2715780891914218/ as they were claiming to support old tagging while claiming to be not supporting new one

I skipped mug one as it was just mistake on a mug.

I skipped ones where they claimed solely generic support of catchall support for all shop=* values
Mateusz Konieczny (2024-03-29 08:35:28+00:00): I guess that it means that next time I should consider contacting when they claim generic support for this specific value
SomeoneElse (2024-03-29 09:41:42+00:00): If a project offers explicit support (even if only generic rendering) it still makes sense to contact them as likely a code change is warranted if a combination is no longer in OSM.
For example, if you search https://taginfo.openstreetmap.org/keys/office#values for "funeral_director" you'll see two values that probably mean the same thing.  If one gets consolidated into the other (probably the singular into the plural, to mirror "shop") then a code change would still make sense to reduce the amount of processing that happens to OSM data before display.  It doesn't matter that "office=funeral_director" and "office=funeral_directors" are very likely to be processed in the same way; if a tag "goes missing" I still need to find out why because it might have been renamed to an unexpected tag that I don't currently process (something or think means something else).
Mateusz Konieczny (2024-03-30 15:14:28+00:00): I opened some issues:

https://github.com/vmarc/knooppuntnet/issues/397

https://josm.openstreetmap.de/ticket/23587 (this outright framed as bug report as it is a bug)

https://github.com/osmandapp/OsmAnd/issues/19427 (this outright framed as bug report as it is a bug)

https://github.com/SomeoneElseOSM/SomeoneElse-style/issues/21

I also contacted wanderreitkarte via email.