Setzt iD Abbiegebeschränkungen ohne Wissen des Mappers?

Weide · 2018-03-23T19:08:19.000Z

Galbinus:

Das bedeutet: Man kann nicht anhand der angezeigten Eigenschaften wirklich nachvollziehen, was iD dort erzeugt hat. Darum ist es auch schwer, Fehler zu erkennen.

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.

kreuzschnabel · 2018-03-23T19:59:41.000Z

Weide:

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.

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.

–ks

Galbinus · 2018-03-23T21:09:54.000Z

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?

wambacher · 2018-03-23T21:17:26.000Z

Galbinus:

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?

Und was ist mit meiner Frage “Und legt iD nun TR-Relationen an oder nicht?” https://forum.openstreetmap.org/viewtopic.php?pid=691024#p691024

das wirst du uns doch wohl noch sagen können.

Ich kann es net, da ich iD nicht kenne.

Gruss
walter

kreuzschnabel · 2018-03-23T21:22:23.000Z

wambacher:

das wirst du uns doch wohl noch sagen können.

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.

Ich probier mal an einer unauffälligen Stelle.

–ks

milet · 2018-03-23T21:45:27.000Z

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

kreuzschnabel · 2018-03-23T21:45:31.000Z

kreuzschnabel:

Ich probier mal an einer unauffälligen Stelle.

Braucht man gar nicht hochzuladen, ist eindeutig:

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.

–ks

Galbinus · 2018-03-23T22:04:08.000Z

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.

Elefant_aus_Wuppertal · 2018-03-23T22:08:11.000Z

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.

Elefant_aus_Wuppertal · 2018-03-23T22:12:49.000Z

Die Unterstützung von turn restrictions mit Ways als “via” macht die Sache halt komplizierter denn je für Unerfahrene…

kreuzschnabel · 2018-03-23T22:26:13.000Z

Lukas458:

Gibt es so was wie restriction:conditional

Yup, steht auf der Wikiseite zu turn restrictions gleich in der ersten Tabelle.

restriction:hgv:conditional=no_left_turn@(length>10)

ist dein Freund.

–ks

slhh · 2018-03-24T00:49:12.000Z

kreuzschnabel:

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.

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.

kreuzschnabel · 2018-03-24T06:25:59.000Z

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.

–ks

Nop · 2018-03-24T08:11:02.000Z

Die Verbesserung des Abbiegeeditors kam mit iD 2.7.0 am 2. März 2018.

https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#271

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.

bye, Nop

Nakaner · 2018-03-25T12:28:12.000Z

Ilya Zverv hat die Anzahl der Abbiegebeschränkungen gezählt und einen Anstieg an Abbiegebeschränkungen mit einem Via-Way entdeckt, weil iD das jetzt unterstützt.

mmd · 2018-03-25T13:08:30.000Z

Da sind schon komische Sachen dabei:

https://www.openstreetmap.org/relation/8143686
https://www.openstreetmap.org/relation/8143900
https://www.openstreetmap.org/relation/8127671
https://www.openstreetmap.org/relation/8127204 (??)

Würde ich alles mit via-Knoten statt via-Way mappen, ist so unnötig kompliziert.

FvGordon · 2018-03-25T14:18:45.000Z

Hier habe ich zwei gegensätzliche Abbiegebeschränkungen mit den selben Elementen gefunden:

“restriction”=“only_left_turn”
Linie: Brückenstraße (561545038) als “from”
Linie: Brückenstraße (561545039) als “via”
Linie: 560557705 als “to”

“restriction”=“no_left_turn”
Linie: Brückenstraße (561545038) als “from”
Linie: Brückenstraße (561545039) als “via”
Linie: 560557705 als “to”

Da reicht doch die no_left_turn.

Auch bei dem 1. bis 3. Beispiele von mmd sehe ich eine falsche Interpretation der eingetragenen Abbiegebeschränkung durch den Router, wenn man von einem anderen Weg kommend in den via-Weg einfährt - dann gilt die Beschränkung nämlich nicht. Diese Beschränkungen sollten noch uf via-Knoten umgebaut werden.

Und im 2. Beispiel (https://www.openstreetmap.org/relation/8143900) sind zu viele no_u_turn vorhanden.

Franz

chris66 · 2018-03-25T15:09:08.000Z

Naja, ID wird halt vorwiegend von Anfängern benutzt, da werden Fehler und komische Eintragungen nicht aus bleiben…

Schön wäre eine Seite wo neue, mit ID erstellte TurnRestrictions rot aufblinken.

kreuzschnabel · 2018-03-25T17:46:55.000Z

chris66:

Naja, ID wird halt vorwiegend von Anfängern benutzt, da werden Fehler und komische Eintragungen nicht aus bleiben…

Und genau deshalb stellt sich die Frage, ob es überhaupt sinnvoll ist, diese Anfänger geradezu dazu aufzufordern, TRs zu mappen. Ohne ihnen zu sagen, welche Reichweite das haben kann, wenn man nicht genau weiß, was man tut (Routingfehler, Auswirkungen auf Fahrradrouting etc.).

Wenn wir OSM als ernsthafte Alternative zu kommerziellen Anbietern von Kartenmaterial platzieren wollen, sollten da möglichst wenige solche Klopfer drin sein (idealerweise natürlich gar keine, aber das wird unerreichbar sein).

chris66:

Schön wäre eine Seite wo neue, mit ID erstellte TurnRestrictions rot aufblinken.

Jo.

–ks

mmd · 2018-03-25T18:08:23.000Z

Die Relationen oben habe ich mit http://overpass-turbo.eu/s/xjU gefunden, dort lässt sich das Tagesdatum sowie andere Kriterien auch noch anpassen. Nicht alles ist von iD, es gibt auch JOSM-Mapper mit via-Way-Ambitionen.

https://www.openstreetmap.org/relation/8146005 sieht irgendwie auch komisch aus mit 2 via Ways und dem no_left_turn auf der Linksabbiegespur…