piebro/osm-data huggingface dataset:
ika-chan! (2020-12-11 21:48:44+00:00): I'm sorry, I must have slipped up with copying the name, probably due to the confusion with editors going for different localisation tags. Is there anything that I can fix for you?
Glassman (2020-11-14 00:15:47+00:00): Thank you for your edit. I reviewed your work and it looks good.
            ---
            #REVIEWED_GOOD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/94089002
eggie (2020-11-17 09:52:58+00:00): In het stuk met water en landuse langs de Laagheidehof/ Nieuwe Overoonseweg zaten zoveel fouten in de multipolygoonrelatie dat ik dat heb aangepast zodat het weer rendert.
Een inner mp water mag niet uit de outer MP grass komen. De tag landuse=grass hoort op de outer relatie en niet op het lijnelement. 
mvg,
eggie
Roelieboelie (2020-11-17 11:34:54+00:00): Bedankt voor het recht zetten eggie.
eggie (2020-11-17 12:06:10+00:00): Mp s zijn best lastig.. De inner mag de outerniet raken ..laat staan er helemaal doorheen steken. Dan rendert het gras niet meer. Dus die twee stukken gras samengevoegd  zodat het water ..de inner.. niet de outer .. het gras .. raakt.
Roelieboelie (2020-11-17 12:52:31+00:00): Haha, goed verwoord. Yes is iets nieuws voor mij. Ik duik erin. Gaan we leren.
!bm (2020-11-13 22:48:52+00:00): Hallo JaayJaay,

was, wenn kein https://wiki.openstreetmap.org/wiki/Tag:office%3Demployment_agency soll es denn sonst sein? Jetzt ist es in OSM nämlich gar nichts. (Ein Tagging ersatzlos zu löschen und dabei nicht zu verbessern, dürfte nicht die Lösung des Problems sein.)

--besteGrüße!bm
JaayJaay (2020-11-13 23:40:42+00:00): Da hat sich das jetzt doch überschnitten. Ich hatte nach einer Alternative unter amenity. geschaut, jedoch nichts wirklich Passenderes als den vorherigen tag gefunden. Ist wieder zurück geändert.
!bm (2020-11-14 06:49:40+00:00): Ja, habe es weiter verbessert: https://www.openstreetmap.org/changeset/94096341

contact:*-Schema ist nicht verpflichtend, empfiehlt sich aber der Übersichtlichkeit halber – phone syntax eher schon, name sollte auch nicht versal geschrieben werden sein, insb. wenn kein Akronym.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/94089026
eggie (2020-11-14 08:10:05+00:00): motor_vehicle=no zit al ingebakken.
De wiki is niet heel duidelijk zie ik. 
Hoeft niet.
Wel kun je moped en mofa=yes taggen om die categorieën door te laten gaan en motor_vehicle=no op te heffen. 
De defaulttags zitten ingebakken.
Soms kan/mag een motorfiets wel langs een paaltje en tag je nog motorcycle=yes mits toegestaan.
Vaak bij doorsteken in woonwijken is dat het geval.
https://wiki.openstreetmap.org/wiki/NL:Tag:barrier%3Dbollard
gr eggie
PT-53 (2020-11-14 07:43:40+00:00): Hallo hiichbinpaul,
Du hast in diesem Änderungssatz den Verlauf der Straße Funkenweg verändert und gibst als Quelle die Bing-Luftbilder an. Auf den Bing-Luftbildern ist der vollständige Verlauf des Funkenweg aber (noch) gar nicht zu sehen.
Im Editor ID stehen im Menue Bildmaterial-Einstellungen am rechten Bildschirmrand verschiedene Luftbilder zur Auswahl, u.a. auch die Luftbilder Maxar Premium Luftbilder (Beta). Dort ist die Straße Funkenweg bereits sichtbar.

Bitte immer alle Luftbilder testen und dabei auch den Versatz beachten
Wiki:
https://wiki.openstreetmap.org/wiki/DE:Good_practice#Luftbilder_vor_dem_Abzeichnen_ausrichten

