Open behrisch opened 8 years ago
In [changeset:"20751"]: {{{
!CommitTicketReference repository="" revision="20751"
Merged revision(s) 20703-20750 from trunk/sumo: cleaning up osm nodes on error, refs #13 ........ working around gui memleaks, refs #3 ........ added test for ticket2316 ........ adapting teleport outputs, refs #21 ........ masking xml column count, refs #21 ........ adapting schema for empty detector output files, refs #21, #2 ........ fixing warning, refs #3 ........ fixing leaking router, refs #13 ........ fixing leaking marouter and routes, refs #13 ........ updated test for ticket 2316 ........ trying to fix undefined behavior, refs #3 ........ fixing svn props, refs #22 ........ added test for ticket 2126 (overtaking with subsecond timesteps) ........ TraCI vehicles are added on the first allowed laned by default, added new byte constants ........ fixing angle bug in moveToXY ........ fixing distance normalization bug in moveToXY ........ added test refs #2319 ........ a bit of verbosity ........ fix #2322 ........ some info to help debugging ........ merging similar subscriptions, refs #2318 ........ now with merged subscriptions, refs #21, fix #2318 ........ fixing vClass permissions ........ fixing cycleway import from OSM ........ patching expected results after [20729], [20730] refs #21 ........ webWizard not computes aggregate statistics ........ added debug defines refs #2329, refs #2287 ........ avoid unnecessary calls of secureGap() in MSLaneChanger ........ fix #2331 ........ fix #2336. Was regression in [20695] ........ refactoring MSPerson, fixing person and vehicle list in TraCI and GUI, refs #12, #1673 ........ removed initial stop from personinfo output, showing all loaded vehicles, refs #21 ........ adapting person API to vehicle API (reverting previous changes to traci vehicle API), fixing running person number, removing unused code, refs #12, #1673 ........ adapting vehicle lists, refs #21 ........ fixed typos in error message, refs #22, #21 ........ network knows about explicit neighbor lanes, refs #2316 ........ fixing offset of one step on container triggered insertions, refs #2339 ........ adapting container triggered insertions, refs #2339, #21 ........ adapted debugging style in MSLaneChanger, MSLCM_LC2013, and MSLCM_JE2013. Inserting debugging code from MSLCM_JE2013 into MSLCM_LC2013. ........ showing running persons and vehicles in the status bar, refs #1943 ........ }}}
to:
1495555698830471
removed clutter
recheck
The test already triggers at a 20m vehicle. This does not seem unusually long, so yes this is still relevant.
A long vehicle occupies the whole junction and wants to change the lane from lane 2 of the target edge to lane 1, while another vehicle on another incoming edge waits for passing the junction towards that lane (and probably represents a blocking follower?).
I found this by chance in the old test for #1804, where due some reason a stop is placed for the long vehicle on lane 2 (otherwise, the situation wouldn't occur), followed by one on lane 1. It seems unlikely, that this would occur without intentionally setting it up, therefore, I flag it as minor.
Migrated from http://sumo.dlr.de/ticket/2319