July 2020, Waze has three camera types: speed, red light, dummy. It is clear talking to different community leaders that the requirements for specific cameras vary from country to country. Thus, we are asking for the ability to add new camera types per country, with the ability to input into text to speech (TTS), and on/off toggle alert in the app. These could be provided by form, similar to new gas station brands, etc. by a country's leadership.

Alternatively, collect a list of camera types from the communities to create a long list, and allow countries to turn them on/off by country.

Obviously there's a wide range of cameras, and in each jurisdiction some are more important to others. There are also new and emerging camera types, such as dual red light AND speed cameras, and even newly released mobile phone detection cameras which fine users for driving while holding their phone.

It would be really great if we could add closures to segments just after creating them. Currently that's not possible. In this case, once the segments are built into the map, the closures would be added to them automatically

Why?

Sometimes city administrations make few changes in the traffic by creating new roads. The problem is that most of the times (at least where I live) we don't know exactly when those roads will be released. In addition, map build may delay.

So, as soon as we know a new road will be built, we can create it on WME and add a closure after that. Once the road is released, we can delete the closure.

by quantumjedi
Link to original suggestion: https://www.waze.com/forum/viewtopic.php?f=1525&t=296229&start=10

To branch off the discussion from the WME release topic:

RichardPyne כתב:
I would find GPS points much more useful if they were color coded by age rather than direction. Th arrows provide useful direction, but in areas where traffic patterns are changing due to construction, knowing the age of the trace would be far more useful.

dchary2418 כתב:
It could help if the GPS traces were the same original color, but shaded darker for older data.

Glodenox כתב:
I'd be all for somehow showing the age of the GPS points. Especially the more recent data seems of interest to me. Something like "last 7 days", "last 30 days" or "older" would work great as brackets for colouring, I think.

The issue with that is probably that it would allow you to track certain users in areas with not as many users. With no indication of age, this is a lot harder to do right now. But in theory this could be taken into account by not showing the age when there is little data.

Currently, Junction Boxes do not have a controllable lock level. From the look of it, the lock level displayed is the minimum level for the country that can edit a JB. For example, in the UK only L5+ editors can edit JBs, so all JBs show auto(5) in WME.

With various changes that HQ are making into WME and the app, it seems to me that they expect a massive increase in JBs over time. U-turn prevention, junction modification for Falcon are just some of the things for which the answer often seems to be "use a JB".

I'm not disagreeing with the increased use of JBs. But some of them in the UK are attached to very complex motorway junctions (https://www.waze.com/editor/?env=row&lon=0.19921&lat=51.87156&zoom=5) which we would definitely want to stay out of reach of junior editors.

On the other hand, we don't want to prevent junior editors being able to use JBs sensibly in situations where they're needed.

Without individual lock levels on JBs we don't have much choice. In order to protect complex, important JBs we have to lock junior editors out of JB use entirely.

By: iainhouse
link to original suggestion: https://www.waze.com/forum/viewtopic.php?f=1525&t=307738

Hello!

I think it would be very helpful if segment history included data from previous "iterations" of that segment, when a segment was created by merge or split.

Right now, the history starts anew any time there is a new segment ID, but I would imagine it should be fairly trivial to develop a backend mechanism that, any time a segment is split or merged, merges the history of the previous segment ID into the new segment's history.

This is useful not only diagnostically but also to catch cheaters on the map, who today can split and merge segments at will with no evidence.

It is very easy to envision how this would work with a segment created by split, as the history of the previous, longer segment can simply be displayed before the "Segment created by split" line, perhaps with the old ID of the previous segment appended.

For segments created by merge, obviously there are multiple histories to incorporate, but I think it can still be done in a sensible way from a UX / UI standpoint, as follows.

Right now, the history of a merged segment starts with "Segment created by merge", and the data is lost. In a better implementation, perhaps it looks like this: "Segment created by merge of [segment ID 1] and [segment ID 2]".

Then, at the time of the merge, the old history of the other two segments are merged into the new segment as well, with the old segment ID appended.

So, let's say you have segments 123 and 345 from the basemap, each with a few edits before, named "Main St", connected by a node, then you delete the node to merge the segments into segment 54321 (newer segments have much higher IDs!). Right now, the history would be simply,
Mon May 01 2017 by sketch(6) / Segment created by merge

Let's say the other segments have history like this:
123:
Wed Dec 14 2016 by EladOfTheBerg(2)
Updated Geometry
GEOMETRY
Changed from [this] to [this]
Thu Jun 23 2016 by WilliamHMacy69(1)
Updated Primary street name
PRIMARY STREET NAME
Changed from Maine Street to Main St

345:
Fri Aug 26 2016 by RickyBobby666(3)
Updated Lock level
LOCK LEVEL
Changed from 1 to 3
Thu Jun 23 2016 by WilliamHMacy69(1)
Updated Primary street name
PRIMARY STREET NAME
Changed from Maine Street to Main St

In the improved implementation, the history for segment 54321 would read:
Mon May 01 2017 by sketch(6)
Segment created by merge of 123 and 345
Wed Dec 14 2016 by EladOfTheBerg(1) (ID: 123)
Updated Geometry
GEOMETRY
Changed from [this] to [this]
Fri Aug 26 2016 by RickyBobby666(3) (ID: 345)
Updated Lock level
LOCK LEVEL
Changed from 1 to 3
Thu Jun 23 2016 by WilliamHMacy69(1) (ID: 123, 345)
Updated Primary street name
PRIMARY STREET NAME
Changed from Maine Street to Main St

