I have a UR in Devon where if you enter the road name Waze directs you to the correct place, but if you add a house number it directs you to the wrong destination.
I could be wrong here but thought I’d put my 2p in anyway. Could it simply be down to 5 Old Park Av has not been added as a house number to WME. Whereas 5 Old Park Rd has and due to the similarity of the names Waze could default/correct the result to what it thinks is right.
Okay in the middle of writing this, I have tested this on google maps and it brings up the same issue taking you to 5 Old Park Rd in the results rather than 5 Old Park Av. So the issue is Google based rather than Waze’s direct fault.
I have no editing rights in the area but if the house numbers are added for Old Park Av would that then help users to get the correct location for the destination?
Further to this due to it being a relatively new estate the location data that services rely upon probably still hasn’t been updated yet meaning that it is currently only feasible to search for the for the road name and not the house number. I tried searching for 5 Old Park Av on Bing even and got a Null result yet if just searching for the road name on it’s own like before does bring up the road.
Yep, the problem lies in the Google Maps API Waze (frustratingly) relies on to do much of its address searching…
Looking at the behaviour of the API on LiveMap, searching for “5 Old Park Avenue” causes the results drop down to list it as the second result, with “5 Old Park Road” being the first. Looking at the API call and response in the console, these two results have different place_id values and so, in theory, do relate to two distinct places in the GMaps data.
When you then select the “Avenue” result, Livemaps performs a new API request to get the location data for the given place_id - whilst it now sends the value associated with the “Avenue” search result, GMaps returns the data for the “Road” result instead, including its place_id value as part of the returned data - i.e. as far as GMaps is concerned, the “Avenue” place_id seems to be nothing more than an alias for the “Road” place_id, so asking for details of the former then just pulls up details of the latter… I’m guessing it’s not dissimilar a concept to how we can link Google places to Waze places, so that the search results for the former can be redirected to give you the location data for the latter.
Whether adding house numbers into the native Waze data for Old Park Avenue will have any effect is one of those questions which never seems to have a reliable answer available - IIRC the latest word from HQ was that native data ought to be prioritised over Google data, but in reality I’m less convinced this is working as expected.
In all honesty, until Waze either manage to rewrite their backend code so that it can be guaranteed to prioritise native data over third-party data, or until they simply cut all ties to third-party providers and rely solely on the native data, I don’t think we’ll ever see an end to problems like this. It’s a complete pain in the arse when it happens, because naturally you want to try and fix the problem, but sometimes it’s just not possible due to the way the backend searches seem to behave when there’s a choice of data sources.
So by all means try adding house numbers here, and if that does resolve the problem then crack open the bubbly and celebrate, but equally don’t be too surprised if it does the square root of FA…
Thanks for your input. I did wonder if it was the referring to Google that was causing the problem, but not understanding the techie stuff, thought it easier to ask.
I have now added a few house numbers, but I think I remember doing this to a similar problem before and it not making any difference.
Change something todo with the segment like the geometry a bit, its not an exact science but that seems to force the numbers to be used. I have added a few house numbers lately and I am pleased to announce waze uses waze instead of google :mrgreen: