1731 results found

1. New Place type "City / Town area": a polygon for where the town name is shown, with an editor-chosen arrival point

   Today, the only way to put a town or village name on the app map is the city name carried by road segments. Editors control neither where that label is drawn nor where a search for the town leads. As a result, some communities bend their naming rules only to get the label near the town centre. In France, for example, the city name is set only inside the built-up area, with a different rule outside it. Yet the city on a segment has no effect on routing.

   Proposal: a new Place type "City / Town area", drawn as a polygon in WME (restricted to a minimum rank, e.g. L4+):
   1. The polygon sets the "urban" zone where the town name is displayed on the app map, independently of the city names on segments. Without it, the name can appear in a forest, kilometres away from the built-up area.
   2. The polygon itself is NOT drawn in the app: it only positions the label, so it never hides the polygons of real places.
   3. It carries an arrival point chosen by editors (town hall, main square). A driver who searches for the town is sent there.
   4. It can represent villages and hamlets that are not municipalities, so they become searchable without inventing a city on segments.

   Benefits:
   - Segment city names can follow the official address (the municipality, as in national address databases): one naming rule instead of two, fewer alternate names, cleaner house numbers.
   - Town labels and search results land where people expect them.
   - The same tool works in every country.

   Not only a French issue. The US, the UK, Spain, Italy and Czechia also keep the city name on segments only inside built-up areas (the US wiki says it is "to keep city names from sprawling"), and they work around the missing sub-cities with plain Place points. This Place type would solve the same problem for them, and it would cover the long-standing request for editable sub-cities.

   Related: "Create UI allowing editing of city center position" (https://waze.uservoice.com/forums/59225/suggestions/42317575) covers only the centre point. This proposal adds the display area and the non-municipal villages.

   Today, the only way to put a town or village name on the app map is the city name carried by road segments. Editors control neither where that label is drawn nor where a search for the town leads. As a result, some communities bend their naming rules only to get the label near the town centre. In France, for example, the city name is set only inside the built-up area, with a different rule outside it. Yet the city on a segment has no effect on routing.

   Proposal: a new Place type "City / Town area", drawn as a… more

   167 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   6 comments  ·  General  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Looking into the suggestion  ·  AdminJoeny Purisima (xWF) (Admin, Waze) responded

2. Add notes fields to map element history (Maybe move edit history and notes to its own tab too)

   Add reason for editing and source(s) fields for map elements. (Also, maybe move the edit history to its own tab when a map feature is selected.)

   With the increasing detail of the map to include many permanent hazards, in addition to the road segments, places layer, and map notes, it would be beneficial if an editor could include a blurb when creating or editing a map element with an explanation, reason, and optionally, public source for the change.

   For example, in my area we have a ton of elements (school zones, cameras, hazards) that are being maintained by many editors. Many times, each editor that comes to review a nearby user report must "start from 0" to confirm the accuracy of nearby map elements.

   If HQ could add the following optional field or fields to each map element (segment, place, PH, etc) it would allow each editor to include a short note and source for their edits, hopefully allowing map maintenance tasks to go more smoothly:
   REASON FOR EDITING: A free text field that allows an editor to leave a note attached to the selected map element.
   SOURCES: A short free text field that allows an editor to leave the source for the edit (URL, street view, user report)

   The obvious question is why not just use a Map Note?
   
   In my experience, adding a map note to explain the reason for every map feature's existence and source of the data is very cumbersome and overkill. We just need a short note attached to the PH/segment/place to document why it was added/changed and/or where the information came from. Additionally, the map note isn't linked to a specific feature, so it not always obvious what feature the map note refers to. Finally, if each new or changed map element required a map note to document the reason for adding the new map element and/or the source for where the map element came from, it would quickly clutter the map note layer to becoming indecipherable.

   Add reason for editing and source(s) fields for map elements. (Also, maybe move the edit history to its own tab when a map feature is selected.)

   With the increasing detail of the map to include many permanent hazards, in addition to the road segments, places layer, and map notes, it would be beneficial if an editor could include a blurb when creating or editing a map element with an explanation, reason, and optionally, public source for the change.

   For example, in my area we have a ton of elements (school zones, cameras, hazards) that are being maintained by many editors.… more

   52 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   3 comments  ·  cartouche  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Reason for rejecting the PUR

   I receive many complaints from new editors who find it frustrating that their Place Update Requests (PURs) are rejected by other editors without even receiving a notification, and especially without any explanation of why the request was denied.

   "How are we supposed to know what we did wrong if we're never told the reason?" is by far the complaint I hear most often.

   Because of this, I believe this is both a very valid and necessary improvement. I also believe Waze itself would agree, since the newer Suggest an Edit feature—such as adding house numbers or creating a new road—already includes the option to provide a reason for rejecting an edit. However, in practice, this still doesn't work as intended, because the editor who submitted the suggestion does not receive the rejection reason provided by the reviewing editor.

   I receive many complaints from new editors who find it frustrating that their Place Update Requests (PURs) are rejected by other editors without even receiving a notification, and especially without any explanation of why the request was denied.

   "How are we supposed to know what we did wrong if we're never told the reason?" is by far the complaint I hear most often.

   Because of this, I believe this is both a very valid and necessary improvement. I also believe Waze itself would agree, since the newer Suggest an Edit feature—such as adding house numbers or creating a new road—already… more

   74 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   5 comments  ·  community  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Not Planned [WME]  ·  AdminJoeny Purisima (xWF) (Admin, Waze) responded

   Thanks for your feedback. At this time, this doesn't fit on our roadmap, but we'll keep it in mind for future product planning.

4. Display the capture date of Satellite imagery

   There are solutions to find the capture date, but they are cumbersome and outside of WME.

   From discussions with staff, I've been told that the date is present in the data Waze receives from Geo, so please please please surface the capture date of Satellite imagery in WME.

   161 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Looking into the suggestion  ·  AdminElla (Waze Team) (Admin, Waze) responded

   Great timing! We’re currently working on the display the capture date of Satellite image. Keep an eye out for updates on the WME.

5. Show Google POI uploaded photos in Waze Map Editor (WME)'s Google Places tab

   Currently, Waze Map Editor (WME) allows editors to view and edit Google Places (POIs) and submit names for approval. This is an incredibly helpful feature for keeping our map aligned and accurate. However, one crucial piece of data is missing: the user-uploaded photos attached to these Google POIs.

   We are requesting the ability to view these Google POI photos directly inside WME (for example, in the Google Place details panel when a Google POI is selected or linked).

   Why this is needed (The Value)

   1. Better Visual Verification: Names and locations can sometimes be ambiguous. Being able to see photos of the storefront, building facade, or signage directly inside WME gives editors immediate, definitive proof of the business's identity without leaving the editor.

   2. Reduces External Searching: Right now, editors often have to open a separate tab, search for the place on Google Maps, and hunt for photos manually to verify a place. Bringing this data into WME streamlines the workflow significantly.

   3. Improves Map Accuracy: Visual confirmation from photos prevents incorrect links and ensures that local places are accurately mapped, leading to a better routing and search experience for Wazers on the road.

   Please consider integrating the Google POI photo gallery view into the WME interface!

   Currently, Waze Map Editor (WME) allows editors to view and edit Google Places (POIs) and submit names for approval. This is an incredibly helpful feature for keeping our map aligned and accurate. However, one crucial piece of data is missing: the user-uploaded photos attached to these Google POIs.

   We are requesting the ability to view these Google POI photos directly inside WME (for example, in the Google Place details panel when a Google POI is selected or linked).

   Why this is needed (The Value)

   1. Better Visual Verification: Names and locations can sometimes be ambiguous. Being able to see photos of… more

   84 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   On the roadmap  ·  AdminJoeny Purisima (xWF) (Admin, Waze) responded

   We plan to work on Show Google POI uploaded photos in Waze Map Editor (WME)'s Google Places tab in the near future.

6. Feature Request – Increase the 10-Change Limit for “Suggest an Edit”

   Background

   Currently, Waze Map Editors can use the “Suggest an Edit” feature to propose changes to a segment that is locked at a higher level or otherwise outside their editing permissions. These suggestions can then be reviewed by an editor with the appropriate permissions, who can approve or reject the proposed changes.

   However, the current limit of 10 changes per suggestion creates a significant challenge when editors need to make multiple corrections to a lengthy road segment.

   The Issue

   For example, consider a lengthy road segment that requires several corrections to its properties. An editor may need to update its road name, road type, speed limit, directionality, elevation, or other relevant attributes.

   When the required corrections exceed the 10-change limit, the editor cannot submit all the necessary changes as a single suggestion. This interrupts the editing process and makes it difficult to communicate the complete set of intended corrections to the reviewing editor.

   As a result, editors may have to split the corrections into multiple suggestions, where possible, or leave some corrections incomplete until the earlier suggestions have been reviewed. This can lead to unnecessary back-and-forth, additional review effort, and delays in completing the required map improvements.

   This limitation becomes particularly inconvenient when correcting lengthy road segments that require several related changes to bring them into compliance with mapping guidelines.

   Proposed Enhancement

   We request that the WME team consider revising the current 10-change limit for the “Suggest an Edit” feature.

   Possible solutions include:

   Increase the limit: Raise the maximum number of changes permitted in a single suggestion.

   Remove the limit: Allow editors to submit all applicable changes to a segment in one suggestion, subject to the existing review and approval process.

   Introduce a configurable limit: Establish a higher limit that can accommodate more complex corrections without compromising the review process.

   The objective is to allow editors to submit a complete and coherent set of corrections for a segment rather than being restricted by an arbitrary number of changes.

   Benefits

   Implementing this enhancement could:

   Enable editors to submit complete corrections without unnecessary interruptions.

   Reduce the need to create multiple suggestions for the same segment.

   Simplify the review process for senior editors by presenting all related changes together.

   Reduce repetitive work and unnecessary back-and-forth between editors.

   Improve editing efficiency and help complete map corrections more quickly.

   Preserve the existing approval and rejection mechanism, ensuring that proposed changes remain subject to appropriate review.

   Previous Discussions

   This issue has been raised on multiple occasions during community meetings. However, a practical resolution has yet to be implemented.

   We would appreciate it if the WME team and the community could revisit this limitation and evaluate whether the current restriction remains necessary or whether a more flexible approach could be introduced.

   Conclusion

   The “Suggest an Edit” feature is an important mechanism for enabling editors to contribute to map improvements even when they do not have direct editing permissions. However, its usefulness is reduced when the number of changes required for a legitimate correction exceeds the permitted limit.

   We request the WME team's consideration of increasing or removing the 10-change limit so that editors can submit complete, meaningful corrections while retaining the existing review and approval safeguards.

   Thank you

   Background

   Currently, Waze Map Editors can use the “Suggest an Edit” feature to propose changes to a segment that is locked at a higher level or otherwise outside their editing permissions. These suggestions can then be reviewed by an editor with the appropriate permissions, who can approve or reject the proposed changes.

   However, the current limit of 10 changes per suggestion creates a significant challenge when editors need to make multiple corrections to a lengthy road segment.

   The Issue

   For example, consider a lengthy road segment that requires several corrections to its properties. An editor may need to update its… more

   28 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   2 comments  ·  community  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

7. In WME beta, allow editors to "change" their user level

   As of now, if we want to test certain features in the beta WME, like suggest an edit, or curated tasks for L1 editors we need to have a test Waze account at L1 and then request that this account have access to the beta editor thru a CAR form. Creating these extra accounts and requesting special beta access takes time and effort. A solution to this problem would be a setting in the Beta WME where we could choose how we want to test. As a level 1,2,3, etc. Problem solved; anyone with access to the beta WME can test any new functionalities designed for new editors. Of course, this comes with certain controls: a level 3 cannot test as a level 4, only 1,2,3, and so on.

   As of now, if we want to test certain features in the beta WME, like suggest an edit, or curated tasks for L1 editors we need to have a test Waze account at L1 and then request that this account have access to the beta editor thru a CAR form. Creating these extra accounts and requesting special beta access takes time and effort. A solution to this problem would be a setting in the Beta WME where we could choose how we want to test. As a level 1,2,3, etc. Problem solved; anyone with access to the beta WME can… more

   54 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   Not Planned [WME]  ·  1 comment  ·  General  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

8. Add selectable traffic light icon options & updated TTS for flashing signals

   In order to be more hyperlocal, please add selectable traffic light icon options to WME that would then display in the app at intersections where flashing yellow (warning) lights are erected or those that have flashing red lights (stop). In some areas, red flashing lights exist and do indicate it's a stop but from a TTS and visual perspective, "Turn left|right at the flashing light" is much more hyperlocal than turn at the stop sign, when a stop sign might not actually exist there.

   An example of said light: https://beta.waze.com/en-US/editor?env=usa&lat=31.77078&lon=-94.19763&marker=true&zoomLevel=19
   Streetview: https://maps.app.goo.gl/biqxPWVDQmM18TTE6

   Editors could easily provide plenty more examples where needed. Thank you!
   Yellow flashing lights are an indicator that a significant (major) junction is ahead where cross-traffic stops but your lane of travel doesn't. Again, another great, hyperlocal option here for display purposes and for TTS to say, "At the flashing light..."

   This would be another key differentiator for Waze and provide enhanced landmark-based routing & navigation.

   In order to be more hyperlocal, please add selectable traffic light icon options to WME that would then display in the app at intersections where flashing yellow (warning) lights are erected or those that have flashing red lights (stop). In some areas, red flashing lights exist and do indicate it's a stop but from a TTS and visual perspective, "Turn left|right at the flashing light" is much more hyperlocal than turn at the stop sign, when a stop sign might not actually exist there.

   An example of said light: https://beta.waze.com/en-US/editor?env=usa&lat=31.77078&lon=-94.19763&marker=true&zoomLevel=19
   Streetview: https://maps.app.goo.gl/biqxPWVDQmM18TTE6

   Editors could easily provide plenty more examples where… more

   151 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   5 comments  ·  General  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Not Planned [WME]  ·  AdminElla (Waze Team) (Admin, Waze) responded

   Thanks for your feedback. At this time, this doesn't fit on our roadmap, but we'll keep it in mind for future product planning.

9. Introduction of construction zones covering significant areas and time periods in WME

   On various occasions, we editors come across large construction zones that are difficult for us to manage. Either they are very long, as on motorways, and in some cases extend over 10 km or more. Or they affect larger areas where, for example, residential quarters are being developed or streets within towns are being rebuilt.

   In both cases, we editors are frequently faced with a large number of user requests. Entrances and exits – or roads in general – are reported as closed today, then as open again in two weeks’ time, whilst another road is reported as closed in the meantime. Or reports are submitted regarding new, modified or lifted speed limits that are difficult to verify.

   My suggestion is to introduce a construction zone in Waze that can be defined in terms of both location and duration. My proposal is modelled on the possibilities offered by the newly introduced school zones. For roadworks, an editor could define a geographically limited zone, for example along a motorway construction site or around another area where extensive and long-term roadworks are taking place. This could be subject to a time restriction, as announced, for example, by the road authorities.

   Users entering or approaching this area would receive a one-off audible warning stating ‘major roadworks ahead’, accompanied by the message ‘Caution! Please observe the altered traffic diversions and speed limits!’, provided they are travelling through this zone with active routing. A suitable visual display would accompany the message. The warning messages could be standardised and, if necessary, manually adapted to the situation by the editor. Users are informed at an early stage of any changes in the situation at major construction sites and no longer need to submit individual reports on this.

   Only experienced editors (L4+) and status statemanagers or higher should be permitted to set these roadworks zones, in order to ensure reliable operation.

   On various occasions, we editors come across large construction zones that are difficult for us to manage. Either they are very long, as on motorways, and in some cases extend over 10 km or more. Or they affect larger areas where, for example, residential quarters are being developed or streets within towns are being rebuilt.

   In both cases, we editors are frequently faced with a large number of user requests. Entrances and exits – or roads in general – are reported as closed today, then as open again in two weeks’ time, whilst another road is reported as closed in… more

   31 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  General  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

10. Variable Speed Limit Segment Attribute without Supporting VSLs

    Currently, Waze does not support time-based speed limits or variable speed limits within the client. Implementing such a system alone is difficult, especially if variable speed limits are purely dynamic. However, I have noticed an existing feature that could be extended to partially support this functionality.

    Whenever a user utilizes a roadway with dynamic tolling, their exist a feature within the toll pricing files that alerts motorist that prices may change in real time (and thus are directed to watch the signs for the correct price). I believe something similar for variable speed limits could be done using segment attributes. For instance, if a segment has a variable speed limit, editors would check a segment attribute box stating “variable speed limit” or something similar (such as headlights, unpaved, next to HOV lane, etc). Users would receive a similar alert to dynamic tolling that speed limits are variable and may change in real time without having to support the true value of the dynamic speed limit in the app.

    This could even work in tandem with VSLs that have a known time, such as the proposed upcoming time based speed limits, but I’m getting a bit ahead of myself.

    Currently, Waze does not support time-based speed limits or variable speed limits within the client. Implementing such a system alone is difficult, especially if variable speed limits are purely dynamic. However, I have noticed an existing feature that could be extended to partially support this functionality.

    Whenever a user utilizes a roadway with dynamic tolling, their exist a feature within the toll pricing files that alerts motorist that prices may change in real time (and thus are directed to watch the signs for the correct price). I believe something similar for variable speed limits could be done using segment attributes.… more

    30 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  General  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

11. New filter "Older than" should apply for URs with no comments

    The new UR filter "last comment time: older than: should apply also to those URs with zero comments (automated comment). This way we could monitor URs with automated comments that have not been answered yet by an editor after x days.

    62 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  General  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Looking into the suggestion  ·  AdminJoeny Purisima (xWF) (Admin, Waze) responded

    Great timing! We’re currently working on New filter "Older than" should apply for URs with no comments. Keep an eye out for updates on the WME.

12. Show client app version in URs User Preferences field

    Currently WME shows various useful information in URs, such as usernames (if available), report source, and various other User Preferences. Please also include app version from which the UR was generated.

    This would be useful when troubleshooting certain reports, as some features may not be available to such users and also that some very old version of the app include 'Reported map issue' in the description field by default.

    This, at the time of writing, also affects automated replies to URs, from Map Team account.

    For e.g., see https://www.waze.com/discuss/t/introducing-automatic-replies-for-urs-without-description-enhanced-filtering/397655/122?u=darkestways thread.

    107 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    6 comments  ·  General  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Not Planned [WME]  ·  AdminElla (Waze Team) (Admin, Waze) responded

    Thanks for your feedback. At this time, this doesn't fit on our roadmap, but we'll keep it in mind for future product planning.

13. Eliminate Heuristics and auto-generate paths instead.

    Heuristics are hidden behind so many elements of the map nowadays. As a result, editors are often expected to read multi-page documentation to understand how to take advantage of them or how to avoid unintended behaviour. In practice, even experienced editors frequently are unaware or uneducated, making this expectation especially unrealistic for new editors.

    My suggestion is to eliminate heuristics altogether, and replace them with auto-generated explicit paths/TIOs/etc. Whether it's an H or an # junction, traffic lights, turn instructions, u-turns, etc, everything should be visible and unambiguous in the editor.

    Some examples:
    1) if a u-turn in an H junction is prohibited due to the length of the median segment, WME should display a red (prohibited) path when the relevant segment is selected.
    2) when selecting a traffic light hazard, WME should display which 'Visibility' and 'Voice instruction' option apply to each path.
    3) for turns, WME should display the selected 'Voice guidance' (e.g. exit/keep/turn right).

    In tandem with removing heuristics, "Waze selected" should be eliminated too. Instead, WME should preselect and display the actual option that will be used, increasing transparency and predictability.

    Heuristics are hidden behind so many elements of the map nowadays. As a result, editors are often expected to read multi-page documentation to understand how to take advantage of them or how to avoid unintended behaviour. In practice, even experienced editors frequently are unaware or uneducated, making this expectation especially unrealistic for new editors.

    My suggestion is to eliminate heuristics altogether, and replace them with auto-generated explicit paths/TIOs/etc. Whether it's an H or an # junction, traffic lights, turn instructions, u-turns, etc, everything should be visible and unambiguous in the editor.

    Some examples:
    1) if a u-turn in an H… more

    103 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    1 comment  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Looking into the suggestion  ·  AdminElla (Waze Team) (Admin, Waze) responded

    Great timing! We’re currently working on it. Keep an eye out for updates on the WME.

