search

eclipse-sumo / sumo

Eclipse SUMO is an open source, highly portable, microscopic and continuous traffic simulation package designed to handle large networks. It allows for intermodal simulation including pedestrians and comes with a large set of tools for scenario creation.
https://eclipse.dev/sumo
Eclipse Public License 2.0
2.57k stars 1.44k forks source link

tls-discard-simple #5953

Open ambuehll opened 5 years ago

ambuehll commented 5 years ago

image

Difference between the two figures is setting tls-discard-simple to false/true. The intersection is not a geometry-like intersection, imo. Files Sumo 1.3

namdre commented 5 years ago

this is what the raw input looks like (unjoined): grafik

Since the souther approach has no signal, the heuristic of tls.guess-signals fails. consequently the other three signals are treated as 'simple' and removed. Due to geometry.remove, the simple junctions are then removed as well.

If you set tls.discard-simple=false, then the tls are kept. They are treated with junctions.join and since the whole junction gets a tls if any of the constituent nodes had a tls, the new junction cluster_1776577161_4372178937_4372178939 is tls controlled.

Since the whole point of discard-simple is to avoid building traffic lights if only one arm has a controlled pedestrian crossing, i'd say things are working as intended.

However, I see the possibility of improving the guess-signals heuristic. In reality, the intersection is controlled but the southern arm is a residential road with a gate and that's why it didn't get a signal. If this is a common occurence it could be worth handling it.

ambuehll commented 5 years ago

Thanks for the quick reply as always! Makes sense, I forgot about geometry-remove. It is not an uncommon issue. I updated the toy network and identified several intersections where similar handling takes place. E.g. edge_id: -141096646#0 439041976#13 161464882#1 15807345#4 15807139#1

One thing that makes this more complicated than previously reported is that OSM doesn't have a standardized way of reporting tls. Sometimes it's one signal per intersection, and sometimes every signal head is marked. In addition, the signal heads are placed at their exact location, far upstream of the intersection. I see two solutions:

  1. "Snap" the OSM-signals to the closest intersection (with a certain threshold). This would avoid the creation of short edges which consequently result in a simple tls.
  2. Join the signals before the evaluation of simple-tls. If a signal is joined, then it should not be treated with simple-tls.

All in all the two solutions above are just suggestions. This is not a pressing issue since setting tls-discard-simple to true works fine for me and creates relatively little problems (most of the simple tls are indeed ped-xings).

namdre commented 5 years ago

The option tls.guess-signals does just that: It snaps signals to the next "real" downstream intersection when they are within a certain distance. However, it requires all arms to have such a signal before recognizing the intersection as controlled. Idee 2 sounds feasible though. I'm keeping this as a low priority idea.