Re: [sumo-user] rerouteTraveltime Odd Behaviour

[Jakob Erdmann <namdre.sumo@xxxxxxxxx>]

Hello,

If you are using the latest development version, this is a likely due to a bug that was introduced 9 days ago that caused traveltimes to become negative and thus promote elongated routes.

This has now been fixed.

If you are using another version of SUMO bad routes may also be caused by bad traveltime estimates for edges where vehicles are all standing in a queue. The function rerouteTravelTimes does not perform smoothing and just takes the current network travelTimes at face value. To get better results you can use the new function traci.setRoutingMode(vehID, traci.constants.ROUTING_MODE_AGGREGATED).

This will use smoothed travel times (exponential or moving window average) as configured: http://sumo.dlr.de/wiki/Demand/Automatic_Routing#Edge_weights

regards,

Jakob

2018-07-25 23:45 GMT+02:00 Jonathan Harper via sumo-user <sumo-user@xxxxxxxxxxxxxxxxxxxxx>:

Hello,

I’ve ran into an odd behaviour in regards to traci.vehicle.rerouteTraveltime(). Sometimes, the best time will produce a route with an absurdly long (as in it will be 100x more than expected kind of long) estimated travel time (using the current travel times of the edges in the route) - unusually, this is not actually the ‘best’ travel time possible, other routes are actually available which are a far better which aren’t picked up by rerouteTravelTime.

Do you know why this may be? Have you come across this before? If so, is there a fix to this issue?

Kind regards,
Jonathan


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
sumo-user mailing list
sumo-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sumo-user