piebro/osm-data huggingface dataset:
Jakka (2021-06-13 06:16:58+00:00): Het is niet omdat het niet bereikbaar is of privé dat dit niet bestaat ?
opendcc (2021-06-12 20:38:52+00:00): Hm, könnte die Straße im Nordosten nicht die Zugspitzstraße sein?
danielaa15 (2021-06-14 06:12:30+00:00): hey, ja war heute nochmal da, ist die Zugspitzstraße
eggie (2021-06-12 11:14:53+00:00): Oke...Mooi!  maar...

warnings:crossing_ways:building-highway

 In dit geval de weg met nodes vastmaken aan het gebouw op twee plaatsen .. en dan alleen onder het gebouw de tag covered=yes.  :)

Je zou het dus nog kunnen corrigeren. Dus aan de zuidkant nog even splitsen.
Denk dat je er wel uit komt.
eggie
rskedgell (2024-01-03 13:57:14+00:00): It's a residential street with no sidewalk, but also no additional restrictions for motor vehicles. It's almost the opposite of a living street, as there is no consideration of or provision for pedestrians.

In the UK, a highway=living_street is signed as "Home Zone", "Share space", or "Quiet Lane".

They are fairly uncommon - there is only one Home Zone in Newham which I can think of (although, Newham being Newham, the 30mph speed limit there tends to upset validators).

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dliving_street
https://www.legislation.gov.uk/uksi/2016/362/schedule/11/made#tgp1-tbl1-tbd1-tr27-tc1
Hungerburg (2021-06-12 16:11:59+00:00): Hallo westnordost! Willkommen in Innsbruck :)
westnordost (2021-06-12 16:30:48+00:00): Haha, danke,  ich bin hier im Urlaub! Du wohnst in innsbruck?
Hungerburg (2021-06-12 17:54:54+00:00): Hab gleich an Urlauber gedacht. Ja, ein local hier - mein Tipp, Gondel aufs Hafelekar - wenn der Wetterbericht stimmt ist am Di die beste Fernsicht.
westnordost (2021-06-13 18:35:52+00:00): Cool, danke für den Tipp!
Mathias_ADAV (2021-08-12 09:46:34+00:00): Bonjour, êtes vous certain qu'il y a des bandes cyclables à cet endroit ?
CouscousMerguez (2021-08-13 08:27:50+00:00): Bonjour, ces modifs ont été fait il y a assez longtemps. Il y a un risque que je me suis trompé avec Streetcomplete. Si vous avez une source plus récente qui indique qu'il n'y a pas de bandes cyclables, vous pouvez bien sur corriger mes modifications.
EneaSuper (2021-06-12 11:28:37+00:00): https://www.genova24.it/2021/06/lagaccio-dopo-quasi-3-anni-di-lavori-riaperto-al-traffico-il-ponte-don-acciai-264127/
mini-me (2021-06-12 14:13:16+00:00): Какая ещё остановка? Тут даже дороги нет
Stahlmann (2021-09-07 18:52:17+00:00): Vielen Dank für das Hinzufügen der Hydranten! Ich habe die Namen jedoch rausgenommen, da ein Eigenname von Hydranten i. d. R. nicht üblich ist. Vgl.: https://wiki.openstreetmap.org/wiki/DE:Tag:emergency=fire_hydrant
aharvey (2021-07-03 11:47:32+00:00): oh interesting I didn't realise there was a track along the creek here connecting the other tracks. I'll have to check it out.
Stahlmann (2021-09-07 19:10:36+00:00): Wie schon im Changeset 106250945:

Vielen Dank für das Hinzufügen der Hydranten! Ich habe die Namen jedoch rausgenommen, da ein Eigenname von Hydranten i. d. R. nicht üblich ist. Vgl.: https://wiki.openstreetmap.org/wiki/DE:Tag:emergency=fire_hydrant
快乐的老鼠宝宝 (2021-06-12 13:09:10+00:00): Don't use the key:construction=* in the planning area, which means that the construction has already started. If so, you can tag it like this, but I guess you mean "long-term planning", it just stays on the blueprint, so I think this should be tagged with Key:proposal=*

