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.

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.

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.

When adding Places, especially outdoor places (such as parks, playgrounds, beaches, etc), there are often posted hours saying the Place is open only sunrise to sunset, or conversely that the Place is closed sunset to sunrise. Unfortunately, the existing Place hours interface doesn't allow for these kinds of hours, only HH:mm times. As sunrise and sunset times change constantly, and in some places drastically due to orbital motion of the earth and time changes due to daylight savings times, it is impractical to estimate open/closing times using HH:mm formats.

It would be beneficial to both app users and map editors to allow for the app to determine/reference local sunset/sunrise times (which it already does for dark/light app modes) and use this to mark the venues as open/closed.

Possible mock-up of feature in WME:
https://i.imgur.com/TYAa7vn.png

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.

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.

An update request (UR) without any text can be automatically handled:
1. There will be an automatic system response to the UR that will invite the user to add more details to his request in the WME (include a link) or in the forum (include a link to the local community forum). The user will get an e-mail as fr any other manual response.

1. Every such UR that has no more responses (other than the automatic one) will be closed as "not identified" after 7 days.

That automatic handling will save a lot of time wasted by area managers. A large percentage of the URs are with no text, and out of these very few get a response from the user when inviting them to give more details.

This idea is similar to the idea here:
https://waze.uservoice.com/forums/59225-map-editor-suggestions/suggestions/42112255-automatically-send-ur-reminders-and-mark-as-not-i
but maybe it is simpler to implement.