Separates Mappen von Ampeln für Fußgänger

Communities Deutschland (Germany)
1

Hallo ins Forum,

Das Changeset Changeset: 175084587 | OpenStreetMap von @Mah hat in einem scheinbar automatisierten Edit von mir eingetragene Ampeln für den Fußverkehr gelöscht, weil diese nicht standardkonform seien. Auf Nachfrage wurde seitens des Autors noch nicht reagiert, jedoch möchte ich auch in Hinblick auf einen potentiellen Revert die Meinung der Community einholen, ob diese Änderung begründet ist.

An Ampelkreuzungen gibt es sowohl Ampeln für den Fahrverkehr wie auch Ampeln für die Fußgänger. Die einfache Mappingvariante setzt ein einzelnes highway=traffic_signals auf den Kreuzungspunkt der beiden Straßen; sobald im Zuge des separaten Gehwegmappings auch Fußgängerüberwege separat gezeichnet sind, wird die Ampel für den Fahrverkehr an die Haltelinie gesetzt und auf den Kreuzungspunkt mit dem Fußgängerüberweg highway=crossing + crossing=traffic_signals gesetzt (Tag:highway=traffic_signals - OpenStreetMap Wiki):

If the traffic signal is not separately mapped, the node that is the actual crossing between the road and highway=footway/pedestrian should be tagged with highway=crossing + crossing=traffic_signals.

Die logische Fortsetzung, die auch im Wiki erwähnt wird (siehe obige fette Markierung), mappt auch die Ampeln für den Fußverkehr separat. Der erste, der das macht, bin ich nicht, z.B. hat schon @Galbinus 2018 diese Variante vorgeschlagen: Ampelgesteuerter Fußgängerüberweg - wie viele Ampeln mappen? - #9 by Galbinus

Die Ampeln für den Fußverkehr mappe ich an der Bordsteinkante (nicht an der Mastposition) mit entsprechendem traffic_signals:direction und traffic_signals=pedestrian, was die übliche Rot/Grün-Ampel mit Mensch bezeichnet:

Ampelmann_rot
Ampelmann_rot150×221 6.67 KB

im Unterschied zu traffic_signals=pedestrian_crossing, das eine Autoampel bezeichnet, die nur für einen Fußgängerüberweg auf rot geschaltet wird.

In OSM sieht das z.B. so aus: Node: 13289913659 | OpenStreetMap
Mancherorts wird der Radverkehr ebenfalls über die gleiche Ampel gesteuert, wofür eine kombinierte Streuscheibe mit Fahrradsymbol eingesetzt wird, wofür ich das Tag traffic_signals=pedestrian_with_bicycle verwende:

Ampel_2x_rot
Ampel_2x_rot730×1061 214 KB

In OSM: Node: 13289913658 | OpenStreetMap
Zusätzlich wird der Fußgängerüberweg zwischen den Bordsteinkanten natürlich auch als solcher gemappt, mit der Information, dass der Überweg signalisiert ist. Das Ampelmapping in dieser Art erlaubt die Unterscheidung in dem Falle, dass die Anlagen an den beiden Enden verschiedene Ausstattung (Taster/Tonsignal/Streuscheibe) haben. Dies betrifft insbesondere den Radverkehr, da sich aus den Streuscheiben eine unterschiedliche rechtliche Bewertung ergibt.

Vor diesem Hintergrund möchte ich nun die Frage an die Community stellen, ob und inwieweit dieses Detailmapping fachlich richtig ist, um in der Sache eine Entscheidung zu ermöglichen, die zukünftige Konflikte vermeidet.

Rechtfertigt die Berufung auf Standardkonformität das Löschen von Einträgen, die in dieser vorgestellten Art erstellt wurden?

2

Zum Thema Ampel-nodes: imho K.I.S.S. (Bsp.-Standard-Ampelkreuzung) :

image
image569×497 30.5 KB

3 Likes
3

Danke @Jofban dass du dieses Thema ansprichst. Das Wiki zu Ampeln ist leider nicht schlüssig und man kann mit dem “klassischen, einfachen” Mapping nicht immer alle Informationen darstellen. Ich hatte das Thema bei Radwegen und Rechtsabbiegen bei Rot. Ich habe dort nur die Ampeln (highway=traffic_signals) ohne traffic_signals=* eingetragen.

Zu deinen Fragen:

  • Löschen sollte man das nicht. Es ist nichts falsches gemappt.
  • Bezüglich der Werte für traffic_signal=* müsste man das ganze komplett neu durchdenken. Du fügst mit “pedestrian_with_bicycle” einen weiteren Tag zu einem Durcheinander hinzu. Das ist nicht optimal. Aber ad hoc fällt mir auch nichts besseres ein. Evtl. “traffic_signals=crossing” und foot=yes und bicycle=yes?
4

