We are picking up quite a few routing errors in London at the moment. In particular routing from S or SW London to N or NW London seems to throw up problems. Some of these may be time dependent. Please can we collect any issues on this in this thread so we can see where the problems are arising. I had a few URs where I was tracking them but some very kind visitors to London have marked them as solved.
I have suspicions that both the A406 North Circular and A10 are involved somehow but no proof. there may be a map problem or some issue with Waze’s algorithms on particular routes.
If anyone wants to do some debugging please do! I’m pulling my hair out at the moment, and it’s my last one.
Example routes that seem to fail (on live map):
Sutton to Cockfosters
Tooting to Hoddesdon
This route was failing the other day but seems to be working at the moment
I’ve noticed some weird routing happening over here in NI as well, I’d just put it down to an algorithm problem or something back end but I shall investigate further! will also have a look at your routes although if I find anything you’ll have to fix it for me…
Been playing around on LiveMap with southerly routes from Cockfosters.
Routing down to Shepherds Bush, Fulham and Wandsworth all look OK, returning complete routes with every request.
Balham is where things start to fall apart - more often than not this doesn’t return any results, and when it does only the route via the A1 actually reaches Balham, the route via the A406 stops short in Battersea.
Wimbledon, Sutton and Croydon appear completely unreachable… some might consider this to be a beneficial side effect of the routing algorithm.
If I then start looking to the east or west, routes become available again to sought-after destinations such as Knockholt and Chertsey, so unlike some other routing problems we’ve seen in the past this one doesn’t appear to be purely distance related.
Returning to Wimbledon as a destination and tweaking the start point shows that routing from Finchley is reliable, yet no route can be found from the nearby Friern Barnet or Bounds Green. A sanity check shows that Bounds Green to Wandsworth is fine.
Bounds Green to Roehampton is OK, as is Bounds Green to Tibbet’s Corner. Attempting the extra mile or so to reach Southfields is a no-no. Oddly, Finchley to Southfields is also a no-no, despite Finchley being valid as a starting point for Wimbledon…
Bit of both but more the later, checked a few out and they worked then they didn’t , so really not sure what is going on. I did check the routes but found nothing untoward bar a few dodgy nodes which I fixed. Will look at some of your routes tomorrow
NI area manager
Waze Beta - iPhone 4s iOS 6.1.2 not jail broken
Checking the above routes from home a few hours later, Cockfosters to Balham, Wimbledon, Sutton and Croydon now all work perfectly. Friern Barnet and Bounds Green to Wimbledon also work fine.
Bounds Green to Southfields is still broken, as are several other randomly chosen starting points, however Bounds Green to a specific road within Southfields is OK.
Still at home, and now this morning all of the routes that were broken as per my original post, and seemed to be fixed as per my second post, are now broken again… Also broken is Cockfosters to Wandsworth, which is now behaving the same way Cockfosters to Balham did originally - either not returning any route, or returning two routes one of which stops short of the destination.
Cockfosters to Fulham, Finchley, and other destinations closer to the origin, all seem to work OK. Cockfosters to Catford and Brighton also work OK, once again indicating that it’s not a simple distance-related bug. The calculation for the Brighton route also took considerably longer than any of the failed route attempts, suggesting also that the routing engine isn’t simply timing out whilst trying to generate some of those shorter routes.
Cricklewood to Wimbledon works fine, so it doesn’t appear to be a basic problem with the map data itself - between the successful Cockfosters-Fulham and Cricklewood-Wimbledon routes, all of the required segments and junctions have been traversed by one or other of the routes, and with more than sufficient overlap in the middle to avoid any risk of it being a segment/junction somewhere in the Fulham area that might be causing the problem.
To avoid the A406/A10, I also looked at routing due south from Cockfosters. Routes to Kennington and Camberwell come up fine, yet routes to Herne Hill, Dulwich and Sydenham all fail.
I’m thinking algorithm problem at this point - breaking the routes down into smaller chunks allows routing, so it’s not a case of incorrectly set segment directions/turn permissions etc somewhere between the overall start and finish points preventing routing at all. Distance, or at least complexity of the route, is somehow involved - as noted above it’s not simply a case of “routes > x miles = failure”, but perhaps more a case of “routes traversing more than x nodes or requiring more than y instructions to turn from one segment to another = failure”. This could account for the longer distance routes (e.g. Cockfosters-Brighton) working OK, as they start to skip large sections of the urban crawl that’s required for the shorter routes contained entirely within London, and instead get routed over the trunk roads which offer more miles per node/instruction.
To aid repeatability, I’ve now run some tests placing the start and end points at obvious places on the map. With the start point at the end of Games Lane in Cockfosters, I started generating routes southwards as before.
This screengrab was taken from an earlier test, hence the route summary box showing a different end point to those mentioned below…
With an end point at the north end of the B219, both the proposed routes are OK.
However, move the end point just a few yards further to the south, and now the route via the A406 stops short to the north of the A2214… Checking that section of the B219 in WME shows no oddities - it’s a single segment between its junction nodes with the A2214 and The Gardens, so moving the end point south like this hasn’t added any extra node/junction traversals compared with the route that ends right at the top end of the B219 - this time it’s purely the extra distance that seems to be messing things up.
Could there be a distance related aspect to this after all?
For these shorter cross-London routes, I’m noticing that when the dark-blue preferred route starts to fall short of the intended destination, the difference between the preferred and alternate route mileages is significant - you can see this in the earlier screengrabs, where the dark blue route is 42 miles whereas the pale blue route is only 26 miles. Adjusting the end point by a small amount then seems to cap the longer route at this distance (give or take half a mile or so), up to the point where Waze then returns no results at all. The capping distance isn’t always 42 miles - repeating this test with a different end point gave a cap at 44.5 miles, then another test gave a cap of 45 miles - but once the routing code decides to cut the longer route short for a given area of the map (and probably also a given route into that area) it does then seem to stick to that cap until something fundamental changes in the route calculations.
I wonder if the routing algorithm starts to degrade once the difference in route mileage gets to a certain point (i.e. where the longer route option starts to fall short of the destination), before falling over completely when the difference gets too great (i.e. where no routes are generated at all)…
This might explain why the problem tends to appear on these cross-city routes, where there’s a fast/lengthy option around the ring road vs a slow/short option directly across the city, but not as you start looking at even longer-distance routing (e.g. city to city) where any localised variation in routing mileage gets swamped by the much greater overall routing distance.
It could also explain why, so far, this problem only seems to crop up with N-S (or vice versa) routing across London, whereas E-W and W-E routing is OK - the shape of the North Circular (and to a less-well defined extent, the South Circular) means there’s less of a distance differential between the time and distance route alternatives travelling E-W than when travelling N-S. Not a huge amount (a quick play around on Google Maps suggests it’s a 1.4x distance penalty E-W vs 1.5x N-S), but it is there.
A13 Alfred’s Way (Barking) to A316 The Avenue (Richmond) = fail
coming in a bit to Mortlake I get two routes but both drop a bit short over the northside of the river. One of these uses the North Circular.
a bit more to the east side of Putney and we get two successful routes neither of which use the North Circular.
Ditto for Chelsea.
Woolwich to Chelsea ok
Woolwich to East Sheen = fail
Woolwich to Putney is a very interesting one so screen shotted. Destination is just by Wandsworth Park but although I get two routes one drops short on the north side whilst the south of the river one actually crosses the river to end up nearer the first one than the destination!
Once again, testing from home in the evening makes the routing engine seem like the pinnacle of coding excellence, with every requested route being delivered without fail… This is on the exact same system which, during breakfast time testing, makes the routing engine seem like a steaming pile of doodah. Meh.
Good work guys. Would this have anything to do with the time that the routing is done? Is it confined to a particular time/s of day?
Does it tie up with say a busy route calculating period or maybe server/database cleanups or backups?
Testing in the mornings (6-7am) and around lunchtime (12-2pm) is when I see routing errors occurring, whereas testing in the evening (9pm onwards) seems to be pretty solid.
I’ve been running another quick test, leaving the start and end points unchanged and just calling the navigate() function from the console. Although I haven’t been getting any errors (as expected given the time of day), I have noticed the routes returned change slightly every now and again, and I’m guessing this is the routing engine adjusting to the live traffic conditions out there right now.
Presumably then, during those times of the day when traffic conditions are more changeable (i.e. the start of the morning rush hour and throughout the working day), the routing engine will have more live data to contend with whilst trying to calculate its routes, and so maybe this is where the problem lies?
I’ve always thought the errors occur when the recommended route is significantly longer than the crow flies (rather than an alternative route).
It’s going to be related to the problems you get routing between peninsulars; for example Barrow to Morecambe, Shoebury to Whitstable, Ilfracombe to Swansea.
Only difference is the cross city London routes have a straight line alternative, but I’m sure the problems with the longer Circular routes is the same.
Chris - I think you have these tests scripted now, is that right? Is it very difficult to tabulate these results so Waze HQ have an easy reference for their checking? No worries if not.
Ideally something like: start lat/lon/street, finish lat/lon/street, time of day, success/fail, distance A, distance B
I haven’t automated any of it yet, but it’s something I was mulling over this morning…
Inbound, weapons hot :mrgreen:
Something else that crossed my mind regarding the interaction between the routing algorithm and the traffic data - since the traffic data changes quite frequently at certain times of the day, I wonder if the routing code takes a snapshot of the data before starting to generate each new route, or if it just assumes that the live data isn’t going to change significantly during the calculation of the new route. If the latter, then there’s always the chance that during the calculations the data has changed in such a way that the intended route breaks whatever internal thresholds/sanity checking are set for the routing code.
Given that it generally seems to be the quickest route option that starts to fall short of the intended destination before the routing code gives up completely, this would tie in with it being traffic data related - the shortest route would only be affected if the road closure data got updated during the routing calculation, whereas changes in traffic density shouldn’t affect it at all (it doesn’t care how long it takes to get from A to B…).
