Kent and I have been discussing a change to the lede for the article. It gives the uses for it, which is somewhat redundant to the main text, but I believe may be needed due to the length and complexity of the article.

There is also an Overview section, which is sort of a second lede. Possibly, it should be merged into the lede, providing a single introduction to the topic that explains the basics of what it can do or can't do, where you might want to use it or not, and what alternative mechanisms there are.


Another thing to look at is breaking up the article. One possible way might be:

* Overall introduction with few details and links to the other articles
* Explanatory article specific to TBTR (not segments)
* Explanatory article specific to segment restrictions
* Explanatory article specific to time restrictions (separate from vehicle)
* Explanatory article specific to vehicle restrictions (separate from time)
* How-to article on the mechanics of using the restrictions interface, which is common to turns, segments, time, and vehicle

So, three or four approaches:

1) Improve lede without any other major changes
2) Improve lede and merge in overview section material
3) Either together with the above or separately, break the article into more digestible chunks, separating the mechanics of the interface from a a general overview and from subtopic-specific overviews
( or 4) restructure is some way differently than I described)

Your thoughts are appreciated.

The zipper lane seems to be an example of a reversible HOV lane, or something similar. If it qualifies for HOV lane status, current guidance would be to include it. If it create a path that in unique, we would have to include it. If all it does is add an extra lane in one direction at certain times, which is close enough to the other same-direction lanes to allow Waze to "snap" it, then it probably isn't necessary at all.

I did not examine the entire route closely enough to follow its exact situation.

(BTW, I think we need to update guidance on HOV lanes. On the Gowanus Expy in Brooklyn, it is mapped per guidance, but it only creates headaches without solving problems. I would love to take it out, and only add it back in if Waze has better support for HOV making it valuable. For now, it just makes the roads look like headphones coming out of my pocket.)

There are several issues that come up:

1) sheer complexity -- when you have a complicated series of parallel roads (HOVs, primary, service, ramps) it can be a mess to edit, which seems like a waste when Waze does not currently support it

2) drivers snapped to wrong road on occasion, leading to weird instructions, especially when they are very close to the other lanes and/or "wander"; secondary effect can be speed data pollution

3) once in a while, if traffic is absolutely terrible, Waze sees the HOV PLR cost as not high enough

HOV and HOT are a little different, but nevertheless, a lot of the discussion overlaps.

Where there is clear lane separation, enough for Waze to snap to the correct road and measure independent speed data, there is no reason not to do so. The characteristics avoid many of the issues, and it may even make sense to map them as regular Freeway type.

Where they are mapped as PLR, and they are close to the regular lanes, there's no real advantage to having them mapped UNLESS there is a different exit configuration. Here's why:

Once set up as PLR, Waze will not route via the HOT/HOV regardless of driver preference. It is only when the driver chooses to take his/her own initiative of taking HOV/HOT that Waze would use a mapped HOV/HOT, after POSSIBLY snapping to it and recalculating the drive. If that occurs, but exits are still identical (same exits, same naming, same maneuver to exit), then we have no advantage to mapping it even once Waze does snap to them, because the driving instructions will be identical no matter whether you chose HOV/HOT or not.

If exits map differently for HOV/HOT, then having mapped the special lanes is an advantage in that Waze knows that the driver can't take the "skipped" exits. But that's assuming Waze snaps the driver to the HOV/HOT. If they are crowded together, this probably won't happen, so the theoretical advantage disappears (and the potential for problems does occur, if a regular lane driver is ever incorrectly snapped to HOV/HOT).

So here would be my guidance:

Crowded, with no difference in configuration: Never map, no advantages, all disadvantages
Spread out, with different configurations: Always map, and use regular Freeway type, suffix (HOV) or (HOT) . No disadvantages, and would cause problems without

Spread out with same configuration: Safe to map same as above, has advantage of not confusing Waze over possible missing roads

Crowded with different configuration: Judgement call, but preference would be to not map, as it is only an advantage for those who ignore Waze and take it despite lacking the instructions... whereas drivers who follow Waze may sometimes get bad routes because of bad snapping. If it is mapped, set each entrance segment as a PLR (tolled if HOT) with same suffixing as above.

kentsmith9 wrote:

CBenson wrote:However even if I have avoid toll routes selected, waze will route through toll segments in some instances. For long routes over 100 miles or so I get an error if the only non-toll route is too circuitous on low road types. But for shorter commuting type trip lengths, waze simply gives me a toll route even if I have avoid tolls selected and there is not a reasonable alternative.

I seem to have a different experience just now in a test. Near the entrance of the San Mateo bridge I routed across to the coastline. With avoid toll, the three routes were by land only and took 60 minutes plus. When I allowed toll routes, two of the three routes were across the bridge and the direct route was 35 minutes. The other two had other roads to get to the coast that ended up taking as long as 60 minutes.

