User:Vectorspace/Diagnosing Update Request & Map Problems View history

This is a draft set of ideas for a new Wiki page on this topic. Motivation for this page is that there has been a lot of knowledge developed by skilled editors about how to diagnose problems on the map but that has not been well documented. New and experiened editors could benefit from this knowledge.

Existing knowledge

This information is for development and not to be included with this page.

  • Update_request
    • This page is focused on the mechanics of the issue, but not troubleshooting. It should not be expanded in order to keep it on point and simple. This draft page should complement and link from/to this page.

Introduction

Waze provides two forms of error reports within the editor. Update Requests (UR) are from drivers using the client. Map Problems (MP) are created by automated algorithms at Waze that find and point out anomalies. This page is focused on approaches and techniques to diagnose or solve these error reports.

Additional information can be found here. It is suggested that before you use techniques in this article that you gain requisite knowledge of URs and MPs by reading the first two items, Wiki pages on those subjects.

Techniques & Tools

This section is currently an outline form of notes about the types of techniques and tools that can be used for troubleshooting and diagnosing URs and MPs. It will eventually be expanded into more detailed content.

Caveats

  • You cannot diagnose every UR. Sometimes users just send in a report for no reason. Sometimes the clues you have are insufficient. Don't waste your time looking too hard. What can you do?
    • You can ask help from another more experienced editor.
    • For URs, you can send a note back to the reporter asking for more detail.

Approaches to Diagnose URs & MPs

This section provides a flowchart or process approach to diagnosing URs and MPs. It is not intended to be the correct or only set of approaches available. It might be useful for new users to consider. Eventually you will adopt your own set approachs.

User Reports (URs):

  • Observe the UR color and comment indicator (ellipsis ...).
    • Color indicates age of the UR.
    • Comment indicator lets you know dialogue on this UR has already occurred.
  • Open UR by clicking on it.
  • Scan available information in order to form potential action.
    • Observe UR Type and Reporter Comment (if any).
      • Note that many users will not select a category and it will default to general error.
      • User comments are sometimes helpful and sometimes confusing. You may need to seek clarification through a response in the comment field. Consider etiquette and canned responses to help you to politely, accurately, and quickly respond.
    • Read existing dialog, if it exists.
      • You cannot identify the reporter's Waze name from this report unless they reveal it to you.
      • Existing dialog from another editor is a warning sign to be careful. Before you interject, consider if you will confuse the situation or help. You may want to write the existing responding editor if you're not sure.
      • If the dialog shows that the responding editor is waiting for a response from the editor, consider not responding unless you have something valuable to add.
      • If the date of the last response is old, over two weeks or a month, you may consider closing out the UR due to inactivity.
    • Observe paths of both User Drive and Waze Provided Route (if they exist).
      • If both paths exist, then compare where they diverge.
        • The point of divergence of the paths may be what stimulated the UR.
          • If the Waze Provided Route is attempting to send the driver in the opposite direction, the driver may not know how to use Waze or made a mistake.
          • The user may be following a preferential route that is better than Waze's navigation. Consider if the roadway the driver took is actually of a higher capacity road than it is marked. Some infrequently edited locations have all streets where some of these should be Primary Streets or Minor Highways.
      • Consider the Waze Provided Route (Waze navigation path) by itself.
        • If the Waze Provided Route is attempting to turn the user in the opposite direction (turn them around), then Waze thinks they are going the wrong way. This could be due to the user purposefully not following the navigation directions for some reason.
      • Consider the User Drive (path user took) by itself.
        • If the path is in a place with no road, a road may be missing.
        • If the path circles a building or special location, the user may be expecting a visible landmark where none exists.
        • If the path diverges from the road in a straight line, particularly in mountainous areas, it is likely that the GPS signal for the driver was lost. This can cause waze to attempt to assume it is on nearby roads, giving them directions that make no sense. In such cases there is likely no error, just a bad GPS signal. Write dialog to the user letting them know this.
        • If the path on a highway seems to take an exit ramp, then route right back on the highway on the onramp, Waze may have faulty speed data causing this navigation error. If possible, make sure to turn the stright-through turn restriction arrow to red to prevent this routing path. Only do so for ramp-only intersections that would not harm other local routing (such as those attached to frontage roads that must have straight-through routing).
    • If you have no User Drive or Provided Route, consider the location of the UR
      • Is there something nearby the UR that looks out of place?
      • Is there a missing road?
      • Check the turn restrictions in the area.
      • Is there a landmark that needs to be inserted as an Area Place?
  • Exit the UR and look around the area to see if you might find other URs from this same driver.
    • While you cannot be sure that the reports are from the same driver, often times a driver will issue multiple reports on a particular problem. Some may contain more information or they all may be considered together to gain more insight.
    • With a significant issue affecting multiple drivers, especially in a high-population area, you may find multiple URs from different drivers on the same issue.
    • If you do not find a related UR, return to focus upon the original UR.
  • Take action on the UR
    • If you can clearly fix the problem, do it!
    • Consider doing nothing.
      • if another editor has been involved consider doing nothing unless you know you can fix the issue or contribute to the solution dialog. If you can fix the issue, then do so.
    • If you cannot identify or fix the problem.
      • Consider writing dialog to the driver/reporter to seek additional information.
      • If you think you could use help from another editor you know, contact them via another means, such as Private Message (PM), and ask for help resolving the UR.
      • If you know the problem cannot likely be resolved, consider closing it.
    • If existing dialog occurred in the discussion area:
      • If a new response from the driver (reporter) exists, see if you can fix the issue.
      • If there is a request for information from another editor that is recent, then do nothing and wait for a reply. Consider asking more information if you think it is needed. Leave the UR open.
      • If the last request from another editor is old, consider closing the UR.
  • Leave the UR
    • Leave the UR "Open" if it has not been resolved.
    • Mark the UR "Solved" if it has been resolved.
      • Before you mark it "Solved" and save, it is considered good protocol to put a note in the comments field how you solved the UR, what you did. This message goes to the reporter and is available for other editors to see in the comments area.
    • Mark the UR "Unidentified" if you cannot solve the UR. This sends a note to the reporter that more information is needed.
      • Only make a UR "Unidentified" if you've considered all the information, wrote to the driver/reporter, or realize immediately through your experience that the UR cannot be resolved.

