piebro/osm-data huggingface dataset:
eggie (2019-01-02 14:20:54+00:00): Dag Rens... nee het is goed gegaan, maar we zien vaak schade omdat je met de linkermuis edit maar ook schuift. 
De opmerking is uit voorzorg.

Kijk ook naar de betere editor JOSM. Daar schuif je met rechts en edit je met links.
Editor iD geeft ook weinig overzicht en is heel beperkt.
editor josm stap voor stap
https://forum.openstreetmap.org/viewtopic.php?id=53710       
Succes verder,
Eggie
user_5173844 (2019-01-02 21:21:53+00:00): Looks like an accidental break in Water Lane.
Andy_W (2019-01-03 09:49:11+00:00): Thanks, fixed now.
Domain Geist (2019-01-02 14:16:57+00:00): missing 1 street segment and mixed up 2 mtb routes - correcting immediately
Domain Geist (2019-01-02 14:24:08+00:00): update / correction to #65959777
◪ Jarv (2019-01-03 23:16:38+00:00): Nice addition with the bunker. But is Military the best attribute?
Maybe something like memorial or museum  is more appropriate due to it not being used for military purposes anymore?
stthomse (2021-02-01 10:05:21+00:00): Pillboxes are my speciality, I curate a database of their locations across the uk. Obviously they have no military purpose any more but the tags specifically exist for them under the Military bunker tag (although strictly they aren't bunkers either as they aren't underground). They aren't museums or memorials or even ruins as some have been tagged so I feel these are inappropriate tags as they were built for military purposes only.
skquinn (2020-08-31 03:28:23+00:00): In general, things should only be mapped once. In this case, the data from node 356830467 should have been merged into the building outline, way 659926052. (I have since fixed this.)
Constable (2019-02-02 13:36:25+00:00): Ciao, occhio però che con questo changeset l'ospedale di Magenta non risulta più sulla mappa. Per favore puoi dare un'occhiata e correggere?
Grazie :)
eggie (2019-01-02 16:28:41+00:00): Dag jansebas.. highway=pedestrian wordt in Nederland meer gebruikt voor voetgangersgebieden(winkelstraten). Bv in winkelcentra en stdascentra. Ook vaak als vlak met de extra tag area=yes.
Reguliere wandelpaden kun je beter als highway=footway taggen en als er geen bord staat altijd highway=path (met bijbehorende access-tags)
eggie (2019-01-02 16:34:35+00:00): ... aanvulling. landuse op landuse hoort niet. Dus geen recreation_ground taggen op landuse=grass. 
Je kunt het wel in een multipolygoon leggen. Dan "bed" je het in. 
MVG,
Eggie
eggie (2019-01-02 16:42:01+00:00): Over het grass ligt ook nog een keel landuse=village_green. Dat is een soort van Brink in Engeland. 
Dat is dus 3x landuse over elkaar.
eggie (2019-01-02 16:46:34+00:00): Ik heb even die village green verwijderd en de recreation ground als inner in de mp opgenomen van het grasveld. 
Wanneer je daar vragen over hebt stel ze gerust. 
Eggie
jansebas (2019-01-08 12:40:35+00:00): dag eggie,
het lijkt soms op in 3 dagen latijn leren...
het is ook een kwestie van kijken en beter kijken. bedankt voor je aandacht en aanvullingen.
groet, jansebas
eggie (2019-01-08 13:09:46+00:00): Dag jansebas
Mappen in Nederland is door alle import van landuse, adressen en gebouwen  gewoon extreem moeilijk. Door ervaring en veel vragen gaat het vanzelf dagen.
Zo'n multipolygoon maken had ik pas na een jaar door hoe dat moest en toen was nog helemaal geen spraken van al die landuse. We hadden een witte kaart.
We zijn wel bezig om de manier van taggen inzichtelijker te maken, maar het is een kwestie van lange adem.
Zie ook het draadje vandaag op het forum. Wat zijn de regels? 
https://forum.openstreetmap.org/viewtopic.php?pid=732757#p732757

