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.

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.

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

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

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

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

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

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.

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

The WME URL field for Places is limited to 100 characters. I'm not really sure why!

Most URLs will fit in this area, true. But some hotels have URLs longer than this. When I try to add one to a Place, it is truncated, so the URL does not work in Waze.

A hotel in my area has this URL:

https://hamptoninn3.hilton.com/en/hotel ... index.html

WME truncates it to this when pasting into URL box:

https://hamptoninn3.hilton.com/en/hotel ... ood-clearv

To compare them:

CODE: SELECT ALL
https://hamptoninn3.hilton.com/en/hotels/louisiana/hampton-inn-and-suites-new-orleans-elmwood-clearview-parkway-area-MSYELHX/index.html

https://hamptoninn3.hilton.com/en/hotels/louisiana/hampton-inn-and-suites-new-orleans-elmwood-clearv

For a hotel in particular, websites can be difficult for searching for a particular location, and the localized names (and therefore the URLs) are really long. So, having the local URL can be very helpful to an app user. Extending the length limit will make this possible. Thanks!

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

Hi,
the real time closure have a problem :

We put them in WME and WME validates them according to their current state in database. But they apply on livemap.

Imagine I have a street that is A->B. Then they decide to reverse it. So it is now saved B->A.

In WME I have B->A
In livemap I still have A->B until tiles update.

To avoid routing people A->B, it would be nice to add a closure, but WME refuse since it thinks the road is in opposite direction.

It would be nice if WME could accept it by really try to add closure in real time server instead of doing a check according to WME database that is too news.

It is similar to https://www.waze.com/forum/viewtopic.ph ... e#p1790951

It's not enough, if you change a segment then need to add a closure, even if the tile build is the next day, it's still one day with routing errors.

For example the road under map comment was inverted, look at the UR that happened in 6 hours.
(photo attached)

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

Show that this data exists, so that editors will be more likely to merge than to delete.

When new place points are added as part of a large upload from Yext or some other advertising aggregator, many editors will be likely to reject the new-place PURs because an already perfect place already exists.

If they were aware that there was some other important information in the PUR, then they would be much more likely to accept the PUR.

The back end data script reveals the existence of this data in places. But I don't think it makes sense to depend on all editors running this script all the time. The fact that this data exists should be clearly visible to all editors.

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

Hi,
when saving, if the backend fails, it returns a message. But often they are not localized, and in that case we get a generic
"Please try again later" which is useless because in most case the problem will not solve and the only solution is to cancel all edits.
Here is a list of messages that are not localized and need to be displayed (maybe not exactly in the same form, but at least do not tell the user to try again if it is impossible that it works.

Invalid street 0 was set for venue ID -100
Missmatch max speed in original segments
Property toSegID of NodeConnection with ID 305118209f/-113r references Segment with no generated ID for -113
Node 282093744 is not connected to segment 356869225

There are probably many more, but it is the one I got while editing recently.

Of course it would be even better if the frontend did not generate situation causing those errors :)

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