Naja, sieh es einfach demokratisch, Du hast mit Deinen Argumenten ja auch niemanden überzeugen können.
Ich habe nirgends gesehen, dass es unbeliebt ist. Und unbeliebt heißt nicht, dass man das nicht so taggen darf/soll, solange es im Wiki steht und nicht auf gemeinschaftlichem Wege rausgeworfen wird, kann man es so taggen. Ich habe mich damit angefreundet und nutze traffic_signals:direction ausschließlich. Immerhin kann man so auch an Kreuzungen Ampeln taggen, an denen es unterschiedliche Querungsmöglichkeiten für Fußgänger gibt. Es gibt ja auch Einmündungen, an denen Fußgänger nicht queren dürfen.
NOCH nicht!, man kann dies ja bei OSM anregen.
Es kann nicht sein, dass wir die Karte für eine bestimmte Software mappen. Der eine Router wertet es so aus, der andere so. Nur weil ich OSMAnd nutze, kann ich nicht für mich beanspruchen, nur mein Tagging ist korrekt!
Das hatte ich schon vor zwei Jahren dort nachgefragt. Da ging es noch um maxspeed:forward was auch nicht unterstützt wird.
Das war die Antwort
-> Actually not yet, there limitations to detect what is forward and backward internally. But we are working on it. VIctor
Auch mehrere Nachfragen, nicht nur von mir, kam keine aktuellere Antwort mehr. Das Problem ist weiterhin aktuell. Das ist ja auch ein Grund warum ich mich frage ob das forward/backward so eine ideale Lösung ist. Mindestens OSMAND, also die aus meiner Sicht beste OSM Routingsoftware, kann damit nicht umgehen. Können es dann Andere? Kann es Scobbler als meine persönliche Nummer 2. Oder gibt es da noch eine Software die ich nicht kenne?
Wenn forward und backward nicht ausgewertet werden, impliziert das vermutlich auch, dass left/right nicht ausgewertet wird, da ohne Wissen, in welche Richtung man fährt, ja unmöglich auszuwerten. Durchaus ein größeres Problem, aber wohl eines, das gelöst wird…
Also
turn:lanes=left|through
zeigt OSMAND korrekt an. Nur mit
turn:lanes:forward=left|through
kann die Software nicht umgehen.
Wenn dann das Problem seit zwei Jahren nicht gelöst wurde scheint es ja so einfach auch nicht zu sein.
Jetzt habe ich ein Verständnisproblem. Ich vermute Du beziehst Dich auf sidewalk/cycleway etc.? Wenn es keine bauliche Trennung gibt, gibt es doch auch gar keinen Grund für einen parallelen Weg, das macht keinen Sinn, in der Realität sind dies ja auch keine parallelen Weg, sondern ein Weg, der nur unterschiedlich ausgebaut und beschildert ist. Oder habe ich Deine Aussage jetzt in den falschen Hals bekommen?
Wir mappen eine 30 m breite Fläche als einen way - mit hw=, lanes=, cyleway=both, sidewalk=left/right, maxspeed=* und eventuell noch forward=, surface=, smoothness*, width=, access=
Skobbler unterstützt momentan soweit ich weiß weder turn:lanes, turn:lanes:forward/backward noch maxspeed:forward/backward, zumindest bei meinem letzten Test. Da wird ja momentan viel umstrukturiert nach dem Verkauf an Telenav.
Es ist eine Frage was man ausgewertet haben möchte. Ich kann schnell erkennen ob ein Fußweg Fahrradweg vorhanden ist und ggf. auch in welcher Richtung der Radweg verwendet werden darf. Aber das ist schon schwerer!
Ebenfalls leicht rauszufinden ist wer es denn benutzen darf. Aber schon mit den Oberflächen wird es schwer. Welcher Weg hat jetzt welche Oberfläche. Gehen wir mal davon aus das alle Wege anders beschaffen sind. Auch der Pflegezustand und die Abnutzung dürfte sich stark unterscheiden.
Was sollte dann ein Navi dem Rollatorfahrer für einen Vorschlag machen?
Ich wäre schon zufrieden, wenn die örtlichen Mapper gefragter wären, denn die sind es, die ihre Umgebung aktuell halten.
Warum haben 3-4 Mapper entschieden, dass eine Doppellinie nicht mehr baulicher Trennung entspricht?
Warum setzen 4-6 Mapper deutschlandweit ihre Ideen schnellsten um (und schaffen sich Argumente, es wird ja in Deutschland so gemappt - nun machen wir es noch in den anderen Ländern)
Warum wird im WIKI ständig etwas geändert?
Ich versuchte die mir bekannte Gegend aktuell zu halten. Wenn aber Mapper aus 200- 300 km Entfernung - ohne vor Ort gewesen zu sein - es besser wissen … Ich habe auch Fehler gemacht, dazu stehe ich auch. Ich finde lanes=* als Spurbezeichnung auf mehrspurigen hw durchaus angebracht. Mittlerweile geht es um detaillierteres mappen - warum nicht hw=lanes als way. Es gibt einige Vorschläge Straßen als Flächen anzulegen (ähnlich waterway). Sollten wir nicht auch andere Meinungen akzeptieren. Wenn ich keine verschiedene Beispiele habe, kann ich auch nicht entscheiden, was ist besser. Ich bewundere andere (netzwolf, maxbe, …) die wenigsten versuchen, welche Möglichkeiten bei verschiedenen Situationen es gibt.
OSM war für mich etwas mehr als Hobby. Ich war bestrebt, Nutzer im Umfeld von “besseren Karten” zu überzeugen und ihre Vorstellungen mit zu beachten: (@anonym: Eine Gasse oder ein Weg von 2.5 m breite ist m.E. kein hw=residential).
ich habe das Proposal erstellt und freue mich über das viele feedback. Ich habe darauf basierend eine neue Version des Proposal erstellt. Ihr findet es unter der alten Adresse:
Ich habe eingesehen, dass das Proposal sehr viele Relationen für eine Kreuzung bedingt hätte und habe die benötigte Anzahl verringert. Nun ist nur noch eine Relation pro eingehender Kante in eine Kreuzung (Kann aus mehreren Knoten bestehen) notwendig. Also in der Regel zwischen 2 und 4.
Der Alternativvorschlag von Michael sah, wenn ich es richtig verstanden habe, so aus, dass auf Relationen komplett verzichtet wird und die Informationen in den traffic_signal Knoten getagged werden sollen. Ich glaube allerdings dass dies nur funktioniert wenn der Knoten nur auf einem der Wege liegt. Liegt er genau auf Kreuzung von Zwei Wegen, bzw. auf dem Ende von 4 Wegen ist mir schleierhaft wie man festlegen soll für welche eingehende Kante welche Ampelphase gilt.
Die Referenzierung der turn:lanes scheint mir auch sinnvoll da es einfacher zu taggen und robuster gegen Änderungen ist. Ich habe das vorgeschlagene Schema größtenteils in mein Proposal übernommen.
Die Möglichkeit mit conditional Zeitabhängige Schaltungen zu modellieren ist auch eine sinnvolle Idee und kann optional benutzt werden.
Dass dynamische Ampelschaltungen existieren ist mir bewusst. Es geht vielmehr um eine Idee wie wahrscheinlich es ist dass eine Ampel grün oder rot ist. Daher habe ich das taggen der Phasen auch vereinfacht.
Die Deklaration von via-ways habe ich auch erstmal herausgenommen, da diese relativ einfach von einem router ermittelt werden können da ein to-way angegeben ist.
Ich würde euch darum bitten das überarbeitete Proposal nochmals durchzugehen und würde mich freuen wenn ihr mir eure Gedanken dazu mitteilt. Am besten auf der Diskussionsseite zu dem Proposal.
Ich bin davon ausgegangen, dass Kreuzen, bei denen man sogar die Ampelphasen mappt, der Ampelknoten nicht mehr die Kreuzungsmitte, sondern an den Haltelinien/Fußgängerfurten liegt. Der Ampelknoten läge dann auf einem Node, der maximal drei Ways angehört – der Fahrbahn für den Kfz- und Radverkehr und dem kreuzenden Fuß-/Radweg, der an dieser Stelle aufgeteilt sein darf, wenn er kein Einbahnfußweg ist. Wie lange die Grünphase des kreuzenden Fuß-/Radweg ist, kann man dann mit phases:crossing=* angeben.
Mit dem Schema kann ich mich anfreunden. Ein nützlicher Nebeneffekt könnten verbesserte Abbiegeansagen bei Navis sein. Wenn ein Mensch als Rolle “to:left” vergibt, wird das wohl auch von anderen Menschen als “links” empfunden. Hoffentlich aber nicht “too:left”, was “zu weit links” bedeutet.
Sondereffekte durch Induktionsschleifensteuerung, Fussgängeranforderung, Busvorrangschaltung
bestimmt.
Die Relation gibt Punkt 3 wieder (sofern der Mapper die Ampel lange genug beobachtet um die mittleren Phasenlängen korrekt zu bestimmen).
Ein Router kann damit den Zeitverlust berechnen, wenn das Fahrzeug die Ampel in der nächsten Phase überqueren kann, das Eintreffen nicht von vorherigen Ampeln getaktet ist (erste Ampel nach freier Strecke) und es keine Sondereffekte durch Punkt 4 gibt.
Dafür erscheint mir der Aufwand recht hoch.
Gibt es weitere Anwendungen?
Die Relation ist komplex, so dass es schwierig ist, die Daten auf Korrektheit zu überprüfen.
Hallo,
also ich empfinde das als sehr kompliziert und mehr als fehleranfällig. Auch habe nicht verstanden, ob die Abbiegerelationen bei Ampeln, welche nicht im Kreuzungsnode sondern an der Haltelinie getaggt sind, genauso aussehen müssen/werden?
Wenn ich mir diese Kreuzungsansammlung ansehe http://www.openstreetmap.org/#map=17/51.36387/7.46436, dann müsste ich, da ich nicht überall abbiegen kann wohin ich will, 35 Relationen erstellen, sofern ich richtig gezählt habe (da an einer Kreuzung auch jede Richtungsänderung gesondert geschaltet ist). Solche Kreuzungshäufigkeiten kommen gerade in Großstädten häufig vor und sind mehr als unübersichtlich. Und jetzt wird an einer Straße etwas geändert…viel Spaß bei der Wartung der Relationen…
Kann es sein, dass du eine veraltete Version des Proposals im Kopf hast? So war das im ersten Entwurf, den ich deshalb auch als zu kompliziert kritisiert habe. Mittlerweile braucht man aber nur noch eine Relation pro Straße, die auf die Kreuzung zuführt. Es ergäbe in deinem Beispiel also:
Kreuzung Graf-von-Galen-Str./Körnerstr.:
1 Relation aus der Graf-von-Galen-Str.
1 Relation aus der südöstlichen Körnerstraße
1 Relation aus der nordwestlichen Körnerstraße
Kreuzung Körnerstraße/Am Hauptbahnhof:
1 Relation aus der südöstlichen Körnerstraße
1 Relation aus der nordwestlichen Körnerstraße
Kreuzung Märkischer Ring/Eckeseyer Str./Altenhagener Str./Körnerstr.:
1 Relation aus der Körnerstraße
1 Relation aus der Altenhagener Str.
1 Relation aus der Eckeseyer Str.
1 Relation vom Märkischer Ring
Das ergibt in der Summe also 9 Relationen. Die Kreuzungen haben vermutlich mehr Abbiegebeschränkungsrelationen als Ampelphasenrelationen.
Da die Rollen der Mitglieder jetzt auch die Abbiegerichtung enthalten turn:left, turn:slight_left, … und diese Abbiegewerte dem Spurmapping entstammen, können Router statt zur Ampelphasenschätzung die Relationen auch für Abbiegeanweisungen verwenden.
