Update Requests

Return to the editing manual

Images are going to be added to clarify these instructions.

The information here is what is known at this time and subject to change.

This article covers Update Requests submitted by Wazers and they appear in the Waze Map Editor as a colored balloon with a white Waze icon. Balloons without a white Waze icon are automated Map Problem reports by the Waze system and are covered under Map problems.

Overview

An Update Request (UR) is what the Waze client app calls a "Map Issue." When a Wazer submits a map issue for wrong driving instructions, or a disallowed turn, etc., the icon with the small Waze icon is added to the editing map in the Update Requests layer. Due to the Waze terms of service and privacy policy, the username of the Wazer is not displayed. The new communication system added to the map editor enable a 2-way conversation between the Wazer reporting the error and the editor.

When an Update Request is marked "Solved" or "Not Identified," an email is sent to the reporting Wazer's registered email address showing the username (not email) of the editor who closed the issue. This secondary communication method enables the reporting Wazer to see the user name of the editor who closed their report, and to make contact in the forums or by private message if they wish.

In the Waze Map Editor, Update Requests contain information about the route the user drove as well as the route Waze had given them. This makes diagnosing the report much easier in many cases, especially for Incorrect Junction and Wrong Driving Directions reports.

When you first click on an Update Request pin, the map will display a window of information at the top of the screen, overlaying part of the map. If you press the show button, the screen will recenter and zoom into that Update Request.

This initial view tries to get you to a spot where you can see the most information. However, you may need to zoom in or out and pan around to see all of the requested route and drive information. In a few cases, the editor may zoom in to a spot somewhat distant from the actual Update Request information, in which case you may need to zoom out far enough so that you can recenter the map manually on the relevant spot.

Note that while this Update Request window is visible, other Update Request and Map Problem icons will appear as faint images until the Close button is pressed.

Interface Elements

The color of the Update Request pin, just like Map Problems, are indicative of something. In the case of Update Requests, it is the age of the update request. See below for details on the several variations of the Update Request pin:

A yellow update request has been open for 0-5 days.

An orange update request has been open for 6-14 days.

A red update request has been open for 15 days or longer.

A white balloon attached to any request balloon indicates a conversation in progress.

A yellow update request has been open for 0-5 days and has a conversation in progress.

An orange update request has been open for 6-14 days and has a conversation in progress.

A red update request has been open for 15 days or longer and has a conversation in progress.

The Update Request changes to this icon when you mark an Update Request as "Not Identified" because you cannot locate a reason for the request or the request is unclear. Not identified update requests are visible on the map for up to seven (7) days after closure.

This is a Solved Update Request which has a conversation. Solved update requests are visible on the map for up to seven (7) days after closure.

When you click on an Update Request pin, the top portion of the map display area is taken over by the information for the update request.

The top bar of the Update Request states that this is a User Reported Problem.

Meta Info

In the top left of the screen you will see the problem description from the user (if entered) and when the user reported it.

Display related (show)

The top right of the display will include this hyperlink that will recenter and zoom the display into the area covering the Update Request. The display can also be manually zoomed and panned to the area.

Drive and Route

On the left will be zero, one, or two checkboxes, depending on the data Waze was able to capture from the app. Each one enables you to show the Route which Waze requested the user take, the user's actual drive, or both. Note that due to privacy concerns, the route driven will only be about 0.1 miles (probably longer) in length, and will not include the very beginning or end of the user's drive. This may make it difficult to truly understand where the user actually ended up driving if there are a number of intersections past the end of the route indicator.

Report As

While any editor can reply to and work on URs, the minimum editor rank to close an Update Request is 2. Rank 1 editors need to work with a higher ranking editor to complete the UR process.

At the bottom of the Update Request area is where you can take an action on the update request. You can leave it open, or mark it as Solved or Not Identified. This action, once you Save it, marks the Update Request as closed in the system, and neither you nor anyone else will be able to change the status again.

