Eine durch Verkehrszeichen festgelegte Maximalbreite sollte man nicht als Breite für die Fahrbahnverengung eintragen sondern für den gesamten Straßenabschnitt als Attribut der Straßenlinie:
maxwidth=2
traffic_sign=DE:264[2]
(vgl. http://osmtools.de/traffic_signs/?signs=264%5B2%5D )

Mein voriger Kommentar bezieht sich auf die nördliche Fahrbahnverengung. Die südliche besteht aus einer Mittelinsel und einer Seitenbegrenzung. Die Fahrbahnen schätze ich Anhand des im vorigen Kommentar genannten Luftbild auf jeweils 2,3m Breite.

Anhand des im iD-Editor hinterlegten Luftbilds "NRW-Orthophoto" und dem eingeblendeten Maßstab würde ich die Durchfahrt an der Engstelle auf ca. 3,5m schätzen.

Wenn man sich die im iD-Editor hinterlegten Luftbilder anschaut, kann man bei "Esri Weltbilder (Klarheit) Beta" noch die Objekte sehen, einen Teil der Objekte kann man auch bei den "NRW Orthophoto" sehen. Aber da man nicht erkennen kann, um was es sich handelt (Zaunpfosten, Poller, Leuchtsignal, ...) war es sicherlich besser, sie zu entfernen. Es kann ja niemand von uns dort vor Ort schauen, um was es sicht handelt, dass müsste schon jemand sein, der dort arbeitet und daher das entsprechende Wissen besitzt.

Da seit 2 Jahren niemand mit Fachkenntnis da was mit gemacht hat und auf dem aktuellen Luftbild nichts mehr zu erkennen ist (anders als vor 2 Jahren) bin ich für Löschen. Da dies von Dir auch als Option genannt wurde, werde ich das jetzt einfach mal tun.

Das weiß ich auch nicht. Auf dem damaligen Luftbild waren diese Objekte erkennbar und ich hoffte, dass jemand anderes an der Stelle weitermachen würde mit genauerer Kenntnis, wozu diese Objekte dienen.

Für einen solchen Hochbehälter für Trinkwasser ist amenity=dinking_water falsch. Das ist für Trinkwasserzapfstellen gedacht. Richtig ist in diesem Fall:
man_made=reservoir_covered
content=drinking_water

An sich richtig. Allerdings ist amenity=drinking_water für eine Zapfstelle mit Trinkwasser gedacht und nicht für einen Hochbehälter. Ich habe dies daher korrigiert. Richtig ist:
man_made=reservoir_covered
content=drinking_water

Thank you, Nagalvad.

Hallo nagalvad, Du scheint gerade reihenweise Kreuzungen, die in der Mitte eine runde Verkehrsinsel haben, zu Kreisverkehren umzubauen, obwohl es sich definitiv um keine Kreisverkehre handelt. Bitte schau Dir mal den "note" an und den Verlauf. Zusätzlich lies Dir bitte diese Diskussion durch, vor allem die Beiträge der letzten Tage. https://community.openstreetmap.org/t/mini-roundabout/7524

Du hast vor ca. einem Jahr trotz meiner hinterlegten Notiz "note=dies ist eine Kreuzung mit einer kreisrunden Verkehrsinsel in der Mitte aber kein ausgewiesener Kreisverkehr und somit abgesehen vom allgemeinen Rechtsfahrgebot ohne klar definierte Fahrrichtung." aus dieser Kreuzung einen Kreisverkehr gemacht (junction=roundabout). Dies ist aber kein Kreisverkehr. Es gibt keine derartige Beschilderung. Und ein längeres Fahrzeug könnte z.B. auch nicht nach links abbiegen, ohne links an dieser Verkehrsinsel vorbeizufahren. Wenn es ein Kreisverkehr wäre, müsste man mit diesem langen Fahrzeug außen um die Verkehrsinsel (entgegen des Uhrzeigersinns) herumfahren und würde dann an der Verkehrsinsel hängen bleiben.

Da die Prommenade durch blaue Beschilderung eindeutig als Fußgängerweg bzw. Fußgängerstraße ausgewiesen (gewidmet) ist, ist gelegentlicher forstwirtschaftlicher Verkehr dem eindeutig untergeordnet. Auch durch eine Fußgängerzone in einer Innenstadt fahren Lieferfahrzeuge, sicherlich sogar mehr als aufs der Bielefelder Prommenade forstwirtschaftliche Fahrzeuge unterwegs sind. Allerdings ist die Prommenade zumindestens im unteren Bereich geschätzte 7 Meter breit. Daher sollte man darüber nachdenken, sie zu einem highway=pedestrian zu machen. Die Beschilderung ist zwar nicht die einer Fußgängerzone, meines Erachtens würde das aber hier passen.

Wie ich schon schrieb, hat z.B. die Navi-App MagicWorld nach meinen Erfahrungen keinerlei Probleme damit, daraus ein einfach "rechts abbiegen" als Sprachansage zu machen.

Es lieg in der Natur der Sache, dass bei jeder Aufteilung von einer mehrspurigen Straße mit Gegenverkehr auf eine Straße mit baulich getrennten die Straßenline, die ja die Mitte der jeweiligen Straßenfläche darstellt, einen leichten Knick macht. Wenn man dafür sorg, dass man diese Aufteilung der Linien in einem flachen Winkel (z.B. unter 30 Grad) kann ein gut programmiertes Routing dies dann leicht von einem echten Abbiegevorgang unterscheiden, so dass es in dem von Dir gewählten Beispiel nur einen Abbiegevorgang ansagt.

Aus meiner Sicht sind diese Fahrbahnaufteilungen die logische Ergänzungen zum Eintragen von Rad- und Fußwegen als eigene Linie. Die Vorteile sind beidesmal ähnlich. Aus meiner Sicht passt beides zu der immer zunehmenden Detailtreue der OSM-Daten. Vor allem Fußgänger und Radfahrer profitieren meines Erachtens sehr davon. Es können so unter Anderem unterschiedliche Bordsteine und Weguntergründe deutlich präziser erfasst werden, u.A. in Hinsicht auf Barrierefreiheit. Aber auch wenn ich mit dem Auto unterwegs bin, freue ich mich darüber, wenn das Kartenbild meiner Navi-App die oft damit einhergehende Spurverschwenkungen dadurch optisch darstellt. Ich nutze mit dem Auto zur Navigation allerdings MagicEarth und das hat keine Probleme mit diesen Spuraufteilungen. OSMAND dagegen schon. Aber OSMAND ist bekannt dafür, dass sinnvolle Sprachansagen nicht unbedingt die Stärke dieser App ist. Wie oft bekomme ich z.B. im Wald eine Ansage, ich möge links oder rechts abbiegen an Stellen, wo es nur eine Kurve aber keine Abbiegemöglichkeit gibt und dann wenige huntert Meter weiter fehlt dann eine Sprachansage, obwohl es dort dann tatsächlich eine Abbiegemöglichkeit gibt und man sich eine Sprachansage wünschte.
Das Thema Fahrbahnaufteilungen wurde bereits mehrfach im Forum diskutiert und ist zu komplex, als dass man sie in einem Chanceset hinreichend diskutieren könnte.

Ich habe mehrere Luftbilder verglichen. Unter anderem das bei ID Editor hinterlegte Esri ist ziemlich aktuell und in dem Bereich ist alles gut zu erkennen. Auf keinem der Luftbilder ist ein Wetterpilz an der Stelle vorhanden. Ob natürlich an anderer Stelle eine neue Schutzhütte errichtet wurde,
weiß ich nicht.

Ich habe mal auf Deinen Hinweis hin bei anderen Pisten geschaut. Im benachbarten Winterberg sind die Abfahrtpisten einfach bis direkt an den Lifteinstieg verlängert worden. Das werde ich jetzt in Willingen auch so umsetzen.

Hast Du eine bessere Idee, wie man das Ende der Abfahrt mit dem Einstiegspunkt des Skilifts verbinden kann?

Ich finde es verfrüht, dass Du die Änderungen bereits vorgenommen hast, bevor die Sperrung tatsächlich aufgehoben wurde. Was Du damit bezwecken wolltest, hast Du auch nicht erreicht, da der von Dir erwähnte Node weiterhin Routingprogramme daran hindern werden, Durchgangsverkehr dort entlangzuleiten. Um den "barrier"-Node aufzuheben, löscht man nicht den Node sondern nur die Attribute. Das lässt sich im ID-Editor relativ einfach machen. Außerdem sollte man an der Stelle die beiden Wegabschnitte miteinander verbinden, da sie nach Aufhebung der Sperre die gleichen Attribute haben. Wenn Du Dir das nicht zutraust, schreib mich bitte nach tatsächlicher Aufhebung der Sperrung direkt an, dann erledige ich das. Aber ich werde nichts entfernen, solange die Sperrung noch vorhanden ist. Und ich kann das nicht vor Ort überprüfen.

highway=track ist wrong. It's not "mostly used for agriculture, forestry, outdoor recreation, and similar activities on open land". It's at least highway=unclassified, because it ist a road, that connects Las Norias and La Laguna.

Ich halte das Einzeichnen dieser kleinen, langestreckten Senke auf dem Eggekamm für unglücklich. Ein Tal is meines Erachtens mehr als eine leichte Senke. Und jetzt überkreuzen sich nun auf dem Bergkamm an zwei Stellen natural=ridge und natural=valley.