Ich habe Deine Änderung zurückgesetzt, so daß die Straße jetzt wieder richtig verläuft.

Grüße

PS.
Für Fragen oder Rückmeldung einfach in diesem Änderungssatz einen neuen Kommentar erstellen.
Glassman (2020-11-14 00:15:41+00:00): Thank you for your edit. I reviewed your work and it looks good.
            ---
            #REVIEWED_GOOD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/94089328
az_az (2020-11-17 16:44:07+00:00): Hello my friend
The planned area denotes that it is sandy ground and the truth is that it is hard or rocky because I know the place
Can you modify it or let me amend it
thank you very much
Cyclono (2020-11-24 14:07:33+00:00): Hi az az,

Sorry i didnt see your comment. We can remove the sand, I saw that they use rock for mountain tops, not for rocky area. 

Since iraq is so hot, i thought sand would be more close. 

In most of other countries it is either farmland or grassland. 

I will check if i can find some desert rock for this. 

Thnks for your comment!
Øukasz (2021-05-05 13:18:03+00:00): Hello,

Just a short courtesy comment that I am working on setting up some relations for Niger roads:

1: https://www.openstreetmap.org/relation/1202801
4: https://www.openstreetmap.org/relation/12670600
11: https://www.openstreetmap.org/relation/12666293
24: https://www.openstreetmap.org/relation/3136633
25: https://www.openstreetmap.org/relation/3136634
zaizone (2021-05-05 13:57:20+00:00): Hello, i'm pleased to hear it, nice work :-) Is it part of a specific project ? Some of these relations are missing in the "super relation" www.osm.org/relation/3136636
Øukasz (2021-05-05 14:31:53+00:00): no specific project at all, just looking for fixes to do.

i haven't touched the superrelation at all, though I am aware of 2 of them. once I'm done with the routes themselves, I'll look at the superrelations.

BTW, I just thought of something: might you know how the N1 goes through Niamey? i left a gap because I don't know the exact route, but maybe you do?

https://www.openstreetmap.org/relation/1202801#map=11/13.4901/2.1094
zaizone (2021-05-06 08:57:54+00:00): Sorry, I have never been in Niamey, just landed once on my way to Ouagadougou. I have checked street level imageries from "mapillary" to see the road references inside Niamey, but I was unable to find these informations on road signs. I suggest to leave a gap in the relation.
gpstracks (2020-11-14 15:10:14+00:00): Hi.
Please, do not add ref number in "name" tag.
Refer to
https://wiki.openstreetmap.org/wiki/CAI#I_tag_da_utilizzare
Thank You.
Nakaner-repair (2020-11-15 20:55:32+00:00): Hallo,

dieser und vergleichbare Änderungssätze sind durch https://www.openstreetmap.org/changeset/94163912 rückgängig gemacht worden. Die Gründe sind dort dargelegt. Ich bitte um Beachtung.

Viele Grüße

