Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

routers do not consider delays due to intersections (trac #2202) #2202

Closed
behrisch opened this issue Mar 15, 2016 · 3 comments

Comments

@behrisch
Copy link
Contributor

commented Mar 15, 2016

even when weight files are loaded or current travel times are used (in simulation routing), the travel time along a route with seldom used intersections is underestimated.

see #752, #2566

Migrated from http://sumo.dlr.de/ticket/2202

{
    "status": "new", 
    "changetime": "2017-04-28T13:07:07Z", 
    "description": "even when weight files are loaded or current travel times are used (in simulation routing), the travel time along a route with seldom used intersections is underestimated.\n\nsee #752, #2566", 
    "reporter": "namdre", 
    "cc": "", 
    "resolution": "", 
    "_ts": "1493384827142505", 
    "component": "routing (DUAROUTER)", 
    "summary": "routers do not consider delays due to intersections", 
    "priority": "minor", 
    "keywords": "", 
    "time": "2016-03-15T14:35:38Z", 
    "milestone": "1.0.0", 
    "owner": "", 
    "type": "defect"
}
@behrisch

This comment has been minimized.

Copy link
Contributor Author

commented Mar 15, 2016

@namdre changed description from:

even when weight files are loaded or current travel times are used (in simulation routing), the travel time along a route with seldom used intersections is underestimated.

to:

even when weight files are loaded or current travel times are used (in simulation routing), the travel time along a route with seldom used intersections is underestimated.

see #752, #2566

@namdre

This comment has been minimized.

Copy link
Contributor

commented Aug 30, 2018

Now that #752 is basically implemented, it would be possible to apply a penalty to the internal edges. However, this is somewhat difficult since delays will become noticeable on the incoming edge once vehicles start to use it and thus a flat penalty would overestimate delays.
For edges where all connections have minor priority, the empty-network traveltime could take the required deceleration into account.
This still would not solve the problem for left-turns from 1-lane priority roads.

A feasible solution would be to add a travel time penalty to internal edges which correspond to a minor link.
At 50km/h this value is somewhere between 1 and 2 seconds (4-5s for a stop sign).

@behrisch behrisch modified the milestones: 1.1.0, 1.2.0 Dec 19, 2018

@behrisch

This comment has been minimized.

Copy link
Contributor Author

commented Dec 19, 2018

A test exhibiting the behavior is sumo/extended/simulation_routing/assignment/taz_astar where the shortest route 5/5to5/6 5/6to6/6 6/6to6/7 6/7to7/7 7/7to7/8 7/8to8/8 8/8to8/9 8/9to9/9 9/9to8/9 is slower than 5/5to5/6 5/6to5/7 5/7to5/8 5/8to5/9 5/9to6/9 6/9to7/9 7/9to8/9 8/9to9/9 9/9to8/9 due to losses at the priority junctions.

@namdre namdre self-assigned this Jan 12, 2019

@namdre namdre added a:SUMO and removed p:minor labels Jan 12, 2019

@namdre namdre closed this in 4672bb8 Jan 12, 2019

namdre added a commit that referenced this issue Jan 12, 2019
namdre added a commit that referenced this issue Jan 12, 2019
namdre added a commit that referenced this issue Jan 13, 2019
behrisch added a commit that referenced this issue Jan 13, 2019
namdre added a commit that referenced this issue Jan 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.