14. Display the speed bump direction (A->B or B->A) with the icon to make it easier to add them to one-way segments

    When adding speed bumps that are one-way only, for example, at a raised intersection, it's generally hit or miss which direction is correct, so this requires extra clicks to get correct. Being able to see the segment direction indicated with the icon would make it much simpler to select the direction.

    38 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    Added to backlog  ·  2 comments  ·  website - general  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

15. Filter Place Update Requests by Waze Username

    Filter Place Update Requests by Waze Username

    The Place Update Request (PUR) interface displays submissions in chronological order but does not provide a mechanism to filter requests by the username of the original submitter.

    This makes it difficult for mentors and senior editors to locate and review submissions from specific users, particularly in areas with high volumes of PURs.

    I'm proposing to introduce a "Submitted by" text filter in the User Feedback section of the PUR Issue Tracker

    The filter should accept a Waze username and support both partial and exact matches through an optional Exact Match checkbox.

    These are some of the use cases I can see this benefitting:

    Mentorship: Review a mentee's submissions to provide coaching and monitor editing progress.This also surfaces their points instead of being buried in high volume areas.

    Quality Assurance: Identify and investigate patterns of inaccurate or problematic submissions from a specific user.

    Community Support: Locate outstanding or historical submissions when assisting users with questions about their place updates.

    Mapping Initiatives: Review submissions from participants involved in Map Raids

    Please consider this request by voting!

    Mockup here https://imgur.com/a/2dqKqYs

    Filter Place Update Requests by Waze Username

    The Place Update Request (PUR) interface displays submissions in chronological order but does not provide a mechanism to filter requests by the username of the original submitter.

    This makes it difficult for mentors and senior editors to locate and review submissions from specific users, particularly in areas with high volumes of PURs.

    I'm proposing to introduce a "Submitted by" text filter in the User Feedback section of the PUR Issue Tracker

    The filter should accept a Waze username and support both partial and exact matches through an optional Exact Match checkbox.

    These are… more

    23 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