——LaoshuBaby 6.12.2021

规划中的地方就不要用construction了，这是代表已经开工了的意思。如果开工了可以这么标记，但是我看你意思是“远期规划”，就是仅仅停留在纸面上，这种应该使用proposal标签
——快乐的老鼠宝宝 2021.6.12
om_mmyexplorer (2021-06-12 13:07:21+00:00): It's Kanchanaburi not Ratchaburi, sorry!
starsep (2021-07-15 12:13:55+00:00): Proszę o zaprzestanie mapowania mobilnych punktów na drogach
ravali_78 (2021-06-14 05:24:03+00:00): Hi nm011206,
I have fixed the alignment,as building polygon overlapping with residential highway.Kindly check with way 873409542,https://www.openstreetmap.org/changeset/106307923.
Thank you.
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/106253098
philippec (2021-06-12 15:15:18+00:00): Ruddervoorde Sijslostraat.
Van Eeno, dat betwijfel ik.
philippec (2021-07-21 08:39:32+00:00): Ruddervoorde Sijslostraat aed.  De locatie beschrijving was verkeerd.  Het stond bij de aannemer die er aan het bouwen was.  Ik heb hem ook 11.3 meter verzet.
aixbrick (2021-06-13 08:14:15+00:00): Hello,
you added a relation for a train route, which does not exist anymore. OSM is not a historical database, i.e. apart from a few exeptions we do not add non existing features. Where did you discuss the adding of those routes to OSM and where is the tag "route=historic_railway" defined?
Up to clarification, please stop adding more historic routes.
Regards
BCNorwich (2021-06-12 17:49:36+00:00): Hi, You've tagged highways Way: 953734616, 953734617, Way: 320565447, Way: 320565444, Way: 953734618 and Way: 953734620 as layer=-1 tunnel=culvert which is obviously inadvertently wrong.

You also have 240 metres long Way: 953734622 tagged as barrier=gate.

Could you please look to remedy these problems, Thanks?

Regards Bernard.
ushills (2021-06-13 10:02:38+00:00): Corrected now.
Colin Smale (2021-06-12 14:10:45+00:00): Hi! Electoral wards should not be tagged as boundary=administrative but boundary=political. See https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpolitical
Colin Smale (2021-06-12 14:11:55+00:00): An example is right there in Norbury - https://www.openstreetmap.org/relation/2234325
ramthelinefeed (2021-06-12 14:46:16+00:00): Hi - sorry yes, I'd already spotted that before I read your message :) 
Have got it right now?
Colin Smale (2021-06-12 16:42:27+00:00): Yeah, it looks good now! Thanks
Colin Smale (2021-06-12 14:15:24+00:00): Hi! Did you really mean to delete all those buildings? It would be helpful if you explained your rationale/sources in the changeset comments (instead of "a" which sounds a lot like "I can't be bothered")
QQQQQ (2021-06-12 18:06:10+00:00): I deleted some buildings which were not accurately mapped since it was easier to make them new than editing the existing ones.
Colin Smale (2021-06-12 18:26:13+00:00): Thanks, but my remark about the changeset comment still stands though.
gurglypipe (2021-06-13 16:21:43+00:00): Hi, I’ve partially undone this changeset, and completely undone your other changeset 106254668 (in changesets https://www.openstreetmap.org/changeset/106289118 and https://www.openstreetmap.org/changeset/106289011) as you appear to be incorrectly re-tagging roads as paths.

I suspect this is a case of tagging for the renderer (https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer) which is not allowed on OpenStreetMap. See the linked page for more details, but essentially it means things like vehicle routing will be broken by your changes.

Please use the most appropriate tagging for an object, regardless of how that makes it look on the rendered map. If you have any questions, please feel free to ask! :)

Thanks for your edits around golf clubs recently.
GoodClover (2021-06-12 14:10:03+00:00): Sorry for the large, changeset.
Must've forgot to click upload between the two
Mateusz Konieczny (2024-03-07 15:39:44+00:00): Hello!

You used
mtb:scale=1æ
on https://www.openstreetmap.org/way/511335113/history