sehe ich auch so, insbesondere scheint es aufgrund der Präfixes auch keine Kollisionen mit etablierteren Taggingmethoden zu geben, insofern ist es kritisch, einfach die Experimente anderer zu löschen. OSM lebt davon, dass man was neues ausprobieren kann, solange das kompatibel mit den etablierten Mappingmethoden ist, sollte man das zumindest tolerieren.

1 Like
5

Ich fände es sehr wünschenswert, wenn wir mal ein sinnvolles Ampel-Tagging bekämen. Im Wiki und in der Praxis finde ich viele, sich teilweise widersprechende, Varianten. Aber Löschen ist sicher keine Lösung, jedenfalls nicht, ohne vorher anzuschreiben.

4 Likes
6

Danke für die Antworten bis hierher.

Zusammengefasst lässt sich sagen, dass der bisherige Standard unzureichend ist. Ob meine Erweiterung der richtige Weg ist, darüber lässt sich reden. Aber eben genau das: Reden. Einfach Löschen ist definitiv der falsche Weg.

Da sich @Mah weiterhin nicht beteiligt, werde ich angesichts des klaren Lagebilds das Changeset in den nächsten Tagen reverten.

7

Mir scheint, dass die Ampeln nur einen kleinen Teil des beanstandeten Changesets ausmachen, vielliecht kannst Du Deinen Revert auf die Ampeln beschränken und nicht alles rückgängig machen. Ausserdem könntest Du dem Benutzer @Mah, der seit dem beanstandeten Edit nicht aktiv war, auch etwas mehr Zeit geben, es sind noch nicht einmal 2 Tage seit Deinem Changeset-Kommentar vorbei, da ist es vielleicht etwas hart, von “reagiert weiterhin nicht” zu sprechen. Es gibt auch Menschen, die zwischendurch mal was anderes machen als OSM ;)

2 Likes
8

Eigene nicht dokumentierte Tags finde ich problematisch. Da verstehst hinterher nur du, was damit genau gemeint ist.

Es ist nicht übrigens einmal klar was traffic_signals=pedestrian_crossing genau bedeutet das wird zwar erwähnt, aber nirgends genau definiert:

  • meint es die einzelnen Lichtsignale für die Fußgänger (also dieses Signal gilt nur für Fußgänger)
    -     oder meint es eine ganze Ampelanlage wo nur Fußgänger eine Straße queren (meinst Bedarfsampel an der Autofahrer nur warten müssen wenn Fußgänger sich grün einfordern).

Ich bin im übrigen auch kein Fan von der Erfassung der einzelnen Ampelmasten für Fußgänger.

9

Es gibt noch ein paar kleine objektive Fehler, wegen denen ich aber nicht unbedingt reverten würde; der Rest scheint nach meiner Durchsicht eher QoL zu sein (Straßenverlauf und Landuses angepasst). Insofern ist die Frage, ob ich mir die Mühe mache, das rauszufiltern. Letztlich hab ich nichts kaputtgemacht.

Mein Plan war es eh, den Revert am Montag zu machen, da liegt noch das ganze Wochenende dazwischen. Bis dahin überleg ich mir auch was wegen obiger Frage.

Zitat aus Key:traffic_signals - OpenStreetMap Wiki

A traffic light that only turns red to let pedestrians cross – and also in use for highway=crossing + crossing=traffic_signals to indicate the traffic signals for pedestrians. That means it has two different meanings depending on the context.

Die Bedeutung im Kontext dieses Threads ist hervorgehoben. Es bezieht sich auf die Ampel für den Fahrverkehr, der mittels eines Rotsignals gestoppt wird, um dem Fußverkehr das Queren zu ermöglichen.

Ich weiß nicht, was Ampelmasten mit diesem Thread zu haben, da keine Ampelmasten gemappt wurden? Bitte drück dich sorgfältiger aus.

10

O.K. Ich muss zugeben, dass ich deinen Betrag nicht genau genug gelesen hatte.

Ich finde gut, dass du nicht pedestrian_crossing für die Wartepositionen verwenden möchtest, auch wenn es laut Wiki anscheinend öfters so verwendet wird. Die von dir vorgeschlagenen Werte machen da schon mehr Sinn und das Schema scheint mir soweit in sich schlüssig.

Dennoch erschließt sich mir nicht der Mehrwert des Einzel-Fußgängerampel-Mappings. Lediglich bei getrennten Fahrbahnen mit Mittelinsel, die keine eigene Ampel aufweist, würde ich einen Mehrwehrt sehen.

An welchem Objekt würdest du button_operated anbringen? An der Warteposition (traffic_signal-node) oder am crossing-way? Die Kerb-Eigenschaften kommen mit an die Ampel-Position?

1 Like
11

Ein Teil dessen ist wohl einfach Gewohnheit; wenn ich es immer mache, brauch ich mir keine Gedanken machen, ob es in diesem speziellen Fall notwendig wäre oder nicht.

Ein zweiter Teil ist der geringe zusätzliche Aufwand für mich. Aufgrund der unterschiedlichen surface splitte ich den Überweg sowieso vom Bürgersteig. Da ich auch Bordsteinkanten mappe (als separate Linie), habe ich die Begrenzung schon automatisch. Und damit auch 2 Punkte für die Wartepositionen.

