An den meisten Ampeln gibt es ja Schilder, die den Verkehr regeln, wenn die Ampel mal ausfallen sollte. Also Stop-Schilder, Vorfahrt-beachten-Schilder und Vorfahrts-Schilder. Sollte man die auch mappen, und wenn ja wie? (Ich gehe von separaten Knoten für alle Ampeln aus, nicht einer Ampel auf der Mitte der Kreuzung.)
Lösung 1: Auf dem gleichen Knoten, wie die Ampel mappen. Das wäre konsistent, geht aber nicht, weil ja dann highway=traffic_signals und highway=stop gesetzt sein müsste.
Lösung 2: Separat mappen. Das verursacht aber Probleme bei Routing-Software, die jetzt nicht mehr entscheiden kann, was für Regeln jetzt an der Kreuzung gelten. Könnte ja auch sein, dass die Ampel nur für eine vorgeschaltete Fußgänger-Überquerung gedacht ist, und die Kreuzung anders geregelt ist.
Lösung 3: Nicht mappen. Dann fehlt die Info dummerweise…
Was meint ihr? Gibt es dazu schon Lösungen? Ich hab’ im Wiki nichts gefunden, aber auch nicht sehr ausführlich gesucht…
Wieso soll diese Info denn in die Datenbank? Es steht ja auch nicht drinnen, wann die Ampel auf grün springt und erst Recht kann keine Routing- oder Navi-App wissen, ob die Ampel ausgefallen ist. Was würde diese Info also bringen? Sollen App-Entwickler zukünftig einen Button einbauen, den man anklickt, wenn die Ampel ausgefallen ist und dann anzeigen, welches Verkehrsschild an der Ampel hängt? Wohl kaum, weil in dem Moment, wo ich sehe, dass die Ampel ausgeschaltet ist, sehe ich auch die Verkehrsschilder, die dann statt dessen gelten. Oder soll eine Navi-App zukünftig beide Infos anzeigen (“wenn Ampel ausgefallen Vorfahrt gewähren”)? Halte ich auch für sinnfrei und eher ablenkend.
Wofür sonst soll also diese Info in die Datenbank?
Klingt sinnvoll, ist aber derzeit kein gültiger Wert…
Naja, nicht jeder Routing-Algorithmus sitzt in einem Navi. Beispielsweise versuche ich mich gerade in Verkehrsplanung, da möchte ich diverse “was-wäre-wenn”-Fragestellungen evaluieren. Für das, was ich machen möchte, sind diese Infos tatsächlich nicht wichtig, weshalb ich sie vermutlich aus Faulheit heraus auch einfach nicht mappe. War mehr so eine Neugier-Frage. Dennoch: Ich könnte mir auch vorstellen, dass man prüfen will, was wäre, wenn die Ampeln einer Stadt alle ausfallen. Dafür wäre die Info dann doch hilfreich.
Naja, ist halt was, was da ist und dann halte ich es schon für sinnvoll es zu mappen; wer weiß, wozu man es mal gebrauchen kann… Anders als Grünphasen rennen solche Verkehrszeichen ja auch nicht weg.
Das halte ich doch für ein sehr konstruiertes Beispiel. Dazu müssten alle Ampeln mit einer Genauigkeit eingetragen werden, die bislang überhaupt noch nicht erdacht ist, geschweige denn umgesetzt.
Ich möchte mal ein weiteres Gegenargument bringen: Um so mehr Infos man an eine Ampel drannpappt, um so fehleranfälliger und wartungsunfreundlicher wird ein solcher Ampelnode.
Verstehe ich zwar nicht, warum man das müsste, aber mir ging es auch gar nicht um die Details. Es ist meiner Erfahrung nach nur so, dass man vorher nicht unbedingt weiß, wozu die Dinge gut sind, die man mappt. Ich erinnere mich noch an Diskussionen aus meiner Anfangszeit (so 2007 rum müsste das gewesen sein), da hieß es, dass man Sackgassen und Verkehrsschilder nicht braucht. Für sowas, wie Leerungszeiten eines Briefkastens hätte man damals auch keine Mehrheit bekommen. Die meisten haben nur an die Karte gedacht. Selbst Routing als Anwendung musste man den Leuten immer wieder ins Gedächtnis rufen. Inzwischen denke ich, man sollte halt mappen, was da ist; was dann später draus wird, kann man jetzt noch nicht wissen.
Das stimmt natürlich schon. Ich hab’ ja auch erst mal nicht vor, diese Info zu mappen. Ich hatte mich nur gewundert; mir ist das halt aufgefallen, weil ich heute einen Stop-Schild-Knoten durch einen Ampel-Knoten ersetzt habe. Normalerweise versuche ich, Informationen, die andere beigetragen haben, zu erhalten (es sei denn sie sind ganz klar falsch). In dem Fall ging das nicht und dadurch kam dann die Frage auf.
genau, es geht beim Erfassen der Daten nicht nur darum, ein Navigationsgerät damit zu füttern um eine ideale Route zu finden. Auch an anderer Stelle gibt es solche Auslassungen, die dazu führen dass unsere Daten für bestimmte Anwendungsfälle nicht so gut zu benutzen sind, z.B. fehlende Abbiegebeschränkungen an Einmündungen (die Art dass es 4 oneways werden), wo manche Mapper sich denken „die Linksfahrenpflicht auf dem linken link kann ich auch weglassen, der Weg links rum ist sowieso länger als rechts rum wenn man rechts abbiegen will“.
Hm… Finde ich persönlich schwierig. Denn so stellt man Daten falsch dar. Die wirken ja zusammen auf einem Knoten.
Effektiv sagt man einem Router hier → Berechne zweimal einen Malus für Verkehrszeichen und Lichtsignalanlage.
Das sehe ich genauso. Wenn man das wollte, müsste irgendwie (z.B. über conditional) klargemacht werden, dass das Verkehrsschild nur gilt, wenn die Ampel defekt oder ausgeschaltet ist.
und wenn kein Polizist die Kreuzung regelt. An wichtigen Kreuzungen wird der Verkehr bei Ampelausfall sowieso durch Personal „kompensiert“. Bei unwichtigen Kreuzungen wird die Ampel dagegen oft nachts grundsätzlich ausgeschaltet, einerseits werden die Schilder dadurch wichtiger, weil sie oft in Kraft treten, andererseits ist dort dann kaum mit Einschränkungen zu rechnen auch wenn man keine Vorfahrt hat, weil sowieso keiner kommt. Von daher spricht zwar nichts gegen eine Erfassung dieser Schilder, sollte aber auch vermieden werden, dass es zu doppeltem Malus kommt, das muss also als Eigenschaft zur Ampel und nicht als eigenständiges Objekt.
Mal den Teufel nicht an die Wand!
Ich sehe vor meinem inneren Auge schon deutlich die Diskussionen um ein Taggingschema für Ampelschaltpläne …
Bei Ampeln mit Nachtabschaltung wäre das für ein live-Routing theoretisch möglich …
Rechtlich gesehen wird das Vorfahrtsschild nur dann wirksam aufgehoben, wenn es am Ampelmast hängt.
Paar Meter davor oder danach stehend gilt es eigentlich zusätzlich zur Ampel …
Daher muss es von der Theorie her auch an den selben OSM-Knoten und dann wäre es auch kein Problem für das Navi, denn das “doppelte” tagging ist dann leicht erkennbar und korrekt auszuwerten “Vz gilt nur wenn Ampel tot”.
Die traffic_sign-Variante kollidiert auch nicht mit den Ampel-tags und traffic_sign reicht für diesen Fall auch völlig aus m.E. …
Das mit vorhandenen 2 Knoten hatte ich tw. beim kürzlich umgemappten Knoten, muss ich bei Muße noch ändern …
Habe hier auch einige Ampeln mit opening_hours=*. Es zeigt sich mal wieder, dass unsere Welt nicht so geradlinig ihre Runden dreht und der Schlingerkurs so einige Besonderheiten mit sich bringt.
Auf jeden Fall, sollte ein gemeinsamer Knoten verwendet werden, um den Bezug zu bewahren. Die Vorschläge mit traffic_sign=* und highway:conditional=* fand ich noch am überzeugendsten.
Das priority_road=* hakt spätestens mit dem Wert end, da Linien geteilt werden können. Um das korrekt abzubilden bräuchte es eine Relation mit “from” und “to” Knoten und dazwischen “via” Linien.
