Fußgängerampeln als triplet gemappt

Ich weiss nicht wie du das findest wenn du in einem ruhigen Wohngebiet wohnst und mit einem mal der Durchgangsverkehr vom extra ausgebauten höherklassigen Straßennetz bei dir in die Zone 30 verlegt wird :slight_smile:

Flo

Gut, dann habe ich das Problem offenbar falsch verstanden, ich dachte es geht um den Fakt, das die Ampel zusammen mit dem Übergang auf der Straße gemappt wurde, anstatt auf den nicht vorhandenen Bürgersteigen. Weil schließlich beschwerst du dich ja über die routing-penalties, weil dir zu viele Ampeln für deinen Router gemappt wurden.

Am besten mappt man also nicht die Realität, weil alles was mehr als eine Linie und eine logische Ampel pro (Auto-)Kreuzung ist, “das Routing kaputt macht!” Nicht, daß ihr vielleicht mal auf die Idee kommt, daß solche Fälle in den Daten für euch passend zu normalisieren. Und solche Voraufbereitung hat auch, wenn man es gut macht, keine nennenswerten Auswirkungen auf die Laufzeit. Klar ist das erst mal zusätzliche Arbeit, aber ihr könnt euch nicht drauf verlassen, daß alle für immer und ewig “für den Router” mappen. Siehe auch das de-facto-Verbot bei “straßenbegleitenden Wegen” wie Bürgersteigen. Nur das zu dem richtigen Argument, das mehr/detailiertere Daten tendentiell besser sind, weil (automatisiert) wegwerfen/ersetzen kann man immer leicht, man muß es eben dann auch nur machen!

Vielleicht packst du mal die Polemik beiseite. Es geht darum das Angewohnheiten von Mappern, oder falsche Doku, dazu führt das Schrott eingetragen wird der nicht unterscheidbar ist und ein malus im Routing einführt. Dieser Malus führt zu Suboptimalen routen die dazu führen das oft Verkehr in Wohngebiete verlagert wird. Das lässt sich vermeiden indem man das unterlässt und das heile macht. Sowohl in der Doku wie auch in den Daten.

Und niemand hat über Bürgersteige geredet. Dieser thread geht um was anderes.

Und wenn du das nächste mal mit

Solltest du drüber nachdenken wievielen Leuten du mit solchen Aussagen auf die Füße trittst und ihre Arbeit herabwürdigst.

Flo

1 Like

Das ist keine Marotte, sondern detailliertes Mapping. Dass das zunimmt, liegt in der Natur der Sache, da unser Detailgrad stetig zunimmt.

Offenbar treffen hier einfach verschiedene Mapping-Philosophien aufeinander. Die “jüngere” Philosophie setzt da, wo eine Ampel wirksam wird (also an der Haltelinie) einen Node mit highway=traffic_signals plus Richtungsangabe. Daraus resultieren in so einem Fall drei Nodes. Ist seit längerem im Wiki so als (empfohlene) Variante dokumentiert.

Dass die Ampeln dann nicht wissen, falls sie indirekt button_operated sind, ist ein anderes Problem, das eine andere Lösung braucht. Spontan fallen mir drei Möglichkeiten ein: Prozessing vor dem Routing, zusätzliches Tagging oder eine Art Ampel-Relation.

4 Likes

Osmose wünscht sich bei highway=crossing + crossing=traffic_signals auch Ampeln in der Nähe. Bei highway=traffic_signals + crossing=traffic_signals kommt die Meldung natürlich nicht.

2 Likes

Wo ist das als empfohlene Variante dokumentiert?

Ich kenne “Button-Operated” Fußgänger- und Radfahrerübergänge, die so stark frequentiert sind, dass die für Autofahrer fast genau so häufig auf rot stehen, wie klassische Ampeln. Da sehe ich keinen Grund, warum eine Routing-App einen unterschied machen soll. Wahrscheinlich sind einfach die Penaltys pro Ampel zu hoch.
Wie wird das an Straßen gehandhabt, die an jeder Kreuzung, also ca. alle 200m eine Ampel haben? Da gibt es dann 10 Ampeln auf 2km und nur bei einer oder zweien davon steht die dann effektiv auf rot.