Michael
DeFra85 (2021-12-28 22:34:34+00:00): Hey, war die Sehenswürdigkeit "Dörenther Klippen" bei deiner Bearbeitung auch nur auf dieses kleine Areal begrenzt?
Glitch-Hunter (2021-12-30 20:35:26+00:00): https://overpass-api.de/achavi/?changeset=94090099
seattlefyi (2020-11-14 06:38:37+00:00): Hi, thanks for adding the restaurant details! Looks like the address number was inadvertently changed, but I put it back. Hope you’re enjoying mapping! Thanks again.
forteller (2020-11-14 00:31:19+00:00): Forgot to mention: I also removed Y-blokka. I was there today, it's been completely demolished.
zuicz (2020-11-14 14:42:09+00:00): Na jakiej podstawie ty to dodajesz? W sensie od kiedy według ciebie oznaczamy jako w budowie? Bo to raczej błędne mapowanie.
zuicz (2020-11-14 14:50:00+00:00): Bo wg wiki Najważniejsze plany budowy dróg i kolei zwykle trwają kilka lat. Używamy tego tagu, aby wskazać aktywne miejsca budowy (w przypadku planowanych projektów, w których jest niewiele lub nie ma dla nich dowodów w terenie. Unikaj więc ich oznaczania lub użyjmy zamiast tego tag proposed=*).
Jeżeli cokolwiek zaczęto już robić to powinno być construction. Na przykład na trasie tramwaju w Sosnowcu zdarto już humus, z tego powodu cała trasa jest już oznaczona jako w budowie - https://www.openstreetmap.org/way/275127607
maraf24 (2020-11-14 15:40:45+00:00): Idziesz w teren i jeśli widzisz jakieś roboty to dajesz w construction. A jeśli są lasy, łąki, domy to nie jest to budowa i dajesz proposed.
Fragment wiki, który zacytowałeś, mówi dokładnie to samo.
Moje mapowanie tutaj jest zrobione wg tych zasad.
zuicz (2020-11-14 17:00:25+00:00): Ok, bo myślałem, że robisz to na jakiejś dziwnej zasadzie tak jak wiadukt TAT (uznałeś że wiadukt co prawda jest w budowie ale tory na nim jeszcze nie, także nie można dać railway=construction xD)
maraf24 (2020-11-14 18:07:46+00:00): Tory nie mogły być w budowie, skoro dopiero budowano przyczółki wiaduktu :) Zwykle taki drobiazgowy nie jestem, ale wtedy akurat byłem na tej budowie i zapadło mi to w pamięć.
mueschel (2020-11-17 08:48:48+00:00): Hi,
please check the tagging of this way. The 'dirt' and 'private road' tags don't exist anywhere else.
https://www.openstreetmap.org/way/871513765

I guess you look for 'operator' and 'surface'.
DP24PH (2020-11-14 01:38:44+00:00): ERRATUM for source:
"...;Maxar;Davao City Ordinance 2010-0409;"
ScottWalkerAU (2020-11-14 02:08:43+00:00): You have lots of different overlapping multipolygons here. I see you've tried over 20 times to fix it, might pay to remove the one-member relations and start fresh
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/94092199
osmowm87 (2020-12-04 03:42:07+00:00): Yes, I think I will. I just cannot get the interiors to show!
Mashin (2020-11-14 14:40:20+00:00): Hi estepme,
there are several issues with your edits:

1) All the building (and other features) outlines are inaccurate. If You switch satellite imagery to 'ESRI world imagery clarity', you will be able to draw more precise shapes. You can also use squaring function to make them all angles 90˚

2) You created additional points with names for each building. Information from the points should go directly on the area and points should be removed.

