[Updated] House Numbers in WME

Moderator: Unholy

Re: [Updated] House Numbers in WME

Postby DwarfLord » Sun Jul 27, 2014 10:42 pm

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
Area Manager
Area Manager
 
Posts: 970
Joined: Sat Dec 07, 2013 4:01 pm
Location: Santa Cruz Mountains, California USA
Has thanked: 565 times
Been thanked: 475 times

Re: [Updated] House Numbers in WME

Postby DwarfLord » Mon Jul 28, 2014 1:01 am

[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
Area Manager
Area Manager
 
Posts: 970
Joined: Sat Dec 07, 2013 4:01 pm
Location: Santa Cruz Mountains, California USA
Has thanked: 565 times
Been thanked: 475 times

Re: [Updated] House Numbers in WME

Postby DwarfLord » Mon Jul 28, 2014 4:58 am

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
Area Manager
Area Manager
 
Posts: 970
Joined: Sat Dec 07, 2013 4:01 pm
Location: Santa Cruz Mountains, California USA
Has thanked: 565 times
Been thanked: 475 times

Re: [Updated] House Numbers in WME

Postby DwarfLord » Mon Jul 28, 2014 3:34 pm

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
Area Manager
Area Manager
 
Posts: 970
Joined: Sat Dec 07, 2013 4:01 pm
Location: Santa Cruz Mountains, California USA
Has thanked: 565 times
Been thanked: 475 times

Re: [Updated] House Numbers in WME

Postby jdeyoung » Fri Apr 25, 2014 1:04 pm

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.
Image
AM Chicago, NW Indiana, SW Lower MI
jdeyoung
Area Manager
Area Manager
 
Posts: 238
Joined: Tue Jun 07, 2011 10:04 pm
Location: Greater Chicago Metro area, NW Indiana, SW Lower MI, USA
Has thanked: 8 times
Been thanked: 80 times

Re: [Updated] House Numbers in WME

Postby jdeyoung » Fri Apr 25, 2014 5:13 pm

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.
Image
AM Chicago, NW Indiana, SW Lower MI
jdeyoung
Area Manager
Area Manager
 
Posts: 238
Joined: Tue Jun 07, 2011 10:04 pm
Location: Greater Chicago Metro area, NW Indiana, SW Lower MI, USA
Has thanked: 8 times
Been thanked: 80 times

Re: [Updated] House Numbers in WME

Postby jdeyoung » Mon Apr 28, 2014 4:23 pm

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.
Image
AM Chicago, NW Indiana, SW Lower MI
jdeyoung
Area Manager
Area Manager
 
Posts: 238
Joined: Tue Jun 07, 2011 10:04 pm
Location: Greater Chicago Metro area, NW Indiana, SW Lower MI, USA
Has thanked: 8 times
Been thanked: 80 times

Re: [Updated] House Numbers in WME

Postby jdeyoung » Thu May 01, 2014 2:43 pm

tonestertm wrote:Unlike the way it handles Google markers, Waze routing Does Not Care where the Number portion of a House Number sits. The important routing work is done by the Stop Point. The Number bubble is just a placeholder, visually cuing us humans to which building the Stop Point with that address, ties.

I do apologize for my lack of precision. The placement of the number bubble (untouched) only represents the point where google will route to until the bubble is touched and available to users only when the tile is updated (as discussed elsewhere). The oddity here is that the stop point was a feature introduced later (I think) after the addresses had already been placed from the mass-import - and yet all of the stop points are generally anchored to the proper street - not the alley. So waze had some knowledge in that process.
So, out of habit when touching addresses, I move the bubbles closer to the street - and then subsequent editors have a visual cue of addresses which have been touched along a given street.
That point is actually key, since the stop point of the address behaves similarly to the newly exposed "place handle" which shows the point within the "area place" that you would be routed to - like gas stations and larger areas.
Thanks for making the clarifying point about the bubbles location. ;)
Image
AM Chicago, NW Indiana, SW Lower MI
jdeyoung
Area Manager
Area Manager
 
Posts: 238
Joined: Tue Jun 07, 2011 10:04 pm
Location: Greater Chicago Metro area, NW Indiana, SW Lower MI, USA
Has thanked: 8 times
Been thanked: 80 times

Re: [Updated] House Numbers in WME

Postby kentsmith9 » Fri Apr 25, 2014 1:34 am

I added a link from [[WME Errors]] to the new House Number error section.

bigbear3764 wrote:I remember seeing a post that the champs were going to find out from waze what added to WME causes a tile update. Did we find out if adding house numbers causes a tile update or do we have to nudge the road to get the update.

Currently no update from house number edits. https://wiki.waze.com/wiki/Map_tiles#Trigger_updates
kentsmith9
Waze Global Champs
Waze Global Champs
 
Posts: 4343
Joined: Mon Apr 23, 2012 3:33 pm
Location: SF/SJ Bay Area of Northern California
Has thanked: 921 times
Been thanked: 1090 times

Re: [Updated] House Numbers in WME

Postby kentsmith9 » Fri Apr 25, 2014 3:00 pm

Two separate issues.

1) House numbers that have been modified will be searched first by Waze, but only if the tiles are updated that hold that segment and house number.

2) Tile updates occur for the reasons listed on that page noted above. If nothing in a tile causes an update on its own, the system will eventually just update the tile automatically. This can take 10+ days depending upon what else the servers are processing that cycle.

If you happen to move a street with a house number that has complaints and then suddenly it is working, it seems plausible that someone else actually updated the house number location before you, but did not trigger a tile update. Your movement of the segment forced the tile update that now uses the newly moved house number.
kentsmith9
Waze Global Champs
Waze Global Champs
 
Posts: 4343
Joined: Mon Apr 23, 2012 3:33 pm
Location: SF/SJ Bay Area of Northern California
Has thanked: 921 times
Been thanked: 1090 times

PreviousNext

Return to Wiki Updates and Discussion

Who is online

Users browsing this forum: kyhtak