Die Idee ist nicht uninteressant. Aber ein via-Node muss schon sein, wie du nach einer weiteren Mütze Schlaf mühelos erkennen wirst 
Ich wollte gerade einwenden, dass üblicherweise ein from-Member reicht, aber in https://www.openstreetmap.org/relation/7972488 hab ich tatsächlich selbst gleich drei hingesetzt. Wäre auch mit einem from möglich, wenn man die verbotene Einfahrt südlich der Kreuzung nochmal unterteilt. Zweistellig wird deren Anzahl aber mit Sicherheit nur sehr, sehr selten.
–ks
Den Knoten brauchen wir auf jeden Fall. Die Rolle fand ich fraglich, weil ja gar keine Reise “von-via-nach” beschrieben wird.
Was besseres fällt mir aber auch nicht ein. Man kann sich ja ein “egal von wo - via - nach” dazu denken.
Wir haben doch auch andere Stellen, wo wir mit dem Problem kämpfen, ob etwas am Node oder am Weg erfaßt wird, weil der Node eine keine Richtung hat und die Eigentschaft aber nur für die Stelle am Weg gilt.
Schwierig ist das ja immer dann, wenn später der Weg getrennt wird oder eben eine neue Straße am via Node verknüpft wird. Da denkt doch niemand daran, dass er den neuen Weg dann als from bei der no_entry Rel hinzufügen muss.
Dann bleibt der am via-Node liegende Teil in der Relation, der andere fliegt raus. Ich glaub, das macht inzwischen sogar iD richtig.
Das stimmt allerdings. no_entry ohne from-Member sowie no_exit ohne to-Member wären weniger fehleranfällig. Eine neue role für den Node würde ich aber keinesfalls einführen, er hat dieselbe Funktion wie ein via-Node in einer dreiteiligen TR und soll dann auch so heißen.
–ks
Ich meinte, wenn man auf eine Rel verzichten würde und stattdessen versucht, die Eigenschaft irgendwie an den Way zu hängen.
Das Problem gibt es doch z.B. bei noexit=yes am Weg, wo eben nicht klar ist, was passieren soll, wenn jemand die Richtung des Wegs umkehrt.
Aus der Sicht spricht auch vieles für eine generelle Relation für solche Eigenschaften, die genau den Node an einem Ende des Weges betreffen.
Will hier aber nicht alles neu erfinden 
edit: Syntax
Wenn, dann würde ich die Eigenschaft auf einen Node setzen, der Teil vom Weg ist. Ähnlich wie eine Barrier, aber mit Richtungsangabe.
Wie würdest Du die Richtung angeben wollen?
Als “forward” bzw. “reverse”, abhängig davon wierum der Weg gemalt ist. Vielleicht “no_entry:reverse=yes”?
Da würde ich zuerst denken “da darf man nicht rückwärts reinfahren” 
Im Ernst, die Verknüpfung von no mit reverse und yes ist eine Garantie für Mißverständnisse. Ausserdem schwierig für den Editor, wenn Du die Richtung des Weges umkehrst. Soll dann ja nicht ein no_entry:reverse=no werden, oder?
Ok, eine no_exit-Relation löst das Problem.
Zu meiner Entschuldigung: Im deutschen Wiki taucht die nigends auf, in der englischen Version habe ich sie übersehen.
edit: JOSM meckert mehrere to auch bei no_exit an.
Zum weiteren: Ein node allein mit no_entry/no_exit-Eigenschaft reicht mMn nicht. Da ein Punkt keine Richtung hat, braucht man zusätzlich einen way.
Ein way allein ist auch problematisch, da dann eine mögliche Richtungsumkehr des Weges beachtet werden muss.
Da wäre eine Relation mit einem way und einem node das kleinere Übel, wenn man vereinfachen will.
Seit version 14494 nicht mehr. Wird aber wohl wieder revertiert. Es ist nur noch nicht klar, ob man no_entry / no_exit gleich ganz “verweigern” soll.
Problematisch, wenn der Punkt Teil von mehr als einen Weg ist oder irgendwann wird.
Irgendwie entgeht mir hier gerade, warum hier jetzt zwanghaft versucht wird für no-entry/exit eine andere Lösung zu finden. Die jetzige funktioniert (oder?) und in meinen Augen ist das vom Prinzip her auch nichts anderes als eine Turn Restriction. Oftmals fällt ein no entry auch mit einer Turn Restriction zusammen, warum dann zwei Dinge taggen?
Es kann in OSM nichts einfach gemacht werden. Wenn es doch kompliziert fehleranfälliger wird ist es doch “besser”.
EDIT: nur ein Beispiel für weitaus mehr Fehler um diese "kleine " Einbahnstraße:
https://www.keepright.at/report_map.php?schema=101&error=45131728&zoom=13&lat=50.83642&lon=13.07016&layers=B0T&ch=0%2C30%2C40%2C50%2C70%2C90%2C100%2C110%2C120%2C130%2C150%2C160%2C170%2C180%2C191%2C192%2C193%2C194%2C195%2C196%2C197%2C198%2C201%2C202%2C203%2C204%2C205%2C206%2C207%2C208%2C210%2C220%2C231%2C232%2C270%2C281%2C282%2C283%2C284%2C285%2C291%2C292%2C293%2C294%2C295%2C296%2C297%2C298%2C311%2C312%2C313%2C320%2C350%2C370%2C380%2C401%2C402%2C411%2C412%2C413%2C20%2C60%2C300%2C360%2C390&show_ign=0&show_tmpign=0
Ich habe hier bisher nichts von einer guten Lösung gelesen. Welche Variante hälst Du denn für am wenigsten schlecht?
Ich finde die Relationslösung jetzt schon gut und fände sie noch besser, wenn es erlaubt wäre, statt vieler from-/to-Ways auch überhaupt keinen zu setzen. Die Aussage „Über diesen Node darf man nicht in diesen Way fahren“ reicht vollkommen aus, wenn es ohnehin alle denkbaren froms betrifft, und ist robust gegenüber weiteren Bearbeitungen (z.B. ist die no_entry-Relation robust gegenüber der Aufteilung des to-Ways oder dem späteren Einbau weiterer möglicher from-Wege an den via-Node).
–ks
+1
+1
Finde ich auch logischer, weil das Z.267 grundsätzlich nur sagt, wo man nicht reindarf. Wo man herkommt ist egal.
Sollte noch definiert werden, dass der via-Node nicht inmitten des Ways liegen darf (sondern nur an Anfang/Ende) bzw. wenn er mittig ist, dass man dann in keine der beiden Richtungen fahren darf?
Wenn wir das als Ausnahme bei TR definieren wollen, dann gilt für den via node das gleiche wie für alle anderen TR.
So, ich habe die Fehler nach bestem Wissen und Gewissen beseitigt. Darüber hinaus verweise ich auf openstreetmap.org/changeset/57292468 . Sollte es irgendwann einen Konsens geben oder es weiterhin falsch sein, gebe ich die Sache gern zur Korrektur frei
VG Uwe
Edit: URL korrigiert
