piebro/osm-data huggingface dataset:
dodado (2021-05-14 09:17:21+00:00): Hier haben sich unsere Kommentare wohl überschnitten: Das Verwaltungsgebäude habe ich schon als solches eingetragen. Damit ist DHL nun auf der Standardkartenebene zu sehen: https://www.openstreetmap.org/#map=18/51.46589/7.26233
Auch über die Suche wird es nun gefunden. Den Namen habe ich noch mal angepasst, denn ich habe gesehen, dass auch die Post da mit drin ist.

Das Hauptgebäude mit den Tags amenity=post_depot und name=* zu versehen, halte ich aber dennoch für nicht richtig. Zu dem Depot gehören eben auch die Rangier- und Abstellflächen für Fahrzeuge etc. Das auf das Gebäude zu reduzieren, verschlechtert in meinen Augen die Daten. Außerdem würde es die Entscheidung des Teams von openstreetmap-carto untergraben, Postdepots nicht standardmäßig darzustellen.
Nur weil woanders diese Entscheidung untergraben und Tagging für den Renderer betrieben wird, müssen wir das ja nicht gleich nachmachen.

Es gibt übrigen Kartenstile, die amenity=post_depot zeigen: https://www.qwant.com/maps/#map=15.60/51.4659257/7.2664870
Skyhead (2021-05-16 15:17:58+00:00): Ich sehe es als Ziel des Mappings an, dass die Nutzer von OSM möglichst gute, genaue und informative Karten zur Verfügung gestellt bekommen.
Und dazu gehört auch, dass bei Gewerbegebieten aus den Karten hervorgeht, um welches Unternehmen es sich hier handelt.
Insofern sehe ich das Mapping des Verteilzentrums aus Nutzersicht nicht als ausreichend an.
Ich kann nicht verstehen, wenn irgend jemand meint, Paket-Verteilzentren wären Geheiminformationen, die man nicht auf der Karte darsstellen sollte. Die Firma steht groß am Gebäude, warum soll man sie also nicht aus den OSM-Karten sehn ?

Statt das gesamte Firmengelände mit amenity=post_depot zu mappen, sehe ich es als bedeutend besser an, nur den Bereich, in dem auch wirklich die Verteilung der Pakete erfolgt, entsprechend zu mappen und andere Bereiche, die damit nur am Rande zu tun haben, wie Firmenparkplätze, Grünflächen, Zufahrtsstraßen dort nicht mit herein zu nehmen.
Insbesondere wenn DHL noch andere Funktionen auf dem Gelände unterbringt, wie Verwaltung, Schulungszentren andere Dienste, stößt man mit dem Gesamt-Mapping für eine Funktion das gesamte Firmengelände schnell an Grenzen. 
Ich halte es für sinnvoller das Firmengelände mit landuse=industrial zu mappen und nur die Gebäudeteile, in denen die Verteilung der Pakete erfolgt, mit amenity=post_depot.
Im Übrigen sind ja schon jetzt 2 Funktionen auf dem Gelände zu finden: amenity=post_depot und office=logistics, was in meinen Augen für eine allgemeinere Darstellung des Gesamt-Firmengeländes sprechen würde.
Hierüber ließe sich auch das Namensproblem lösen.
dodado (2021-05-21 11:36:57+00:00): Ich möchte gar nicht behaupten, die Standorte von Verteilzentren seien „Geheiminformationen“. Der Firmenname wird ja sogar auf der Karte dargestellt, nämlich dort, wo die Büros sind.
Und auch ich möchte Nutzer*innen eine Möglichst gute und informative Datenbank und auch eine gute Karte zur Verfügung stellen. Allerdings zeichnet sich eine gute Karte nicht unbedingt dadurch aus, dass alles nur erdenkliche darauf abgebildet ist. Vielmehr sollte die Karte übersichtlich sein und alles wichtige zeigen, während unwichtiges kleiner oder gar nicht dargestellt wird. Ob ein Paketzentrum nun wichtig genug ist, in einem bestimmten Kartenstil dargestellt zu werden, ist nicht unsere Entscheidung. Das kann jede*r, der/die eine Karte aus den Daten erstellt, selbst entscheiden. Das Team von qwant maps hat sich entschieden, Paketzentren darzustellen. Das Team der  openstreetmap-carto-Standardkarte hat sich dagegen entschieden. Wenn du die Entscheidung nicht richtig findest, kannst du auf https://github.com/gravitystorm/openstreetmap-carto anregen, Verteilzentren doch darzustellen.

