Currently City Boundary layers are not drawn precisely, which can result in the wrong city name being displayed to users in the app. I continue to get URs on this regularly in my area.
This issue seems to be seen commonly when cities are divided by an undulating river. Users should not be shown that they are in a city that they are not in. The system to "draw" the city layer should rely on more data points to draw a more accurate city layer. I will attach screenshots to show this more clearly.

https://www.waze.com/en-US/editor?env=usa&lon=-122.59338&lat=49.19848&zoom=2

https://imgur.com/V9kFFp4
Incorrect city "Maple Ridge" is displayed on the north section of "Langley" (Blue Circle)
The reverse is also true Incorrect city "Langley" is displayed on a portion of Maple Ridge (Red Circle)

The areas have been meticulously scanned there is no place or street with the wrong city name.

Send the UR closing message to the user when the map really gets updated (contains all changes up to the UR "closing" time).

Some things may get fixed immediately (by adding a closure or updating a place), most things require a map update. That means that we always have to write stuff like "in few days/after the next map update, the problem will be fixed".

Maybe a third button like this:
"Mark as Solved"
"Solve on map update" <-
"Mark as not identified"

When the second button gets clicked a form opens when I can write a message to the user, and you just need a third email template where to put it in and to place the email on a queue, which gets sent when the map update succeeds (you could even put multiple replies in one single email, to avoid spamming the poor users doing a lot of reports).

There are many places where Lanes go one or two junctions back (H junctions for example). The editor should allow to define lanes that are not limited to the turns at the end of this segment:
Real example:
We have 3 lanes. The left lane is loaded for 1 KM. In that 1 KM there are 4 junctions ( right turns allowed).

It would be nice to be able to define 1 lane for Left turn, one for going Straight Ahead, and one for Straight Ahead or Right.And be able to do this for all 5 segments.

By: Rill
Link to original suggestion: https://www.waze.com/forum/viewtopic.php?f=1525&t=307279

I would like to be able to place custom warnings in WME that come through to the app.

problem:
- certain tunnels see a lot of truckers or camper vans getting jammed because they are too large to enter.
- school area's getting dangerous when people who do not know the area are routed through due to a traffic jam somewhere else.

Idea:
I imagine this like placing a speedcam in WME but then beeing able to fill in a message (with a set maximum of characters).
We could use those to put warnings in problematic areas, and these can be adjusted to the needs of each local community.
for example:
- Underpass max 2,8m ahead
- school area ahead

Exactly like with a speedcam: in the app it should pop up in the green banner with the warning in it.

alternatively:
if a custom waring is too difficult or prone to problems; add a couple standized ones such as for a school area.

Not only will this help make traffic safer. I believe it will also get us a lot of goodwill with local authorities.

As we've added more parking lot roads to shopping centers wazers have become accustomed to being directed to a specific store when they search by name. As a result, they are reporting navigation errors when navigating by address results in a stop point on the road in front of the stopping center. This is particularly bad when the route has to circle around the shopping center to reach the house number.

To work around this, we've taken to adding both a PP and a RPP when a store in a shopping center has a unique address.

It would be great if we could check a box when editing a PP to indicate that waze should enable navigation by both name and address.

Please harmonize the nomenclature Waze uses for roads that may beat up cars or get them dirty.

Currently, WME allows marking segments as "unpaved", while the companion feature in the app allows the driver to avoid "dirt". But unpaved and dirt are two different things; for example, many would consider a gravel road to be unpaved, but few would call it dirt. Meanwhile, even some paved roads have such poor surface quality that local drivers might wish to avoid them in favor of better alternatives.

Since the underlying goal is to allow drivers to avoid roads with poor surface quality, why not harmonize the nomenclature to "Poorly surfaced roads" or just "Poor roads"? Using this nomenclature instead of "unpaved" or "dirt" would better match the goal of the feature, and would encourage local editors to apply the feature in ways that make sense for their road environment and Wazing community.

Failing that, WME and the app should at least use the same terminology anyway.

Drawing large rivers on the map, for example, is torture. Although there are scripts that "help" the task, Waze should add its own feature to add water covers, instead of the place editors as it is today.

My suggestion is that each type of water cover has its own type of editor. For example, to draw a river, the editor draws a line that follows the direction of the river and chooses the width, Waze then fills in smoothly, that is, with several "dots".