Und der dritte Teil ist das leichtere Mapping, denn so kann ich jede Ampel einzeln abarbeiten.
Ich sehe also eine Warteposition. Kann ich die Ampel irgendwie beeinflussen, z.B. über einen Knopf (=button_operated)? Gibt es Signale, wie ich die Warteposition finden kann, oder eines, das mir sagt, dass ich gehen kann (traffic_signals:sound und traffic_signals:vibration)? …

… Das alles sind letztlich Features des Wartebereichs. Die Streuscheibe kommt dann ins Spiel, um zu sagen, für wen der Wartebereich gilt; bei reinen Fußgängerampeln muss der Radverkehr nicht warten.
Wenn ich so drüber nachdenke, ist die Streuscheibe eigentlich ein Hinweis darauf, für wen der Überweg gilt; denn für Radverkehr existiert der Überweg nicht (es ergeben sich weder Rechte wie Bevorzugung noch Pflichten wie warten). Insofern gehört diese Information an den Überweg und gar nicht an das highway=traffic_signal.

Wenn man den Bordstein als Knoten mappt, ist die Position identisch. Ob man da einen extra Node für erstellt, sei mal dahingestellt.
Ich selbst umgehe das Problem dadurch, dass ich den Bordstein linear zeichne (mit highway=traffic_signal an einem der Knoten). Die angrenzenden Ways mit barrier=kerb liefern dann die gewünschte Information.

12

Ich bin auch stark dafür, foot=yes sowie bicycle=yes ggf mit motor_vehicle=no zu taggen. Wer will schon irgendwann ein traffic_signal=pedestrian_with_bicycle_horse_and_mofa?

In den Vorlagen von Vespucci ist das mit bicycle=yes schon umgesetzt. Ich dachte auch, dass das manche Router auch auswerten, finde es aber gerade nicht.

Screenshot_20251128_215959_Vespucci
Screenshot_20251128_215959_Vespucci1080×935 119 KB

Screenshot_20251128_220007_Vespucci
Screenshot_20251128_220007_Vespucci1080×781 140 KB

(Die zweite Zeile ist traffic_signals:direction)

13

Ich glaub mich an eine Diskussion zu erinnern: Wenn ein Weg einen Knoten mit einem Zaun teilt, dann fragt die Qualitätssicherung, was für eine Öffnung dort ist. Wenn die Barriere kein Zaun, sondern einen Bordsteinkante ist erübrigt sich das?

Zweite Frage: Wie gehen Router damit um, wenn ein Weg eine Barriere schneidet und der gemeinsame Knoten (sofern es überhaupt einen gibt) keine Hinweise drauf liefert? Bekommt ein Router das überhaupt mit? Der muss dazu ja bei jedem Knoten schauen ob der nicht Teil irgend eines andren “Wegs” ist und welcher Art …

1 Like
14

Ich bin stark dagegen, hier wieder access-Tags zu missbrauchen…

3 Likes
15

Die Frage würde ich grundsätzlich bejahen, da die Bordsteinkante gewöhnlich keine “Öffnungen” hat (oft ist der Bordstein abgesenkt und sehr niedrig, aber weg ist er nicht). Insofern wäre die Parallele zum Zaun, dass man ja über den Zaun klettern kann, wenn man dort lang möchte - da hört es aber schon auf, weil eine Bordsteinkante konstruktionsgemäß leichter überwindbar ist, während ein Zaun ein tendenziell unüberwindliches Hindernis darstellt.

Hier muss also die Qualitätssicherung anhand der Barriere entscheiden, wie wahrscheinlich dort eine Öffnung ist oder nicht. Bei Bordsteinkanten könnte man nach der Höhe fragen.

Ja, die Art ist nicht unbedingt routerfreundlich, aber die Info ist da. Im Zweifel ist das ein weiterer Preprocessing-Schritt.

Interessant, das wusste ich nicht. Steht das in der Wiki irgendwo?

Nach einer kurzen Overpassabfrage wird ersichtlich, dass das Konzept nicht unbedingt jeder verstanden hat (oder sich mit was anderem überschneidet) - Die Ampel Node: 1327200462 | OpenStreetMap ist äußerst unwahrscheinlich mit dem Radverkehr kombiniert, und auch die anderen Vorkommnisse (z.B. Node: 743371179 | OpenStreetMap) sind zweifelhaft, da nichtmal mit den separaten Radwegen verbunden. Mapillary zeigt in beiden Fällen eine einfache Fußgängerampel.

16

Eh, es gibt da locker fünf verschiedene Werte um genau das zu erfassen, damit man eben nicht auf gut Glück. Gerade bei den Übergängen unterscheiden sich die regelmäßig vom Rest der Kante.

17

Ja, davon sollten wir wirklich wieder weg. Aber vermutlich ist dieser train=yes bereits abgefahren :frowning: