voludu2 wrote: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.

voludu2 wrote: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.

qwaletee wrote:Well, for the other side of safety, it actually presents a problem. In the past week, we had one event where the closure server went down, and drivers were being routed through closed segments. OTOH, since closures are real-time, that's safer than waiting possibly days for a tile update. Also, false positives can lift the closure inappropriately (e.g., construction worker who forgot to turn off Waze when he reached the site, mis-snapped drivers, bad GPS data).

Note also that in the sense you are primarily using it - data preservation - it is only safer than a disconnect or hard turn restrictions.

qwaletee wrote:Do you have all that verified? Or is this opinion?

For example the info on % of usual traffic density verified? Because I saw a closure lifted with what seemed like very little traffic locally to me. I guess it was a % - you know the old joke, zero is a number, too.

And don't be so sure about snapping either. We know that the detailed analysis takes place in the drive update server, which is not real-time. We know closure lifts are real time.

And automatically reinstated closures? This is absolutely the first I am hearing about them.

DwarfLord wrote:This is wonderful, thanks!

I do remain deeply concerned that the article implies that real-time restrictions fully close the affected segment, which appears not to be true. The best illustration might be this:

Consider a single segment that has a one-way closure put into effect. It is open to traffic westbound, but closed to traffic eastbound. The road crew has put a big "ROAD CLOSED" barrier at the west end of the segment.

The average editor could, I think, be forgiven for expecting that the result of a one-way real-time "closure" in WME will be that Waze will route drivers to destinations along that road by taking them to the east end and then into the segment westbound. But this is not what will happen. Waze will happily route drivers to the west end and right through the barrier.

To create the closure effect we want, it will be necessary either to close an additional segment leading into the west end which in many circumstances might require adding a junction node specifically to support this "lead-in" segment, or to add timed turn restrictions at the west end. But both of these approaches contradict the guidance in the wiki that there is no need to modify the map!

I may be misunderstanding the behavior of real-time restriction functionality, in which case I apologize! But this is how my tests are shaping up. If this is how real-time restrictions operate I believe it would be a great asset to editors for the wiki to articulate that.

DwarfLord wrote:While you're talking with the devs, here is a specific example of the problematic behavior. It is a vehicle-based restriction, not a real-time closure, but the behavior is identical.

https://www.waze.com/editor/?env=usa&lo ... ts=5071831

Only Muni buses may drive this segment eastbound. So, it was thought that a segment restriction that prohibited all but public transportation from eastbound travel would reflect that. But no!

We have a UR from a Wazer whose destination was on that segment whom Waze blithely routed right down the muni lane.

So, a one-way segment restriction actually treats the segment as two-way in the case of local traffic. I don't think that is intuitive behavior for segment restrictions any more than it is for real-time closures. I sure would be grateful if you could run this by the Waze devs!

DwarfLord wrote:Regarding vehicle-based segment restrictions -- that function the same as road closures, with an exit penalty instead of an entrance penalty -- here is an example of a workaround.

As in the previous example involving Haight, Waze has been routing drivers (presumably whose destinations were on this section of McAllister) down a Muni lane. This was counterintuitive to the marking of the segment as closed to private vehicles going that direction.

https://www.waze.com/editor/?env=usa&lo ... s=85071610

Rather than create two vehicle-based turn restrictions that would be intuitively redundant with the segment restriction, I just added a junction node a few meters from the intersection.

Since road closures behave the same, perhaps this is a good workaround for now when implementing road closures, especially one-way road closures. Extra junction nodes are fairly innocuous if they stick around after the closure is over.

Now, I don't *like* this workaround (though I like it better than multiple redundant vehicle-based turn restrictions) and I'd prefer more intuitive solutions. But the more intuitive solutions all involve Waze changing something...