Send the UR closing message to the user when the map really gets updated (contains all changes up to the UR "closing" time).

Some things may get fixed immediately (by adding a closure or updating a place), most things require a map update. That means that we always have to write stuff like "in few days/after the next map update, the problem will be fixed".

Maybe a third button like this:
"Mark as Solved"
"Solve on map update" <-
"Mark as not identified"

When the second button gets clicked a form opens when I can write a message to the user, and you just need a third email template where to put it in and to place the email on a queue, which gets sent when the map update succeeds (you could even put multiple replies in one single email, to avoid spamming the poor users doing a lot of reports).

After the pandemic of COVID-19, some information such as air-conditioned or Wi-Fi became less relevant when choosing a restaurant, for example. It would be interesting for editors and users to be able to add information related to health safety measures, such as:

1.Need for reservations: Some restaurants require that the consumer has already made the reservation before.
2. Space for the elderly: Some places separate a place for the elderly, reducing the risk of contamination.
3.Contactless payment: The location features payment via NFC or other contactless methods.
4. Masks required: Despite obligation always, it is a good incentive and even a reminder for Wazer to use masks.
5. Drive-Through Types: After the pandemic, many restaurants and shopping malls joined Drive-through, but most of them need to place an order beforehand and pick it up at the place, while some allow the user to place the order at the place. With that, it would be a suggestion that Waze differentiate the two types of Drive-through.

I have been using Waze for many years and the service options in the POI information have not changed. It is a good time to improve this.

It would be nice to have a way of setting PLRs to be able to use speed data (versus a set speed) while having the same penalty settings (i.e., the road has no penalty between the two PLR settings). This would be useful in large parking lots area such as sporting venues and malls, where set speed is fine for aisles and minor roads but speed data would be useful for finding the fastest entrance/exit on it's higher volume roads. With the set PLR speed, you are almost always getting the shortest route of PLRs, even if that lot exit is much busier and slower (or if say the right turn lane out the lot is fast but a left turn is slower than using a different lot exit).

This could be a checkbox on PLR segment settings, or potentially a new road type (with the current one named "Parking Lot Aisle" and the new speed data type taking on the "Parking Lot Road" name).

Currently, when you try to connect an existing segment (segment E) to a segment leading to a Junction Box (Segment L), the WME won't allow to create a Junction.

On the other hand, creating a new segment (segment N), Segment L can be split, but then a saving error will happen (operation not supported).

This different behavior is confusing and it's not easy to understand why it is like that. This mostly looks like a bug to the user when the Junction box is far away and not even on screen.

To fix both problems, WME should allow splitting a segment L if the split happens outside the Junction box area, and update Segment L's ID inside the roundabout.

At the moment, it is no longer possible to add a closure to a segment you have removed or split up, even though this segment is still being used live in the app. If it were possible to add closures in the snapshot mode (recently renamed to "Current live map"), even with a strict time limit, our life would become a lot easier during road works.

At the moment, we need to apply segment restrictions, wait for the map update, remove the closure, make our changes, wait for the map update and then probably add new closures. If we can add closures in the live view, we would just remove the closure, make our changes and add the closure back in the live view. Even easier from a user's standpoint would be allowing us to make changes to closed segments, but I can imagine that would be harder to do.

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.