User:Ruggles76/Address-Related Routing Problems View history

< User:Ruggles76
Revision as of 11:58, 2 May 2016 by Ruggles76 (talk | contribs) (corrected typo)

Overview

This page is intended as a reference to help editors understand how Waze determines destinations, when they are entered by address.

While many cases are simple, others are not, and sometimes the most common solutions can hurt more than help. This page should help you resolve URs when the routing to an address is wrong. It will also help you understand the often complex relationship between Google Maps pins (GM), Waze house numbers (HNs), and Waze residential point places (RPPs).

Basics

Most seasoned editors will be familiar with most of these basics, but will still benefit from reading them - there may well be a few things you didn't know.

Waze Routing Basics

When you enter a destination into Waze, it converts it to a GPS point (latitude and longitude). It then finds the closest point on a navigable road and sends you there. If there are exceptions to this rule, I haven't found them. So the trick is always to figure out how and where that GPS point is and, if it's wrong, how Waze got it so you can fix it.

Waze House Number Basics

Each street segment in Waze can have one or more house numbers (HNs), visible if you select the segment and click "Edit House Numbers" (or "View House Numbers, if the segment is locked above your editing rank).

  • The Editing Wiki has a good overview of House Numbers in WME that you should be familiar with first. In the event of conflict between that article and this one, the official one should take precedence.
  • In HN editing mode, if you click any HN, you can see two dots associated with it - one near the number that can be dragged to relocate the number, and one on the street called the stop point, connected by a dotted line, that determines where, on the street, Waze will direct the user (for exceptions, see below).
  • A house number may be unconfirmed (meaning it came from the original base map and no one has verified it), or confirmed (meaning an editor created or confirmed it).
  • You can identify a confirmed house number by clicking on it (on a street where you can edit house numbers); you'll see "Last edited by" and an editor name in the top left; if you don't see that, it's unconfirmed.
  • If you use the WME HN Tool script, then unconfirmed HNs appear in orange, vs. confirmed ones in white. This is the only way to tell if a HN is confirmed on a segment that's locked above your editing rank.
  • Waze editing standards say that in confirming a HN, the number (or the dot next to it, when editing it) should normally be centered on the roof. This is used ONLY to display where the destination is on the app's map; it may be near the road or far away. But it doesn't affect routing, so there's no reason to put it anywhere other than where the standard says.
  • Waze editing standards say that the stop point for a HN should normally be at the end of the driveway; you can find the full standard here. This point DOES affect routing, so placement matters.
  • When HNs are unconfirmed, especially in newer housing developments, it is not unusual for them to all be "piled up" in a single location. If you are trying to create a HN and get an error that it already exists, chances are good that it's hiding under an unconfirmed one, so try moving any unconfirmed ones around to see if there's something underneath.

How Waze converts a destination to a GPS point

This logic is specific to the USA. In other countries, significant differences may apply.

  1. Waze looks up the address on Google Maps. If Google recognizes the address, then the GPS coordinates of the GM pin are returned. Note that the city/state need not match exactly, as long as they are reasonably close by.
  2. The Waze map is consulted to see if there is a confirmed HN on the street with the searched name (it can be an alternate name). A mismatch in the street or city name may cause no match to be found, in which case the GM pin is used. But if there is a match, then the GM pin location (if there is one) is ignored, and the pin is set to the stop point for that HN. By design, stop points for HNs are ALWAYS on a segment of the street with the given name, they can never be elsewhere. If the Waze HN is NOT confirmed, it is ignored.
  3. The Waze map is consulted to see if there is a RPP with the same address; again, street/city must match, at least alternates. If there is, then the GPS location of the RPP is used.

How to Diagnose an Address Problem

If you get a User Report (UR) where the reporter was taken to the wrong location, you first need to determine what their destination was, and whether they entered it as an address or as the name of a business or building. This page deals only with destinations entered as an address.

  • If the user selected a calendar item to "drive to", then the address in the location field is used, so these instructions apply.

Once you have done this, you can do the following.

  1. Search the address in the Waze app (I have found this often gives a different result than Live Map, so I don't recommend using Live Map). Navigate to it. (You may want to pick a nearby point to set as your start point.) Is the pin visually consistent with where the reporter says they were directed?
  • If it is, then proceed to analyze why the pin is in the wrong place, and fix it.
  • If not, check other search results to see if one of them is consistent with where the reporter says they were taken. Sometimes you get multiple identical search results for the same address, and only one is wrong. Or there may be slight differences and the Reporter might have chosen the wrong one.
  1. If the pin is the culprit, then do the following.
  • If the pin is off by more than just a bit, then search the address in Google Maps, and see if the pin is wrong there. If it is in completely the wrong place, use the "Send Feedback" item on the menu to move the pin. (You can do this in Google Mapmaker if you prefer, but my experience is it takes a lot longer to get approved.) Depending how far off the Google pin is, you may not be able to get the right routing until this is fixed, although in most cases you can override it in Waze.
  • If the Google pin is at least approximately in the right place, AND if the correct stop point is on the named street, then select the street segment in WME and click "Edit House Numbers". Is the target house number there? If it is, select it, and see if it's confirmed (see Basics above to determine this). If not, confirm it. It's polite to fix the entire block if you have enough information to do so. See the section below on "Fixing HNs on a Block."
  • If the Google pin is at least approximately in the right place, but the correct stop point is on a different street, then delete the HN.
  • For a house on a corner where the entrance is on the side street, create a RPP at the end of the driveway (or walk, if there is no driveway in the front).
  • For a business in a shopping center, where the entrance isn't obvious from the named street in the address, the best option may be to let the GM pin prevail - that will happen if you delete the HN.
  • Make sure there is a PLR that provides access to the location specified by the GM pin.
  • If the GM pin is somewhere where this will cause routing problems (e.g. closer to the wrong PLR or a side street), you can either try to move that pin in GM, or create a RPP for the address.
  • Remember that if the Waze HN is present and isn't overridden by a RPP, then navigation will stop at the street, not at the front door of the business. This usually isn't desirable unless the business is both visible and accessible from the stop point on the street.
  • If you create a RPP. it should be positioned the same as any nonresidential place point for the business (if the address serves only one business) or at a compromise location if there are multiple businesses (center of building, main entrance, etc.).

Cache issues

Once a location has been searched in the app, the GPS coordinates are saved in the phone and will be reused it the user navigates to the same address again. It's therefore [b]essential[/b] that the user be instructed to remove the destination from their navigation history and/or favorites. Since this isn't always intuitive and can vary by app version (iOS, Android), it's best to give a link to the Reporter.

If a user has cleared the location from cache and is still getting the wrong location, but when you test the location it's right, then most likely it's an API issue with a third-party app such as Uber (link).

GM pin problems

  • Mislocated
  • Duplicates (including variants without a required cardinal)
  • Wrong or inconsistent spelling

Fixing HNs on a block

RPP problems

  • When you can't save an apparently valid RPP (the hidden layer)

API handoffs e.g. Uber

Update schedules

  • GM
  • Waze HN layer
  • GIS Sources
Retrieved from "https://beta.waze.com/wiki/USA/index.php?title=User:Ruggles76/Address-Related_Routing_Problems&oldid=143880"