If you really want to get fancy, the "123" and "345" in "Segment created by merge of 123 and 345" could be little hover buttons like with the geometry changes.

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

When adding or editing RPP, if there is a conflict with the HN layer (i.e. too far), then the WME issues an error that prevents you from saving your edit. Thus, you cannot add or update this RPP.

To resolve the issue you need to perform the following steps:
1. Update/Remove the address in HN layer
2. Wait for next (successful) map build
3. Add the RPP

This is an annoying procedure that should and can be avoided.

The issue can be handled in one of the following ways:
1. Verify the RPP against the most updated data either in the edited or production HN layer databases.
2. Allow conflicts. Issue a warning but allow to save (rank depended). The same as forced HNs are allowed. Especially that for navigation, exiting RPPs are used before HNs.

The above suggestions or any other solution that will allow immediate RPP editing would be very welcomed.

I prefer option 1, as it also solve the conflict.

Now we can only close the segments, but it would be really useful to be able to close only the turns.
In many cases, for example, when there are road works at an intersection or roundabout, you can turn in one direction but not in another.
In these cases for the moment, we can not do anything, at most we can insert a restriction on the turns but obviously with all the limitations of the case.
They are not in real time and are not visible on the map.
The ability to close nodes recently arrived on the WME does not help in these cases, as the same node could be open in one direction and closed in another.
I believe it is an absolutely essential function.

I would like to have the ability to draw a single 2-way segment but be able to mark it as divided so it does not say you have arrived until on correct side of road. Sometimes you may have a segment that may not really need to be divided into 2 One-Way segments but if you want routing to offer the correct directions you would have to divide the segments. In my picture below, the red line shows what Waze currently does (it says you have arrived as you pass the house) The green line shows what it should be doing. This can be accomplished by dividing but if there was an attribute that says "divided segment" that Waze would treat the 2-way segment as 2 One-Way segments, then we would not have to add extra "unneeded" segments but still give the correct routing.

I really think this would go a long way in helping when we have just a short segment that is divided along a longer undivided segment.

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

It may be nice for us to be able to "subscribe" to a segment ID, not sure if it should be rank locked or not.

Basically, add a check box on a segments panel to subscribe to changes of the segment.

When subscribed to a segment, if a change is made to a segment the subscriber gets an email notification that their segment has had changes (and of course provide a PL)

Among other possible uses, it could be used to get notification if someone makes a change to a segment that is part of the Toll Price feature.

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

With the newly implemented Lane guidance we see new problems rising up.
In belgium, beeing densly populated, we somtimes have several entry's or exits of the highway following up on each other very closely.
sometimes even as close as 20-50 meters.

I would like to have a sort of junction box type of tool to combine 2 lange guidance segments.

for example:
2 highway exits within 50 meters. I want the Lane guidance before the first exit to allready show in what lane I have to stay if I have to take the 2nd exit.

It's kind of hard to explain but there are plenty of examples where lane guidances following up shortly on each other form a problem.

The restrictions tool used to be simpler a few years ago. Today it allows to setup not only time/days restrictions but also permits/passes, number of passengers, toll roads and more. With new options such as "allowed", "toll free" and "prohibited" it became confusing even for higher rank editors sometimes.

I've lost count of how many times I checked editors that made 1-2 edits and that added a 24/24h 7/7d permanent restriction on what should be a simple "private road". Or even setup a freeway pass on a simple street.

This tool has become extremely complex and powerful, especially since routing was changed years ago to treat any segment with a restriction applied to behave as a "Walking Trail", not routing into the segment but stopping at the junction node if the address is on the segment.

Applied restrictions are almost impossible to detect or keep track of. Without scripts or selecting and opening menus, we cannot easily differenciate a useful restriction from a wrong one. The UI also makes it harder to see, compared to a wrong red/green arrow, missing segment or other more obvious errors.

For all of those reasons it should be possible to restrict its usage per level and per country.
I would personally make it available only at L2, as 3000 edits is usually enough time to figure out that segment types exist and what their penalties are vs adding restrictions.

When a Map Comment (MC) has been entered and is nearing its expiration (2 weeks in advance or 1 week in advance), notify and/or place a note in the Feed of the expiring MC.

This would allow the editor to verify if the MC is still needed, extend it, and/or reconnect road segments where a long-term project may have warranted segment disconnects instead of long-term RTCs.

If roads were disconnected and the project is nearing completion, this would allow the editor to reconnect the segments and then add RTCs so routing could occur immediately upon the completion of the project instead of waiting on a tile update.

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

WME shows two kinds of closures:
- effective closures, affecting routing and visible on livemap
- suggested closures, non affecting routing and not visible on livemap. Those suggested closures always have a duration equal to a multiple of 24 hours, starting and ending at the same time of day (on different days, obviously), and are usually created by editors having a layer lower than 3. Those suggested closures result from closure reports made from the app.
The WME displays both kind of closures using exact same visuals: it is necessary to open and examine the closure, to determine if it is effective or suggested.
I suggest enhancing the WME to allow visually identifying the type of closure.

Hi,
when editing from the feed (closing MP, UR), after saving WME moves to a random place where it thinks there are other UR I can solve. It is extremely annoying. When editing I save often because of various save bugs, and as soon as I saved it moves somewhere else and I cannot find where I was editing to finish the job.
Same problem when saving, if Waze thinks there is a problem it moves my map to where it thinks the problem is, and if it is a long road, it happens often that the road is offscreen.
So to summarize :

NEVER MOVE THE MAP AUTOMATICALLY.

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