16. Add "above number of days filter since reported date" to Issue Tracker

    This idea is similar to https://waze.uservoice.com/forums/59225-map-editor-suggestions/suggestions/48574424-add-above-number-of-days-since-last-comment-filt

    The main difference is to add "Above number of days since reported date” to the Issue Tracker.

    The reason is to find URs that Waze auto-responded to and sufficient time (e.g. 4 days) have passed and there is no response from the reporter. so we can do a follow-up response. Without this filter, we have to keep changing the end date in the area section (above the Update Request (UR) dropdown) of the Issues tab.

    59 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    Added to backlog  ·  0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

17. Issue Tracker: Add options to "area" and "last comment by"

    When using the issue tracker, to make searches more practical and useful, the following options are missing:
    1. When specifying last responder, we need option to mark "Not me" as sometimes another user may add comments to a UR he didn't report. Right now, there is no easy way to select these URs.
    So, all options for last comment by should be: Anyone, Reporter, Me, Not me.

    1. The search area should have the option "not in managed areas" as a checkbox or other way. When we scan for URs in a large are in "Specific area" (le a country or a state), we may want to get only URs that are not inside managed areas. Because no one is responsible there. Right now, a search like that returns all URs in the area (ie country) which is a bit waste of time to scan them all.

    When using the issue tracker, to make searches more practical and useful, the following options are missing:
    1. When specifying last responder, we need option to mark "Not me" as sometimes another user may add comments to a UR he didn't report. Right now, there is no easy way to select these URs.
    So, all options for last comment by should be: Anyone, Reporter, Me, Not me.

    1. The search area should have the option "not in managed areas" as a checkbox or other way. When we scan for URs in a large are in "Specific area" (le a country or… more
    54 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    Looking into the suggestion  ·  0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

18. WME should indicate when a segment end overlaps but is not connected

    Firstly, take a look at this image:

    https://imgur.com/a/OPph9D5

    As per the screenshot, these segments are NOT connected but it looks like they are. It should be obvious in WME when segment ends are close but not connected. In this screenshot, the little dot on the green segment looks like there's a junction node there, but in reality, there is not.

    Please make it clear that segments aren't connected when they probably should be.

    60 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  General  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    Looking into the suggestion  ·  AdminJoeny Purisima (xWF) (Admin, Waze) responded

    Great timing! We’re currently working on WME should indicate when a segment end overlaps but is not connected. Keep an eye out for updates on the WME.

19. Tram Trail Project (TTP) – Light Rail & Tram Safety Alerts

    Target Product: Waze Navigation

    Feature Name: Tram Trail Project (TTP) / Light Rail Crossing & Shared Lane Safety Alerts

    Target Platforms: iOS, Android, Android Auto, Apple CarPlay

    1. Executive Summary As urban transportation evolves, light rail and tram systems increasingly share roadway space with private motor vehicles. Unregulated rail crossings and tracks embedded directly in driving lanes present significant hazards for drivers.

    The Tram Trail Project (TTP) introduces dynamic, context-aware audio-visual notifications into Waze. By focusing strictly on actionable 150-meter proximity warnings and dedicated Shared Lane Modes, TTP drastically reduces collision risks while preventing driver alert fatigue.

    1. Problem Statement High Collision & Skid Risks: Trams require substantially longer stopping distances than cars and cannot steer away from obstacles. Furthermore, wet steel tracks embedded in asphalt create severe skid hazards for motor vehicles.

    Driver Blind Spots: Urban intersections with light rail frequently lack active signal gates, leaving drivers vulnerable when making turns across tracks.

    Alert Fatigue in Navigation Apps: Overly frequent or distant alerts (e.g., warning 500 meters in advance in dense city centers) lead drivers to ignore navigation prompts altogether.

    1. Key Feature Capabilities A. Precision Proximity Alert (150m Critical Zone) Actionable Timing: Omits redundant 500m pre-warnings in dense urban grids, triggering alerts precisely 150 meters before a rail intersection.

    Visual Banner: High-visibility yellow/slate warning banner featuring a custom tram icon and distance counter.

    Audio Signature: Distinct, non-intrusive chime combined with a concise voice prompt ("Caution, tram crossing in 150 meters").

    B. Shared Lane Mode (Tracks in Roadway)
    Automatic Detection: Identifies road segments where tram tracks run flush with vehicular lanes.

    Contextual Caution: Displays an active banner reminding drivers to maintain increased trailing distance behind trams and exercise caution during wet weather due to decreased tire traction.

    C. Seamless Infotainment Integration
    Fully adapted layout designs for Android Auto (Coolwalk) and Apple CarPlay, maintaining native UI guidelines and zero-clutter principles.

    1. User Experience & Interaction Flow Approach Phase: Vehicle enters 150m radius of an active or unregulated tram crossing.

    Visual & Audio Prompt: Top banner animates subtly into view; single distinct chime plays.

    Driver Action: Driver adjusts speed and verifies clearance across the tracks.

    Crowdsourced Validation: Drivers or passengers can tap a single-touch button ("Clear" or "Hazard Still Present") to maintain real-time accuracy.

    1. Expected Business & Safety Impact 35% Reduction in Urban Rail Collisions: Substantial decrease in intersection broadside collisions with light rail vehicles.

    0 UI Clutter Guarantee: Streamlined alerts build high user trust and feature engagement.

    Municipal Transit Collaboration: Potential for direct data-sharing partnerships with city public transit authorities.

    Target Product: Waze Navigation

    Feature Name: Tram Trail Project (TTP) / Light Rail Crossing & Shared Lane Safety Alerts

    Target Platforms: iOS, Android, Android Auto, Apple CarPlay

    1. Executive Summary As urban transportation evolves, light rail and tram systems increasingly share roadway space with private motor vehicles. Unregulated rail crossings and tracks embedded directly in driving lanes present significant hazards for drivers.

    The Tram Trail Project (TTP) introduces dynamic, context-aware audio-visual notifications into Waze. By focusing strictly on actionable 150-meter proximity warnings and dedicated Shared Lane Modes, TTP drastically reduces collision risks while preventing driver alert fatigue.

    1. Problem Statement High Collision… more
    21 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  General  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

20. Automate restricted area pass creation directly from WME to eliminate lengthy manual workflows

    The current workflow to create and deploy navigation passes (toll and restriction passes) is overly complicated, error-prone, and causes massive delays for local communities and map editors.

    Current Workflow Bottlenecks:
    Manual Data Duplication: Editors must configure the restricted area in WME, manually fill out an external spreadsheet with the area's technical details, and hand it over to the coordinators.

    Complex Communication Chain: Coordinators must submit a request to the dedicated team.

    Massive Turnaround Times: The review and creation process often takes months. If instructions are misunderstood or a minor mistake occurs, the request is rejected or improperly configured, forcing editors to restart the cycle and wait for months all over again.

    Feature Proposal:
    Automate the pass generation pipeline directly within WME.
    Once an authorized editor creates and saves a restriction area with its parameters on the map, the system should automatically generate the corresponding client pass metadata—or at least offer a direct, one-click WME-integrated option to spawn the pass without relying on external spreadsheets.

    Key Benefits:
    Instant Routing Accuracy: Drivers get timely, correct routing for restricted zones and toll areas instead of waiting months for passes to appear in the app.

    Reduced Overhead: Eliminates repetitive administrative tasks for local coordinators and internal Waze support teams.

    Lower Error Rate: Removes human error caused by manually copying and pasting segment IDs, polygon data, and restriction parameters into spreadsheets.

    Instant deletion of no longer needed or expired passes

    The current workflow to create and deploy navigation passes (toll and restriction passes) is overly complicated, error-prone, and causes massive delays for local communities and map editors.

    Current Workflow Bottlenecks:
    Manual Data Duplication: Editors must configure the restricted area in WME, manually fill out an external spreadsheet with the area's technical details, and hand it over to the coordinators.

    Complex Communication Chain: Coordinators must submit a request to the dedicated team.

    Massive Turnaround Times: The review and creation process often takes months. If instructions are misunderstood or a minor mistake occurs, the request is rejected or improperly configured, forcing editors… more

    19 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  General  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating