Moin!
folgendes ist mir in Viernheim aufgefallen:
Es werden die Nodes für den Fussübergang gemappt mit dem Tag der Ampel und danneben auch noch die Nodes für die Ampelstandpunkte selber.
Ich spreche hierbei nicht von Kreuzungen, sondern nur von Fussgängerüberwegen, wie Node: 3694231560 | OpenStreetMap
Ist das richtig oder sind die Ampel-Nodes damit überflüssig - bekannt ist mir “wir mappen nicht für den Renderer”.
Gruß Jan
Steht doch genau so im Wiki: DE:Tag:highway=traffic_signals - OpenStreetMap Wiki (4. Beispiel, Fußgängerüberweg(e) separat gemappt). Wird sogar so empfohlen, siehe Zeile drüber. Sollte man also so machen, muss man aber nicht.
Wo siehst du hier Mapping für den Renderer (also sachlich falsch mappen, um eine bestimmte Kartendarstellung zu erzwingen)?
Renderer-Mappen - Darstellung der Ampeln
Jan
Ampel 2 und Ampel 1 stehen an den Haltelinien des Autoverkehrs und wirken jeweils nur in die Richtung aus dem dieser kommt.
Für mich sieht das nach Tagging wie er vor Ort tatsächlich entspricht.
Es ist ja okay etwas zu mappen, damit der Renderer es darstellen kann. Kritisch ist das mappen von falschen Dingen, damit der Renderer es wie gewünscht darstellt 
Es hängt wohl davon ab, welchen Abschnitt im Wiki (DE:Tag:highway=traffic_signals - OpenStreetMap Wiki) man tatsächlich zur Bewertung heranzieht:
Die Formulierung “wird stattdessen” suggeriert klar, dass bei einfachen Fußgängerampeln keine hw=traffice_signals gesetzt werden. Ich kenne das auch eher so. Ich würde das Mappen der Ampeln allerdings auch nicht als falsch bezeichnen.
Ich verstehe die Diskussion nicht.
Das Wiki führt (in der Tabelle mit den Mappingbeispielen) für reine Fußgängerampeln (durchgehende Straße ohne Einmündung) zwei Möglichkeiten an und empfiehlt die zweite. Und das ist genau die, die hier diskutiert wird - Straßenampeln (highway=traffic_signals) und Fußgängerampel (crossing=traffic_signals) auf drei unterschiedlichen Nodes.
Damit ist die Sache doch klar, oder?
Das Wiki ist ja auch nicht immer perfekt und braucht manchmal noch etwas Finetuning.
Ich halte die Darstellung mit 3 Punkten zwar für richtig aber in den meisten Fällen für übertrieben. (siehe Abschnitt den @limes11 erwähnt hat, aber auf Kreuzungen und nicht für Übergänge abzielt)
Die Haltelinien sind nun mal ein paar Meter rechts und links neben dem Übergang und ich finde auf ein paar Meter kommt es da auch nicht an. Wenn die Positionen davon besonders abweichen, dann sind 3 Punkte notwendig.
Nur ein highway=crossing + crossing=traffic_signals ist allerdings zu wenig, da ich nun nicht weiß ob die Autos an der Stelle halten müssen oder ob für sie irgendwo eine extra Ampel erfasst ist.
Ich bevorzuge daher die JOSM-Variante mit nur einem Knoten
highway=traffic_signals
crossing=traffic_signals
traffic_signals=pedestrian_crossing/on_demand
button_operated=yes/only (Meist ist ja nur per Knopfdruck für Fußgänger grün zu bekommen)
Damit ist klar das hier eine Ampel für Fahrzeuge und eine Querungsmöglichkeit mit Ampel für Fußgänger vorhanden ist.
Bei drei Knoten wäre es dann für die Ampeln
highway=traffic_signals
crossing=no (falls Fußwege nicht separat erfasst sind)
und für den Übergang
highway=crossing
crossing=traffic_signals
button_operated=yes/only
Stimmt, es ist für mich an dieser Stelle etwas zu JOSM-lastig bebildert, im iD sieht es zum Beispiel so aus:
crossing=* ohne highway=crossing ist für mich nicht ganz so vollständig, daher bevorzuge ich die 3-Knoten-Variante, bei der es folgenden Zuordnungen gibt:
1x highway=crossing + crossing=traffic_signals (Fußgängerampel)
2x highway=traffic_signals + traffic_signals=pedestrian_crossing (Straßenampeln)
Hallo,
meine Version bei Fußgängerampeln also Haltelinien direkt am Übergang.
>1Node> Fußgängerampel:
crossing=traffic_signals
highway=crossing
1Node> Fahrzeugampel:(knapp neben den Fußgängernode gesetzt)
highway=traffic_signals
traffic_signals=signal
traffic_signals:direction=both
Gruß
Danfost
Ich bin der Meinung: Ein Node mit Hinweis auf die Ampel gehört entweder auf den Kreuzungspunkt oder auf die jeweilige Haltelinie mit Richtungsangabe, d.h. an die Stelle, wo die Ampel wirkt und in welche Richtung sie wirkt.
Ich würde nie beides eintragen, da dies suggeriert, es gebe kurz hintereinander zwei Ampeln.
Beispiel:Node: 2872971475 | OpenStreetMap
Die Information, dass es sich bei der Ampel um eine Fußgängerampel handelt, steht bei dem jeweils an der Haltelinie eingezeichneten Ampel-Node:
highway=traffic_signals
traffic_signals=pedestrian_crossing
traffic_signals:direction=forward
Die darüber hinausgehenden Infos wie die Art der Markierung, ob Blindenleitsystem vorhanden ist, … habe ich an der als Linie eingezeichneten Fußgängerquerung eingetragen. Das ist ja auch nur eine Information für die Fußgänger und nicht für die PKW. Für die PKW reicht ein Ampelnode an der Stelle, wo sie anhalten müssen mit dem Hinweis, dass es sich hierbei um eine Fußgängerampel handelt. Diese Information zusätzlich noch einmal an den Kreuzungspunkt zu pappen, halte ich für falsch. Entweder Detailmapping oder Erfassung auf dem Kreuzungspunkt, niemals beides.
Sehe ich im Grunde auch so, funktioniert aber nur, wenn der Fußgängerüberweg als separater Weg erfasst wurde. Und das ist beim Großteil der Wege eben nicht der Fall. Insgesamt ist mir schon sehr oft aufgefallen, dass unser Ampel-Mapping sehr widersprüchlich ist. Als Quelle hab ich mich damals https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#How_to_map_(new) bedient, aber selbst dort stehen ja beide Varianten drin. Und das Problem
hat mich dazu gebracht, es genau so zu taggen, wie von JOSM beschrieben, bis sich irgendwann mal jemand ein Herz fasst und das mal sinnvoller definiert. Bis dahin lebe ich damit, dass die meisten Ampeln vermutlich von Routern ignoriert werden, weil die auch nur raten können, für wen die überhaupt wann gilt.
Meine Meinung dazu: Wenn ein Fußgängerüberweg nicht als separater Weg erfasst ist, sollte man auch darauf verzichten, die Ampeln als einzelne Nodes an den Haltelinien zu erfassen. Man sollte sich entweder für ein pauschales mapping alles in einem Punkt, in dem Fall dann dem Kreuzungspunkt, entscheiden oder für ein detaillierteres Mapping mit Erfassen der einzelnen Ampeln an den jeweiligen Haltelinien und des Fußgängerüberwegs als Linie.
Da setze ich noch einen drauf: An der Haltelinie ist gar keine Ampel. Eigentlich erfassen wir traffic_signals als Wirkfunktion und nicht als physikalisches Objekt.
Aus meiner Sicht wäre hier an den Haltelininien ein DE:Tag:road_marking=solid_stop_line - OpenStreetMap Wiki angebracht - wenn man schon so genau sein will.
Sollte man auch den Ampelmast (bzw. den physikalischen Ort der Lichtzeichenanlage und/oder den Knopf, auf den der Fußgänger drücken muss) erfassen wollen, dann würde man dafür ein eigenes (anderes) Tag benötigen. Den Vorschlag “Ampelmast” gab es schon einmal (von wegen “3D-Tagging und superrealistisches OSM”) - offenbar gibt es aber zu wenige, die das für nötig/sinnvoll/wartbar oder was auch immer halten. Mich eingeschlossen.
Genau so ist es.
Wir “malen” Ampeln nicht dort hin, wo der Mast steht oder wo der Kasten mit den bunten Lichtlein herumhängt sondern dort, wo er wirkt. Das ist dann bei Fußgängerampeln der Bordstein und bei Fahrzeugen die aufgemalte Haltelinie. Etwas anderes halte ich ebenso wie Du für nicht sinnvoll.
Gerade bei Fußgängerampeln ist das rote Licht in der Regel auf der gegenüberliegenden Straßenseite angebracht. Wir erfassen es aber dort, wo man stehen bleiben muss, wenn es leuchtet.
Wozu erfasst man dann noch 2 Ampeln? An den Stellen wo man warten muss sind die Bordsteine bzw. dort beginnt die Linie für den Übergang. Die Ampelinformation reicht theoretisch an der Linie mit footway=crossing.
Ich halte die Information an der Linie für zu unpräzise. Es gibt z.B. Fußgängerübergänge mit Mittelinsel, bei der es aber nur ein für die gesammten Übergang geltendes Lichtzeichen gibt und es gibt welche, bei der es auf der Mittelinsel noch ein weiteres Lichtzeichen gibt.
Auch bei Bordsteinen ist es ja durchaus sinnvoll, diese Information nicht an die Linie zu schreiben sondern als Punkt dort, wo die Überweg-Linie auf den Bordstein trifft. Es gibt ja leider genügend Übergänge, bei der beide Seiten baulich unterschiedlich sind, auf der einen Seite ein abgesenkter Bordstein, auf der anderen gar kein Bordstein, …
Wenn man schon einen Fußgängerübergang als eigene Linie einzeichnet, sollte man meines Erachtens auch diese Informationen an der Stelle eintragen, wo sie “wirken”.
Gegen die Bordsteinpunkte habe ich auch gar nichts gesagt. Sie sind beim Detailmappen genau da wo die Überganslinie endet. Mit der Mehrteiligkeit der Ampel stimme ich dir zu, dass lässt sich so lösen.
Bei Radampeln ist mir oft aufgefallen, dass ich die Ampel nicht an die Postition der Haltelinie zeichnen kann. Radfahrer müssen meist etwas weiter vom Bordstein halten, damit sie den Fußgängern nicht im Wege stehen. Wenn es dann Möglichkeiten zum Abbiegen gibt, dann ist nicht klar, für welchen Übergang die Ampel gilt.
Insgesamt fehlt auch eine Möglichkeit dem highway=traffic_signals mitzuteilen was es eigentlich genau ist bzw. auf wen sie wirkt.
Die traffic_signals-Werte beziehen nach meinem Verständnis alle nur auf die Ampel für die Autofahrbahn.
Ich wäre ja froh wenn die Übergänge in der Fläche erstmal routingfähig erfasst wären und nicht z.B. sowas, wo insbesondere die Wege für die Übergänge fehlen.
Oft genug sieht man separat erfasste Geh- oder Radwege und Straßen mit foot/bicycle= use_sidepath aber dann kein Übergänge eingezeichnet um die Straße queren zu können.
Ich befürchte, dass Du mich da etwas missverstehst. Ich meinte das abstrakter. Mir reicht ein Wirkpunkt am (von der Sache her ja selbst schon abstrakten) Straßenlinienkreuzungspunkt. Sonst bräuchte ich an einem simplen Fußgängerüberweg bereits vier Ampeln (beidseits der Straße je an der Bordsteinkante des Fußweges und beidseits an der Straße an den Haltelinien. Mein Ansatz wäre, dass es genau eine Ampel am Kreuzungspunkt geben soll und die vier anderen “Haltepunkte” von wem auch immer andersartig (siehe oben) erfasst werden dürfen. Von mir aus auch sehr detailliert. Aber eben nicht als Ampelhaufen, den Router/Kartenersteller nicht mehr auswerten oder mühsam vereinfachen/missinterpretieren 