So if I had avoid tolls during my commute to work, it would not give me a bridge if it saved 25 minutes of my 60 minute route. That is a fail in my book.

That's a fail in that the routing engine has a very limited toll avoidance system. It is not aware of relative costs of tolls, number of tolls, and balance of toll size versus detour. In my limited testing, it seems that avoid tolls is applied at just after the pruning process. If it fails to find a route at that point, it will drop the toll check, and go back to using any route that was not pruned, even a tolled one. But if the only untolled route uses local streets, you won't get that route.

If we had a way of indicating relative amounts of tolls across the route, and there was some sort of slider for detour:toll instead of just a checkbox, then you might be able to get what you want. Until then, in many cases, you can end up with what you got. Fail? Yes, for real life. But that;s a system limitation, not a bug, adn we have all sorts of system limitations that are frustrating when routing using Waze.

Kent,

Got it. I imagine there are other places where we need to make exception, too.

I am finally following up on the HOV/HOT guidance discussion above. I have produced a test revision page that is close the version I proposed, incorporating the suggestions of I believe sketch, kent, and CBenson, with some revisions of my own.

Please take a look and let me know what you think. I suspect the wording can be simplified/bulletized in some cases, and other formatting changes. But please let's start with whether it is sagacious, before we tinker with the presentation.

https://wiki.waze.com/wiki/Carpool,_HOV ... s/Revision

Note that the discussion of HOV/HOT is probably a diversion for this thread, so we may want to move the posts related to it into a dedicated one.

CBenson,

I believe we covered most of this earlier in the earlier discussion, but I have no problem opening it up again. The logic behind the overall solution is in bullet points below, but I'd like to address what I think are the main themes of your questions first.

You are bothered about the choice of PLR versus HOV restrictions checkboxes. Long-term, I agree. For now, since I don't have a crystal ball telling me when Waze will be ready to release bug-free HOV preferences in the app nor how long it will take for the new version to become prevalent, I'm continuing to not rely on them. It's "soon" syndrome, right?

If my POV on "the future" is incorrect, then yes, I need to rework this. If my POV is correct, however, would you still have those objections?

On the amount of separation and varying separation, I see your point. Needs some additional work in this area. I was thinking about situations where there are long stretches of crowding, where the GPS inaccuracy could be a real issue.

Future direction - definitely outdated, I didn't touch the rest of the article, and I should. I'll try to get to that over the weekend.

------------

Summary of the logic leading to the current decision matrix (for those who do not want to re-read the whole thread):

* We have an imperfect system, we have no way of having true restrictions today, or of consistently either allowing the route or disallowing them.

* Where there is a special advantage to the routes (not just a dedicated lane, but a bypass route) we want to allow Waze to take advantage of them. Therefore they need to be completely restriction-free, and we rely on drivers to recognize that they may need to bypass it. Expect URs, but nothing we can do about that. By definition these will be limited access roadways, so they will always be Freeway. This is case (2b).

* Where there is no special advantage other than a more lightly traveled lane, we want Waze to ignore the dedicated lane for route proposals, but recognize it if taken anyway, to avoid MPs and to record corrected data where possible. This is case (1b).

* The commonality of the "b" cases above is that Waze can differentiate lanes. For the "a" cases, it will probably not be able to differentiate, so for both cases, we don't want to map. Where there is no difference between the restricted/unrestricted lanes, there's really no case for mapping (2a), but there may be some circumstances where we want to map (2b) because otherwise we could be closing off a real routing option.

* In some areas, this guidance will create routing problems for many editors. Because of this, always check local guidance. An example is the San Francisco area, where the combination of HOt (toll lanes) and unavoidable bridge tolls would lead to questionable routing under the proposal.

CBenson,

>> We used to use PLR to dissallow them. Now we can restrict them to only HOV vehicles which also disallow them

That's predicated on the HOV restriction setting having an effect on routing. That is not true today, so it is effectively "restriction free." Certainly, we should indicate correct HOV restrictions where we have them, just like we should be putting in truck restrictions. They're for the future app that supports those settings. The same applies to your last remark.

For today's app, which doesn't support those settings, we have to have a strategy that avoids routing there in the cases I suggest to map as restricted. That would still be via use of PLR (alongside the forward-looking HOV settings), until such time as it is safe to assume that drivers have HOV-based routing available.

ON the comment "HOV should always apply" -- there are exceptions. Right now, we're treating HOT and HOV lanes the same. The HOV will migrate to HOV restrictions (which we can set up now), but the HOT will continue as before, unless we get additional restrictions support.

OK, got it. I missed the subtlety of the private vehicles. I will update the page proposal to explain this clearly.