Another suggestion is the possibility of connecting aquatic elements, such as connecting the river to a lake. Or connect two different rivers.

These changes seem simple, but would be of GREAT help.

Wildlife, especially deer, are a significant hazard to drivers in many parts of the world. Collisions with deer account for one to two million insurance claims each year in the US alone. While wildlife on the roadway is harder to anticipate than other hazards, authorities do know of specific areas, times of year, and times of day that drivers are at increased risk of collision. Please let us mark these hazard areas (with the times of year and times of day they should be "active" to avoid hazard-alert fatigue) to communicate this risk to drivers. Both drivers and wildlife will benefit.

Description: Currently when editors make most changes to a turn between two segments the segment history simply shows "Turn onto X road updated". It would be much more helpful if we could easily tell what was changed about that turn. Was is a turn instruction override (TIO)? A difficult turn? Time-based restrictions? There was a change in a value associated with the data model of that segment, so it's very much possible to have the segment history be more specific.

In this image there are three entries for turn updates to the same turn, but other than the TIO there is no way to know what exactly was done. If there's been a tile update then we only have the option to email a community manager to pull the change info for us. It'd be much quicker and more helpful to be able to get this info at a glance.

Current behavior: All changes to turn attributes are saved to segment history in a generic format.

Desired behavior: Changes to turn attributes are displayed in segment history with descriptive wording. ie - "Turn onto X road turn instruction override added/deleted", "Turn onto X road difficult turn added/deleted", etc.

By: SkiDooGuy
Link to original suggestion:https://www.waze.com/forum/viewtopic.php?f=1525&t=306811

Bonjour, je me permets de vous contacter pour vous soumettre une idée qui pourrait rendre votre application encore plus attractive et qui pourrait rendre service à un grand nombre de personnes...

Étant actuellement à la recherche du petit chien de ma sœur qui à fugué, j'utilise Waze pour vérifier les signalements d'animaux morts sur les routes (en espérant ne pas le retrouver de cette manière).

L'idée est qu'il serait vraiment très pratique de développer une option permettant de signaler des animaux errants... Encore plus pratique, un service permettant de signaler aux conducteurs qu'un animal est recherché dans une zone précise (un peu comme les zones de controle radar mais avec une photo de l'animal recherché apparaissant dans un coin).

Cette idée permettrait de renforcer la communauté Waze et en ferait un réel outil apportant de l'espoir à des personnes qui recherchent désespérément leurs compagnons adorés. Cela permettrait également de prévenir les conducteurs qu'il faut redoubler de prudence car un animal perdu ère dans cette zone.

Merci de m'avoir lue, espérant que vous considérerez mon idée afin de la rendre réalisable.

Bien cordialement

When we currently enter the name of a street, we get autocompletion suggestions based on existing roads in the neighbourhood. It would help quite a bit if the associated city field would also be filled in whenever we use one of these suggested road names. I know that every street has a city set (or none, on purpose) in the underlying data model, so this shouldn't be a big effort to add.

(see Mock up 1 + 2 attached )

I'm still contemplating whether I'll write a userscript for this or not. It's not so easy to hook into those functions, if I remember correctly.

Implementation notes:
To distinguish between nearby street names that exist in two cities (motorway names, for example, but also local roads can sometimes keep their name between cities), it would be best to also show the city name in the suggestions list. At the moment road names show up several times in the suggestions whenever they exist nearby in more than one city, which can be slightly confusing at first.

If no city is set for the selected street, the 'none' checkbox for the city should be checked as well. It can of course still be changed afterwards, but I suspect that most of the time this would be most practical.

This behaviour should only activate if a suggestion has not been clicked or has not been navigated to with the down arrow (or any other means of selecting a suggestion that I'm forgetting here). When just typing in a name, the city should not be set automatically.

Notes about my mock-up
An alternative for detailing the city name would be using a comma as separator, like it is done when you're not editing the name. Other alternatives: putting it between brackets or making the font smaller. The last one has the advantage that it takes up less space.
For the first one I had to decrease the left and right padding of the autocompletion to 15px to prevent the dropdown to be covered by the scroll bar. This can probably be done better.
For the second one I used these CSS properties: font-size:0.7em; padding-left:5px; font-weight:bold; text-transform:uppercase

by Glodenox
Link to original suggestion: https://www.waze.com/forum/viewtopic.php?f=1525&t=250354