Get a sneak peek at whats next for Permanent Hazards on our April 7th Office Hours!
Post by DwarfLord
AlanOfTheBerg wrote:What may need more discussion/clarification is this new statement: "If an address is on an unnamed private roads and the marker is a long way from the actual house location, it is advisable to delete the Waze house number and properly adjust only the Google Maps address marker."
After encountering a UR that may be due to this effect, I found my way to this entry in the wiki and thence to this thread.

Is this really our best current guidance? Delete problem house numbers when Waze won't let us place their associated stop points on roads other than the address road?

I had hoped that Waze was still actively developing this implementation. As discussed in this thread there are many cases where it doesn't work, primarily malls and rural areas with long driveways and private roads, but also occasional corner residences with access from the "wrong" street.

If not...OK...I can grit my teeth and delete Waze house numbers when they simply can't be fixed under the current implementation. I thought that was a bad, bad thing to do...can I say "the wiki made me do it"? :mrgreen:
DwarfLord
Wiki Master
Wiki Master
Posts: 2512
Has thanked: 1065 times
Been thanked: 1451 times
Send a message

Post by DwarfLord
tonestertm wrote:...including the speech about deleting old search.
I've just responded to a UR from a large estate. The Google pin is on the main house, as usual. But the driveway gate is NOT located at the closest part of the address street. It's much further away.

Naturally, Waze+Google positioning routes this reporter to the part of the street closest to the house, bypassing the gate by a long shot.

I don't plan to move the Google pin because I'd have to move it quite far from the house and that's not how Google likes to do things. I also don't want to add a private driveway because it will mess up routing for the neighbor.

