Route Timing for UR in Pickering, ON
I could use some help resolving a route timing issue for this UR in Pickering, ON.
Local knowledge (specifically mine and the UR OP, but I'm sure other locals would agree) indicates that the longer route should not be chosen unless there were some issue on Hwy 401 causing a backup, since this is just after the collector lanes open up and traffic normally frees up in this area of the 401, and therefore just based on speed limit difference (60 km/h vs. 100 km/h) plus the extra light at Whites, the longer route would almost never be the faster route (except, as I said, if there were a traffic event on the 401).
Using LiveMap and isolating to the shortest possible route that includes the routes described in the UR, I had already determined that a certain times of the day, Waze would take the longer route, which actually includes an extra light cycle for a left turn at the busy intersection of Kingston Rd and Whites Rd and has a longer distance traveled on 60 km/h roads vs. 100 km/h speed limit on the 401.
I installed the WME Route Speeds script to debug further, and have some odd results. If you want to duplicate my results locally, set your A point to -79.108937, 43.823042 (on Kingston Rd) and B to -79.121862, 43.812278 (should be on the 401 Collector Lanes). The shortest route should be the first ramp onto the 401 at 1.66 km, the next longest will probably be via Whites Rd at 1.74 km.
Here's my problem: Segment cross-times don't add up to the total travel time from A to B ... not even close.
If I set the day to Tuesday and the time to 08:00 (one of the times that produces seemingly bad results in LiveMap), the numbers for the shortest route don't add up (neither the average speed or the trip time, if you set the Show Cross-Times option). For speed, I get 38+58+99+95+118 for the 5 segments, yet the average shows 39.2 km/h. For cross-times I get 21+35+13+14+7, which adds up to 90 seconds, but the total time shows 2:33, 63 seconds more than the sum of the segments. Why are these numbers so far off? This "unaccounted-for" 63 extra seconds for the shorter distance route is no doubt why Waze is routing to the slightly longer route.
On the longer segment I get the opposite effect: 23+30+13+43+7+32+7=155 seconds, but the displayed total A to B time is 1:32, 63 seconds less than what it should be. Very interesting that they are both wrong by the same number of seconds... could the routing engine be "getting its wires crossed"???
Clearly I don't understand how Waze routing engine works internally (does anyone, really?
), but can anyone explain why the individual segment cross-times would not add up to the total time?
After posting here, I do plan to post a link to this thread in the Waze -scripts Slack to draw in some help. If you know of other forums or individuals that should be linked in, please do so or let me know so I can.
Thanks,
Roy.
Local knowledge (specifically mine and the UR OP, but I'm sure other locals would agree) indicates that the longer route should not be chosen unless there were some issue on Hwy 401 causing a backup, since this is just after the collector lanes open up and traffic normally frees up in this area of the 401, and therefore just based on speed limit difference (60 km/h vs. 100 km/h) plus the extra light at Whites, the longer route would almost never be the faster route (except, as I said, if there were a traffic event on the 401).
Using LiveMap and isolating to the shortest possible route that includes the routes described in the UR, I had already determined that a certain times of the day, Waze would take the longer route, which actually includes an extra light cycle for a left turn at the busy intersection of Kingston Rd and Whites Rd and has a longer distance traveled on 60 km/h roads vs. 100 km/h speed limit on the 401.
I installed the WME Route Speeds script to debug further, and have some odd results. If you want to duplicate my results locally, set your A point to -79.108937, 43.823042 (on Kingston Rd) and B to -79.121862, 43.812278 (should be on the 401 Collector Lanes). The shortest route should be the first ramp onto the 401 at 1.66 km, the next longest will probably be via Whites Rd at 1.74 km.
Here's my problem: Segment cross-times don't add up to the total travel time from A to B ... not even close.
If I set the day to Tuesday and the time to 08:00 (one of the times that produces seemingly bad results in LiveMap), the numbers for the shortest route don't add up (neither the average speed or the trip time, if you set the Show Cross-Times option). For speed, I get 38+58+99+95+118 for the 5 segments, yet the average shows 39.2 km/h. For cross-times I get 21+35+13+14+7, which adds up to 90 seconds, but the total time shows 2:33, 63 seconds more than the sum of the segments. Why are these numbers so far off? This "unaccounted-for" 63 extra seconds for the shorter distance route is no doubt why Waze is routing to the slightly longer route.
On the longer segment I get the opposite effect: 23+30+13+43+7+32+7=155 seconds, but the displayed total A to B time is 1:32, 63 seconds less than what it should be. Very interesting that they are both wrong by the same number of seconds... could the routing engine be "getting its wires crossed"???
Clearly I don't understand how Waze routing engine works internally (does anyone, really?
), but can anyone explain why the individual segment cross-times would not add up to the total time?After posting here, I do plan to post a link to this thread in the Waze -scripts Slack to draw in some help. If you know of other forums or individuals that should be linked in, please do so or let me know so I can.
Thanks,
Roy.
), and the times were actually 2:33 for the second ramp and 1:32 for the first ramp. However, the mystery remains why LiveMap was actually recommending the second ramp at that time, despite it being over a minute slower.
Re: Route Timing for UR in Pickering, ON