Ich stehe auch weiter zu der Entscheidung, das gesamte Gelände als amenity=post_depot zu taggen. Durch das Anfahren der entsprechenden Ladeluken durch die LKW findet ja auch gewissermaßen ein Teil der Sortierung statt. Besonders auch die Abfertigung der ankommenden LKW direkt rechts hinter der Einfahrt ist für mich eindeutig teil des Verteilzentrums, auch wenn sie unter freiem Himmel stattfindet.
Und dass sich die Verwaltung auf demselben Gelände befindet, sehe ich nicht als Problem. Ich kann mir vorstellen, wenn du eine*n Mitarbeiter*in fragst, wo die Postverwaltung liegt, wird die Antwort so etwas wie „An der Grete-Schickedanz-Straße, im Paketzentrum hinter dem Parkplatz links“ oder so ähnlich sein. Was ich damit sagen möchte, ist, dass dieses Mapping der Wahrnehmung entspricht, dass sich die kleine Verwaltung im großen Paketzentrum befindet.

Wollte man diese Verschahtelung der Einrichtungen umgehen, würde es auch nicht reichen, amenity=post_depot an das Gebäude zu taggen, da sich die Verwaltung ja in demselben Gebäude und damit immer noch innerhalb liegt. Um keine Verschachtelung mehr zu haben, müsste man so weit gehen, ausschließlich den U-förmigen Gebäudeteil als amenity=post_depot zu taggen. Dann wären aber auch die südlichen Gebädeteile außen vor. Und angezeigt würde der Name auch nicht, da openstreetmap-carto nur die Namen von building=*, aber nicht die Namen von building:part=* darstellt.

Ich schlage vor, hier alles so zu lassen wie es ist, und stattdessen auf https://github.com/gravitystorm/openstreetmap-carto zu diskutieren, ob Paketzentren zukünftig in der Standardkarte angezeigt werden sollen.
Skyhead (2021-05-24 17:07:36+00:00): Hallo,
So wie das Gebiet des Verteilzentrums zur Zeit gemappt ist, ist auf den OSM-Karten keinerlei Information über die Nutzung dieses Gebiets zu finden, und dass ist ein schweres Manko. 
Ich nehme an, das der übergroße Teil der OSM-User die von OSM erzeugten Karten nutzt. Und wenn hier Informationen über die Nutzung eines Gewerbegenbietes nicht zu finden sind, dann ist das Mapping nicht User-gerecht und sollte geändert werden.

Du führst an, dass in den Karten von Suchmaschinen wie Qwant (oder auch Google?) die Informationen über die Nutzung des Geländes zu finden sind. Reicht Dir dass, das Suchmaschinen wie Qwant, Google, Bing die Nutzung des Geländes auf ihren Karten darstellen, OSM aber nicht? Soll das heißen, die Nutzer sollen doch lieber Google Maps oder Qwant Maps oder was auch immer benutzen, wenn sie wissen wollen, wozu dieses Gelände dient, aber bloß nicht OSM?
Ich sehe dies eher als Anreitz für OSM, wenn Suchmaschinen, wie Qwant, Google usw die Nutzung des Geländes darstellen, dann sollte OSM dies auch auf seine Karten tun. Ich denke, OSM hat den Anspruch Karten zu produzieren, die zumindest gleich gut, wenn nicht besser sind, als die Karten von irgendwelchen Suchmaschinen wie Google oder Qwant.

Wenn eine Information zu einem Gelände von mehrere 1000 Quatratmetern hinzugefügt wird, dann ist das kein unübersichtliches Mapping. Schau Dir die Mapping-Dichte in Fußgängerzonen an. Die ist sehr hoch, aber nicht unübersichtlich. Oder möchtest Du deswegen auch alles Mögliche aus den Fußgängerzonen löschen?

Außerdem. den angeblichen Beschluss, dass Paketzentren nicht dargestellt werden sollen, habe ich nirgendwo gefunden, nicht im Wiki, no sonstwo. Gibt es ihn wirklich ?

Die Vorgehensweise, das gesamte Firmengelände mit allen Grünflächen, Parkplätzen und was auch immer als amenity=post_depot zu mappen, halte ich für falsch, denn außerhalb des Gebäudes wird weder Post sortiert noch gelagert. Selbst die Verkehrsflächen haben damit so gut wie nichts zu tun, denn die Fahrer bekommen lediglich gesagt, an welchen Tor sie ihre Ladung abholen sollen. Die Fahrer fahren dann halt irgendwie dahin. Das hat aber nichts mit dem Sortieren und Lagern zu tun.
Außerdem halte ich die Zuordnung der Gebäudefunktion zu den Verkehrsflächen für falsch, da sie im Gegensatz zu vielen anderen Mappings steht. Zum Beispiel bei anderen Logistik-Unternehmen kommt auch niemand auf die Idee, die Verkehrswege als Lagerhalle zu mappen. 
Oder bei Supermärkten wird auch nur die eigentliche Verkaufsfläche als shop=supermarket gemappt, aber nicht die Parkplätze darum herum.

Außerdem, Du hast selber ein gutes Beispiel gebracht, wenn Du jemanden fagst, wo denn in Bochum Laer das Paketverteilzentrum von DHL liegt, und der guckt auf die OSM Karte und sagt: Gibt es hier nicht, auf der Karte ist nichts eingetragen, das muss woanders sein. Wäre Dir das nicht auch peinlich?

Im Übrigen, es gibt nie nur eine Mapping-Variante, es gibt immer mehrere, die korrekt sind. Und da sollte man die, die wählen, den größten Nutzen für die User der Karte darstellt.

