Ich habe den Kollegen Galbinus in https://www.openstreetmap.org/changeset/51919460 auf einige unsinnige und unzutreffende TRs aufmerksam gemacht. Er stimmt mir zu und kann sich gar nicht erinnern, diese Relationen überhaupt gesetzt zu haben. Sie stammen aber laut History eindeutig aus seinem CS!
Kann es sein, dass iD abhängig von der Kreuzungsgeometrie in letzter Zeit (der CS ist 6 Monate alt) selbständig solche TRs setzt? Abbiegeverbote auf Radwege ohne Spezifikation der Verkehrsarten? Wendeverbote an spitzwinklige Einmündungen, wo das Wenden überhaupt nicht verboten ist?
Wenn ja, dann haben wir ein mega Problem, denn viele dieser TRs sind nicht nur überflüssig, sondern geradezu falsch!
Mir sind hier auch in Taunusstein schon einige davon aufgefallen, die ich User:Mah angelastet habe, weil es seine CS waren. Möglicherweise kann er dann gar nichts dafür.
An https://www.openstreetmap.org/way/509327294 hab ich vor einigen Wochen auch so einen Unsinn gesehen (und beseitigt).
Ich halte es für denkbar, dass iD uns hier gewaltige Eier ins Nest legt. Oder iD-User werden in letzter Zeit geradezu relationengeil.
Man fügt im iD Abbiegebeschränkungen nicht per Relation ein oder ändert sie auch nicht auf diesem Wege. Man klickt im Editier-Modus auf den betreffenden Kreuzungspunkt, dadurch geht im linken Bereich, dort wo die Eigenschaften geändert werden kann, ein vergrößertes Bild des Kreuzungspunktes mit den dort hinführenden Wegen auf und dort werden bestehende Abbiegebeschränkungen als Pfeile angezeigt (grün=erlaubt, rot=verboten, blau=tja, weiß ich nicht, sieht man nur, wenn eine Abbiegegeschichte vorhanden ist, man selber konnte bis vor kurzem jedenfalls einen solchen blauen Pfleil nicht erzeugen)… so war das jedenfalls noch vor wenigen Monaten. Inzwischen wurde mal wieder einiges geändert. Das beschriebene Kreuzungsbild wird jetzt nicht mehr links oben angezeigt sondern rechts unten und es werden auch die Abbiegepfeile von Kreuzungspunkten in der Nachbarschaft angezeigt - ich sehe das heute das erste mal, da ich in der letzten Zeit wenig editiert habe - und es sieht erst mal sehr verwirrend aus. Das ist eines der Probleme mit dem iD - es gibt immer wieder deutliche Veränderungen und man muss neu überlegen, wie arbeite ich nun mit dem veränderten iD und wozu dient die Veränderung.
Das bedeutet: Man kann nicht anhand der angezeigten Eigenschaften wirklich nachvollziehen, was iD dort erzeugt hat. Darum ist es auch schwer, Fehler zu erkennen.
Ich habe gerade mal rumgespielt. Offensichtlich hat hier der iD einige Funktionen erweitert. Nun kann man auch blaue Pfeile erzeugen und es wird auch angezeigt, was gemeint ist. Trotzdem sehr, sehr verwirrend…
Ja, jetzt sagt so mancher: Soll Galbinus doch endlich auf JOSM umsteigen. Aber: Ich habe das schon mehrmals versucht, ich komme mit JOSM nicht klar, bzw. ich müsste so viel Lernen darein investieren, dass ich den Spaß am Mapen verlöre. Und ganz ehrlich: Ich erwarte, dass der offizielle von OSM integrierte iD-Editor so korrekt arbeitet, dass ein umsichtiger Maper damit keine ungewollten Fehler macht.
Es mag sein, dass man die Probleme der Vergangenheit erkannt hat und die aktuelle Version (mit der bis heute noch keine Abbiegebeschränkungen erstellt oder bearbeitet hatte) hier besser arbeitet als die vorherige Version. Wir werden sehen. Ich kann vorschlagen, dass ich - sobald ich mal wieder irgendwo mit Abbiegebeschränkungen zu tun habe, einen erfahren JOSM-Verwender drüber schauen lasse.
Und es ist schwer, miteinander zu kommunizieren. Wenn der eine nie sieht, welche Daten bei seinen Editieraktivitäten tatsächlich entstehen und der andere nur die Daten sieht, dann kann wird Kommunikation sehr schwierig.
Wenn ein iD-User eine Bus-Relation beschädigt, dann muss man immer über Dinge reden, die der iD-User augenscheinlich garnicht zu sehen bekommt. Statt dessen ein pauschales “das geht mit iD nicht” von sich geben ist schlecht für das Verhältnis der Mapper untereinander.
Ja. Es kann nur zum Aneinander-Vorbei-Reden führen. Der alte Hase fragt den Anfänger: Wie konntest du das nur machen, lass doch die Finger von Sachen, mit denen du dich noch nicht auskennst. Der Anfänger antwortet: Wieso, ich hab doch gar nichts gemacht, ich weiß ja nicht mal, was eine Relation ist. Der alte Hase: Aber im Changeset steht, dass du die Relation angelegt hast. Der Anfänger: Was ist denn jetzt schon wieder ein Changeset?
Ich bin nicht glücklich mit einem Editor, der einerseits sehr einsteigerfreundlich ist und andererseits den Einsteiger Sachen machen lässt, deren Tragweite der Einsteiger nicht absehen kann. Abbiegebeschränkungen auf Radwege zum Beispiel. Sie mögen nett gemeint sein, aber sie sind bezüglich PKW unnötig (weil ein Router im PKW-Modus sowieso nicht auf Radwege abbiegt) und bezüglich Radfahrern falsch (weil sie uneingeschränkt auch für diese gelten, denn ein except=bicycle wird nicht gesetzt) und führen damit zu unnötig komplizierten Fahrrad-Routings, oder sogar dazu, dass Radfahrer auf die Straße statt auf den Radweg geschickt werden, weil die Straße für den Router „erlaubter“ aussieht.
iD sollte zumindest den Anwender auf die Gültigkeitsbreite (auch für Radfahrer) aufmerksam machen, wenn so was gesetzt wird.
Ich will gar nicht wissen, wie viele solcher gut gemeinter, aber sachlich falscher Abbiegebeschränkungen schon in der Datenbank sind. Leider schränkt das die Brauchbarkeit unserer Daten für Fahrradrouter deutlich ein.
Was die Abbiegerelation für den Radweg betrifft: Ich habe noch nie eine solche Abbiegerelation versucht zu machen, es sei denn, ich hätte mal in geistiger Umnachtung sowas aus Versehen getan. Deswegen verwundert es sehr, dass es dort jetzt eine gab, die ich angeblich vor 1/2 Jahr erstellt haben soll. Denn natürlich ist es totaler Unsinn eine solche Abbiegebeschränkung zu machen.
Es ist für mich etwas schwierig, hier aktuell etwas Erhellendes beizutragen, da ich im Moment beruflich so sehr eingespannt bin, dass ich abends nicht mehr sonderlich munter hier ins Forum schaue, bei OSM auch nur kleinere Verbesserungen anbringe (mal hier und da eine Sitzbank einzeichnen, die mir beim Laufen aufgefallen ist oder Wege nach einem Waldlauf in Surface und Streckenführung korrigieren, aber nichts mit Relationen oder andere komplexere Sachen), da ich für anderes keinen Kopf habe. Um zu verstehen, was bei iD nun in Sachen Abbiegebeschränkungen geändert wurde, bräuchte ich einen klareren Kopf. Kann nicht jemand von den JOSM-Profis mal mit iD ein wenig rumprobieren?
Einen Gang zurück bitte, Walter. Galbinus hat gerade geschrieben, dass er beruflich gerade so eingespannt ist, dass er kaum zum Mappen kommt und für solche Recherchen wohl gar keine Zeit hat.
Ja, iD legt Relationen für TurnRestrictions an. Man sieht das auch, wenn man im linken Bearbeitungs-Fenster nach unten scrollt.
Die grafische Editier-Funktion verschleiert das natürlich etwas. Screenshot_1 Screenshot_2
Ganz von selbst setzt iD keine Abbiegebeschränkungen, jedenfalls ist mir gerade nichts dergleichen aufgefallen.
Klickt man einen shared node zweier Straßen an, öffnet sich im linken Panel automatisch ein Editorfenster für Abbiegebeschränkungen. Dort wird die Umgebung des Nodes nochmals dargestellt, und man wird aufgefordert, per Klick einen “von”-Weg zu selektieren. Hat man das getan, werden alle in Frage kommenden “to” mit grünen Pfeilen (erlaubt) gekennzeichnet, und der User kann per Klick einzelne Pfeile rot (verboten) oder blau (vorgeschrieben) machen.
Es gibt im Abbiegebeschränkungen-Editor keine Möglichkeit, den Gültigkeitsbereich bezüglich Verkehrsarten zu beschränken. Und auch keinen Hinweis, dass man das eventuell machen muss.
Die angelegte Abbiegebeschränkung erscheint sofort unten unter “Alle Relationen”. Da muss man natürlich erstmal hinscrollen.
Nur wenn man dort unten die angelegte Relation gezielt selektiert, kann man Ausnahmen festlegen. Das macht man natürlich nur, wenn man überhaupt weiß, dass Ausnahmen festgelegt werden können und manchmal auch müssen, weil TRs per default für alle Fahrzeuge gelten.
Ein Mapper, der das gemacht hat, sollte also – Thema Kommunikation – zumindest mit „Abbiegebeschränkung“ etwas anfangen können, denn das steht groß in dem aufpoppenden Editor.
Bedenklich finde ich:
Punkt 2: der automatisch aufpoppende Editor erweckt den Eindruck, als seien solche Beschränkungen an jedem shared node erforderlich oder wünschenswert. Das wird durch die Aufforderung „Selektieren Sie einen von-Weg“ noch forciert und kann einen Benutzer schon dazu verleiten, vorsichtshalber mal Abbiegeverbote auf einen kreuzenden Radweg einzutragen. Es gibt dort keinen Hinweis darauf, dass a) Abbiegeverbote nur dort gemappt werden sollten, wo sie unbedingt erforderlich sind, und b) keine Abbiegeverbote gemappt werden, wo sich der Sachverhalt schon aus anderen Umständen ergibt (also PKW biegt nicht auf Radweg ab).
Ich würde den Abbiegebeschränkungen-Editor nur auf Wunsch aufgehen lassen, nicht schon beim Selektieren eines shared node. Denn alles automatisch Erscheinende erweckt den Anschein, als sei es der nächste erforderliche Schritt, dort etwas zu machen.
Punkt 3: der Abbiegebeschränkungen-Editor sollte ein Schaltfeld „Betroffene Verkehrsarten“ bekommen, das per Default auf „alle Fahrzeuge“ steht. Dann nämlich merkt der Mapper, dass er auch in dieser Hinsicht etwas machen muss.
Kreuzschnabel, was Du beschreibst, ist der neue iD. vor 1/2 Jahr war das anders. Deutlich rudimentärer. Und ich habe den Verdacht, dass damals bereits vorhandene Abbiegebeschränkungen bei Veränderungen mittes iD verschlimmbessert wurden. Ich vermute bei dem von Kreuzschnabel gefundenen Fehler mit dem Radweg, dass dort irgendwas vorhanden war, was ich verändert hatte und dabei ungewollt eine vorhandene Abbiegebeschränkung übernommen habe…
Im aktuellen wird iD deutlich mehr angezeigt und werden auch erklärende Kommentare eingeblendet. Und alles sieht deutlich komplizierter aus. Damit werde ich mich mal in einer ruhigen Stunde näher beschäftigen, jedenfalls bevor ich irgendwann mal wieder eine Abbiegebeschränkung bearbeite.
Wo wir gerade beim Thema sind - wie ist das eigentlich: Verkehrsteilnehmer, die die Beschränkung nicht beachten müssen, werden ja i. d. R. mit except=* ausgenommen. Ist es mittlerweile denn auch als Methode anerkannt,
restriction:<betroffene_verkehrsteilnehmer> zu verwenden? Das kannte ich bisher von restriction:hgv, da man dort das so einfacher handhaben kann als wenn man tausend Values in except=* schreiben muss.
Und was mache ich, wenn ich eine Abbiegebeschränkung habe, die nur für hgv’s ab 10 m tatsächlicher Länge gilt? Gibt es leider hinter Bahnübergängen in meiner Gegend dauernd.
Gibt es so was wie restriction:conditional oder except:conditional? Denn genau wie bei Zugangsbeschränkungen stößt man sonst an seine Grenzen, wenn die Definition der Beschränkung quasi in den Value gehört und nicht in den Key.
gilt nur für Relationen, die den urspünglich selektierten Node als via Member haben.
Wenn man dort Abbiegebeschränkungen mit anderem via node oder mit via Way anlegt, muss man für 5. erstmal einen der Member in der Hauptkarte selektieren.
Wie auch immer, das Hauptübel sehe ich darin, dass beim Selektieren des shared nodes dieser blickfangende Editor von selbst aufklappt und dem Mapper suggeriert, er müsse als nächstes unbedingt dort was machen, als sei das ein notwendiger oder auch nur empfohlener Schritt. Da wird nicht drauf hingewiesen, dass das Setzen von TRs an shared nodes die Ausnahme ist und nur dann gemacht wird, wenn es ansonsten wirklich zu Fehlroutings kommen kann.
Eventuell handelt es sich um ein bereits behobenes Problem.
Ich sehe es auch problematisch, daß sich dieser Editor dem Benutzer so aufdrängt. Ich war beim ersten mal sehr überrascht und wußte auch nicht so recht was ich damit anfangen sollte.
Letztendlich habe ich ihn in meinem Fork komplett deaktiviert, a man zum Wandern keine Abbiegerelationen braucht und er doch enorm verwirrt.