Have you maybe meant
mtb:scale=1
?

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?
knuthaug (2024-03-07 16:01:15+00:00): Definitely a typo! Please fix it if you have the time. If not, I'll get around to fixing it during the weekend.
eggie (2021-06-12 16:03:15+00:00): Dag Goofy  Achter het hek is het gewoon een highway=service met access=private

De openingstijden kunnen bij de info van de milieustraat op het vlak. 
Het gaat om de info.. 
Gebruik deze 'tool' om de tijden in te vullen en plak de resultate achter opening_hours=... 
openingsuren-tool 
 
http://projets.pavie.info/yohours/ 
Dus dit niet op de wegen gaan taggen. 
Openbare wegen kun je taggen 

Wegen waar tijden gelden gaat met conditionaltagging
bv
naast access=private
motor_vehicle:conditional=yes @ (Mo-Sa 06:00-12:00; Su 07:00-13:00) 
Dan zou het om die tijden moeten routeren mits de app bouwers er rekening mee houden. 
Bij het afvalstation zou je het beter alleen bij de openingstijden houden. Buiten die tijden kun je er toch niet terecht.
Gr eggie
szalona_entropia (2021-06-17 10:07:45+00:00): Fragmenty łącznic pozwalające przejechać pomiędzy Żywiecką a Bystrzańską nie powinny być trunk_link
John Kastner (2021-06-17 13:26:46+00:00): This revert deleted some segments of road in College Park, MD. I'll restore them when I get a chance, but it may be worth checking that nothing else has been similarly affected.
ZLima12 (2022-09-05 01:59:39+00:00): Hi,

You mapped a traffic signal on the subway line beneath the street. Please be careful with what you're mapping.
turepalsson (2021-06-30 17:20:51+00:00): Relation 76908 is now a member of itself. I doubt that was intentional. =)
Neuwieder (2021-07-01 11:34:02+00:00): Thanks. Should be fixed now. Maybe an Issue with ID?
Firefishy (2021-06-14 23:30:41+00:00): Nice first edit. Any more appreciated.
ottwiz (2021-06-12 22:25:04+00:00): Mapped forests, and aligned/added roads in Eastern Texas. Shame on you, JOSM for adding no comment.
mueschel (2021-06-13 08:52:53+00:00): Please don't add points for alignment of aerial images to the OSM database.
There is a dedicated service for that:
https://wiki.openstreetmap.org/wiki/Imagery_Offset_Database
Bert Araali (2021-06-14 11:48:06+00:00): I know, and I am a very intensive user of it. The calibration point keys I am adding at this time are an extension and tested out locally. A proposal will be established when it gains support. Although the Imagery_Offset_Database is a nice implementation it has the following issues:
1. Data is stored in an external db, currently only as plug-in for JOSM. The calibration points and offsets are not accessible or implemented in other editors like iD. Since it is an external dB with a server outside OSM, one might question how long it may exist, it's up to the support and gratitude of the developer. 
2. It uses a license different from OdBl, compatible but might create attribution or licensing issues in other editors.
3. The source of the calibration data cannot be entered, only limited comments are possible. 
4. Only support way data. This is an issue when you want to use geodetic ref points as nodes, calibration points by default. It also doesn't allow to enter or reference coordinates in different datum.
5. Applicability is defined as a fixed radius of 15 km. Maintenance tools are poor. This especially is an issue in mountainous areas where a higher density of calibration points is needed. 
So this new or reused calibration (recovered from the True Offset proposal which never gained support) key and namespace tries to address these issues, we will see if it is useful and gets support. Will truly resolve ever growing issues mostly by beginners and HOT teams to disregard true offsets.  Storing it in OSM is even more desirable as it stores real ground truth and verifiable information, not just for imagery offsets but also for support of other GIS related dataset coordination.  Don't worry, I will keep track of the sets I am creating, when no support is gained I will remove them later. Greetings, Bert Araali.
mueschel (2021-06-14 12:05:36+00:00): "Storing it in OSM is even more desirable as it stores real ground truth and verifiable information"

No, it doesn't. It's not even clear which version of images from which provider it refers to. Knowing the date and provider doesn't help either, because you could have any kind of older picture in your cache or you might be served a completely different set of images depending on the location of your computer!

