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

When using the WME search box to find a road, it would be really nice if WME could leave the current zoom level well alone rather than always resetting it to level 3.

Even if it just defaulted back to level 4 that'd be an improvement, but jumping back out to 3 means we then always have to zoom back in at least one step if we want to be able to select a street segment. And even at L4, anyone looking to do some work on point places would then need to zoom in one step more before they show up... So really, not altering the zoom level at all would be the best choice IMO.

by Twister-UK
Link to original suggestion: https://www.waze.com/forum/viewtopic.php?f=1525&t=276683

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

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'm not sure if it's a minor-bug or intended, but I ask you to take a look:

Issue regarding Map Editor Beta and Production.

:arrow: When you find a new place waiting for approval, if you click on the red arrow everything runs smooth, but if you feel the need to click on the yellow arrow to check what's that place is about before approving it (sometimes you can't tell just by the name title), notice it isn't possible to change the address... well maybe it's ok at this point before approving it.

(attachment 1)

• After you Approve you can't still change it.
  (attachment 2)




• You need to click on the map background to remove selection and the click on the place again and now you can change the address. In my opinion this extra step is unnecessary.
  (attachment 3)

by KarderGomes
Link to original suggestion: https://www.waze.com/forum/viewtopic.php?f=1525&t=301965#p2064955

Sometimes it's necessary to select multiple segments to perform a road closure either for MTE or for a conventional closure. After you have several segments selected, you accidentally select a node and all work is lost (the section disappears). I suggest making a modification that prevents the disappearance of the selection of these segments and notifies the editor that you selected a node and it will not be possible to make the respective closure (before or at the moment of trying to save). Obviously the idea is to give you the opportunity to remove the node from the selection and continue with the work.

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

I brought this up Jan/2015
I think It should be revisited, here is the original forum post link and quote:

https://www.waze.com/forum/viewtopic.php?f=211&t=125253#p1009107

"some thoughts on Live closure implementation....Seg to Seg closure is great. But if you have a parade route (for instance) you can close an entire street for a mile (say west to east segs). Unfortunatly it has no affect on cross streets (say if you wanted to cross the closed road from north to south on a side street). So...Side streets have to be closed also if they cross your closed segment. Seems to me what's really needed is not segment closing, but node closing, and the app showing closed on segs between nodes. Unfortunatly the only way to do 'node' closing is time based turn restrictions that need to go through a tile build. I think if the live closure got re-vamped to 'node' clousure, the process would be alot more affective. Since to get to a seg you have to pass through a node anyways. Knowing waze will allow you to cross closed streets via a side street, now double or triples the amount of closures needed for just a simple one street multiple block (or whatever leangth) closure"

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

If there is a two way segment that has an active closure in one direction and a future closure in the other direction it appears in WME like a two way closure.

This is because the arrows for current closures and future closures are both solid black.

I am suggesting that the arrows for future closures be changed from Black to Grey.

This would give a better indication of what is occurring and what is scheduled.

Will post pictures later.

This occurs in both WME production and WME Beta w/o scripts.

Updated 22:40 pm EST

Pictures:

Current Closure one way A-B (Active in app) - Attachment 1
Future Closure one way B-A (Not Active in app) - Attachment 2
Current Closure and Future Closure on same segment with different directions - Attachment 3

Notice the final picture looks like it is a two way current closure.

If the images are stacked would like to have the Current active closure on top so that you see the read and white closure symbol on the road segment and the one or two black arrows.
Then have the future closure under the active closure. You would not see the grey and white closure symbol since the active red and white one would be on top but if there was not a current closure in one direction but only future closure(s) in that direction then there would be a grey arrow displayed. One arrow would be black to show the current closure direction and one arrow would be grey to show there was a future closure in that direction.

If there was a current closure in both directions then both arrows would be black and the future closure(s)' arrow would not be displayed.

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

I am attaching a suggestion here to allow adding lanes in node that refer to a "far turn". Implementing this suggestion will solve all the problems of setting lanes (including extreme complicated junctions, H and # junctions) without the need for any heuristics! It will work at any junctions even if it is extremely complex with many auxiliary segments.

In the WME:
When defining lanes to a segment, turns are automatically displayed for the end of the segment with the segment names to which they refer.
My suggestion is to add an option for adding to lanes a "far turns". When you want to add a lanes for a "far turns", you will get an option to select the "far turn" and it will be added to the turns list for the lanes setting. You can define one or more "far turns".
The idea will look like this (attachment 1)
In the app:
The lanes will display as defined in the WME for that node (the number of lanes and the arrows).
When there are lanes at the node with "far turn", the arrows will be highlighted if the route passes in the "far turn".

An example of this type of solution is required:
The node:
https://www.waze.com/editor/?env=il&lon ... ts=1172278
The "far turn":
https://www.waze.com/editor/?env=il&lon ... des=800851
The lanes arrows:
(Attachment 2)

At this node, the arrows in the 2 left lanes (as seen in the attached photo) is for the next turn ("far turn").
The left-most lane should only show left and the lane next to it should show straight and left. Currently, the WME does not allow lanes to be defined correctly at that node. The proposal demonstrates how the lanes should be edited for this node.

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

With the recent release of version 3 of reCAPTCHA (the thing you may get to see when you log in and the system suspects you may be a bot instead of a user), it would be a great idea to upgrade to the latest version. We've had several users who have had to fill in the CAPTCHA protection every time for some weird reason (I suspect someone in their neighbourhood is to blame), which could be alleviated with the new system. The system now gives you a score between 0 and 1 to gauge how trustworthy the request is. That also means you can alter how strict the system will be.

The only downside of this means that you'll need to figure out what you'll do with people/bots with low scores. The reCAPTCHA v3 manual suggests requiring two-factor authentication or e-mail validation from such users, which would indeed help against wrong passwords, but probably won't protect the Waze map from scrapers (I suspect that is also part of the reason why the captcha was implemented).

Either way, I think it would be a good idea to already add some v3 calls in the background without adjusting any behaviour, just to get an idea of what scores the system generates.

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

With restricted areas, a level 5 (or Level X user depending on what the final level will be when released in production/country setting) could currently add a restriction to a level 6 segment.

Steps: find a rank 6 segment, draw an area on it => The segment is restricted.

This may be a WAD (similar to closures for people who have closure permissions), but it's still risky and lowers the protection of the rank system. If the user deletes the area restriction right after the map update, the problem cannot be identified without staff intervention.

Permalink: https://beta.waze.com/editor/?env=row&l ... =244207735

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