Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sumo-user] Queue delay

The latest development version supports attribute 'speedThresholdRelative' for this purpose. As a work-around you could also define multiple edgeData definitions (one for each distinct speed limit) using attribute 'edges' (for all edges with a specific speed limit) and setting a speedThreshold apppropriate for the corresponding limit.

regards,
Jakob

Am Di., 30. Juni 2026 um 20:31 Uhr schrieb Pedro Oliveira <pedro.engenhariae@xxxxxxxxx>:
Good afternoon,

Regarding the comparison between a theoretical empty network and the actual one, I believe `timeloss` comes quite close to that objective.
I would like to try estimating the average time spent in a queue.
The "Lane- or Edge-based Traffic Measures" output includes a `waitingTime` metric, which can be adjusted using the `speedThreshold` parameter.
According to a reference source, a vehicle can be considered to be in a queue under the following conditions:
The gap to the vehicle ahead (leader) is less than or equal to 6 m;
And its speed is greater than or equal to the leader's speed;
And its speed is less than or equal to one-third of its desired speed.

For an initial approach, I could define a vehicle as being in a queue (or as the first in line) if its speed is less than or equal to one-third of its desired speed; however, since I have varying road speeds, I cannot set a fixed default value. Is there a way to set the `speedThreshold` using a formula such as `0.33 * edgeSpeed`?

Since the data is aggregated as a total—just as I did for `timeloss`—I can generate the edge data by dividing `waitingTime` by `flow` to obtain an average value in seconds per vehicle.

Sds,

Pedro Oliveira

Não contém vírus.www.avast.com

Em ter., 30 de jun. de 2026 às 02:39, Jakob Erdmann <namdre.sumo@xxxxxxxxx> escreveu:
The queue output has several deficiencies in this regard:
- the 'queing_time' is the maximum waiting time over all queued vehicles. If one vehicle has been waiting for a long time and the next queued vehicle has only been waiting for a short time, then the average control delay will be lower than the queing_time
- only standing vehicles are considered for queuing time, so time lost due to slowly creeping in a queue is not considered
- it is focused on a single lane. If the queue spills over a sequence of lanes (as often happens when the edge is split to model short turning lanes), you manually need to aggregate the correct values 

The cleanest approach (as described in the HCM) is to simulate the intersection once without cross traffic on the major road to get baseLine timeLoss and then subtract this from the timeLoss in a full-traffic simulation.

regards,
Jakob


Am Di., 30. Juni 2026 um 02:50 Uhr schrieb Pedro Oliveira via sumo-user <sumo-user@xxxxxxxxxxx>:
Good evening,

How are you?

In SUMO, the output in QueueOutput: queueing_time = The total waiting time of vehicles due to a queue, I would like to check if this time can be called queue delay, something similar to this definition: the delay of the time interval if the vehicle is in the queuing state; otherwise, 0.

Instead of using time loss (SUMO), my intention is to approximate the HCM Level of Service for intersections based on queue delay.

image.png
Sds,

Pedro Oliveira

Não contém vírus.www.avast.com
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user

Back to the top