User:Tonestertm/HouseNumbers in depth

From Wazeopedia

< User:Tonestertm

Revision as of 09:30, 12 February 2015 by Tonestertm (talk | contribs)

Note that this page is still a bit under construction, please bear with any missing parts. Thanks! -tonestertm

How House Numbers work: the nitty gritty

Here's a little clarification about how House Numbers work in Waze; they do not function in the same way that Google address pins do.

Waze House Numbers have two parts: the Number point and the Stop Point. <insert image> The Number point belongs directly centered over the building with that address. Waze does not route to the Waze Number Point.

Searching in the Waze app

There is a prioritized system of "trust" when searching for an address in the client app -- Waze will route to either the Waze Stop Point or the Google pin, according to the trust level for that address:

  1. Confirmed Waze House Numbers
  2. Google Address Pins
  3. Unconfirmed Waze House Numbers (if no Google pin is found)

If a Waze result is chosen, Waze will route to the Stop Point, which is always on the road named in the address. If a Google pin is chosen, Waze routes to the closest it can "physically" get to that pin on the nearest routable road, whether that's the named address road, an alley behind the building, or even another street altogether. (There are some esoteric exceptions, but they would confuse the explanation right now.)

(Most of) Waze's House Numbers were originally imported from an outside source, and these numbers, untouched, are "unconfirmed". You may have noticed that many of them do not line up well with the buildings and streets in the Waze map. In addition, the address points, as imported from the source usually sit approximately in the center of the property, rather than on the main building on the property. This is also usually the case with Google address pins.

Confirming House Numbers: the nudge

So, how does an Unconfirmed House Number get Confirmed and become the first choice for routing, instead of third? By handling it and Saving, in the House Number editing window. This occurs because Waze reasons that if an editor has taken the time to open the House Number window and handle a given House Number, then the information left behind is likely to be correct, or confirmed.

Confirmation can be accomplished by adjusting the Number Point, the Stop Point, or both, and then Saving. It can even be accomplished by picking up one of these points, moving it away, putting it right back where it was, then Saving. The important thing is, that it got handled and Saved. This process is sometimes referred to as nudging, bumping, or touching, the House Number.

This is why, when House Numbers reappeared in the editor, it seemed, at first, that moving the Number Point closer to the street, as we do with Google pins in MapMaker, made addresses work properly. But it wasn't that moving them closer to the street made the Waze HNs work better; it was that they were being handled, increasing their trust level. The Number point itself can go anywhere within a certain range and not affect routing. Waze Stop Points are on the Street, by design, so they do not cause misroutes to nearby streets, the way that Google pins do, when they sit in the middle of the property.

So, keep in mind as you work HNs in the future: Number Point centered on the building, Stop Point moved to where Waze should route. The important thing is that something gets handled ("nudged") and Saved. This causes Waze to use a House Number instead of a Google pin in future searches. It is a good idea to nudge all House Numbers on a given street when you do one; if one is routing to the alley, it's likely that others will, in the future.

You can tell if a HN has been previously confirmed by clicking on it. A confirmed HN will cause a "Last edited by..." popup in the upper left of the HN window.

Finally, note that any HNs added by an editor are automatically confirmed.

Stored data: when good phones go bad

So, once you've nudged the misbehaving House Number, thus confirming it and making it the first choice to route to (after a Private Point place, which has priority over even confirmed House Numbers, when it exists) all should be right with the world, and the complaining reporter should now be able to find their home, right?


When a search is performed in the Waze app, a request is sent out, using the text entered in the search box. The data that comes back to Waze includes a set of GPS coordinates. These coordinates are stored in the phone AND the online user profile (for Favorites) and used whenever that Favorite or a previous search result (a "history" result) is chosen. These coordinates are NOT refreshed each time the result is chosen, they are static. If a Favorite was stored with a misplaced Google pin or a House Number in the wrong position, Waze will continue to route to that same bad location, given the same road placement in the vicinity.

To make matters worse, when a Favorite or History result is searched again, they come up at the top of the Autofill results, almost ensuring that even a new search will result in the choice of one of the old results, with the bad coordinates, leading to yet another faulty routing, even though the House Number has been confirmed. In order to overcome this, the user must delete their Favorite and/or History result for that given POI or address and search anew, making sure that the result they choose does not have a Star (Favorite) icon or Clock (History) icon at the left. This process of clearing old results and performing a fresh search should load the newly confirmed House Number Stop Point coordinates (once the tiles have updated) and NOW routing should be flawless.


To make routing work properly when a destination is incorrectly placed on a street "behind":

  • Nudge Waze House Number (or add, if nonexistent)
  • Move Google pin in MapMaker (optional)
  • Inform reporter to delete previous results for that location and do a new search--after the tiles have updated.