36 results found

1. Keep previous history for merged/split segments

   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

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

   110 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   Added to backlog  ·  AdminWaze Team (Admin) (Admin, Waze) responded

   Hey!

   Thank you very much for this great suggestion.
   It was added to our backlog to try and see the possibility to implement it.

   Please note there is no ETA for it yet.

   Best,
   Hezi

2. [Segment Attribute Request] Treat 2 Way as Divided

   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

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

   •  

   100 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   4 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   Added to backlog  ·  AdminWaze Team (Admin) (Admin, Waze) responded

   Hey,

   This topic may not answered as part of the suggestion up until now, but it has been discussed multiple times across the relevant teams.

   We will keep on updating with any news

   Best,
   Hezi

3. Restrictions feature (TBR): Limit access by editor level

   The restrictions tool used to be simpler a few years ago. Today it allows to setup not only time/days restrictions but also permits/passes, number of passengers, toll roads and more. With new options such as "allowed", "toll free" and "prohibited" it became confusing even for higher rank editors sometimes.

   I've lost count of how many times I checked editors that made 1-2 edits and that added a 24/24h 7/7d permanent restriction on what should be a simple "private road". Or even setup a freeway pass on a simple street.

   This tool has become extremely complex and powerful, especially since routing was changed years ago to treat any segment with a restriction applied to behave as a "Walking Trail", not routing into the segment but stopping at the junction node if the address is on the segment.

   Applied restrictions are almost impossible to detect or keep track of. Without scripts or selecting and opening menus, we cannot easily differenciate a useful restriction from a wrong one. The UI also makes it harder to see, compared to a wrong red/green arrow, missing segment or other more obvious errors.

   For all of those reasons it should be possible to restrict its usage per level and per country.
   I would personally make it available only at L2, as 3000 edits is usually enough time to figure out that segment types exist and what their penalties are vs adding restrictions.

   The restrictions tool used to be simpler a few years ago. Today it allows to setup not only time/days restrictions but also permits/passes, number of passengers, toll roads and more. With new options such as "allowed", "toll free" and "prohibited" it became confusing even for higher rank editors sometimes.

   I've lost count of how many times I checked editors that made 1-2 edits and that added a 24/24h 7/7d permanent restriction on what should be a simple "private road". Or even setup a freeway pass on a simple street.

   This tool has become extremely complex and powerful, especially since routing… more

   59 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   Added to backlog  ·  0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. combine Lane guidance segments

   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.

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

   62 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   3 comments  ·  General  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   Added to backlog  ·  AdminWaze Team (Admin) (Admin, Waze) responded

   Hey,

   Thank you for this suggestion.
   We have added it to our back log. It will take some time. But it will be be solved as part of JB revamp.

   Thanks

5. Segregating effective and suggested closures

   WME shows two kinds of closures:
   - effective closures, affecting routing and visible on livemap
   - suggested closures, non affecting routing and not visible on livemap. Those suggested closures always have a duration equal to a multiple of 24 hours, starting and ending at the same time of day (on different days, obviously), and are usually created by editors having a layer lower than 3. Those suggested closures result from closure reports made from the app.
   The WME displays both kind of closures using exact same visuals: it is necessary to open and examine the closure, to determine if it is effective or suggested.
   I suggest enhancing the WME to allow visually identifying the type of closure.

   WME shows two kinds of closures:
   - effective closures, affecting routing and visible on livemap
   - suggested closures, non affecting routing and not visible on livemap. Those suggested closures always have a duration equal to a multiple of 24 hours, starting and ending at the same time of day (on different days, obviously), and are usually created by editors having a layer lower than 3. Those suggested closures result from closure reports made from the app.
   The WME displays both kind of closures using exact same visuals: it is necessary to open and examine the closure, to determine if it… more

   32 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   Added to backlog  ·  0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. POI's moving distance

   At the moment moving a POI have a distance limitation (2km I belive?) Sometimes when a business changes phisical place to another place, like 10km away, we need to move the POI like 2km, save, move again, save again...

   It makes no sense. Please remove it or allow us to move POIs further.

   Thank you.

   40 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   Added to backlog  ·  1 comment  ·  General  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. Subscribe to segment

   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

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

   93 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   Added to backlog  ·  AdminWaze Team (Admin) (Admin, Waze) responded

   Hey!

   Thank you very much for this great suggestion.
   It was added to our backlog to try and see the possibility to implement it.

   Please note there is no ETA for it yet.

   Best,
   Hezi