Mapse verder,
Eggie
Leo Slager (2019-01-02 23:44:18+00:00): moved over to the correct position
dónal (2019-01-02 15:26:10+00:00): correction: source was bing aerial imagery.
jguthula (2019-01-18 02:28:26+00:00): Hi Cameron Ford,
Thanks for looking into this road and converting it from construction to a motorway. It looks like the road is missing a proper connection with appropriate highway at this location https://www.openstreetmap.org/edit?way=620480701#map=19/29.70049/-95.77733 . Since there is no recent satellite imagery to make this edit I am not touching it. If you have local knowledge please do fix it. 

Happy mapping!

Regards,
Jothirnadh
sabas88 (2019-01-02 17:35:02+00:00): This is plainly wrong
szydzio (2019-01-02 16:34:35+00:00): Hej miko101!Nie zbyt rychłe te zmiany już na nową numerację? Ledwo wymienili naklejki z rozkładami, nawet autobusy na wyświetlaczach maja jeszcze 55, kierowca zagadnięty kiedy to zmienią sam nie widział, o tabliczkach przynitowanych do wiat nawet nie wspominam… Może do czasu kiedy przyjemniej autobusy na wyświetlaczach nie zaczną mieć nowej numeracji użyć raczej official_name i official_ref tak jak to zostało zasugerowane na forum=> https://forum.openstreetmap.org/viewtopic.php?pid=730897#p730897  ?
rab (2019-01-04 18:47:29+00:00): Hi,
Kubudirira Street + 774/6 is now 2x on the map.
tdiesel (2019-03-05 08:03:43+00:00): Bitte POIs nicht doppelt eintragen wenn diese schon vorhanden sind. Danke!
maraf24 (2019-01-20 09:50:37+00:00): Uzupełniłem adres.
evanvosberg (2020-05-24 19:07:52+00:00): I wonder why "access" is set to "no" for path 60044924.

It's not accessible with motor vehicle for sure, but what about hiking or mountain-biking? Is it really not accessible?
Thomas_Schmitt (2020-05-24 19:34:45+00:00): access = no is definitly wrong. maybe I made a fault.
neuhausr (2019-01-04 15:02:48+00:00): Hi, welcome to OSM and thanks for mapping golf course features! I'd like to suggest a couple improvements to what you've done--you can read more at the Golf wiki page: https://wiki.openstreetmap.org/wiki/Golf  The golf=fairway tag should be used only for the mown area between the tee and the green. The tee area (golf=tee) and green (golf=green) should be drawn and tagged separately. Information on the hole (especially par=* and ref=* for the hole #) is usually kept on a way tagged golf=hole that goes from the tee area to the green. Name is only used if the hole has a specific name (ie "The Bear Trap" or "Amen Corner"). Lastly, adding landuse=grass is discouraged because it is technically incorrect, and people usually just add it in order to make features renders on the main OSM map. The French OSM map renders more of these features, ie http://tile.openstreetmap.fr/?zoom=16&lat=48.72648&lon=2.60806  Thanks again, and happy mapping!
topolusitania (2019-01-07 12:33:57+00:00): Olá
RUA JOSÉ DOMINGOS DOS SANTOS
-> Rua José Domingos dos Santos
Alecs01 (2019-01-02 18:35:07+00:00): Wrong edit again, please stop, those are not the names of the pitches.
Alecs01 (2019-01-02 18:33:50+00:00): Not a name
Alecs01 (2019-01-02 18:33:29+00:00): How would you call it a name? https://wiki.openstreetmap.org/wiki/Key:name
Alecs01 (2019-01-02 18:32:15+00:00): This is not the name of the pitch
mjlux (2019-01-24 12:33:53+00:00): Moien, den Tramsarrêt "Philharmonie-MUDAM" ass den Ament den eenzegen, deem säin Numm am Standard Layer net ugewise gëtt. Ech mengen, dat kënnt dovunner, dass du hei "station:railway" ewechgeholl hues. Ech weess elo net, wat richteg ass, mä 't sollt dat nämmlecht fir alleguerten d'Arrête sinn. Kéints du do vläicht nach eng Kéier dropkucken? Merci!
Stereo (2019-02-27 11:59:30+00:00): Moien! Merci fir däi Message a pardon fir di spéit Äntwert. Jo, wahrscheinlech well railway=station net méi drop ass. Op der anerer Säit ass dat wirklech nëmme fir eng Gare geduecht. Sou vill wéi ech vum Tram begeechtert sinn, soll all Halt wirklech bei zoom 14 gewisse ginn? Ech loosse mech gär iwwerzeeche, mä ech menge net. Wat mengs du?

Guillaume
mjlux (2019-02-27 13:16:31+00:00): Merci fir deng Äntwert! Fir mech ass dat heiten een "tram stop" an ech géif et esou taggen wéi et op https://wiki.openstreetmap.org/wiki/Trams#Tram_stops steet. Mä den User Lyon-St-Clair huet eise ganzen Tram op "light rail" mat iwwerall "railway=station" ëmgestellt an hie schéngt sech do vill besser auszekennen ewéi ech Newbie. Ech wëll also elo keen Edit War ufänken. Fir mech ass et nëmme wichteg, dass alleguerten d'Arrête gläich ugewise ginn. Wéi gesoot: Ech kenne mech do guer net gutt aus. Wat maache mir?
sskalyan (2019-07-24 04:53:38+00:00): Hi kwametedros,

Good job in editing turn restrictions and road directionality in this vicinity. you have aadded turn restrictions into this road (https://www.openstreetmap.org/way/329306374) from all possible entries, without any exceptions. Street sign says residential traffic only, people who are living inside the South Greenwood Avenue can access it anytime, which justifies the destination tag to the road. Kindly relook into this issue again.
We would like to learn from experinced mappers like you.

Thanks and cheers,
Kalyan.
kwametedros (2019-07-24 17:22:57+00:00): Hello Kalyan, thanks for bringing this up. I have removed the turn restrictions on the road as there is an access=destination tag on the way which will restrict non residential traffic away. Thanks again.
sskalyan (2019-07-25 04:33:46+00:00): Thanks for the quick response and resolution. 

Thanks and cheers,
Kalyan.
manings (2019-01-08 07:48:03+00:00): Contains profanity, reverted via: 66119948
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.mapbox.com/changesets/65965129
eggie (2019-01-02 18:57:01+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privébericht.
eggie (2019-01-02 19:06:00+00:00): Dag Jesyx. Het heeft eigenlijk weinig zin om gebouwen van vorm te veranderen in OSM, want de import en updates zijn allemaal Kadaster richting OSM.
Wanneer iets niet klpt kun je het beste een terugmelding doen bij het Kadaster zodat ze hun administratie op orde krijgen.

Op deze site op het potloodje klikken.. tenminste als het gebouw nu echt veranderd is.
MVG,
Eggie
https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html#?searchQuery=chopinlaan%20137&resultOffset=0&objectId=0355100000724804&geometry.x=143054.94&geometry.y=456782.73&zoomlevel=6&detailsObjectId=0355010000806720
eggie (2019-01-02 19:09:43+00:00): Ik heb het bos losgemaakt van het gebouw en het goed uitgelijnd mbv de BGT omtrekgericht. Dus de tekening van het kadaster. 
Eggie
Bąbel (2019-01-18 23:25:14+00:00): jak dla mnie nadałeś numer śmietnikowi pomijając że to duplikat !! a co z innymi AKTUALIZACJAMI  w twoim wydaniu ??
spam999 (2019-01-19 07:56:21+00:00): Jak popełniłem błąd wystarczy mi go wskazać. A co ma być z innymi aktualizacjami?
Bąbel (2019-01-19 22:55:07+00:00): 4 edycje a ile w nich punktów?
maraf24 (2019-01-20 09:45:45+00:00): @spam999: Widzę, że poprawiłeś kilka adresów na inne niż są na stronie mpruszczgdanski.e-mapa.net
Jeśli faktycznie adresy u nas nie zgadzały się z tymi w terenie, to proponuję byś na powyższej stronie kliknął na Zgłoś proble m i zgłosił miastu te błędy. Dzięki temu nie rozpowszechnią się one na inne serwisy i nie będzie groziło, że przy kolejnym imporcie Twoje zmiany zostaną nadpisane i błędne adresy przywrócone.
Ewentualnie możesz zmienić source:addr na np. "survey", by zaznaczyć, że nie pochodzą one z bazy Urzędu Miasta.
manings (2019-01-08 07:49:48+00:00): Contains profanity, reverted via: 66119977
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.mapbox.com/changesets/65965946
viloan (2019-01-02 18:07:20+00:00): Bem-vindo(a) ao OpenStreetMap e parabéns pela sua primeira edição! :-)

Temos um portal brasileiro sobre o OpenStreetMap, com várias informações úteis em https://wiki.openstreetmap.org/wiki/Brasil

Enquanto você está se acostumando com o OpenStreetMap, é recomendado que sempre pergunte aos usuários mais experientes antes de remover ou modificar objetos do mapa, especialmente aqueles que são aparentemente "estranhos" ou "fora do lugar".

Além disso, pedimos que não copie dados de mapas proprietários (como nomes de ruas do Google Maps, por exemplo) e que mapeie apenas o que existe na realidade.

Se você está mapeando por causa do Pokémon, dê uma olhada em https://blog.openstreetmap.org/2017/12/01/dicas-para-novos-mapeadores-pokemon-go/?lang=pt-pt

Se tiver qualquer tipo de dúvida você pode entrar em contato com a comunidade brasileira através de algum dos canais disponíveis em https://wiki.openstreetmap.org/wiki/Pt:Contact
O canal "Comunidade" do Telegram costuma ser o mais movimentado.

Abraço e boa diversão com suas edições!
viloan (2019-01-02 18:15:26+00:00): Bem-vindo(a) ao OpenStreetMap e parabéns pela sua primeira edição! :-)

Temos um portal brasileiro sobre o OpenStreetMap, com várias informações úteis em https://wiki.openstreetmap.org/wiki/Brasil

Enquanto você está se acostumando com o OpenStreetMap, é recomendado que sempre pergunte aos usuários mais experientes antes de remover ou modificar objetos do mapa, especialmente aqueles que são aparentemente "estranhos" ou "fora do lugar".

Além disso, pedimos que não copie dados de mapas proprietários (como nomes de ruas do Google Maps, por exemplo) e que mapeie apenas o que existe na realidade.

Se você está mapeando por causa do Pokémon, dê uma olhada em https://blog.openstreetmap.org/2017/12/01/dicas-para-novos-mapeadores-pokemon-go/?lang=pt-pt

Se tiver qualquer tipo de dúvida você pode entrar em contato com a comunidade brasileira através de algum dos canais disponíveis em https://wiki.openstreetmap.org/wiki/Pt:Contact
O canal "Comunidade" do Telegram costuma ser o mais movimentado.

Abraço e boa diversão com suas edições!
stevea (2019-01-03 18:48:19+00:00): Adam, national forests (part of the US Department of Agriculture) are not National Parks (part of the US Department of Interior).  These should not be tagged boundary=multipolygon (period — that is reserved for the "type" key), they should be tagged boundary=protected_area + protect_class=6 and the boundary:type=protected_area key-value pair should be removed.

Please set tags on all 26 of these National Forests back to what they are supposed to be.
stevea (2019-01-03 19:00:43+00:00): Update:  IF (and ONLY if) they are multipolygons (some are, some are not) set to type=multipolygon.  Otherwise, correct tags are boundary=protected_area and protect_class=6 and removing boundary:type=protected_area.
Adam Schneider (2019-01-03 19:16:13+00:00): I personally didn't set them as boundary=national_park; I just changed them to multipolygons, which they definitely should be.

