piebro/osm-data huggingface dataset:
gpserror (2020-02-21 17:08:30+00:00): It looks like you edited the original road in https://www.openstreetmap.org/changeset/81159035 (road is circa https://www.openstreetmap.org/way/221353854#map=13/40.7078/-86.1217)
Seems like your editor tool is dropping bits and pieces of old edits without clearing them, and placed in weird places.  Please get back ASAP I don't want this piece of road in my Garmin maps and want to delete this extraneous road quickly, but want you to fix your tools or workpath.
gpserror (2020-02-22 04:09:39+00:00): Couldn't contact in 24 hours on this serious problem, I went ahead and deleted the erroneous road in Fort Collins, CO that overlapped Mulberry Street.
gpserror (2020-02-22 04:21:57+00:00): The changeset that I did so is in # 81338179 ... sorry I had to change this back so quickly before you had a chance to respond to figure out how this happened to begin with.
freebeer (2020-02-22 19:56:04+00:00): off-topic, but i thought i'd mention this is an amazon edit, but unlike earlier where i could identify them based on the absence of a particular header, this one does in fact include
   host https://www.openstreetmap.org/edit
although i've not paid attention for some weeks to know if this is a new development and commonplace.
gpserror (2020-02-22 22:11:45+00:00): This was a fairly large piece of road that was plopped down, I really would like to get an explanation on how this got through.  Unlike the previous overlapping roads that were of the same road, this one was two different roads in two different states...  Noting that the overlapping roads problem is fairly frequent, I sure hope this kind of splatter isn't frequent, Amazon really needs to figure out what's going on fast, and so far it seems like they're dragging their feet.
freebeer (2020-02-23 07:07:11+00:00): yeah, now that i look at this, the v1 is a clone of the edited v6 (names need tweaking in indiana, some of the roads with this naming pattern have been expanded to South but not this S), it is not within the bbox of this edit which should be limited to the single car park service drive in pennsylvania.  there's probably some explanation why colorado is involved.

the two edits linked in
 << 81158988 · ssange · 81159095 >> 
before and after the v6 edit give no clue how the road got cloned about 1000 changesets total later.  here we have
 << 81159884 · ssange · 81160031 >> 
in michigan and minnesota, so no clue why colorado should be involved at all.

all these edits were made via the osm website, while i still see other amazon edits without the given host (internal amazon iD instance).  there is a common bug where amazon editors save multiple distinct edits to a single save creating large changeset bboxen; today i have suggested opening a new broswer tab for each edit rather than re-using an older edit tab when the editing session appears to freeze.

however, i recall reading somewhere that iD checkpoints unsaved data, so this might not be such a good idea to be running multiple editor instances, which i routinely due with potlatch which does not checkpoint unsaved data anywhere i know of, meaning unsaved work gets lost when the oom-killer reaps the flash instances.  so it may well be that my suggestion of multiple tabs may make things worse, with each iD instance claiming the unsaved data for itself.

