| Re: [sumo-user] Flow Edge data |
| Morning | |||
| Junction | Control Type | Mean Control Delay (HCM) | Mean Time Loss (SUMO) |
| P1.1 | Traffic light | 73 | 22,5 |
| P1.2 | Priority (Stop) | 4,1 | 0,86 |
| P2.1 | Traffic light | 71 | 17,63 |
| P2.2 | Priority (Stop) | 6,5 | 0,80 |
| P3 | Priority (Stop) | 2,6 | 6,88 |
| P4 | Priority (Stop) | 6,9 | 14,47 |
| Afternoon | |||
| Junction | Control Type | Mean Control Delay (HCM) | Mean Time Loss (SUMO) |
| P1.1 | Traffic light | 75,3 | 23,8 |
| P1.2 | Priority (Stop) | 5,1 | 0,57 |
| P2.1 | Traffic light | 75,7 | 18,47 |
| P2.2 | Priority (Stop) | 7,2 | 0,96 |
| P3 | Priority (Stop) | 3,5 | 5,92 |
| P4 | Priority (Stop) | 7,1 | 8,75 |
A problem with the proposed metric of timeLos/Veh in the context of edgeData output is the bias from differing edge lengths that approach an intersection.If you go by incLanes, you will only capture the edges/lanes that are directly connected to an intersection and their lengths usually vary when comparing different incoming roads and also when comparing different intersections. This might partially be mitigated by including additional edges/lanes in a radius around an intersection but even then it is generally not possible to have a consistent radius around each intersection because the granularity is always on the level of whole-length-edges.The metric timeLoss/(veh * edgeLength) would only partially mitigate this problem: If intersections have differing incoming edge-lengths then they will include different proportions of queued and free-flowing vehicles and this would still introduce bias into any comparison.An unbiased way to estimate the control delay is to define entryExitDetectors around each intersection in a well-defined radius (which can be automated with https://sumo.dlr.de/docs/Tools/Output.html#generatetlse3detectorspy). This type of detector can be configured to report traffic data incoming road or a combined value per intersection and it's outputs include the meanTimeLoss which is timeLoss/Veh.regards,JakobAm Mi., 19. Nov. 2025 um 01:57 Uhr schrieb Pedro Oliveira <pedro.engenhariae@xxxxxxxxx>:Good evening,
The Highway Capacity Manual (HCM) uses the average delay (seconds/vehicle) as the criterion for evaluating the Level of Service at intersections, as shown in the following table.Although control delay and time loss are theoretically not the same thing, considering that in a traffic microsimulation network, especially in congested networks (in which HCM is limited - see figure below) it is impossible for the delay in a trip to be exclusively due to the intersection control delay, time loss in seconds/vehicle would be a good approximation for the Level of Service of the edge that connects at the intersection.Density is a good indicator for Level of Service in uninterrupted flows, while for intersections, average delay is more suitable. In urban areas, the relative speed (percentage of the permitted speed) is used, which is already available in the SUMO output.Density is a good indicator for Level of Service in uninterrupted flows, while for intersections, average delay is more suitable. In urban areas, the relative speed (percentage of the permitted speed) is used, which is already available in the SUMO output.
With your help in some past emails, I continued working on the algorithm that calculates flow and timeloss/vehicle. The flow is now standard for edge data; I will update the algorithm to obtain timeloss/vehicle.
The next step I'm working on is obtaining the average timeloss/vehicle of the edges approaching the intersection. I can already do this manually, because by analyzing the NET.xml file I observed that the lanes approaching a junction are called incLanes, so I obtained which edges they would be and subsequently obtained the average for the junction, but it's still very manual. By the way, I would like to know if, in case I obtain an algorithm to perform this procedure, it is possible to make it public to other SUMO users?
Regards,
Pedro OliveiraEm ter., 18 de nov. de 2025 às 21:00, Jakob Erdmann <namdre.sumo@xxxxxxxxx> escreveu:> Regarding the tool: instantOutToEdgeCounts.py, what was my mistake in using it?As the name of the tools tries to convey, it is meant to process the output of the instantInductionLoop (https://sumo.dlr.de/docs/Simulation/Output/Instantaneous_Induction_Loops_Detectors.html) whereas your detectors are inductionLoops.> In a new version of SUMO, is it possible to include the timeLoss/veic output in the edge data?Potentially, though I'm reluctant to add arbitrary derived values to the default set of attributes.If you can bring up examples where this metric is used/published in other contexts, it would help to make an argument for general usefulness.regards,JakobAm Di., 18. Nov. 2025 um 18:02 Uhr schrieb Pedro Oliveira <pedro.engenhariae@xxxxxxxxx>:Good afternoon!
Thank you!
Regarding the tool: instantOutToEdgeCounts.py, what was my mistake in using it?
In a new version of SUMO, is it possible to include the timeLoss/veic output in the edge data?
Regards,
Pedro OliveiraEm ter., 18 de nov. de 2025 às 12:43, Jakob Erdmann <namdre.sumo@xxxxxxxxx> escreveu:Thank you very much for your careful observation and the examples. It was indeed a bug in the flow computation which is now fixed in the development version:regards,JakobAm Di., 18. Nov. 2025 um 12:20 Uhr schrieb Pedro Oliveira <pedro.engenhariae@xxxxxxxxx>:Good morning!
Attached file.https://we.tl/t-Wh48CM66YT
I managed to run the command: instantOutToEdgeCounts.py, I included the following parameters:
"%SUMO_HOME%/tools/output/instantOutToEdgeCounts.py" -d contadors.add.xml -i result_cont.xml -o detector_data.xml -b 0 -e 3600
However, the file remained empty.Sds,Pedro OliveiraEm ter., 18 de nov. de 2025 às 04:44, Jakob Erdmann <namdre.sumo@xxxxxxxxx> escreveu:Indeed, in my own simulations, the 'flow' attribute is always lower than the 'intermediate' value and this is what I would expect due to discounting of partial distances on departure and arrival.Please provide a minimal example simulation where the flow is higher.PS: the new tool is called in instantOutToEdgeCounts.py and resides in tools/output (the name given in the changelog was wrong and has now been corrected).regards,JakobAm Di., 18. Nov. 2025 um 04:35 Uhr schrieb Pedro Oliveira via sumo-user <sumo-user@xxxxxxxxxxx>:Good evening!_______________________________________________
I'm analyzing the "flow" output data that was added to "Edge data".
I installed version 1.25 with all the extras to run the new tool: instantOutToEdgeData.py, but the command was invalid (not recognized). I couldn't find the new command in the SUMO folder.
For a more realistic comparison, I would like to present a comparison of the flows from our detectors, but since I couldn't run the new tool, I'm presenting the comparison from the CountEdgeUsage tool (the detectors showed lower values).
The following figures show the comparison between countedgeusage and the flow output (edge data) from the new version of SUMO. I expected to see that flow would always be less than or equal to the count of the edges/detectors. I would like to understand the values that are higher.Thank you in advance for your attention.Sds,Pedro Oliveira
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