Discrete Observations & Tools

This section provides a set of discreet observations and tools you might use to diagnose URs and MPs. Observation: User Comment

  • If you're lucky, a user will enter in a comment about their issue. This is displayed as "Problem:" in the map editor when you select a UR. For example, "Problem: misspelling: Paseo del Paisano." Here the user is clearly indicating the road name is misspelled. Other comments can be less clear.

Observation: UR / Map Issue type

Users submitting URs can choose a particular type when selecting "Map Issue." These listed below with suggested approaches:

  • General map error
    • Unknown - Seek additional information from elsewhere in the UR.
    • Look for a map anomaly in the area of the UR, such as a missing road,
  • Turn not allowed
    • Check the Waze Provided Route to see if Waze suggested an impossible or illegal turn. Add turn restrictions as needed.
    • ?
  • Incorrect junction
    • Are two roads that should connect not connected by a node on the map? If so, add a node junction between these two roads.
    • ?
  • Missing bridge or overpass
    • See Incorrect Junction
    • Are two roads that are not connected (e.g., with an underpass/overpass) connected on the map? If so, remove the junction and adjust levels of the segments.
    • ?
  • Wrong Driving Directions
    • This is one of the most difficult URs to resolve because the directions being reported could be a long distance from the UR location and you do not have the whole path available to you.
    • Wrong driving directions may be the result of a faulty Point of Interest (POI) search, wrong search results, or an error by the user.
    • Check the Waze Provided Route and the User Drive paths.
    • ?
  • Missing exit
    • Is there a missing road or ramp in the region of the UR? If so, correct it.
  • Missing road
    • Is there a missing road or ramp in the region of the UR? If so, correct it.


Observation: UR Location

  • UR location is the pin placement location
  • UR location is usually where the user presses the "Map Problem" report button in the client. It may not be the exact GPS coordinates and may snap to the nearest existing map road nearby the user.
  • Potential knowledge gained
    • Is there an obvious map error at this point?
      • Road missing?
      • Potential routing error difference between the Waze Provided Route and the User Drive?
      • Road geometry wrong?
      • Place Area missing?
      • ?

Observation: User Drive & Waze provided Route

Waze attempts to record a partial path for both the User Drive and the Waze Provided Route around the region of the UR. If the user is not navigating to a location, no Waze Provided Route can exist. If the user is stationary or some other error occurs, you will not always see a User Drive.

  • Comparing User Drive & Waze Provided Route
    • Are they the same?
      • If the two paths are the same, you will gain little information from this comparison. Consider the path itself as mentioned below.
    • Are they different?
      • This is a potential routing issue, at least in the mind of the user. Some differences are expected because Waze may have a different path in mind.
      • Look at the point of departure between the two paths to see if there is a map error.
  • User Drive by itself.
    • Look along the path of the User Drive to see if you can find a map anomaly.
    • Did the user drive an unusual path that may show they were confused by Waze in some way?
    • Did the user drive by landmarks (Area Places) that they may thought to be missing?
    • ?
  • Waze Provided Route by itself.
    • Look along the path of the Waze Provided Route to see if you can find a map anomaly.
    • Does the path take an unusual route that might have seemed wrong to the user?
    • ?

Observation: Text To Speech (TTS) Commands

  • A turn command on a straight road
    • Zoom in close to the location and look for errant nodes that may cause turn instructions, but that are not visible at wider zoom levels.
    • ?

Tool: Live Map Live Map is a tool that can simulate routing in Waze. Within Live Map, you can select an origin and destination and Waze will create three routes between these locations. This is a great diagnostic tool to try to reproduce routing problems that users may have experienced.

  • Routing destination problems
  • Mention that traffic can change answer
  • Inability to route
    • The road network may be disconnected in some way by a faulty road or node so there is no connectivity between the origin and destination parts of the map. In such cases attempt to use Live Map to navigate between shorter different segments of the likely path as a way to isolate where the disconnect exists on the map.

Tool: Validator

  • Validator is a script tool that you may consider using. It is a fairly advanced tool that should not be used by new editors.
Retrieved from "https://beta.waze.com/wiki/USA/index.php?title=User:Vectorspace/Diagnosing_Update_Request_%26_Map_Problems&oldid=71884"