It's also not clear to me how a tag like
calibration:lon = 34,266633 should be interpreted - it's on a node at a different location after all  (and won't be understood as a number by most locale settings at all because it uses a comma as decimal separator)

If the building is in a different location, then it should be moved, but not tagged to be somewhere else!
Bert Araali (2021-06-14 15:14:34+00:00): They are not offsets, it doesn't refer to any imagery, it is like the calibration points in the Imagery Offset database, coordinates in WGS84 as default in OSM, independent from any imagery or other data but usable to determine offsets accurately. Calibration:lon and calibration:lat refer to the initial positions and part of the calibrated shape.  They are not stand alone nodes. If we use them on geodetic or surveyed points they will be added as attribute tags. They are required so one can verify if the original calibration shape is retained when calibration was done. You have a point with the comma, should be a point, is caused by my keyboard locale settings, will change that. The buildings are not in a different location, the nodes with the coordinates apply to that specific object they are part of. The objects should not be moved, they are calibrated with GPS readings, that's the whole point of this tagging. Be patient, will become clear when it is properly documented.
Bert Araali (2021-06-14 18:37:58+00:00): Changed the decimal , to . . Noticed also that mistakenly some buildings were copied with lat and lon on a building, copy error.  Deleted those tags. Everything is now according to calibration points also stored in Imagery Offset Database. Will prepare doc later this week.
fabiotofy (2021-06-16 10:48:31+00:00): non sembra piuttosto che quì prosegua via Lignano fino alla confluenza con viale Europa Unita ?
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/106257820
Horza (2021-06-13 20:45:24+00:00): Plus a Little Caesars in Chicago. In future could you keep your changesets more geographically localised?
Diana IRM-ED (2023-03-17 10:02:21+00:00): Hi pamym,
your editing looks awesome.
I want to ask some questions whether the building is in relation with ID 12842091
(https://pewu.github.io/osm-history/#/relation/12842091). Is that building apartment actually one building? 
because you are made a polygon with 4 member outers, and you mapped in all of Apartment Seri Kembangan area in the same way. I think instead of simply creating a multipolygon with 1 member outer (apartment building) and 1 member inner (area inside the apartment). May I modify the relation like that? or have you any other suggestions?
Thank for your understanding.
Happy Mapping
Jakka (2021-06-12 17:21:52+00:00): Je corriger votre edit.
Ces toujours un building type house....
            ---
            #REVIEWED_GOOD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/106258689
Jakka (2021-06-12 17:28:20+00:00): attention jamais mettre deux fois même info
            ---
            #REVIEWED_GOOD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/106258689
JeroenHoek (2021-06-12 16:34:41+00:00): Lekkum*
Anisa IRM-ED (2023-03-17 07:31:46+00:00): Hi, pamym
Thank you for your mapping contribution.

While doing validation about MultiPolygon relation, I find that the apartment building that belongs to Multiploygon relation with an id of 12842137 is mapped by sharing each other building nodes, and unfortunately, it causes the error "multipolygon outer way shares segment with other ring"

Due to my lack of local knowledge on this area, please allow me to ask some questions:
1. Is the Apartment building a single building or consist of several separated buildings?
https://pewu.github.io/osm-history/#/relation/12842137

2. Do you mind if I fix this issue by merge the separated buildings into one building as the outer member of relation and the field inside of the building as the inner member of relation? or do you have any other suggestions?

Feel free to provide any suggestions, it will be really appreciated :)

Thank You, and Happy Mapping!
pamym (2023-03-17 10:02:16+00:00): Hi,
1. It's apartment area that consists several block.
2. Please feel free to edit as you wish.