obviously my earlier suggestion was not well thought out, and won't help with the known problems, so i should go back to my day job hauling stones and leave anything requiring thought and intelligence to the experts.
gpserror (2020-02-23 17:40:54+00:00): oh fu** (expletive self censored) the openmapchest USA map snapshotted this error :(  Looks like this two weeks I have a bad map.  Need to make sure I don't archive this weeks map with a known problem.

But anyway I was always worried about how iD handles restored sessions.  I knew that if you make changes in iD and then goto another page (firefox will warn unsaved changes) and then come back, it will offer to "restore" changes.  The restore seems kind of flaky, don't know what it actually saves.  And you're right, you cannot have two different iD sessions open at the same time (at least with the same userid on the same computer/browser).  While I don't know how the change got duplicated into Colorado, they need to find out.

Another thing that I found annoying is that while editing turn restrictions, a lot of the changesets are tiny.  I couldn't find a way to get iD to collate a bunch of tiny changes into one big change.   I gave up - and just saved the tiny changes.   I figure this is safer with how iD handles going back to a old session.  Really should just switch over to another editor if I really want to make a big changeset with only TR fixes in it.
freebeer (2020-02-24 03:43:07+00:00): dunno why, but the obsessive-compulsive in me has decided to look more into this behaviour, and thanks for your observations.

i started an iD window - it took several minutes to get beyond the white screen, but eventually it did.  admittedly i've got far too many tabs open, three with dubious javascript that looks to be a memory hog to monitor my public services.

partial output of cpu-sorted `top':
12324 freebeer  20   0 1754892 787984  10384 S  10,6 23,7 513:35.32 plugin-con+

(this is a separate process for multiple potlatch 1 and 2 windows with work-in-progress, including a pulled-and-joined node that p1 can't revert the way i tried before temporarily giving up)

21253 freebeer  20   0  457388   8652   1844 S   5,3  0,3   2:04.42 avplay     
 2227 root      20   0  328688  58244  28124 S   3,3  1,7 390:46.04 Xorg       
11953 freebeer  20   0 3412580 1,988g  54388 S   1,3 62,6   3845:16 firefox    

i really need to close multiple tabs.  last time i paid attention the main browser process was around 30% memory, now there is discernible thrashing, and like i said, i was ready to give up on starting iD with no visible action for several minutes.

 2237 freebeer  20   0   42528    464      0 S   0,3  0,0  15:23.70 twm        

call me old-fashioned, but it works great for me.

anyway, while my potlatch tabs are all in a separate process, the iD thread-or-whatever is part of the monolithic firefox and has put its memory use from 50-something to over 60%.

when i opened https://www.openstreetmap.org/edit?node=1036681089#map=19/42.31805/-72.64060 in potlatch1, it took longer than normal but not so long as this iD session.  so much for a lightweight simple editor for beginners.  to make things worse, i have a pile of Handys older than this machine that are even more memory-limited, where the browser will be killed within seconds of starting iD in order to visualise a changeset.

anyway...

i've edited road 400 in iD, deliberately did not save, and closed the window.  during this process i could not identify where iD checkpointed the work - `lsof' showed nothing, nor did the usual suspects like /tmp or ~/ reveal anything.  i think i need to dig in the source code rather than dissect my filesystem, the goal being to see what and how is being checkpointed, and where.

regards the small changesets, there are a few issues i saw, https://github.com/openstreetmap/iD/issues/1598 and https://github.com/openstreetmap/iD/issues/2251 and probably https://github.com/openstreetmap/iD/issues/703 which disappeared from my `lynx' browser history but not me brane so if the link is wrong, blame me.

oh blast, i meant to try to start two simultaneous iD instances.  but since i haven't found where to look yet, not sure if that would get me anywhere.

anyway, i don't have much to offer so i may as well mash the `Comment' button and go to sleep.
freebeer (2020-02-24 06:00:15+00:00): Nachtrag:

in fairness to the issue of iD startup time, i should note that i have observed that it attempts to make a connection to some microsoft mothership, for which i see no reason and which i do not permit, unlike the imagery layers and the like.  it could be that iD waits for this connection to fail/succeed; on the other hand i see hundreds of DNS connections to a server the ISP provides that is unresponsive as at present i am trying to debug the half-dozen problems on the ISP side why their 'net connection Does Not Work.  i used to get paid well for this.  anyway, if iD depends on being able to talk to microsoft, fakebook, and a plethora of other sites i don't give access to and have seen that iD functionality breaks, well, my observations are probably not relevant.  just setting the record straight, i hope.
gpserror (2020-02-24 08:27:52+00:00): iD takes forever to startup on slow machines like my Atom 1.6GHz - it takes minutes to load up and very sluggish in edits.  On fast machines, it's not really noticeable, mostly network latency.  However when editing several hundred node ways, it gets slow on even fast machines.  when i was drawing boxelder creek in the unrelated changeset https://www.openstreetmap.org/changeset/81338878 , by the end of the creek it took nearly 1 second to lay down another node and connect the way to it.  Pretty painful.  In any case one thing I noticed with iD is that by default it will pickup business logos from face***k etc, i made sure to turn it off as it was ***king with my privacy blocker script in my browser.   The option is like one of the only options you can change in iD which is kind of disappointing but very very helpful in itself.

Dang.  Really need a chat forum for discussions like this.  On the other hand perhaps another tangently related question is

how can we get paid by amazon to ***k up the map? :-)

Sorry, bad joke, sorry, sorry....
gpserror (2020-02-24 08:52:08+00:00): BTW if anyone was looking at my thousand edits, a lot of them were trying to address the errors showing up at https://www.openmapchest.org/mapfixer/united-states/ -- I click through them one by one, and each time they pull up iD or whatnot to edit, I can't "merge" multiple edits into one changeset.  I don't know if this use model is considered or not, then again, any two errors may or may not be physically close together.

