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: [email protected] <[email protected]> Im Auftrag von Jakob Erdmann Gesendet: Montag, 15. Juni 2020 20:56 An: Sumo project User discussions <[email protected]> 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 <[email protected] <mailto:[email protected]> >: 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 <http://sumo-user-mailing-list.90755.n8.nabble.com/> at Nabble.com. _______________________________________________ sumo-user mailing list [email protected] <mailto:[email protected]> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user -- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus
_______________________________________________ sumo-user mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
