Re: [sumo-user] Induction Loop

["Jan Grimm" <jan-grimm@xxxxxx>]

Hi Jakob,

 

Thanks for the reply.

 

I just noticed that under certain circumstances, occupancies can grow much higher than 100%.

 

I query induction loop occupancies each timestep, using

double occupancy = (double)sumoConnection.do_job_get(Inductionloop.getLastStepOccupancy(<detName>));

in my Java application.

 

During heavy congestion (mostly standstill with rarely a vehicle moving), I measure occupancies reaching levels somewhere in the 10.000s. I guess this happens due to the very low speeds. Of course I can easily work around this, but maybe the occupancy returned by the above function should be changed to never return more than 100%?

 

As a remark on the previous issue (FYI):

I compared the TraCI occupancies with data from a real motorway (induction loops as well as overhead sensors). During congestion, I got a pretty good match on the occupancy/volume relationship, independent of the type of the detector. The congested part, i.e. occupancies above 35% is what matters to me (since I use the occupancy to apply a certain congestion warning algorithm), so the following is not a problem for me, and I’ll stick with the traci occupancy output. I’m just a little curious here 😉

 

In contrast to congestion, during free flow TraCI occupancies tend to be a little lower than empirical occupancies at similar volumes. If I add a term reflecting the detector length (say 4m), I get a better match in this case. However, then the occupancies would be way too large in the congested case. The following graph shows this (similar for most other detectors used for comparison):

 

 

The orange dots are occupancies calculated like this:

 

1. Accumulating occupation time per vehicle in a time step:

accOccupationTimeInStepConsideringDetLength += (sumoVehicleRecord.leave_time - sumoVehicleRecord.entry_time) + (4.0 / speed);

 

2. Then, calculating the occupancy like this:

double altOccupancy = (accOccupationTimeInStepConsideringDetLength / deltaT) * 100.0;

 

deltaT is the simulation step in s, speed is in m/s.

 

Is the calculation of occupancies somehow different during congestion compared to the non-congested state?

 

Thanks a lot and have a nice weekend

Jan

 

Von: sumo-user-bounces@xxxxxxxxxxx <sumo-user-bounces@xxxxxxxxxxx> Im Auftrag von Jakob Erdmann
Gesendet: Montag, 15. Juni 2020 20:56
An: Sumo project User discussions <sumo-user@xxxxxxxxxxx>
Betreff: Re: [sumo-user] Induction Loop

 

1) yes

2) 0

 

If you need detectors with non-zero length you can use laneAreaDetector or entryExitDetecor

 

regards,

Jakob

 

Am Mo., 15. Juni 2020 um 18:05 Uhr schrieb grimm <jan-grimm@xxxxxx>:

Hello all,

I'm processing induction loop data via TraCI, including entry time and leave time of each vehicle passing the induction loop detector, as well as the detector occupancy for each simulation step.
With respect to this, I have a few questions:
1.) Which reference points of the vehicle are entry time and leave time related to, respectively (front bumper, rear bumper)? I assume, entry time is when the vehicle front hits the upstream end of the detector area, and leave time is when the rear bumper leaves the downstream end of the detector, is this correct? This would have an impact on how to interpret the detector occupancy.
2.) What length is an induction loop assumed to have in SUMO?

Thank you very much for a reply!
Jan

---

Sent from the Sumo User Mailing List mailing list archive at Nabble.com.
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user

Virenfrei. www.avast.com