1 Like

Das ist doch egal. Sollen die Anwendungen entscheiden. Nur müssen die zwischen einer Füßgängerampel und einem Überweg einer größeren Ampelanlage unterscheiden können.

Ich persönlich bin Detailmapper. Aber ich möchte einen einfachen Ampelübergang mit nur einem Knoten erfassen können und nicht mit drei.

1 Like

Sowohl Ampel-Mapping als Fußgängerüberwegmapping sind einfach noch nicht zu Ende gedacht.

So wie bei den Überwege bis kürzlich noch “continuous” und “informal” als Typen fehlten fehlt es bei den Ampeln ein einem einheitliche Konzept insbesondere auch die zusammengehörigen Ampel zu kennzeichnen. Ich glaube aber nicht daran, dass es eine gute Idee wäre jede Ampelanlage mit zig Relationen zu versehen um damit die Paare, Gruppen und ganze Kreuzungen zu gruppieren. Das wäre unwartbar. Eine einzige Relation für die ganze Anlage kann ich mir hingegen schon vorstellen.

Und was das Routing angeht, weniger ist manchmal mehr - vielleicht die Zeitstrafen für Ampeln einfach weglassen - es bleibt sowieso nur ein großes Raten

2 Likes

Ich halte das für sinnvoll. Die Angabe in der Mitte ist die Information für die Fußgänger, dass es sich um eine Querungsstelle mit Ampel handelt; würde die fehlen, hätte man Probleme mit dem Fußgängerrouting. Die kann beim Auto-Routing ignoriert werden, weil für die Autos separate Ampeln eingetragen sind.

Die anderen beiden hingegen sind die Verkehrszeichen für die Autofahrer - ähnlich wie z.B. Vorfahrt-Beachten-Schilder. Idealerweise steht dort noch ein traffic_signals:direction dabei. Routing für Autofahrer sollte dann nur die von den beiden auswerten, die in die richtige Richtung zeigt, die andere nicht. Damit hat man dann nur eine Ampel beim Autorouting.

Soweit zur Theorie. In der Praxis muss man bei OSM damit rechnen, dass man alles mögliche bekommt. Ein, zwei, drei oder vier Ampeln (sind ja vier vor Ort vorhanden), oder gar einen Zebrastreifen mit Ampeln… Das muss man sinnvoll vorverarbeiten und man wird nie 100% Korrektheit erreichen, daran führt erfahrungsgemäß kein Weg vorbei, egal ob man jetzt routen, rendern oder die Daten wissenschaftlich auswerten will, oder was auch immer sonst noch.

Wenn also eine oder mehrere der drei Ampeln fehlen, kann man sie nicht oder nur eingeschränkt beim Routing berücksichtigen. Das liegt dann einfach daran, dass Informationen fehlen. Wenn eine Ampel bei OSM nicht eingetragen ist, kann man sie ja auch nicht berücksichtigen…

1 Like

Ich weiß nicht, wie es heute aussieht, aber als mich vor einigen Jahren wegen mkgmap mal mit der Idee beschäftigt habe, Ampeln mit irgendeiner penalty zu belegen, da habe ich am Ende entschieden, dass es eher sinnfree ist. Mein Ergebnis damals war, das ein Router alleine aus den Eigenschaften der Straßen an Kreuzungen die durchschittliche Wartezeit abschätzen kann/könnte.
Eine Fußgängerampel gibt es ja meist nur, weil der Verkehr zu bestimmten Zeiten so dicht ist, dass Schulwege als zu gefährlich angesehen werden. Es ist also nicht die Ampel, die die Autos ausbremst, sondern die anderen Autos.

1 Like

Der Punkt ist das bei den Fußgängerampel triplets die HALTELINIEN noch mit einem highway=traffic_signals getagged werden. Es gibt dort keine Ampel. Es gibt einen Galgen über der Fahrbahn.

Zum anderen will ich die Ampeln im Car routing ignorieren - Denn es sind Anforderungsampeln - die habe ich im graphen drin und könnte die beachten.

Wenn ich jetzt 3 Ampeln eintrage wo nur eine ist, und die beiden äusseren als “fake ampeln des KFZ” Verkehrs habe ich eine penalty die nicht existiert.