8. [Request] Map Comments Expiration Notification

   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

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

   45 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   2 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   Added to backlog  ·  AdminWaze Team (Admin) (Admin, Waze) responded

   Hey!

   Thank you very much for this great suggestion.
   It was added to our backlog to try and see the possibility to implement it.

   Please note there is no ETA for it yet.

   Best,
   Hezi

9. Do not move my map somewhere else after an edit

   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

   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.… more

   24 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   Added to backlog  ·  AdminWaze Team (Admin) (Admin, Waze) responded

   Hey!

   Thank you very much for this great suggestion.
   As we believe this will be solved with a release of related features, we added to our backlog to track and make sure it was solved.

   Best,
   Hezi

10. WME frontend should show backend errors

    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

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

    11 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Added to backlog  ·  AdminWaze Team (Admin) (Admin, Waze) responded

    Hey!

    Thank you very much for this great suggestion.
    It was added to our backlog to try and see the possibility to implement it.

    Please note there is no ETA for it yet.

    Best,
    Hezi

11. RTC : ability to add them on current tiles

    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

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

    20 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    1 comment  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Added to backlog  ·  AdminWaze Team (Admin) (Admin, Waze) responded

    Hey!

    Thank you very much for this great suggestion.
    It was added to our backlog to try and see the possibility to implement it.

    Please note there is no ETA for it yet.

    Best,
    Hezi

12. Show "Hidden" external providers like Yext

    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

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

    •  

    13 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Added to backlog  ·  AdminWaze Team (Admin) (Admin, Waze) responded

    Hey!

    Thank you very much for this great suggestion.

    It was added to our backlog to try and see the possibility to implement it when we will next use external providers.

    Please note there is no ETA for it yet.

    Best,
    Hezi

13. Show RPP PUR's on feed list

    There is no privacy issue involved here.

    There's simply a pin in the map, among many others, but I can't find them like any others, just because category is "residential"

    The privacy issues are solved by the already omitted creator/updater of the place. By not showing them, you are simply making it harder for the PUR be moderated, as we have to scan the map or rely on scripts to do that.

    So, plainly: RPP PUR's should be shown in feed list just as any other PUR.

    OBS: Previous discussion took place here: https://www.waze.com/forum/viewtopic.php?f=211&t=249211&p=1774596#p1774596

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

    There is no privacy issue involved here.

    There's simply a pin in the map, among many others, but I can't find them like any others, just because category is "residential"

    The privacy issues are solved by the already omitted creator/updater of the place. By not showing them, you are simply making it harder for the PUR be moderated, as we have to scan the map or rely on scripts to do that.

    So, plainly: RPP PUR's should be shown in feed list just as any other PUR.

    OBS: Previous discussion took place here: https://www.waze.com/forum/viewtopic.php?f=211&t=249211&p=1774596#p1774596

    By: biuick84
    Link to original suggestion: … more

    3 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Added to backlog  ·  AdminWaze Team (Admin) (Admin, Waze) responded

    Hey!

    Thank you very much for this great suggestion.
    It was added to our backlog to try and see the possibility to implement it.

    Please note there is no ETA for it yet.

    Best,
    Hezi

14. Better history for place update

    Hey,

    in place edit history, it would be nice to have more details on PUR : the only status is accepted or rejected.
    Maybe it is not easy to tell what photo was refused or a refused change name, but it would be nice to know what was the updated fields (was it about adding or removing a photo, rename the venue).

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

    •  

    6 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Added to backlog  ·  AdminWaze Team (Admin) (Admin, Waze) responded

    Hey!

    Thank you very much for this great suggestion.
    It was added to our backlog to try and see the possibility to implement it.

    Please note there is no ETA for it yet.

    Best,
    Hezi

15. New Place Address

    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

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

    •  

    •  

    •  

    0 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Added to backlog  ·  AdminWaze Team (Admin) (Admin, Waze) responded

    Hey!

    Thank you very much for this great suggestion.
    It was added to our backlog to try and see the possibility to implement it.

    Please note there is no ETA for it yet.

    Best,
    Hezi

16. Improvements in segment selection for road closures

    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

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

    0 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Added to backlog  ·  AdminWaze Team (Admin) (Admin, Waze) responded

    Hey!

    Thank you very much for this great suggestion.
    It was added to our backlog to try and see the possibility to implement it.

    Please note there is no ETA for it yet.

    Best,
    Hezi