So -- perfect application for a Waze House Number! I adjusted the house number as per instructions and moved the stop point to the driveway gate. I made sure to tweak a bit of road nearby to wake up a tile change. But, how does Waze deal with an old Google position and a new Waze house number?
  • Is it necessary to remove the address from the nav list and favorites under these conditions, when the Google pin has not changed but is rather being superseded entirely?
  • If the reporter removes the address from the nav list and favorites, then searches for the address again, are they guaranteed to get the Waze House Number provided it's been "touched" and the tiles have updated?
  • If so, does the Google position then become completely unused by and irrelevant to Waze (except for users who haven't cleared the stale address from cache)?
I'm guessing yes, yes, and yes... :?
DwarfLord
Wiki Master
Wiki Master
Posts: 2512
Has thanked: 1065 times
Been thanked: 1451 times
Send a message

Post by DwarfLord
Thanks! OK, I have added the following item to the "Caveats/Warnings" section of the House Numbers article. There was an warning already there about app behavior, so it seemed another warning about app behavior would not be out of place.
The Waze app will not use a new or modified Waze house number if it already has the corresponding address in its navigation and/or favorites lists. The user must remove any existing instances of an address before the app will obtain new position data for that address.
By the way, a UR reporter recently complained that he had waited six months (!!!) for an address fix made by another editor to work, and it hadn't. I suggested he remove the address from the app and load it in again. A few days later -- "yay!".

But what a shock. I always assumed that the addresses stored in the app had some kind of time-to-live. If they do, however, it is apparently longer than six months.
DwarfLord
Wiki Master
Wiki Master
Posts: 2512
Has thanked: 1065 times
Been thanked: 1451 times
Send a message

Post by DwarfLord
[EDIT: Preamble regarding confusion removed, crossed posts.]

New questions:

1. Should the text I added to the House Numbers article be removed? If removing the entries from nav list & favorites is unnecessary then the text I added is wrong. However, in a test I conducted just now, searching for an already-listed destination adds a new item to the nav list that appears identical to the existing item. I can't see at first glance how to discriminate between them, but maybe I'm missing something. How will I know which one is old and which one is new if I don't remove the old one? And, what good does it do a typical user to leave the old search result in place even if there were some way to discriminate?

2. In order to get to the part of the app where one can select Google as a data source, one must scroll to the bottom of the default results screen and select "More results for xxx". So rephrasing my question: once the House Number is in Waze and updated etc., is the Google result for a street address -- provided a Waze match is found -- always relegated to the "More results for..." process?

What I am trying to understand is what exactly to tell the UR reporter.
DwarfLord
Wiki Master
Wiki Master
Posts: 2512
Has thanked: 1065 times
Been thanked: 1451 times
Send a message

Post by DwarfLord
sketch wrote:Regarding 1: while it's not necessary to remove the listing from your previous destinations, it may still be advisable, for the reasons you listed.
FYI all, here is the revised language for the new item in the House Numbers article:
The Waze app cannot update the position of an address already listed as a recent or favorite destination. The user must add the destination again to obtain the most recent position data. Removing any existing instances of the destination before doing so will reduce the chance of confusion.
DwarfLord
Wiki Master
Wiki Master
Posts: 2512
Has thanked: 1065 times
Been thanked: 1451 times
Send a message

Post by DwarfLord
So, in this case...
  • The user has an existing recent and/or favorite for an address but this does not route well because of the location of the Google pin;
  • In response, I have "touched" the user's house number, adjusted the stop point, and "touched" a nearby segment to force a tile update;
  • The Google pin has intentionally not been modified; and
  • Status shows that tiles have updated.
...what do I tell the user to do?

I would start by asking them to remove any instances of the address from their recents and/or favorites list. Then I would ask them to search for the address from scratch. A list will pop up as they type with various icons and text. But I am still not sure what to tell them next to maximize the likelihood that their routing problem will be solved.
DwarfLord
Wiki Master
Wiki Master
Posts: 2512
Has thanked: 1065 times
Been thanked: 1451 times
Send a message

Post by DwarfLord
Does Live Map still rely heavily on Google positions, more so than the app? As long as it continues to do that, it seems like some mention of Google is warranted. Many editors rely on Live Map to test routing.

I am not tracking the rapid movement of Waze's routing preferences and how those are reflected in the app and Live Map. If Google really is out of the picture, that's great to know!
DwarfLord
Wiki Master
Wiki Master
Posts: 2512
Has thanked: 1065 times
Been thanked: 1451 times
Send a message

Post by jdeyoung
OK, now I'm really puzzled. If I'm understanding this right, not only must we bump addresses on a street but ALSO touch the street itself to make searches work correctly? The oddity here is, when you "touch" the address - it shows the connection point where the address should be "on" the street. Could this also possibly imply that simply touching the street itself could cause the address to be properly routed to the correct street itself? The issue doesn't just occur with alleys, it also occurs with corner addresses too. If touching the street itself could trigger tile/search updates that would be FAR simpler than having to do both.
In any case, correcting the auto-placed house numbers screams for a more systemic fix - or automation potential.
jdeyoung
Posts: 665
Answers: 2
Has thanked: 26 times
Been thanked: 229 times
Send a message

Post by jdeyoung
It seems then that there is an impasse. In residential areas - which of course neither waze or google actually "knows" - we have probably millions of address numbers that are not guaranteed to be closest to the streets for which they actually apply. Google is usually smart enough to temper the GPS coordinates to align with the actual street of the address. When it is not, the exceptions can be addressed on a one-off basis in google. Unfortunately, the waze algorithm can't/doesn't use street name as part of the consideration and routes to the closest drivable point to the gps-only coordinates. I would bet with confidence that the vast majority of routing directions in Chicago to residential addresses lead to the alley and not the street. And most wazers simply shrug their shoulders because waze gets them "close enough". But for a vocal minority of wazers that are in services businesses that are based on addresses in (more than likely) unfamiliar locations for each and every place they need to visit on a daily basis, we get a steady stream of URs complaining about constantly being routed to alleys and/or wrong streets. Again, getting a large number of editors to pitch in should be what waze is all about, but the house number tool isn't as reliable as it need to be for that to happen either.
jdeyoung
Posts: 665
Answers: 2
Has thanked: 26 times
Been thanked: 229 times
Send a message

Post by jdeyoung
sketch wrote: Automating the confirmation of Waze house numbers, or allowing the use of non-confirmed imported house numbers, will cause enormous problems not only because it will disallow us from making that assessment but also because some of the house number data imported into Waze is truly, truly awful.
As I indicated, that leaves us at a bit of an impasse. I've lived in/around Chicago all of my life, and can look at addresses on a street and know they've all been mass-imported (like little toy soldiers all lined up) and placed too close to the alley. I'm not suggesting waze itself have this knowledge and do so automatically nor does it make sense to wait for each and every resident along the street to report a UR that their address is incorrectly too close to the alley. Should we wait for the hundreds of thousands of these to be reported? A better approach to solving these ad-hoc after a user reports a wrong location for the umpteenth time would be to solve these for entire streets at a time with a proper tool. It was a massive effort to mobilize editors in the area to attack the problem of alleys created from basemap as streets. Now multiply that by 40-50 addresses per block of all the residential streets and you get an idea of the amount of effort needed.
jdeyoung
Posts: 665
Answers: 2
Has thanked: 26 times
Been thanked: 229 times
Send a message