Closed Update Requests are visible on the map for up to seven (7) days after the closed date using the green icon. Comments added after the closed date will reset the closed date and extend the visibility of the UR.

Solved

If you are able to identify a reason for the reported issue, and if you are able to fix the problem in the editor, fix the problem and save your changes. Then mark the update request as Solved.

Not Identified

For various reasons, such as lack of detail provided by the Wazer, or conflicting route vs. drive trace information, you may not be able to identify the source of the reported problem. In these cases, you should attempt to initiate a conversation with the reporter.

If a conversation has already been initiated by another editor and a reasonable time has passed since last hearing from the reporter, suggest that it be closed. Wait for that editor to contribute prior to taking further action.

If you do not receive a response within a reasonable period of time (minimum one week) after asking the question, you may consider marking the Update Request as Not Identified.

Also, users may sometimes report problems that are valid problems, but not problems that can be fixed in the editor – for example, problems with the app not loading map tiles properly. These should also be marked as Not Identified, with an explanation to the reporter that the reported issue cannot be fixed in the editor.

Before Saving

Before Saving, enter a comment about why the request is being reported/closed in the manner you have chosen and Send that comment before clicking Save.

Once you choose one of these selections, you need to click the Save button to save your changes. As soon as you click Save, any Update Requests and map edits you updated since the last save will be saved, and an email is sent to the Wazer who submitted the update request.

Close

Far to the right of the Update Request information area is a Close button. This button doesn't actually mark the Update Request as closed but simply dismisses the interface for reviewing the update request. It also hides the route information displaying on the map. This button is useful for clearing up the map display area while you work on solving the Update Request. Click on the Update Request again to bring up the details so you can mark the Update Request as Solved or Not Identified.

Driven and Requested Routes

The route that the user received from Waze will be shown in purple, just like in the app. The route that the user actually drove is in bright green.

If you cannot see the direction arrows or direction of the route, you may need to zoom in. Once zoomed in, the lines will show the direction of travel. Additionally, at each junction on the requested route (purple), a turn marker will be shown.

One of the following turn instructions is placed at each junction on the purple request route line:

