Currently, the WME only allows assigning 1 road shield to the primary name.
This has a lot of limitations:

• The PN must be unique inside its state


• If a road has a local name, a Road Shield can only be assigned to the entire road (or the segments must be renamed).

It would be good to be able to assign 1 Road Shields for each alternative name, too (which is even already supported by the data model).

The Client, could then:
- randomly pick one road shield to show for that segment (for streets with multiple RS)
- must also look in ANs for a roadshield, as PNs may not have one.

More details here (WME beta only): https://www.waze.com/forum/viewtopic.php?f=211&t=314572&p=2131205#p2131205

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.

This is slightly outside the scope of WME Beta, but in general about our ability to provide a better service for end users.

Allow users to reply to URs via email. Many support systems allow this, and in most cases, the process is fairly simple. The process might be as follows:

• User submits a request/issue from the app while they drive


• We (editors) get a pin on the map with submitted details as before


• User gets an email with a unique response email address (something like 8766123133@requests.waze.com)


• User gets instructions on how to view the map issue they submitted


• User gets instructions on how to provide more details (ie, from the app, or reply via email)


• If user replies via email, the email goes to a processing application and the details are added to the UR


• If user replies via app, they get an option to approve the full details of the journey to volunteers (start/end, exact details entered, route taken, etc)


• Editors now have a higher chance of getting details to support drivers because of email support, and the check box allows drivers to approve exposing extra details to volunteers.

Obviously the exposing extra details to volunteers will probably have to go through some legal process, but as we (as editors) often ask for details about the driver's routes anyway, I'm not sure there really is a difference.

The really important bit here is the reply via email. With it pinned to a sub-domain of waze.com (such as requests.waze.com) a processing application can append the replies to existing requests (based on the part in front of the @). This is a pretty common practice on many support ticketing systems, and I'm sure we'd get a much higher response rate on user request follow-ups.

Cheers
Jonathan

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

I noticed that Waze doesn't approach bilingual countries just like GMM does.
For example, in GMM, we can write multiple names for the same road in 2 different languages and based on the user's current phone language chosen, the map changes accordingly.
Unfortunately that doesn't happen in Waze, we are stuck in 1 language only, even if we add "Alternative" name.

Here in Kuwait, we use both Arabic and English (Even street signs are written in both Arabic and English) , in Google Maps we are having no problems since most of the roads in the map are written in both Arabic and English. But in Waze, it is way different.

This is causing problems since most of the locals here prefer the map in Arabic, but also there are people who use the map in English.

My suggestion is:
In WME, when selecting a segment, we should have at least 2 fields to name the selected segment, there also has to be a drop-down menu to choose the wanted language.
The user's map should display the correct language based on the user's language settings in his/her phone.

Give editors the ability to enter Notes onto User Reports without these going to the reporters themselves.

This will allow us to leave messages for other map editors without the reporter being notified, for example, Please leave open - due to a Waze developer investigation, Please leave open for a pending site survey, etc.

It may also give us the ability to for to use for an internal conversation about the report that the reporter doesn't need to know about.

Yes, I know we have Map Comments, but having the ability to do this directly on the report would make it easier.

User Reports (URs) come in by the truckload. Despite a message from an investigating editor, only 10% of URs will receive a reply. This represents a significant amount of time by editors, particularly senior editors managing large areas, to the manual handling of individual URs. Since 90% of the URs result in the same process, help us streamline and automated it so we can focus our valuable time on productive investigations and edits that will value add to Waze.

I propose an additional tick box under "Follow conversation" that says along the lines "Auto reminder and mark as not identified."

When ticked:

• and a user replies, the auto remind and close is disactivated


• and a user does not reply, the user is automatically sent a reminder message after 4 days of the last editor reply, and after 7 days, the UR is automatically marked "not identified" and the last editor to reply is credited with the UR closure.

The "Auto reminder and mark as not identified" flag can only be toggled on if a message is sent. The flag can be toggled off however without a message being sent.

Possible visual presentation: https://imgur.com/VMIGTEW

Access to this feature can be controlled by a country level permission, ideally level 3 and above as default.

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

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