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.

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.

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.

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

I'm not sure if this sort of thing will be covered in Permanent Hazards development, but it would be very handy to be able to define an area polygon to which a hazard report would apply.
To me, the obvious application would be for prolonged construction zones where roads remain open but users ought to be made aware of an issue ahead.
How I see this working:
An editor would draw a polygon over the affected area and then choose a hazard type and add an optional comment to the polygon. It should be possible to define schedules and an expiry date.
In the client this could be rendered as a hazard bubble at every entrance to the polygon, possibly special shading on the segments, or the editor's polygon could be rendered directly on the map.
Any user comments or photos would be attached to the 2D hazard, and would be viewable by anyone presented with the hazard bubble or alerter.
Also, the ability for CCP partners to submit this type of object via feed should be considered.

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

A nice feature would be to surface the real error message from house number additions. Sometimes when there is a conflict between segments, you get a generic "there was an error" type message, but the back end call has the full details which you can see through dev tools. For example:

This segment: https://www.waze.com/en-US/editor/?env=usa&lon=-97.48797&lat=30.16312&zoom=6&segments=48240740
Conflicts with: https://www.waze.com/en-US/editor/?env=usa&lon=-94.82458&lat=29.82488&zoom=6&segments=48240740,511847520,511847562,511847579

When the city is listed as "none" (No City). When adding "115" to the latter, this resulted in an error (see attached)

However, the backend error that is returned by the web request is (see attached)

There's enough in the error message there to surface a link to the conflicting segment. This would help troubleshoot issues.

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