Thanks.
LudovicG (2025-10-07 04:59:01+00:00): Bonjour Florian (on s'est croisé au SOTM FR 2025),
Je suis surpris de la ref de la post_box "CLE34" qui ne ressemble pas au format A9A9A9 plus classique.
D'après Datanova, la ref serait A0K1V7.
As-tu des éléments pour comprendre cette ref atypique ?
overflorian (2025-10-14 07:22:58+00:00): Hello, ravi de te retrouver ici après t'avoir croisé !
On a bien des photos Panoramax à cet endroit-là mais impossible de lire le numéro de référence.
Je suis d'accord avec toi, le format est très suspicieux, je pense avoir fait une erreur; je supprime ça.
Merci pour ton attention.
Владимир К (2021-11-03 13:06:50+00:00): пожалуйста, не используйте тег crossing=marked на точках переходов. переходы могут быть только регулируемыми(со светофорами) и нерегулируемыми(без светофора) - crossing=traffic_signals и crossing=uncontrolled соответственно
Владимир К (2022-02-06 10:20:11+00:00): Возник вопрос, пор какиому признаку выф расставляли motor_vehicle=destination? там везде стоят теперь знаки?
Noelren (2022-06-14 09:27:20+00:00): С удовольствием расскажу. Я работаю в такси, которое использует OSM как навигацию для построения маршрутов. Прокладка маршрута полностью строится на правках в этих картах и если маршрут предполагает возможность построить себя через "упиздошеные в хлам" улицы, на которых можно проколоть 5 из 4 колес, согнуть диски, порвать все днище о неровности этих "дорог", он с удовольствием это сделает. Изюминкой на торте становится то, что доказать пассажиру, что лучше мы поедем по нормальной дороге в обход и это будет стоить дороже на 20-30 рублей, иногда становится испытанием. И вот дилемма: мне жертвовать лишние деньги на ремонт авто, потому что навигатор повел меня так, а клиент не хочет платить, либо исправить построение маршрутов так, как мне было бы удобно и выгодно, не доказывать клиенту то, что картами пользуемся, которые словно дети рисовали и не размениваться на копейки с каждым таким типом.
Знал бы каждый таксист, что я им жизнь облегчаю, носили бы меня всем скопом на руках.
P.S. Этот тэг никому не вредит, прошу не править их, т.к. я исхожу лишь из своего личного опыта присутствия на каждом правленом участке. К тому же, глядя на прорисовку некоторых районов города, приходит мысль, что всем вообще похуй на нормальную картографию.
Владимир К (2022-09-28 15:07:12+00:00): тег вредит своей некорректностью. тег должен стоять, там где есть знак. убитость дорог следует указывать тегом smoothness
Владимир К (2022-09-28 15:28:17+00:00): тем более не понятно, зачем вешать тег поголовно на все residential, по ним и не должно вести транзитом, когда есть рядом дороги более высокого уровня. так что теги с частного сектора я убираю, знаков там нет
Noelren (2022-12-23 08:25:43+00:00): Тэг smoothness исключает транзит кратчайшим путем и навигация будет строится по ближайшим более качественным дорогам?
Владимир К (2022-12-23 17:56:30+00:00): теги сами по себе не исключают ничего, теги описывают реальное положение на местности. 
https://wiki.openstreetmap.org/wiki/Key:smoothness

если этот тег не учитывается роутером при построении маршрута, то это недостаток роутера, не надо подгонять данные под него
SekeRob (2021-06-12 19:46:53+00:00): Hi

Not sure why you say one thing and then include an edit in South-East Asia as well. Accidental?

The phone number format is incorrect. Proper is country code, area code, local phone number i.e if this is in Germany +49 09171 81329
If there is a second phone number dont use phone_1, rather use the semicolon separator and add the number, again in the prescribed format, so in total, delete phone_1 and make the whole
phone=+49 09171 81329; +49 09171 4784
Same applies to the Deutsche Bahn footway.
cheers
gscholz (2021-06-16 04:50:16+00:00): Hi  José,
this changeset has created errors in the OSM databse regarding overlapping ways:

http://tools.geofabrik.de/osmi/?view=routing&lon=-88.08652&lat=15.49521&zoom=14&overlays=duplicated_edges,duplicated_edges,duplicated_edges_areas,snap_points,unconnected_open_ends_1,unconnected_open_ends_2,unconnected_open_ends_3,unconnected_open_ends_4,unconnected_open_ends_5,unconnected_open_ends_6

https://overpass-api.de/achavi/?changeset=106259889

Can you please fix this?
Guido
eggie (2021-06-12 17:54:31+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht. 

Feedback  Je kunt nog toevoegen
religion=christian
denomination=roman_catholic 

MVG, 

Eggie 

Namens de OSM Community
Abdullah Abdulrhman (2021-06-13 15:53:38+00:00): نرجوا عدم إضافة أماكن عشوائية أو خاصة غير صحيحة
moreno96 (2021-06-25 15:56:18+00:00): سلام.
چرا منطقه مسکونی گلبهار رو تغییر دادید به city؟
aixbrick (2021-06-13 09:29:08+00:00): same as in https://www.openstreetmap.org/changeset/106254015
aixbrick (2021-06-20 08:48:07+00:00): No reaction, reverted with https://www.openstreetmap.org/changeset/106657195.
But thank you for deleting the other route (https://www.openstreetmap.org/changeset/106276234).
Konkon153 (2021-06-13 12:02:15+00:00): [ und damit alle Adressen in der Gemeinde Hagenow vollständig angepasst ]
ezekielf (2021-06-14 20:21:50+00:00): Looks right to me, Stan, although I was under the impression most OSM based routers assumed bicycle=no on highway=trunk roads unless otherwise tagged.  Sounds like that wasn't your experience though.  What routing service were you using?
Stan Brinkerhoff (2021-06-14 22:38:13+00:00): I was using (https://wandrer.earth/scoring#0.32/0/-124.2).  I'll follow up with the author as they do seem to suggest trunk would have excluded this path. 

Thank you for the feedback!
SekeRob (2021-06-12 18:49:38+00:00): Hi,

'Bearbeitungen in China'. When making changes in other countries then where they natively speak German, please apply the courtesy to either do the edit comments in the local language or in English so they have at least an indication what you did, but 'bearbeitungen in China' is so meaningless you could as well have made none or make it in Klingon.
2. Why does the rest of the world have to see those edits in their local change history from Murmansk to Beijing with North America and Europe in-between?

Anticipating your future consideration.
Oskarst_ (2024-05-21 10:58:42+00:00): Hei,
Ser en del av stiene som er kartlagt ikke har noen bruk i Strava heatmap, og heller ikke er synlige i flyfoto. Dette gjelder blant annet østlige del av 953808790, østlige del av 953808796, deler av 953808793 og 953808794. 

Kjenner du til om stiene finnes?
erickdeoliveiraleal (2022-05-21 14:01:15+00:00): this street really exists https://www.openstreetmap.org/way/953811372 ?
GartenStuhl (2021-06-15 05:54:39+00:00): hello there
since you requested a review, ill check in into some of yours

on this one, i kinda dont get it. its a small hut but its not covered?

so i think the wood or fuel is covered in the small hut but not the tables and benches? except that i dont get it (probably others too), this CS looks fine :)
i would revisit the description-tag
https://wiki.openstreetmap.org/wiki/Key:description
tivolo (2021-06-15 06:29:25+00:00): danke fürs reviewen. die holzhütte ist überdacht und hat sitzbänke und einen tisch. Die feuerstelle ist draussen und es gibt kein holzlager. ich ändere auf covered=yes und ändere die beschreibung auf deutsch (gemäss wiki sollte es local language sein). Ist das so verständlicher?
GartenStuhl (2021-06-15 06:36:23+00:00): Ich denke, dass covered=yes zählt jeweils nicht für die Feuerstelle selbst sondern für die Sitzbänke (habe mich das nie so explizit gefragt...)
jetzt wo dus schreibst ist es mir klar ja.

Es gäbe noch die Möglichkeit die Grillstelle und die Bänke separat einzutragen.
https://wiki.openstreetmap.org/wiki/DE:Tag:tourism%3Dpicnic_site
Könnte aber auch etwas overdose sein...
tivolo (2021-06-15 08:06:24+00:00): Macht Sinn, bin wohl ein wenig zu technisch vorgegangen.
GartenStuhl (2021-06-15 05:57:18+00:00): looking fine.

if you now know, that there is no roof, you could add the tag covered=no, so everybody knows it.