Addresses not findable in Waze - Enough is enough
Can we please get some official traction on this issue? This is ridiculous.
There are numerous examples of this issue, it is not an isolated problem, but for purposes of discussion here is one of the events:
https://www.waze.com/editor/?env=usa&lo ... 460&zoom=7
Confirmed HN of 8604 is attached to NE 13th Place.
Address 8604 NE 13th Place is not findable in the Waze app. It does not matter if you specify the CDP (Hazel Dell), USPS City (Vancouver), or leave the city out. There is no way to slice this search, you cannot get the results to come up in the app anywhere. But they are clearly drawn into WME correctly, with both the verified CDP city as well as the USPS city as an alternate.
Autocomplete results in the app do find wildly inaccurate results from GMaps.
This is a newer subdivision that is not in GMaps at all, despite existing for over a year. A brilliant opportunity to win over users because Waze is more up to date than GMaps.
When this UR came in, we reverified everything. We re-nudged the HNs even though they had all been manually created. We nudged nodes to force a tile update. We finally deleted and rebuilt the subdivision from scratch in case something was corrupt. Still can't get it to go.
Looks like the only solution we have, other than making RPPs (which we should definitely NOT have to do to fix this), is to fix GMaps.
So this begs the question, why in the world are we wasting time in Waze when GMaps results overrule all? If I have to go fix GMaps to make Waze work, what is the point of all our time in WME? Why aren't we all editing GMaps, since that's what it takes to make Waze work?
This is a glaring, inexcusable issue. One of Waze's many, not the least of which is the new WME.
Hoping against hope, but not holding my breath, that HQ takes notice and fixes this problem. Can I get an Amen?
There are numerous examples of this issue, it is not an isolated problem, but for purposes of discussion here is one of the events:
https://www.waze.com/editor/?env=usa&lo ... 460&zoom=7
Confirmed HN of 8604 is attached to NE 13th Place.
Address 8604 NE 13th Place is not findable in the Waze app. It does not matter if you specify the CDP (Hazel Dell), USPS City (Vancouver), or leave the city out. There is no way to slice this search, you cannot get the results to come up in the app anywhere. But they are clearly drawn into WME correctly, with both the verified CDP city as well as the USPS city as an alternate.
Autocomplete results in the app do find wildly inaccurate results from GMaps.
This is a newer subdivision that is not in GMaps at all, despite existing for over a year. A brilliant opportunity to win over users because Waze is more up to date than GMaps.
When this UR came in, we reverified everything. We re-nudged the HNs even though they had all been manually created. We nudged nodes to force a tile update. We finally deleted and rebuilt the subdivision from scratch in case something was corrupt. Still can't get it to go.
Looks like the only solution we have, other than making RPPs (which we should definitely NOT have to do to fix this), is to fix GMaps.
So this begs the question, why in the world are we wasting time in Waze when GMaps results overrule all? If I have to go fix GMaps to make Waze work, what is the point of all our time in WME? Why aren't we all editing GMaps, since that's what it takes to make Waze work?
This is a glaring, inexcusable issue. One of Waze's many, not the least of which is the new WME.
Hoping against hope, but not holding my breath, that HQ takes notice and fixes this problem. Can I get an Amen?
Re: Addresses not findable in Waze - Enough is enough