Flo

Ich fände das auch spannend. Es wäre natürlich Vorraussetzung das die Kreuzung keinerlei Anforderungsschaltung hat - Das ist heute denke ich kaum noch gegeben.

Ansonsten könnte man ja sowas wie ein “traffic_lights:interval=” in sekunden taggen. Dann weiss ich das mein penalty statistisch die hälfte ist. Ich hatte mal überlegt ein kleines Microcontroller basiertes Schächtelchen zu machen was ich einfach via Saugnapf auf irgendeine Ampel Lampe kleben kann das mir das misst, oder sogar via LoRaWan wegmeldet :wink: Klebt man drauf und lässt es mal ein paar Stunden drauf.

Die Näherung die wir jetzt haben ist glaube ich schon ziemlich gut - vorraussetzung ist halt das da kein Schrott eingetragen wird. Wenn man reine Anforderungsampeln die 99% der Zeit Grün sind, als penalty behaftete KFZ regulierende Ampeln einträgt kann es ab da nicht mehr besser werden. Und da diese reinen Fußgängerampeln überwiegend auf den vielbefahrenen Durchgangsstraßen sind, die ich dadurch dann schlechter mache, führt das dazu das der Verkehr in die Wohngebiete gedrängt wird. (Routing technisch)

Flo

Es ist dort keine Ampel. Dort ist eine Haltelinie.

Falsches tag, Fiktive Ampel gemapped.

Dazu ist die unterscheidung im Wiki ziemlich eindeutig - und die hat ihren Grund wie ich hier ja dargelegt habe. Wir brauchen eine Unterscheidung. Und bei OSM ist eben auch “Viel hilft viel” eher kaputt.

Flo

Um es nochmal klarer zu machen - Warum sind das 3 Ampeln? Die ist ohne Anforderung sogar aus wie man hier schön sieht.

https://www.mapillary.com/app/?pKey=1876978735801055

Das stimme ich dir ja zu. Ich bin auch nur für einen Punkt mit allen Infos - den kannst du auch einfach ignorieren.

Eben nicht. Aus meiner Sicht ist es nicht sinnvoll, das Vorhandensein eines Ampel-Knotens mit irgendeiner penalty zu belegen, egal was für eine Ampel. Ob und wo und wie oft der Knoten gemappt ist oder nicht sollte für’s Routing völlig egal sein. Die Kreuzung an sich, die Geometrie und die Klassen der kreuzenden Straßen sind wichtig.
Aber ich hab das nicht studiert und habe auch noch nie einen Router programmiert.
Wenn ich es täte, dann würden Autofahrer wohl bei mir erst mal die Frage gestellt bekommen, ob sie das kurze Stück nicht besser mit dem Rad oder per ÖPNV fahren könnnen :wink:

1 Like

Wir haben bei OSM noch nie “Ampeln” als Objekt gemappt. Es gibt eine handvoll Mapper, die für die Ampelanlagen im physischen Sinne man_made=gantry nutzen (ich glaube, das ist inzwischen sogar irgendwo im Wiki erwähnt), aber das ist derzeit ein Micromapping-Randphänomen. Das hat aber nichts mit highway=traffic_signals zu tun, das ein generalisiertes Tag für die Wirkung der Anlage ist (“Hier ist eine Stelle, an der ich bei rot halten muss”).

Die nördliche umkringelte gibt es noch, gefixt hast du aber weiter südlich: Changeset: 146002292 | OpenStreetMap. Hätte es z.B. bei Node History: 6425317889 | OpenStreetMap nicht gereicht, zunächst mal “direction” durch das korrekte “traffic_signals:direction” zu ersetzen? Oder spielt das keine Rolle?

Das Problem ist doch, das highway=traffic_signals für verschiedene Dinge verwendet wird

  • für ganze Ampelanlagen (auf dem Kreuzungsknoten von Straßen)
  • für die Haltepunkte an Ampeln (dann hoffentlich mit forward/backward-Angabe)
  • und vermutlich auch gelegentlich für einzelne Ampelmasten

Sinnvoll wäre es für diese 3 Dinge verschiedene Tags zu haben.

2 Likes