3) You are misusing `landuse=commercial' and 'leisure=park' for features that have their own set of tags e.g. leisure=pitch for sport.

4) You put `intermittent=yes` on Mount Tom Pond, which would indicate that it is seasonally dry. That seem very unlikely.
erickdeoliveiraleal (2020-11-14 12:25:20+00:00): good morning @bymoxb thanks for map the note I created. Only a tip: dont draw like this: https://www.openstreetmap.org/way/871519134 because when someone wants to put the name into the road it will need to cut on the corner with the other street, it's better to already map cutting when meets other streets
bymoxb (2020-11-21 02:50:09+00:00): Thanks for the advice I will take it into account from now on and correct my changes
Jochen Topf (2020-11-17 08:26:44+00:00): This change breaks the whole world map! The Chesapeake Bay is a bay but it is still part of the sea, not an inland water area. The bay is clearly tidal, clearly part of the sea, so the natural=coastline tags have to go around it. On many maps this huge area will now not be visible as water any more, because many maps don't render inland water until larger zoom levels. This change is also blocking updates to *all* coastlines around the world, because the automatical coastline tool has noticed this huge change in the world map. See
https://osmdata.openstreetmap.de/internal/coastline/
ElliottPlack (2020-11-17 14:17:38+00:00): Jochen, that sounds like an issue with the apps that consume OSM, not the data itself. There are other, larger inland water bodies that are tagged this way, like Lake Michigan, which is 3x as big as the bay. https://www.openstreetmap.org/relation/1205149

I had removed much of the Chesapeake Bay's tributaries about 4 years ago and no one has said anything yet.

I have read that apps like MS Flight Sim don't recognize water relations, but that'd be tagging for the renderer... The coastline is correct, it follows the bathymetry of the Bay.
Jochen Topf (2020-11-17 14:38:49+00:00): Lake Michigan is an actual lake, not part of the sea, so it doesn't apply here.

You can not just change what a tag is supposed to mean that has been around for years. Such changes break OSM. You just have to look at a map like the cycle map: https://www.openstreetmap.org/#map=4/43.13/-94.83&layers=C It doesn't show the great lakes in small zoom levels and it will not show Chesapeake Bay in the future any more of this change stands.

I am not sure what you mean with "follows the bathymetry of the Bay". The wiki defines the coastline as "The natural=coastline tag is used to mark the mean high water springs line along the coastline at the edge of the sea." By that definition your coastline is way off.
Sparks (2020-11-17 14:43:37+00:00): The Chesapeake Bay is not part of "the sea", it is a defined area of water that is specifically delineated from an ocean.  If it is not rendered appropriately, then the renderer should be fixed.  Under your definition, because it is tidal, many rivers should be considered seas which isn't correct.
woodpeck (2020-11-17 15:35:57+00:00): Who are the people who have decided on this "collaborative project" - is it just the two of you, or does this have the support of the US community? Has it been discussed anywhere that has a publicly accessible archive (i.e. specifically *not* Slack)?
ElliottPlack (2020-11-17 16:33:12+00:00): Some of these discussions have taken place on changesets, but mostly in the OSMUS Slack, which I thought was a fine place to have such conversations.

The reason we considered this is because new users kept breaking the coastline by drawing it on arbitrary lines or one ways already covered by water. Some of these users claimed to be coming at it from the MS Flight Simulator use case, but I wonder how it works if they fly over the great lakes in that app. We thought that by simplifying the coastline out where the salt/fresh transfer occurs, we'd prevent these kinds of edits.

Here's one of those changesets. https://www.openstreetmap.org/changeset/93828561 The user never responded so I went ahead and rolled it back, then started doing it the proper way, setting up water areas for all the named sections of bay.
Sparks (2020-11-17 16:44:35+00:00): Back to the point of the matter, the Chesapeake Bay is an inland waterway and not a sea like an ocean, the Gulf of Mexico, or the Caribbean Sea.  It is vastly smaller and surrounded by land.
Jochen Topf (2020-11-17 16:56:55+00:00): Sorry, Sparks, but it doesn't matter for OSM what something "is". All that matters is that we agree on tagging, so that everybody can use the data consistently. And the agreed definition on where natural=coastline is tagged is in the wiki and has been used for a long time. You can not change this without breaking a whole lot of usage of the data. You are free to invent new tags that mean a different thing, but you can not change existing definitions. (Well, you could, but in something like this it would take quite a lot of community discussion and a worldwide consensus which would be very hard to reach.)
Sparks (2020-11-17 16:59:07+00:00): I'm not changing the definition of anything.  I'm defining the "thing" that I am mapping.
Minh Nguyen (2020-11-17 19:41:09+00:00): Is it possible to have it both ways? I realize it isn’t an exactly analogous situation, but San Francisco Bay appears to be mapped as both a bay and as a series of coastlines, and it seems to have been that way for a long time without breaking renderers and other data consumers:

https://www.openstreetmap.org/relation/9451753
https://www.openstreetmap.org/way/157480226

Nothing about the coastlines explicitly claims that the San Francisco Bay is part of the Pacific Ocean, so the only semantic challenge might be some redundancy between the bay and its coastlines. But that could be resolved by making the coastline ways part of the bay relation.

In the case of the Chesapeake Bay, that would just be a matter of adding the coastline tags back to the ways surrounding the bay, but otherwise retaining the (useful!) bay relation.
ElliottPlack (2020-11-17 19:54:47+00:00): I like the idea of having it both ways. That way we could still have this relation and the level of detail around all of the water ways (instead of natural=bay points). Jochen, can you check to see how SF Bay looks on the renderer/data app you are using? I think we can reach an amicable solution for everyone here.
Sparks (2020-11-17 20:50:13+00:00): Looking at an application that uses OSM data, the SF Bay is identified as North Pacific Ocean because it is improperly mapped using coastline and only, what I suspect, has a node dropped in the middle of the area, saying that it is the Bay.  That's the problem with mapping these inland waters like this.  Using "coastline" and then dropping a label in the middle is great if you're making a paper map but if you're using software to actually use the data you actually have to identify the what those areas are and the SF Bay is no more the Pacific Ocean than the Chesapeake Bay is the Atlantic.
Minh Nguyen (2020-11-17 20:52:15+00:00): Which application did you check? The San Francisco Bay Area relation at https://www.openstreetmap.org/relation/9451753 includes all the coastline ways as members, so it forms a polygon. If the application represents it as a point, it’s probably calculating the centroid automatically.
Sparks (2020-11-17 20:55:26+00:00): Ahh, I see the relation, now.  However, the use of coastline is still bringing in the ocean as that is what coastline is for, IMO.

I'm looking at YAAC which has the side effect of pulling way identifiers from OSM data and displaying them to the user.
Minh Nguyen (2020-11-17 20:55:49+00:00): (Correction: the San Francisco Bay relation, 9451753, includes ways redundant to the coastline ways, but not the coastline ways themselves. I’m unsure about the history behind that approach, but it does seem to result in a correct representation of the bay.)
ElliottPlack (2020-11-17 22:10:28+00:00): Do the named ways of the relation affect how those apps display the info? See how this coastline has a name? (It was like that before I edited it yesterday) https://www.openstreetmap.org/way/591823494#map=14/37.8278/-75.4774
Minh Nguyen (2020-11-17 22:15:45+00:00): The coastline ways shouldn’t be named. The name on way 591823494 seems to be an error left over from when https://www.openstreetmap.org/changeset/57065106 introduced https://www.openstreetmap.org/relation/8099409 .
Jochen Topf (2020-11-18 09:35:02+00:00): I personally don't have an opinion on any tagging here except that natural=coastline should be where it used to be. If you want other tagging for naming the Bay that's fine with me.
imagico (2020-11-18 13:28:01+00:00): For reference:  Previous discussion on the matter can be found on

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

https://lists.openstreetmap.org/pipermail/talk-us/2016-January/thread.html#15819

For several years now this region has required special processing for anyone who wants to derive a consistent coastline data set from OSM data - for map rendering or other purposes.  In fact the whole US east coast  is now globally by far the area that deviates most from the global consensus regarding coastline placement (as measured by the number of cases where it deviates from that, not by surface area of course, here the Rio de la Plata has the undisputed lead).

The discussion here seems to lead towards a reiteration of the discussion regarding the Rio de la Plata we had a few months ago on tagging.  I would therefore like to point to the question i had asked back then already:

https://lists.openstreetmap.org/pipermail/tagging/2020-August/054519.html

Side note:

These riverbank polygons:

https://www.openstreetmap.org/relation/1357743
https://www.openstreetmap.org/relation/6840775
https://www.openstreetmap.org/relation/177638
https://www.openstreetmap.org/relation/1344442
https://www.openstreetmap.org/relation/6840775

are mapped incorrectly because

(a) the name of a river by broad consensus goes to the waterway line (waterway=river), not to the riverbank polygons.

(b) some of these don't even have a waterway line mapped - which by consensus is mandatory for a river.
ElliottPlack (2020-11-19 04:24:07+00:00): To all that are following this changeset, I wanted to point out that there is now an ongoing discussion in the tagging mailing list. 

https://lists.openstreetmap.org/pipermail/tagging/2020-November/056310.html

I am reviewing that, and the comments here--I haven't forgotten about this.
Jochen Topf (2020-11-21 10:38:35+00:00): The way the natural=coastline tags have been understood for the last >10 years clearly say that the coastlines tags should go around the bay. Some of the details of the discussion on the tagging mailing list do not matter for the situation here. Are you going to revert this now?
Sparks (2020-11-21 15:49:24+00:00): No.  I disagree with your interpretation of coastline and can only say that it's time to fix this interpretation that you've been propagating for the last ten years.  Legally, scientifically, and locally, the Bay is neither ocean nor sea.  There are better ways of tagging this and that's what we've done.  So, instead of armcharing this from many thousands of km away, how about you let us that actually live here define what's here.
Jochen Topf (2020-11-21 16:06:38+00:00): You are breaking >10 years worth of software, style sheets, maps, etc. Everybody who has dependet on this definition. This is not something you can change.
woodpeck (2020-11-21 16:23:04+00:00): ElliotPlack, regarding the question of Slack: Slack is a private communications medium with no public archive that can be viewed by other members of the community who are not signed up to Slack. Of course mappers may use any form of private communication but if the result is a grand plan like this, it is worth at least outlining it in a form that is accessible and archived even for those who are not signed up to Slack, ideally on the talk-us mailing list.
muralito (2020-11-21 16:31:08+00:00): There are users who use the coastline for rendering (although they do not have the nobility to recognize it) and they care less that the data is used to determine what is ocean and what is not, as shown by the various examples of the coastline mapped tens of kilometers within England or Germany.

They are just tagging the coastline for the renderer!!! JUST FIX THE RENDERER!!! The OSM is data, not a renderer image for the web. Render is one of the uses of the data, but it is not the only only one, nor the most important, but they fails to understand that, and they continue to insist on moving the coastline, as they did with the Rio de la Plata and it is currently very poorly mapped.

The question about what is ocean and what is not is a basic question that OSM data cannot answer with the natural=coastline that some people insist.

I suffered the same fact with the armchair mapping in Rio de la Plata, seems that the local mapper knowledge is less valuable than the opinion of these people. This is a fact right now. The problem has more than one year now.

I'm still waiting since July to see the DWG position on this issue.
muralito (2020-11-21 16:33:41+00:00): The coastline sould be mapped where it should , not where it use to be, if the software is broken fix the software, but the data sould be right.
Frans S (2020-11-27 12:04:42+00:00): hello. Thanks for mapping here
Please do not map clusters of buildings as 1building.  
Best regards
Frans S (2020-12-08 15:07:46+00:00): Hello. Thanks for mapping here
A small remark. When buildings are partly hidden by trees, please map the (hidden) rooflines rather than the treelines.
Best regards
Frans S (2020-12-08 15:10:33+00:00): Hello again. Please do not buildings which are close together as 1 building.
Each building needs to be mapped individually
Best regards
Frans S (2020-12-02 13:45:46+00:00): Hello. Thanks for mapping here.
A remark. Pleas map buildings individually. Do not cluster buildings and call it 1 building
Best regards
topolusitania (2020-11-14 23:57:18+00:00): O nome Parque Gonçalo Ribeiro Telles já é oficial ? Creio que é apenas uma proposta para o jardim que vai ser criado na zona se chamar "Jardim Gonçalo Ribeiro Telles"
DiogoBaptista98 (2020-11-15 01:59:10+00:00): A CML lançou um comunicado onde este nome vai ser alterado para o que coloquei. Parque Gonçalo Ribeiro Telles
daniel_solow (2020-11-17 14:39:47+00:00): Hello please revisit this changeset. The footpath is drawn straight through a residential area and does not follow satellite imagery. Please correct the geometry
Frans S (2020-12-01 10:11:25+00:00): Hello. Thanks for mapping here 
a few remarks about your mappings.
You hardly square buildings with the Q key and map clusters of buildings and call it 1 building.
See also my PM to you