Das dürfte in der Tat der Fehler sein. Dieses Beispiel: http://www.openstreetmap.org/browse/relation/1230487 wird unter NRW aufgeführt, liegt aber komplett in RLP - kurz hinter der Grenze.
Allerdings kann es gar nicht passieren, daß ein in der Relation referenzierter Weg nicht existiert. (Lokal natürlich schon, aber nicht in der OSM-Datenbank.) Das verhindert der Server beim Hochladen. Insofern sollte diese Fehlerklasse unnötig sein.
Edit: Grammatik.
Ich fände es sinnvoll, wenn man sich irgendwo als Bearbeiter eines Paketes verewigen kann, damit dann nicht 2 Mapper gleichzeitig die Fehler beheben und der langsamere dann Konflikte bekommt bzw. umsonst gearbeitet hat. Dazu evtl. nach 25 Fehlern die Tabelle abbrechen und eine neue beginnen und oberhalb von jeder Tabelle ein: “Zurzeit bearbeitet von:”
Ich denke mal du generierst dir das mit einem Skript, oder?
Moin,
habe Schleswig-Holstein mal bearbeitet und kommentiert.
1 Fehler behoben
1 unklare SItuation, unverändert belassen
3 “False positive”
Gruß
Georg
Schau mal in die History, bevor die Relation verhunzt wurde:
Weg Bundesstraße (75487768) als from
Weg 27879335 als to
Knoten 891104213 als via
Ich denke, dass könnte helfen… (hab jetzt gerade kein JOSM bei der Hand)
Grüsse
mdk
http://www.openstreetmap.org/browse/relation/1326338/history
EDIT: Der to-Weg ist gelöscht, aber ohne Ortskenntnis ist da wohl nix zu machen.
Gruß,
ajoessen
Moin,
mach ich doch immer in solchen Fällen - wie soll man das denn sonst nachvollziehen. 
André
hat da mit seinem Fazit schon ganz recht, Ortskenntnis ist erforderlich.
Für diejenigen, die sich mit diesem Nebenschauplatz auseinandersetzen wollen (sonst Folgendes einfach ignorieren):
Der ehemalige from-way wurde mit dem ehem. to-way zusammengefasst und ist jetzt als to-way allein übrig.
Der ehemalige via-node ist noch mittendrin vorhanden.
Vermutlich war der ehem. from-way die im Luftbild zu erahnende Rechtsabbiegespur des aus Norden kommenden trunk.
Vermutlich war da ehemals noch ein jetzt fehlender bidirektionaler Anschluss für die übrigen Fahrmöglichkeiten.
Vermutlich sollte das Linksabbiegen dorthin verhindert werden.
Vermutlich hat jemand die Einmündung vereinfacht - und dadurch ist die ganze Relation hinfällig geworden.
Ist da jetzt tatsächlich eine räumlich getrennte Fahrspur?
Oder ist das ganze nur aufgemalt?
Ist das Ganze auf den 15 m überhaupt von Belang?
Ist das Ganze evtl. schon komplett umgebaut?
Die jetzige Situation ist korrekt routingfähig.
Die Relation ist zwar Datenmüll, aber sie stört kein Routing.
Für den Fall, dass sich jemand anderes in den Edit-War stürzen will, habe ich die Relation nicht gelöscht.
Gruß
Georg
Mach mal in JOSM das Changeset 8052041 rückgängig (natürlich ohne Hochladen), dann siehst du genau, wie’s vorher aussah. Die Einmündung war kleinteiliger gemappt; die only_right_turn-Relation (die wohl besser eine only_straight_on hätte sein sollen) verband dabei zwei entgegengesetzte oneway-Abschnitte auf der L 273 und sollte verhindern, daß man, von der B 5 kommend, auf der L 273 wenden und zur B 5 zurückfahren kann. Sprich ohne diese Details wird die Relation nicht mehr gebraucht, das läßt sich auch ohne Ortskenntnis sagen. (Nicht aus der Ferne beurteilen läßt sich hingegen, ob die Kreuzung tatsächlich zurückgebaut/vereinfacht wurde und die De-Detaillierung in #8052041 sinnvoll war.)
Hinweise möchte ich nur auf http://wiki.openstreetmap.org/wiki/DE:Relation:restriction/Fehlerhafte_Turn_Restrictions#T.C3.A4glich_Kachelbezogene_Daten_f.C3.BCr_Deutschland
hat mir vielleicht zufällig jemand ein vernünftiges poly-file von Hamburg, damit ich das sauber ausschneiden kann? danke…
Ich hab mir Berlin angeguckt. Die unteren 4 sind wohl false positivs? Ich kann jedenfalls keinen Fehler finden.
From und to werden angeblich nicht gefunden. Einen klick weiter auf der Wikiseite der Relation werden from und to aber aufgelistet.
danke für das poly-file…
nun sieht es schon viel besser aus. Die False-Positives in Hamburg sind mit diesem poly nicht mehr vorhanden. dafür sind jetzt noch 2 zusätzliche Turn-Restrictions angemeckert worden (ob False-Positive oder nicht, muss gecheckt werden).
Ich werde bei Gelegenheit die anderen Bundesländer auch nochmals machen.
Oft sind die TRs zwar syntaktisch korrekt aber trotzdem falsch wie ich gestern in Mönchengladbach anhand der
Tracks und Abbiegepfeile auf den Satbilder gesehen habe.
Naja, damit muss man wohl leben, oder man ignoriert beim Routen einfach alle TRs (so wie ORS). 
@efred: Überprüfst Du auch, ob der via-Knoten Teil (genauer: erster oder letzter Knoten) der to- und from-Wege ist? Bzw. bei komplizierteren Konstellationen die to-, via- und from-Wege verbunden?
Keine Ahnung, wie häufig solche Fehler sind, aber das könnte man ja bei der Gelegenheit herausfinden.
Kommentar eines Users den ich angeschrieben hatte:
Bitte bei den erledigten ein “done” reinmachen, danke.
Betrifft zB Thürigen wo User aighes anscheinend schon aufgeräumt hat.
Chris
steht doch groß über der Tabelle, dass ich damit durch bin.
Hmm, welche Dateien muss mal denn da nehmen? Die die ich geprüft habe, da waren über die Hälfte
False-Positives.
http://dev.openstreetmap.de/aio/mkgmap-errors/germany/
Chris
Hmm…
so wie es aussieht, geht es um die “RestrictionRelation.txt” Dateien in den Verzeichnissen. Da die alle das gleiche Datum haben, entsprechen die Verzeichnisse wohl bestimmten Teilgebieten. Ich habe aber keine Ahnung, was die Verzeichnisnamen bedeuten. Es gibt auch noch die riesige Datei “1_RestrictionRelation.txt”, die vermutlich eine Zusammenfassung ist…
Grüsse
mdk
Hi,
wo sind denn unsere Garmin-Experten?
7001 ist das eine family-id oder so und dann wird munter raufgezählt.
Ich würd’ mal auf die Dateien
1_OSM_rest_doesnt.txt
1_OSM_rest_extra.txt
1_OSM_rest_unknownmember.txt
rest wie restriction