Bei Auteilung von Straßen beteiligte Abbiegebeschränkungen beachten!

Multipolygone sind dazu da, um Flächen zu definieren, nicht um Objekte zusammenzufassen.
Dabei sind Teilfächen mit der Roll inner von der eigentlichen Fäche ausgeschnitten, gehören also nicht zum gemappten Objekt.
Und highwas sind sowieso keine Flächenobjekte.

Für Wanderrouten bitte keine Wege doppelt einzeichnen, wo schon welche sind, sondern ein Route anlegen mit den bestehenden Wegen als Mitgliedern:
osm.wiki/DE:Relation:route

Bitte nicht neinfach neue Wege über schon vorhandene zeichnen!
http://tools.geofabrik.de/osmi/?view=routing&lon=11.09580&lat=49.74058&zoom=15&opacity=1.00&overlays=unconnected_major1,unconnected_major2,unconnected_major5,duplicate_ways

Autobahnen sind keine Wiese! Folgen u.a.
http://osrm.at/b46

Es wäre schön langsam an der Zeit, sich mit dem Zeichnen korrekter Polygone zu befassen:
http://tools.geofabrik.de/osmi/?view=geometry&lon=11.35961&lat=47.74414&zoom=14&baselayer=GeofabrikStandard&opacity=1.00&overlays=self_intersection_ways,self_intersection_points

Das als natural grassland zu mappen ist glatter Hohn. Unnd bitte nicht diese Art von Multipolygonen, das entspricht nicht best practice!

Bleib doch bitte bei den Tatsachen und lege Wiesen und Äcker nur dort an, wo auch welche sind, nämlich neben und nicht auf den Straßen. Dann passiert es auch niicht, dass plötzlich Straßen miteinander verbunden werden, die in Wirklichkeit keine Verbindung haben. Hier kannst Du mal sehen, was das für Auswirkungen auf Router und Navigation hat: http://osrm.at/aTX

Offenbar hast Du dabei was falsch gemacht. Lade dir mal den Bereich und lass den JOSM-Validator drüberlaufen!

Ich bin mit dem OSM-Inspector drauf gestoßen, der hier unverbundene Wege meldet.

Wer der Ersteller ist, ist im Prinzip egal.

Hauptstraße und Peilstraße nochmal angelegt, obwohl sie schon existieren! Wieso?
JOSM gibt doch da eine Fehlermeldung!

Die restriction und die Richtung des to-Weges. passen nicht zusammen!
siehe http://map.comlu.com/?zoom=19&lat=50.874654&lon=11.79743&layer=OSM%20Standard&overlays=FTF

Du schreibst NICHT RECHTS abbiegen. In der Relation steht aber NUR RECHTS abbiegen. Wenn Lastwagen nicht nicht rechts abbiegen dürfen, sondern nur geradeaus fahren oder links abbiegen , müsste das NICHT RECHTS (no_right_turn) sein. Dann müsste der to-Weg aber auch rechts abzweigen, anstatt links wie jetzt.

Way #319729340, gelöscht, der zwar keine Eigenschaften hatte, aber Teil des Landuse-Multipolygons #4256486 als äußere Grenze war und damit praktisch die Wiese entfernt.

iD warnt nicht vor den Folgen solcher Löschungen und erfordert deshalb besondere Sorgfalt beim Löschen vermeitlich überflüssiger Linien.

Dann dürfte die Beschränkung aber nicht only_right_turn sondern only_left_turn sein. Dann stimmen auch die Wege in der Relation.

Von den Fahrzugtypen habe ich nichts geschrieben.

die beteiligten Wege passen doch wohl nicht zur Richtung der Abbiegebeschränkung

gibt es eine bestimmten Grund, jetzt schon zum zweitem mal den outer-way des landuse-Multipolygons zu löschen?

Warum hier einfach neue Wege über schon bestehende legen, anstatt der Eigenschaften anzupassen?

http://tools.geofabrik.de/osmi/?view=routing&lon=12.75932&lat=46.82526&zoom=18&opacity=1.00&overlays=unconnected_major1,unconnected_major2,unconnected_major5,duplicate_ways

weder reichen Äcker und Wiesen bis zur Straßenmitte noch teilen sich Wege unter und auf einere Brücke einen gemeinsamen Node

gesamte Residenz als 1 Gebäude, da geschlossener Gebäudeumriss ohne Baulücken. Gebäudeteile innerhalb als building:part=yes.
Adresse des Herkulessaals=Eingangsadresse, nicht die der Verwaltung

Das ist doch hoffentlich nicht Absicht! Oder ist das der erste Schritt, alle Wiesen, Wälder, Grasflächen usw. der Erde in jeweils einem einzigen Multipolygon zusammen zu fassen?

MP diesser Art widersprechen eindeutig guter fachlicher Praxis:
osm.wiki/Relation:multipolygon#Mapping_Style.2C_best_practice

Dass das Komma als Dezimaltrenner ein Fehler ist, ist eindeutig und und keine Geschmacksfrage (osm.wiki/DE:Map_Features/Units#H.C3.A4ufige_Fehler) und bedarf wohl keiner Diskussion.

Das Vorgehen ist folgendes:

Abfrage der ways mit width-Angaben, die ein Komma als Dezimaltrenner enthalten, aber ansonsten korrekt sind, mit Overpass Turbo.
Abfrage mit regulärem Ausdruck:
osm-script output="xml">
<union>
<query type="way">
<bbox-query {{bbox}}/>
<has-kv k="width" regv="^[0-9]{1,}(\,[0-9]{1,}){1,1}( m){0,1}$"/>
</query>
<recurse type="way-node"/>
</union>
<print limit="" mode="meta" order="quadtile"/>
</osm-script>

Export des Egebnisses in JOSM

Manuelles Ändern der Werte in JOSM. Objekte mit identischen key-value-Paaren lassen sich auswählen und in einem Schritt bearbeiten.

Validierung mit dem JOSM-eigenen Validator.

Die Angabe layer=0 wird dabei auch erkannt und mit der Reparaturfunktion des Validators korrigiert.
layer=0 ist implizit für alle Objekte Standard, die explizite Angabe ist eine redundante Information, die unnötigen Aiuswertungsaufwand zur Folge hat.