• - Continue straight/forward (client doesn't give this instruction by design)
• - Turn right
• - Turn left
• - Exit/Keep right
• - Exit/Keep left
• - Roundabout numbered exit turn
• - Roundabout left turn
• - Roundabout right turn
• - Roundabout straight through
• - Roundabout "u-turn" (exit the way you came in)
• Blank Arrow - junction error (see below)

Note that these turn instructions are relative to the direction of travel (the arrows inside the purple line). For example, in the upper left corner of the screenshot above, the route was heading west and then turned south, so the icon for a left turn is shown, even though the arrow is pointing away from the direction of travel. In other words, the icon indicates a turn to the left relative to the previous direction of travel, not a turn to the west.

Diagnosis

Route Diagnosis

Using the information provided by any divergence of the requested route and user drive, you can look for turns which may need to be allowed at intersections.

If you are able to determine a fix for the user's report, you may click the Solved action on the Report As section and then click Save.

There will be times when the user description for the problem is provided, but does not seem to relate to the portion of their route you see on the map. This typically happens when the driver initially looks at their overall route and they see a problem at the end of the navigation turn list or on the map. They mark the problem there at the beginning of their trip, but don't realize an editor only sees about a mile of their route and nothing else about their trip. There is nothing you can do in these cases if they did not provide enough information to identify the problem area without the map route visual so mark these as "Not Identified". The original reporter of the problem may then reply directly to you or come to the forums to better explain what they saw.

Turns Diagnosis

Orientation

Example "turn left" instruction.

When reviewing the route, it is easy to be confused by the black turn direction arrows displayed at junctions along the Waze recommended route. Note that these will display the turn for the direction being traveled. Because the Waze Map Editor uses north-up orientation, for a route going south, these turn arrows will appear to be backwards. You need to put yourself in the orientation of the driver. Details are covered in the Driven and Requested Routes section above.

Continue arrow

Remember that the "continue" arrow is merely informational. At this time, the routing server does not give the client any information about what to say for these. In the future, this feature may be enabled for specific circumstances.

Blank arrow

There are circumstances which will cause Waze Map Editor to show a blank turn arrow tile at a junction.

The blank instruction means the routing server failed to provide an instruction in this node. The client treats this as a non-audible continue straight instruction, which usually means the instruction the user hears and refers to is the next instruction after the blank one.

The reasons for this are:

1. There is something invalid with the junction
   • It could have a short circular segment
   • Very distorted in some way
2. There is a bug in the routing server when handling this node.

If the reason is #1, it should be quite obvious and fixable in the editor. If not, it may be #2, in which case you will need to open a support ticket.

Conversations

Two-way communication with the user who submitted a Map Issue (the Reporter) from the App is possible via a feature called Conversations. Newly submitted Update Requests will have no replies and so the Conversations button will show "0" until replies are added. The Conversation feature allows editors to ask for clarification of the Reporter, and allows the Reporter to respond back. This conversation can go on until the issue is clarified and resolved or determined to not be solvable.

Note: You will need to have Update Requests checked in the Map Layers to view open conversations.

Interface

To the right is an example of a conversation with several replies from both an Editor and the Reporter. The conversation button will show the total number of replies or comments which have been submitted by Editors and the Reporter for that Update Request.

The Reporter's comments are shown in blue bands and the Editors are shown in white/gray bands. The colors alternate between blues and white/gray if the Editor or Reporter enters more than one comment before the other person responds.

Note: If you comment on your own Update Request (you opened it as a Map Issue in the app), you will show as the Reporter in the conversation thread.

Usage

To open an Update Request conversation, click the Conversation button. The Conversation button alternately opens and closes the Conversation panel. Collapsing the Conversation panel allows you to see more of the map.

Add a comment or question into the box marked Enter comment. To submit the new comment, click the Send button. You may enter as many comments as you like.

When you enter a comment, the system will automatically set you to Follow the Update Request conversation. You may click the Unfollow button if you do not wish to be notified of replies. See the Notifications section below for details.

Once a comment is entered, it cannot be removed from the Update Request Conversation. Your comments will be visible to all editors.

You may elect to receive notification of comments and replies on an Update Request by clicking the Follow button. You can do this on any Update Request on the map. Click the Unfollow button to stop receiving reply notifications.

Any Editors who are Following an Update Request can also add comments from the Waze App Inbox message they receive after any reply is added to the Conversation.

It is likely that you will find the drive and route data to be very helpful in resolving Update Requests without needing to request additional information from the Wazer who submitted the Map Issue.

Notifications

Here is a quick summary of notifications which the system sends:

• If you are the Reporter

1. You will receive an email to your registered email address (if you have one) and a message in the Waze App Inbox when another Editor adds a comment to the UR Conversation
2. You will receive an email and a message in the Waze App Inbox when an Editor (who is not you; see note below) closes (marks Solved or Not Identified) the Update Request

• If you are Following an Update Request Conversation (as an Editor)

1. You will receive an email and a message in the Waze App Inbox when either another editor or the Reporter adds a comment to the Conversation
2. You will receive an email and a message in the Waze App Inbox when an Editor other than you closes (marks Solved or Not Identified) the Update Request

The resolution process / Etiquette

When you respond to user reports, you are interacting with the original reporter, and you may also be interacting with other Waze editors who respond to the same request. The recommendations in this section are designed to:

• Promote harmony between editors and the reporter, and improve the good reputation of Waze and its user community
• Promote harmony among editors and prevent conflict or duplication of effort
• Engage the reporter productively, efficiently, and courteously in the problem resolution process

Below is a description of the issues that require finesse in your response etiquette to prevent or resolve.

Missing information

Many reporters do not describe the map issue well enough for an editor to find the root cause of the issue and resolve it. Editors must find a way to engage the reporter to get additional information. There is a balance between composing a request that gets the responding editor all needed information with the most exacting accuracy, and overwhelming the reporter. There are many ways to overwhelm the reporter! Requests for too much detail. Jargon or other overly technical descriptions of the information requested. Exacting specifications for the answer. Discourteous language or cultural issues. With the exception of the latter, each of these might be requested in good faith, and may even be somewhat necessary - but they may turn the reporter off and cause the reporter to disengage. As an editor requesting information, your job is to present the request in such a way that the reporter is willing to work with you, while getting the reporter to provide you with the right information to solve the problem reports where they initially lack enough information to properly analyze.

Style/boilerplate

Under most circumstances, use short response texts, as reporters are unlikely to read longer texts.

The New Jersey and Pennsylvania editors have developed two boilerplate text approaches that you should consider using. With experience, you will probably be able to find an approach based on their examples that works optimally. Note that "optimally" may mean that you still only get a low success rate in getting responses or getting workable responses. However, the alternative is an even lower response rate, or lower quality responses, or both.

The URComments-Enhanced (URC-E) script implements a similar boilerplate approach. However, be careful, as the text is not always an exact match for the situation. The automated boilerplate's ease of use may lull you into not tailoring the text for the situation.

You can find a list of boilerplate responses published by various editors in the Sample responses category list page.

Non-responsive reporters

A clean map, with few open reports and a low percentage of old reports, is a good goal. However, in practice, we often have "littered" maps, with many older reports (orange and red icons). This is partially due to manpower, and partially due to missing information, causing the report to stay open even after an editor starts working on it.

The best way to reduce this clutter is to speed up the cycle of report resolution. But this has to be done without prematurely closing reports that could still be worked on, with resulting map or routing improvements.

The guidance below will help you engage reporters initially, provide them opportunities to work with you, but not allow reports to remain open indefinitely. In particular, be sure to review the flow chart for responding.

Multiple editors

Our standards of etiquette call for allowing the first responding editor to take ownership of problem resolution as a general matter, although individual states or regions may have different approaches that should be followed. Other editors should not step in unless they think the owner needs help (whether the owner realizes it or not), or has abandoned/lost track of the report over time. If you see reports being mishandled by a particular editor -- whether in the language of interaction, analysis and problem-solving skills, the map edits taken toward resolution, or an abusive own/abandon cycle across many report -- you should still avoid direct confrontation. Consider that your responses may trigger a defiant response, especially in the public nature of the report conversation technology. Instead, you may want to use private messages to make constructive suggestions. If the other editor takes offense, disengage and ask the Regional Coordinator for assistance.

Closing the Update Request

Before marking an Update Request as Not Identified or Solved, enter a conversation message stating what you did to resolve the problem, or why the request is being marked as Not Identified.

Flowchart

Once you add a comment or question to an Update Request that requires a response from the Reporter, it is recommended that you wait at least seven (7) days for a response. If there is no response, then you will need to decide how to handle the Update Request as best you can from the data available. (This situation is no different than before Conversations existed.)

This may mean you have to close the report as Not Identified. In that case the Wazer who submitted the Map Issue will be notified via email when their Update Request is closed. They can still try to contact you through a private message if they do have more information.

When you come across an Update Request that has an on-going conversation, do not close that UR unless you were separately asked by either the Reporter or other Editors via email or private message that it is OK to do so.

If the Update Request conversation has no updates for at least seven (7) days, and the last message was from an Editor, you may try to solve the request and mark it appropriately. If the last message was from the Reporter, add a note so that the original Editor receives another message, which should "wake them up" and complete working on the UR. If another seven days goes by with no action, you are free to solve/close the UR as appropriate.

Return to the editing manual