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

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

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

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 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

Hi,
very often I am notified of an event that needs closure after it started, then I go to select the many segments that must be closed.
When I want to add a proper closure on them, there are already dozen of closure made by drivers and I have to remove all of them one by one before adding mine. That's annoying because it is slow, and sometimes new closure are made by drivers while I am removing them :

And overlapping closure are not a real problem because when it is done by waze app it happens often so it seems it is a check added by WME that lead only to bad ergonomy.

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