Incidentally I've stopped fixing them for about a month now or at least slowed down a lot... the times I was actively editing, the biweekly error count was holding steady.  Now it's growing like 100 errors per week.  misery...
ssange (2020-02-24 10:01:42+00:00): Hi,
Apologies for the late response. Ideally our team responds within 24 hours any changeset comment unless its a weekend. Thank you for correcting the wrong edit and providing me inputs for improvement. On 18th, Feb somehow West 400S road got copied into my cache and was popping up every time I pasted access tags. Identifying it, I made sure to manually delete the West 400S road every time it got pasted. I made a total of 126 changesets on 18th, Feb but only in this changeset the road got pasted in a different state and got missed from my end. This is the first time I came across such scenario in my editing experience. Will take extra care going forward and would not repeat such errors again. Looking forward to learning from you.

Thanks,
ssange
SomeoneElse (2020-02-24 12:32:37+00:00): > Dang. Really need a chat forum for discussions like this.
There are a bunch of these - probably the most widely used in the US is the OSM US one listed at https://wiki.openstreetmap.org/wiki/List_of_OSM_centric_Slack_workspaces .  There's also IRC (see https://wiki.openstreetmap.org/wiki/IRC ) and a number of communities use Telegram (https://wiki.openstreetmap.org/wiki/List_of_OSM_centric_Telegram_accounts ) and others.
gpserror (2020-02-24 21:18:04+00:00): Yeah there are a lot of them around, unfortunately I'm not affiliated (nor really want to be affiliated) with any other organizations.  Would be nice to have a shared authentication that all OSM users can use directly.  The comments field works but quickly devolves off topic such as what I just wrote...sorry again...
MarkT105 (2020-02-24 06:11:57+00:00): This was not actually a change. I had accidentally interstected my building edit with a land use boundary and deleted the intersection. As an OSM newbie I didn't know if there was a way to delete this accidental edit.
Supaplex (2020-06-18 13:52:23+00:00): 恭喜您完成第一次的地圖編輯！ 歡迎加入開放街圖，群眾共同參與，繪製生活週遭大家關心事物的共編地圖。以下是相關的參考資料，歡迎隨時指教與提問。

編輯須知
台灣的標示依循準則可參考 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