Viele Grüße Skyhead
dodado (2021-06-14 13:12:21+00:00): gelöst in https://www.openstreetmap.org/changeset/106263072#map=15/51.4655/7.2690
eggie (2021-03-02 07:23:07+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privébericht. 
Feedback access=private hoort op de wegdelen niet op de wegpunten(nodes)
MVG, 

Eggie 
namens de OSM Community
eggie (2021-03-02 09:46:06+00:00): access=private naar wegdeel verplaatst
mvg
eggie
JWMeijerink (2021-03-02 20:59:31+00:00): Dank je eggie voor de toelichting! Dit was mn eerste wijziging, hopelijk zullen er nog velen volgen.
iandees (2021-03-01 22:27:12+00:00): Thanks for your contribution to the map! It looks like the city calls the park "Whissel Park" on their website. Do you think they misspelled it there?
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/100232521
Andrew Kvalheim (2021-03-02 01:09:56+00:00): Hi, I've edited the driveway a little to match how they're usually mapped.
Glassman (2021-03-02 21:04:29+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/100232808
tastrax (2021-03-12 07:08:25+00:00): Hi folks FYI - Phone numbers in Australia should be added to OSM according to the following format +61 x xxxx xxxx, (+61 xxx xxx xxx for mobiles) or use the phone:AU key if a 1300 or 1800 number as per the wiki guidelines https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines - I have just updated a recent addition that you made to OSM – Cheers
JoeG (2021-03-05 22:32:24+00:00): Just want to say I am annoyed by this change and don't endorse it.
waterway=riverbank was being actively discussed on the tagging list, and pushing through the so-called "river modernization" does not reflect a consensus view.
I'm not going to do anything about this, but I thought I'd let you know I'm unhappy.
tastrax (2021-03-05 23:09:57+00:00): I am more than happy for you to revert the changes. Its unfortunate that multiple tagging approaches exist as I think its hard for both mappers and data consumers. I felt it was a good project and didnt receive any adverse feedback on the au mailing list or slack channels. Unfortunately I find the the tagging list a bit aggressive so I no longer subscribe to it.
Tilia_J (2021-03-01 22:25:31+00:00): Verdere edits volgen.

Zie changesets voor notes:

https://www.openstreetmap.org/changeset/100155996
https://www.openstreetmap.org/changeset/100113184
Glassman (2021-03-02 21:09:14+00:00): Thank you for your edit. I reviewed your work and it looks good. I'm not sure this will fix your delivery problems. While Amazon Logistics uses OSM basemaps the drivers seem to ignore what's mapped. It's also difficult to stop on Greenlake Drive and your driveway looks small to turn one of their trucks around, especially UPS trucks. Good luck. And thanks for contributing to OSM. I'll send you more info on OSM in a message.
            ---
            #REVIEWED_GOOD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/100233240
eterle (2021-05-13 08:18:19+00:00): What is your reference for the location of Tuilerie de Bursins? There are indeed constructions from the same period where you located it, but the actual construction with the kilns is on the East side of Chemin de La Tuilière, just beyond the administrative boundary. The photos in the wikipedia page are of the buildings that you tagged. However, they are correctly labeled as "buildings nearby", and not the actual Tile factory with the Hoffman kilns.
Note_Fixer (2021-03-01 22:47:35+00:00): Note 1913302
MikeN (2021-03-02 00:00:46+00:00): Hi, Great work in Greenwood!   These buildings with inner courtyards are the trickiest parts to get right.  There's still a technical problem in that the outer parts of the multipolygons share ways, which is not allowed - therefore might not render correctly or at all.   I don't know the easy way to get it back in ID from where it is, but starting over, I see First Presbyterian as one outer way and 3 inner ways.   If you draw all 3 that way, then select the "Merge" function from the right click menu, it should create a good multipolygon.
cbhackmeyer (2021-03-02 06:34:40+00:00): Thanks for the feedback and the iD "Merge" tip; I didn't know it would make multipolygon relations for you like that. I understand what you're saying, and looking at OSMI I can see these are flagged as errors. I can't find anything in the wiki that actually says shared segments of outer *closed* ways make a multipolygon invalid; maybe I'll try and add such an example to the wiki if that's the case. And the geometry is actually rendering just fine in OsmAnd, though it looks more like a mixed bag in Mapnik. I mapped them this way largely because I wanted to indicate some parts are enclosed buildings, while others appear to be just roofs over covered walkways. But I guess building:part=roof is the standard way of doing that. So I'll try and get around to remapping those churches that way in the next few days. Thanks again for your help!
cbhackmeyer (2021-03-04 06:34:51+00:00): I believe this issue has now been resolved by changeset 100393750. Thanks again for the feedback!
habi (2021-03-02 07:50:37+00:00): Hallo Perspolistextiländerung
Willkommen bei OpenStreetMap.
So wie du https://www.openstreetmap.org/node/8477368378 eingetragen hast, ist die Textiländerung nicht zu finden.
Du müsstest den Tag `craft=tailor' (so wie in https://wiki.openstreetmap.org/wiki/DE:Tag:craft%3Dtailor angegeben) hinzufügen, der Namen alleine hilft wenig :)
Es ist auch möglich, die Telefonnummer und die Webseite der Textiländerung hinzuzufügen.
E Gruess us Bern,
habi
Note_Fixer (2021-03-01 23:11:42+00:00): Note 580845
Note_Fixer (2021-03-01 23:20:28+00:00): Note 1828116
alexey_zakharenkov (2021-03-03 21:24:46+00:00): Добрый день.
А что, здание кинотеатра снесли?
Note_Fixer (2021-03-01 23:27:40+00:00): Note 2347263
CoyKoi (2021-03-02 00:31:23+00:00): Note that amenity=research_institute is currently unrendered, but is actively being considered for rendering: https://github.com/gravitystorm/openstreetmap-carto/issues/2077
Note_Fixer (2021-03-01 23:49:34+00:00): Note 1323427
Note_Fixer (2021-03-01 23:57:43+00:00): Note 2457718
ChehrehBargi (2024-02-16 05:05:09+00:00): ضمن تشکر از زحمات شما
جایگاه سوخت با استفاده از مولتی پولیگن رسم شد.
سه محل مجزا برای یک جایگاه رسم شده بود که همگی ادغام شدند.
Note_Fixer (2021-03-02 00:16:31+00:00): Note 2415956
Note_Fixer (2021-03-02 00:24:19+00:00): Note 2271881
eggie (2021-03-02 07:43:37+00:00): Dag janwillem... Beter niet foot = no gaan taggen op reguliere wegen. Soms worden de trottoirs weggehaald omdat het niet gebruikelijk is om die te taggen. Vaak worden ze opgenomen in de hoofdrijbaan met sidewalk=both  left of righr  .. zelfs none.
Nu is ook de wandelroute onderbroken, want van zuid naar noord en visa versa loop knooppuntroute 64-67
Die werkt nu niet meer.
MVG
eggie
eggie (2021-03-02 07:45:43+00:00): Hier zie je de wandelroutes lopen. 
https://hiking.waymarkedtrails.org/#?map=17!53.174!6.9719
eggie (2021-03-02 08:03:02+00:00): reverted by #100258261

Beter geen foot=no op reguliere wegen zetten behalve bij dat ronde witte bord met rode rand en de voetganger in het midden. Dan ook steeds weer checken of er geen routerelatie loopt. 
MVG
eggie
janwillem99 (2021-03-02 11:06:50+00:00): Sorry ik had de route over het hoofd gezien
eggie (2021-03-02 11:10:46+00:00): Het is al weer correct nu..  Er zit nog een hele wereld verborgen in OSM en dat kun je als starter niet weten.

Mvg
Eggie
Note_Fixer (2021-03-02 00:33:18+00:00): Note 2401810
Enderbyte99 (2021-03-04 22:56:35+00:00): To think that I misspelled "some"...
woodpeck_repair (2021-03-29 19:16:10+00:00): This changeset has been reverted fully or in part by changeset 101936141 where the changeset comment is: revert an undiscussed import of milestone markers
nickvet419 (2024-05-01 19:42:54+00:00): noticed a lot of the indoor mapping of pathways that should have been changed to indoor corridors were removed in changeset 142163645, I restored most of them but still missing the main level.
ivanbranco (2021-03-06 13:22:24+00:00): Hi kubahahaha,

what's the meaning of the 
Michale=Szkoła tag?
gscholz (2021-03-06 10:02:53+00:00): Hi rimugu,
your recent changeset have added several errors to the OSM database regarding not connected ways:

http://tools.geofabrik.de/osmi/?view=routing&lon=-106.63417&lat=29.12077&zoom=8&overlays=duplicated_edges,duplicated_edges,duplicated_edges_areas,snap_points,unconnected_open_ends_1,unconnected_open_ends_5,unconnected_open_ends_6

As you problably know, unconnected ways can not be used by routing software. Can you please fix this and, as this seems to be a systematical error, think about how to avoid this in the future?
Kind regards
Guido
adhy SEA (2021-03-02 02:41:32+00:00): thank you, and allow me to update the real data in the field
ScottWalkerAU (2021-03-02 03:29:32+00:00): Hi - Instead of `note=FIXME` you can use the `fixme` tag
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/100238559
neomanic (2021-03-03 06:04:41+00:00): It was a left-over from the original mapper that I didn't notice. Have removed it, added the streams around there and I will verify on the ground next time I run past.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/100238559
mueschel (2021-03-08 15:08:57+00:00): Hi,
please check this building, it got 3 housenumbers:
https://www.openstreetmap.org/way/911025639
skquinn (2021-03-02 03:20:43+00:00): Source should include Bing imagery
VLD159 (2021-05-19 18:20:01+00:00): Thank you for all of your contributions to OSM. Based on the imagery source that you used, Bing aerial imagery, the pitch feature that you edited (Way 817985814) doesn’t exist in imagery. Do you happen to have local knowledge for this area? 

Hope to hear from you soon,
Anthony
martin-kokos (2022-02-01 09:59:35+00:00): Hi. You've tagged a marked crosswalk here. I am not sure crosswalks painted in roads are common in the middle of the woods. In fact, the road looks like a water stream.
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/100240947
user_5359 (2021-03-02 05:17:08+00:00): Hello! Please add useful change set comments (and no "Changing data" isn't) . You add the key sports (correct key is sport) and area=no (which is wrong from my point of view) to the relation https://www.osm.org/relation/3272367.
Surveyor2503 (2021-03-02 06:04:01+00:00): Hi Supt, I noticed you made some changes on the pakenham east train depot. I'm just curious as to what changes you made, as I redid the depot a few months ago. 

I'm just asking as I want to know if there were mistakes that you noticed, so that I know not to do them next time 
Thanks :)
Supt_of_Printing (2021-03-02 07:09:48+00:00): Hi Surveyor, I did the original trackage in the depot and I noticed that names had been added to the various roads and some of the curves and turnouts had been made a bit clunky, so I smoothed out some of the curves and turnouts, particularly the loop road. I also added the drain that goes through the depot from north to south.
Warin61 (2021-03-05 09:23:19+00:00): No need to have a relation for a simple way. 
The parking area by it self would have no name, the name "Woodgrove Shopping Center" would be on the entire shopping center.
Dimacn (2021-03-02 10:02:48+00:00): В тег name вписываются только собственно названия или официальные названия. Характеристики объекта - это не названия. Свойства объектов задаются специальными тегами. Пожалуйста удалите текст из name.
Berlin53 (2021-09-03 13:41:29+00:00): ich habe bei cycleway:both=no bicycle=yes wieder eingetragen (wird sonst wie bicycle=no interpretiert)
StefanHRT (2021-09-03 14:21:05+00:00): Hallo Berlin53, Bei welchem System wird dies als bicycle=no definiert? Komoot (nutze ich täglich) und Strava sind es zumindest nicht ;) cycleway:* sagt ja nur aus,dass kein Radweg vorhanden ist, sonst gilt der Standardaccess der Straße. VG
Berlin53 (2021-09-03 16:54:06+00:00): Habe mich ja auch gewundert, da das nirgendwo so dokumentiert ist. Aber nach deiner Änderung hat OsmAnd nicht mehr über die Blockdammbrücke navigiert. In iD kann man ja auch die Navigation mit OSRM und GraphHopper simulieren. Das gleiche, eigendlich unlogische Ergebnis. Jetzt funktionieren alle drei Navisysteme wieder wie gewünscht. Sollte also besser so bleiben. Zumindest bei OsmAnd könnte ich einen Call aufmachen.
StefanHRT (2021-09-03 17:20:41+00:00): Ich habe mal geschaut, die Änderung mit dem cycleway wurde durch BER319 mit der App StreetComplete schon vor über 9 Monaten gemacht, Die Ursache muss eine andere sein (ich wurde in der Zeit schon oft darüber geroutet), ich hatte vor ca 6 Monaten nur Traffic_Signs ergänzt *grübel*
StefanHRT (2021-09-03 17:49:35+00:00): Habe glaube den Fehler gefunden. Der Weg https://www.openstreetmap.org/way/4782475 hat vehicle=no und ein Fahrrad ist ja rechtlich ein Fahrzeug, das Traffic_Sign beinhaltet zwar die Radfreigabe, dies wird aber nicht ausgewertet.
Berlin53 (2021-09-04 16:36:12+00:00): Das könnte es gewesen sein. In dem Fall hat das bicycle=yes die bestehende Einschränkung an dieser Stelle überschrieben und die Navigation mit OsmAnd und anderen Navisystemen funktiniert wieder. Ich werde mal als Test einige der von mir vorgenommenen Änderungen rückgängig machen. Im Erfolgsfall folgen dan die anderen auch noch.
StefanHRT (2021-09-04 16:45:30+00:00): Danke. Da u.a. durch StreetComplete schon etliche Straßen in Berlin das cycleway:both=no haben, kannst Du auch so bereits testen (z.B. ist um die Dörpfeldstraße oder ein Großteil von Marzahn damit versehen und Navigation funktioniert einwandfrei;) )
Berlin53 (2021-09-05 09:25:43+00:00): Danke für deine Mithilfe. Habe die Änderung bis auf den way https://www.openstreetmap.org/way/4782475 wieder rückgängig gemacht.
StefanHRT (2021-09-05 11:10:29+00:00): Danke, das mit dem einen Weg ist verständlich durch den Tag mit dem vehicle ;) Und schön das wir den Fehler gefunden haben.
OSM_RogerWilco (2021-03-02 07:50:31+00:00): Hallo Briella Gomez,
da Du nicht auf Kommentare reagierst und weiterhin ausgedachte Namen in OSM einträgst, habe ich eine Meldung an die DWG gemacht.

Für eine Spaß-Karte könnt ihr Euch eine auf OSM-Daten basierende eigene Karte mit umap erstellen. Anleitung auf Youtube: https://www.youtube.com/watch?v=ZohcuwWMi3c
SomeoneElse_Revert (2021-06-05 13:26:57+00:00): This changeset has been reverted fully or in part by changesets 105882167, 105878073 where the changeset comment is: Following a report to the DWG, reverting some road merge edits in South Africa.  See https://www.openstreetmap.org/user_blocks/5047 and https://lists.openstreetmap.org/pipermail/talk-za/2021-May/thread.html#1295 .
Øukasz (2021-03-31 12:48:46+00:00): Hello mustafakamil, Mariateresa. I'm crossposting this comment to changesets 100248648 and 96717934.

it looks like features https://www.openstreetmap.org/way/912638031 and https://www.openstreetmap.org/relation/12115924 are what is an area split in two by an arbitrary boundary of analysis. They were classified differently, however, on the imagery I don't see a clear boundary. 

Is there a way in which you can improve your process so that seams like this one do not appear?

Thanks!
mustafakamil (2021-03-31 14:04:59+00:00): hi Øukasz
Thank you for your comment
The area has been modified
ZldYe (2021-03-02 11:48:23+00:00): Helemaal top, dankjewel!