As to what value should be assigned to the "boundary" tag, that seems to be up for debate. (See: https://wiki.openstreetmap.org/wiki/WikiProject_United_States_Public_Lands.) "National Forests" in the U.S. have the same legal status as "National Parks" in some other countries. I don't have a strong opinion either way.
stevea (2019-01-03 19:53:06+00:00): And this:  https://wiki.openstreetmap.org/wiki/US_Forest_Service_Data#Wilderness_Boundaries says to tag the way I tag, so I understand the confusion.

OK, I found your assertion of type=multipolygon to be true (all 26 in this changeset are, but not all protected_areas across the country are), so I left that tag there, because it is true for these.  I also conflated relation 70010 into 70986, because they are the same entity.

However, rather than changing all of the entities in this changeset (and indeed all of the USA) from boundary=national_park to boundary=protected_area (and assuring there is also the correct "paired tag" with that of protect_class=6), I'll wait for the Carto folks to better render boundary=protected_area.  (There is a move to get the recently "vote approved" boundary=aboriginal_lands rendered in Carto, for example, so render work for these keys does slowly improve).  I would like to see deleted on all 26 relations here the boundary:type key, as it is nonsensical and being deprecated, even though your source documents it (as a "red" key, meaning it has no wiki entry).

Summary:  longer-term, national parks should be tagged boundary=national_park (as many/most are today) but other protected lands (like these national forests) should be tagged with boundary=protected_area + protect_class=6 as well as having their nonsensical and being-deprecated boundary:type tag removed.

Thanks for your quick reply.
Adam Schneider (2019-01-03 20:05:29+00:00): Ah yes, now I remember: we've been using "boundary=national_park" because boundary=protected_area doesn't get rendered at all!  (Which is the same reason I tag Wildernesses as leisure=nature_reserve.)

As we speak, I'm working on standardizing all the tags on the western NFs.
Adam Schneider (2019-01-03 20:24:30+00:00): Next task: making sure all the Wilderness areas are included in the NF areas.  (I'm not sure why someone decided that they should be separate!)  I've already done it for Oregon and Washington.
stevea (2019-01-03 20:25:22+00:00): Yes, a somewhat-strong tenet of OSM is "don't tag for the renderer" (https://wiki.osm.org/wiki/Tagging_for_the_renderer) but since these are vast areas (30% of the USA land mass, by one estimate), a bit of a wink and a nod seems to be acceptable (I think it rather stinks and hold my nose, wishing this sort of tagging didn't happen) and these sorts of gyrations are done.  

For example, I sincerely believe that adding a leisure=nature_reserve to a Wilderness is technically incorrect, yet I know many do exactly that.  WHen you say "standardizing" there really is no such thing, simply this opinion vs. that opinion.

Honestly, the sooner (the better) for Carto to start to render boundary=protected_area (though the myriad protect_class values make this difficult:  look how much wrangling goes on to simply render boundary=aboriginal_lands in a single color).
stevea (2019-01-03 20:28:03+00:00): Wilderness are ABSOLUTELY different and therefore must be separate.  For example, in Los Padres National Forest (LPNF), I can collect downed wood (it is a forest, I am its owner) and build a campfire (provided there are no burn restrictions in effect).  I am not allowed to do any such thing in Ventana Wilderness, a significant part of LPNF.  These are distinctly different landuses and this must be accounted for in the tags, this is why they have different names (NF vs. Wilderness, protect_class=6 vs. protect_class=1b).
Adam Schneider (2019-01-03 20:30:23+00:00): By "standardizing", I mean setting all the National Forests to the same set of tags, so they'll all render consistently with each other, at least.  Then, when the carto people finally figure out a better solution, it'll be easy to set them to where they should be.

(I also don't think leisure=nature_reserve is necessarily "incorrect" for wildernesses. The wiki page says it should be used on "a protected area of importance for wildlife, flora, fauna or features of geological or other special interest, which is reserved and managed for conservation and to provide special opportunities for study or research.")
Adam Schneider (2019-01-03 20:34:36+00:00): Wildernesses are generally inside National Forests; when you're in Ventana Wilderness, you're ALSO inside Los Padres NF.  When you're in Mount Jefferson Wilderness, you might be in any one of three different National Forests. By making them separate entities, we'd have to erase the inter-NF boundaries inside the forest, and that isn't right.
Adam Schneider (2019-01-03 20:35:47+00:00): If you're looking for guidance from a protect_class, I suppose the thing to do would be to see which polygons you're inside and go with the lowest number that applies to that location.
stevea (2019-01-03 20:37:36+00:00): I know, I've tagged this way before MYSELF on wilderness areas.  There is a lot of history going on here (I've been repeating myself on these issues for almost ten years in OSM) and the main reason is that leisure=nature_reserve renders and boundary=protected_area doesn't render (yet).  I'm glad you have an eye towards the future when boundary=protected_area WILL render, as I do, too.  However, do know that while leisure=nature_reserve on a Wilderness boundary isn't "sloppy-bad wrong" it has been effectively superseded by protected_area and 1b.  But those don't render, yada-yada.  I get it, I hope you do, too, it appears you largely do as you say "when the carto people finally figure out a better solution...".  This stuff is messy and has a whole lot of history and a future that still has yet to unfold.  So, we have a bit of a mess on our hands.  Thanks for keeping it civil.
stevea (2019-01-03 20:39:31+00:00): Mmmm, "lower number" (of protect_class) doesn't automatically always mean "more protection."  It might appear that way, but I don't think it should be applied as a rule.
stevea (2019-01-03 20:40:35+00:00): Right, Ventana is inside of LPNF, AND it has stronger protections (1b vs. 6).
Adam Schneider (2019-01-03 20:46:58+00:00): No, I'm not suggesting that it should be a "rule" that's programmed into OSM somewhere.  After all, it's not OSM's job to communicate the laws that apply to a wilderness.  But I do think it's important that a National Forest's boundaries should include ALL of the land managed/owned by that NF; it's misleading if the wilderness makes a "hole" in the forest.  After all, when you're in Ventana and you meet a ranger, it's a Los Padres ranger, not a Ventana ranger!

Meanwhile, I need to start over on my cleanup task, because those Shasta-Trinity changes are wreaking havoc with my conflict resolution panel. :)
phidauex (2019-01-03 20:50:10+00:00): Hi, I'm interested in this discussion because I've done some repairs to CO and WY national forests. I agree with the end result here, but I question the "type=multipolygon" part of the relation. I thought "type=boundary" was actually the newer standard, with "type=multipolygon" being deprecated for boundaries? https://wiki.openstreetmap.org/wiki/Relation:boundary
stevea (2019-01-03 20:54:34+00:00): Again, we agree:  wilderness which is truly part of a NF shouldn't be a "hole" in a NF, it should be "part of it" but with protect_class=1b instead of the "enclosing" protect_class=6.

Regarding your Shasta conflicts, I suppose I could say "I'm sorry," yet I don't believe did anything wrong, rather simply conflated two entities into one when that was the correct thing to do.  I have struggled through some unbelievably painful JOSM conflicts, so I do feel your pain.  There is a single node there (one of those funny "corner boundaries") which threw Validator for a minor warning, but otherwise relation/70986 seems pretty "clean."  (Although any multipolygon relation with almost 200 elements is certainly "complex.")
Adam Schneider (2019-01-03 20:57:48+00:00): stevea: No worries.  It happens.

phidauex: It's a good question.  I thought that type=boundary was more for political entities (states, counties) that might end at a coastline and so might not be "closed," whereas a National Forest is always a defined area.  It seems unresolved on the "boundary" talk page: https://wiki.openstreetmap.org/wiki/Talk:Relation:boundary
stevea (2019-01-03 21:02:54+00:00): phidauex, for those "simple polygons" which don't need the extra topological complexity of why "multipolygon" exists (e.g. "holes" and the need for "inner" and "outer" roles on elements), there is absolutely no need to tag type=multipolygon.  (By omitting this, you do end up needing to put a key of type with SOME value into the relation, so use type=boundary in the case of simple polygons).

However, most of the time, these really are complex enough to warrant type=multipolygon (with outer and inner role set on elements as appropriate) and so in those cases, tag with key boundary.  That key can have many values, among them national_park but more recently (and it is attempted to be more accurately) with the boundary key's "paired tag" of the protect_class key, which has dozens of numerical values).

It's not really correct to say that type=multipolygon is deprecated as #1, that's not true, and #2, if the "lands" you are describing really NEED multipolygon topological "richness" to describe them (with inner and outer roles), then nothing else will do.  Please don't confuse multipolygon (a way of describing complex topology) with the sort of boundary the relation intends to convey (it might be a national_park, aboriginal_lands, something which protected_area + protect_class=xy better describes, etc.)