台灣社群網站
台灣 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!
Supaplex (2020-06-18 13:53:25+00:00): 可以使用 life cycle 前綴處理
https://wiki.openstreetmap.org/wiki/Lifecycle_prefix
之後有新店家能將新店家資料加上去
eggie (2020-02-18 09:54:04+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privébericht.
Review:  Wellicht name=......  er nog bij?
MVG,
Eggie
eggie (2020-02-18 10:02:18+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privébericht.
Tip:  wanneer iets niet klopt in de Kadasterdata kun je een terugmelding doen bij het Kadaster via 
https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html#?searchQuery=boortorenstr&resultOffset=0&objectId=1702200000000297&geometry.x=188558.055&geometry.y=402103.605&zoomlevel=6&detailsObjectId=1702010000000297

MVG,
Eggie
muchichka_s (2021-02-20 17:23:14+00:00): Привіт. Звідки інформація, що ця будівля не має ужгородської адреси?
https://www.openstreetmap.org/way/309607784
osmviborg (2020-02-18 09:55:38+00:00): Det hjælper ikke at slette adressepunkter, punktet kommer tilbage. Hvis du mener det er en fejl, at adressen er der, skal du informere Frederikshavn Kommune.
Niels Jæger (2020-02-18 10:32:19+00:00): Ok tak igen. Huset findes ikke mere, så det er en fejl, at adressen er der. Adressen fremgår heller ikke af kommunens kort.
osmviborg (2020-02-18 10:59:39+00:00): Se her: 
https://danmarksadresser.dk/adresser-i-danmark/?husnummerid=0a3f5099-e31f-32b8-e044-0003ba298018
Niels Jæger (2020-02-18 12:46:31+00:00): Tak igen. Jeg kontakter kommunen.
tyr_asd (2020-04-28 17:10:40+00:00): Hallo. Wieso hast du denn hier die "ref" Nummer der Ausfahrt Zenzendord auf "Exit 4" geändert (und Innsbruck Süd auf "EXIT 3"), statt diese einfach als Nummer "4" (bzw. "3") zu lassen?
streckenkundler (2020-02-18 17:15:33+00:00): Hei,
Uhi... ist ja eine Menge... Danke! Das ist das schöne, wenn jemand vor Ort die Änderungen im Blick hat! (nur der Vollständigkeit halber für Dritte: hier der Link zur Quelle: https://www.senftenberg.de/media/custom/2779_2025_1.PDF) Du kennst ja unter Garantie den Link...
Sag mal, kannst du aus dem Stehgreif sagen, ob es auch eine Liste sorbischer Straßennamen von Senftenberg gibt?

Danke und Daumen hoch!

Sven
Riad bilkis (2020-02-26 03:06:04+00:00): Hôtel not hospital
Tomas Straupis (2020-02-18 13:05:52+00:00): Šitas kelias yra privažiavimas prie namų, jis neturi pavadinimo.
eggie (2020-02-18 11:16:12+00:00): Top!
user_5359 (2020-02-18 16:39:50+00:00): Welcome to OSM! I have delete your SEO SPAM (mostly no standard keys, no verifiable data or not positive verifiable address data). If this is an error, you can report it here, then we will be happy to help restore the data. For the most information in the description we have own keys. Please have look on the website http://wiki.openstreetmap.org.
mavl (2020-02-21 16:08:01+00:00): This changeset has been reverted fully or in part by changeset 81324628 where the changeset comment is: The changesets are reverted [DWG has the request to revert the changesets. Reason: nonexistent objects - https://www.openstreetmap.org/user_blocks/3512].
isidor (2020-02-18 11:30:40+00:00): Please read wiki carefully:

Disused rail lines have a special method of tagging which is in use:
RAILWAY=DISUSED + disused=rail/light_rail/tram
Vinber (2020-02-21 09:04:14+00:00): Bonjour et bienvenue dans OpenStreetMap,

nouvelle-nouveau, un petit mot ici pour faciliter votre arrivée : https://wiki.openstreetmap.org/wiki/FR:WikiProject_France/bienvenue

Cas particulier / Vous êtes en seconde, en cours de SNT, alors s'il vous plait, veuillez faire suivre à votre enseignant-e le lien suivant https://dane.ac-lyon.fr/spip/spip.php?article628

Et n'hésitez pas à répondre, poser des questions, ...
Alecs01 (2020-02-18 19:50:00+00:00): Ciao, perchè hai tolto il tag service=spur da questo binario? E' usato solo per traffico merci.
capostazione (2020-02-18 20:23:50+00:00): Il binario AP è diventato binario di circolazione con segnali di 1a categoria ed SCMT ed inserito in FL, non è più una semplice diramazione per lo scalo hupac
Alecs01 (2020-02-18 21:14:17+00:00): Ok grazie, lo prendo per buono, ma dà accesso soltanto allo scalo HUPAC, o sbaglio? Passano solo treni merci da lì, come anche da qui per esempio https://www.openstreetmap.org/way/223455424 mi sembra più coerente taggarlo come binario "di servizio"
capostazione (2020-02-18 22:00:37+00:00): I binari 7 e 8 di Gallarate non hanno marciapiedi, quindi non è ammesso il servizio viaggiatori, ma sono binari di circolazione per arrivo e partenza dalloscalo Hupac ma anche per incroci e precedenze per la linea domossola e Luino.
Ho letto le definizioni di open map e sono a tutti gli effetti binari principali ancorché dedicati solo ai merci. Fammi sapere se trovi delle definizioni diverse, grazie per le osservazioni
mavl (2020-02-21 16:07:58+00:00): This changeset has been reverted fully or in part by changeset 81324628 where the changeset comment is: The changesets are reverted [DWG has the request to revert the changesets. Reason: nonexistent objects - https://www.openstreetmap.org/user_blocks/3512].
Dimacn (2020-02-18 12:48:02+00:00): Здравствуйте. Скажите, по какой причине вы удалили фрагменты административной границы https://www.openstreetmap.org/way/340644776/history и https://www.openstreetmap.org/way/340644778/history  ? Кто будет их восстанавливать?
PLima785 (2020-02-18 13:21:26+00:00): Hello there
Can you please not use Bing since is old sat image the most update is ERSI or MAXAR https://wiki.openstreetmap.org/wiki/Pt:Uso_de_Imagens#Imagens_sat.C3.A9lite_em_Portugal
Also don´t erase reuse the poligons the historic is important
Lastly in Portugal the tag for motel is amenity=love_hotel not tourism=motel check https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dlove_hotel 
Thank you
mavl (2020-02-21 16:08:02+00:00): This changeset has been reverted fully or in part by changeset 81324628 where the changeset comment is: The changesets are reverted [DWG has the request to revert the changesets. Reason: nonexistent objects - https://www.openstreetmap.org/user_blocks/3512].
SomeoneElse_Revert (2020-03-02 13:20:06+00:00): This changeset has been reverted fully or in part by changesets 81679210, 81682323 where the changeset comment is: Reverting more political edits between Armenia and Azerbaijan .  See https://www.openstreetmap.org/user_blocks/3528 for more information
mavl (2020-02-21 16:07:55+00:00): This changeset has been reverted fully or in part by changeset 81324628 where the changeset comment is: The changesets are reverted [DWG has the request to revert the changesets. Reason: nonexistent objects - https://www.openstreetmap.org/user_blocks/3512].
Nmxosm (2020-02-18 18:18:37+00:00): Hallo komori4,

bei dem Supermarkt existiert noch die vorherige Beschreibung der "Medienbildung für die Stadt Frankfurt am Main". Bitte entferne diese noch. 

Zum Überblick sind die folgenden Seiten sicher hilfreich:
https://osm.org/help
https://wiki.osm.org/wiki/DE:Beginners%27_guide
https://wiki.osm.org/wiki/DE:How_to_map_a
https://wiki.osm.org/wiki/DE:Good_practice

Bei Fragen melde dich bitte einfach als Antwort hier, schreib unter https://forum.osm.org/ oder einer der zahlreichen Mailinglisten (z.B. http://lists.osm.org/mailman/listinfo/talk-de) oder erstelle eine Note (https://osm.org/note/new)

Ich hoffe, ich konnte dir erstmal weiterhelfen.

Viele Grüße
Nmxosm
Nmxosm (2020-04-19 08:45:11+00:00): Mit https://osm.org/changeset/83763324 erledigt.
aharvey (2020-02-19 05:48:11+00:00): See https://wiki.openstreetmap.org/wiki/Tag:leisure=fitness_station.

"Similar to playground equipment, individual exercise equipment within a fitness station should be mapped individually as separate nodes inside the fitness station area using fitness_station=* for the equipment type.

Alternatively it is acceptable to describe the available equipment on the leisure=fitness_station object with prefix-tags in the format fitness_station:<equipment_type>=yes."

So there should only be one leisure=fitness_station.

I've fixed this in https://www.openstreetmap.org/changeset/81202581
calcium990 (2020-02-19 07:25:01+00:00): Okay thanks for the tip and thanks for cleaning up after my newbie error! I did read the linked article at the time, but the nuance of the quoted statement was lost on me. I read the first paragraph of it and assumed it meant individual stations should be individually mapped within the region.
calcium990 (2020-02-19 07:27:35+00:00): Oh, sorry. I see what you mean. It was the "leisure=fitness_station" tag on the nodes that was the problem, not the nodes themselves. This was from picking it in the iD editor node type dropdown/autocomplete. I incorrectly presumed bare points was bad.
aharvey (2020-02-19 07:34:15+00:00): Yep, it's good to map them individually, with fitness_station=* on each of the nodes, but then just a single leisure=fitness_station. This is more in line with the wiki recommendation and https://wiki.openstreetmap.org/wiki/Good_practice#One_feature.2C_one_OSM_element. It means data consumers can know there is 1 fitness station here with multiple equipment.
mavl (2020-02-21 16:07:56+00:00): This changeset has been reverted fully or in part by changeset 81324628 where the changeset comment is: The changesets are reverted [DWG has the request to revert the changesets. Reason: nonexistent objects - https://www.openstreetmap.org/user_blocks/3512].
trigpoint (2020-02-18 12:36:37+00:00): Why have you added motor_vehicle=no to a footpath, the highway classification indicates it is not for motor vehicles.

Cheers Phil
di5order (2020-02-18 15:00:54+00:00): Because this footpath have tag access=yes, in navigation engines it means that footpath is routable for motor vehicles. for solution needs add motor_vehicle=no or remove the access=yes
Riemer17 (2020-12-30 14:15:57+00:00): Hi Garmin-User,
These boundaries are correctly tagged as boundary=place. Boundary=place is an agreed tag by the Dutch community for tagging boundaries of places like neighbourhoods and quarters.

https://forum.openstreetmap.org/viewtopic.php?pid=813285#p813285

Please do not change tags where you don't know if there is conscencus about and otherwise make a post on the forum.
user_177389 (2020-12-30 16:03:19+00:00): Thanks for the hint!

I've read the thread (google translated).

If it helps, I will restore the relations to the original tags.

Instead of boundary=administrative, I would tag the boundary lines with boundary=place. Is it okay?

Best regards

Mario
user_177389 (2020-12-30 17:01:41+00:00): Hello Riemer17,

I fixed it. Two relations have already been corrected:

https://www.openstreetmap.org/changeset/96681835

Best regards

Mario
Riemer17 (2020-12-31 20:59:05+00:00): Hello Mario,

Thanks!
user_5359 (2020-02-18 16:40:13+00:00): Welcome to OSM! I have delete your SEO SPAM (mostly no standard keys, no verifiable data or not positive verifiable address data). If this is an error, you can report it here, then we will be happy to help restore the data. For the most information in the description we have own keys. Please have look on the website http://wiki.openstreetmap.org.