DwarfLord wrote:

DwarfLord wrote:If a destination is located along a closed segment, will Waze route the driver as if the closure wasn't there?

It would seem the answer is yes.

So, is the only way to really, truly, completely CLOSE a road to use turn restrictions? I'm a bit befuddled here.

Screen shot 2015-03-21 at 9.13.56 AM.png

I mean, what's the problem though, exactly? Don't you want to get as close as you can to your destination, if it's on a closed/restricted segment? It's up to you not to make that last turn.

The difference between restricted segments (plus closed segments I'm sure) and private/parking lot roads is that restricted segments do not create a network. You can get a turn onto a restricted segment if your destination is on that segment.

There is actually some work under way to amend the side closures statements. I believe it will be presented here, shortly. (This guidance has been looong overdue, IMHO. Caveat: there will be resistance)

Having had to explain the Ignore Traffic box a couple of times recently, and noting the fact that we have no wiki info on it, I'll heartily support the revision for that.
Perhaps "... a brief period of time..." or "a small fraction of an hour", if we don't want to be too specific about the duration.

I believe, but am not 100%, that the same threshold applies for re-closing the segment, as that for opening it.

And I wonder if the addition of the word "automatically" prepended to "reinstated" might make the information that little bit clearer, or if it would just be so much noise.

I think this new content is going to be helpful.

I would like to see it reorganized, so that the vast majority of editors, who cannot use the real time closure interface, can understand what they should do.

1) The primary page, which is the one that the vast majority of editors will find first, will explain, very simply, what the preferred method is and why, and also link them to how to submit requests for real time closure, as well as to set expectations for how long it will take (in the US NE region, for example, this is currently 4 to 6 weeks) to get a real-time closure onto the map. This is the information most editors need to know. It will help them decide whether to put in a TBR to cover the 4-6 week gap until they are likely to get the Real-time closure, so that at least waze will not route wazers through the closure. This information might appear on a separate page, which can also be linked from other pages, such as a guide to how editors can get help from other editors to get stuff done.

2) I would like to see a clear separation between "best practices" and "detailed instructions on using the WME interface" So that the long section on how to use the interface would perhaps be a separate page. That "how to use the WME interface for real time closures" page can then be linked directly from the Map Editor Interface and Controls page.

Following this, I would also like to see translation into some kind of Simple English.

There are a few little things that need to be fixed up (like nonexistent https://wiki.waze.com/wiki/User:WonderL ... res_in_wme)

What is meant by "safe" in this context? It is not clear to me, and I don't think it will be clear to those who most need to read this page.

Now I am enlightened. You have provided two things -- a definition for what you mean by "safe" in the article and also a persuasive paragraph about why this "safety" makes RTC a better choice.

I think "safe" will be confusing for others. (Safe for drivers?). I think lede paragraphs or sections can use a phrase like "RTC preserves all map and traffic data and will disappear once enough wazers drive through it". If there is a more detailed sub-section, it can use the full list of all the things which RTC leaves intact and which other approaches destroy.

As for 2b -- Waze will only RARELY route drivers through closed segments. Description of the exceptions is out of scope for the article, but is a real edge case.

I think we should have a section on "Ignore Traffic" and what happens in WME when this option is checked or unchecked.
* if unchecked, then enough Waze traffic transiting a closed segment causes a temporary suspension of the closure penalty on that segment for some period of time. If Waze traffic ceases (or, perhaps, is very little - I don't know which it is) for some period of time, then the closure penalty on that segment will be reinstated if it hasn't yet expired.
* if checked, then the closure penalty will be in effect until expiration no matter how much Waze traffic transits the segment.

edsonajj wrote:There will soon be no need to explain the function of the ignore traffic checkbox, this just appeared in Transifex today:
"Check this box only if the closure is permanent and Waze should ignore any detected movement"

Even so, I think it is worth explaining on the wiki page (which is what is proposed here). A significant number of editors are under the misapprehension that, if traffic is detected and the box is not checked, then the RTC will expire early. The truth is that it will be temporarily suspended, and will be automatically re-enabled if traffic ceases before the RTC expiration date/time.

Well sure. I have heard that you champs have been successful getting the Waze team to change some of the strings used in WME.

Making this change to the wiki page should be easier, as it does not require Waze team approval, merely a good discussion to make sure the explanation is global in scope and clearly stated, followed by approval from the global wiki moderators to make the actual change.