Post by PesachZ
ct13 wrote:I think a helpful addition to this page would be something that explains the road type classification on segments that are part of divided road intersections. It would be provide instructions on how to assign road types inside of the intersections, similar to the roundabout road type page.


"When road segments of 2 different types converge at divided road intersection, choose the highest road type of the parallel, intersecting segments. Doing so will ensure that high priority roads are not unduly pruned by the routing algorithm at an intersection."


Here is an extreme example of the type of graphic that could used to illustrate this point.
1.png
2.png
It' a good idea, and we should include guidance for median segments when they are not in a box junction as well.

Though I would argue that by our AGC rules in the US the two medians you set as MH, should really be mH. making them mh will have no detrimental on routing here.

The issue will be that the guidelines fo this kind of thing varies by country. Perhaps it is better placed in the page for Median Uturns, and have that page expanded to cover all median typing in the USA.
PesachZ
Wiki Master
Wiki Master
Posts: 4518
Has thanked: 1365 times
Been thanked: 1572 times
Send a message
https://s.waze.tools/gc.pngNYhttps://j.mp/1xPiWC8https://j.mp/1C9mUY2
Formal Mentoring, Wiki
Useful Wiki pages
URs & etiquette | WME | Editing Manual | Quick-Start Guide | Best Map Editing Practices | Junctions
State specific Wiki | Forum

Post by PesachZ
ct13 wrote:Maybe we can spin this off into a new topic or move to the correct place?
PesachZ wrote: Though I would argue that by our AGC rules in the US the two medians you set as MH, should really be mH. making them mh will have no detrimental on routing here.
If we followed AGC rules, it seems like the turn from the PS to the MH or the mH would be adversely effected by having the median segment set as street type. I think that having it be the highest segment type is a much simpler rule than following the AGC rules except when the road group changes; for instance, "when MH and street meet, defer to the highest type, but when 2 types of highways meet, pick the lowest of the two." would be much more confusing for a negligible (or arguably worse) change in routing. One size fits all rules are always easier to remember and since there is a bigger downside associated with choosing a lower road type than a higher one, this would err on the side of caution.
PesachZ wrote:The issue will be that the guidelines fo this kind of thing varies by country. Perhaps it is better placed in the page for Median Uturns, and have that page expanded to cover all median typing in the USA.
That sounds like a good place for it. Additionally, a link from the Road Types/USA page from this sentence would also seem appropriate.
Wiki wrote:Special rules are used to determine the road types of roundabouts and at-grade connectors.
I don't argue street would be bad, when I suggested a chance to your proposal, I meant only to change those two MH medians to mH.

I'll explain better what I meant by the AGC rule.
The wiki article for AGCs now (which really reflects the US usage for them) is simplified. It only really discusses a single segment (the agc) connected to one segment on either side.
The rule is to use the lower of the two road types. The logic which leads to this rule is that no additional penalty or pruning will ensue while traversing the AGC. Since it is continuing the same type as either the preceding segment, or the segment afterwards.

In short the logic is What is the lowest type this can be without adding an additional penalty or pruning effect .

When you expand this logic to a more complex AGC connecting more than two segments we have to apply the same logic. The simple way to explain it is very similar to how we explain roundabouts typing.
  1. Assess each possible route through the segment.
  2. List the lower road type for each route.
  3. Choose the highest type on the list you made in step 2.
With this rule the two E-W medians in your box become mH, while the other two remain PS as you had them.

The same role can be applied to an AGC connecting 3, 4 or more segments with ease.

There is a thread in the NJ where we spent a long time hashing this out for use in guidelines for jughandles.

If this is at all unclear, let me know I can create images to better explain it.

Sent using Tapatalk for Android
PesachZ
Wiki Master
Wiki Master
Posts: 4518
Has thanked: 1365 times
Been thanked: 1572 times
Send a message
https://s.waze.tools/gc.pngNYhttps://j.mp/1xPiWC8https://j.mp/1C9mUY2
Formal Mentoring, Wiki
Useful Wiki pages
URs & etiquette | WME | Editing Manual | Quick-Start Guide | Best Map Editing Practices | Junctions
State specific Wiki | Forum

Post by PesachZ
codgerd wrote:Hi all,

A discussion started recently on the Canada unlock forum as to best practice in terms of placing the junction node of an exit ramp. The wiki guidance on the Interchange page recommends placing the first geometry node of the ramp segment level with where the solid line starts at an exit i.e. at the last legal decision point to take the exit, and to put the junction node itself prior to this point such as to make a 10 - 15 deg angle with the roadway.

https://wiki.waze.com/wiki/Junction_Sty ... complexity

As (at least in Canada) it seems that in practice there is a wide range of configurations employed for ramp geometries and the wiki guidance is clearly not being followed in any consistent way, I raised the issue with my local champ mentor, who in turn raised it with the Canadian and US champs and routing experts.

I gather that the discussion is still ongoing, but it seems that the emerging consensus is that this may not in fact be the recommended guidance; rather, it seems that it should be the junction node itself that be placed at the last legal decision point, not the first geometry node of the ramp segment.

If they arrive at a full consensus on this, I suspect it will be brought to the wiki community's attention via other channels, but I thought I would raise the issue here to allow for any discussion that may be deemed appropriate.

Cheers
codgerd
I do agree that based on how the TTS timing is set up in the app, that the user will have a better experience if the junction node is at the gore ( the last legal point to make a lane change).
PesachZ
Wiki Master
Wiki Master
Posts: 4518
Has thanked: 1365 times
Been thanked: 1572 times
Send a message
https://s.waze.tools/gc.pngNYhttps://j.mp/1xPiWC8https://j.mp/1C9mUY2
Formal Mentoring, Wiki
Useful Wiki pages
URs & etiquette | WME | Editing Manual | Quick-Start Guide | Best Map Editing Practices | Junctions
State specific Wiki | Forum

Post by PesachZ
jondrush wrote:OK guys, I think I figured this out. I'm normally approaching the ramps at 70-80 mph. The other night I was stuck behind a truck doing 50, and sure enough the last exit call-out was too early. So it appears the Waze is not doing it's sums correctly when calculating the timing for the announcement. But for now, I think the classic guidance of first geo node at the gore point is still correct. You really, really don't want a late ramp call at 75 mph. Early is still better.

Then next step is to make Waze aware of the problem and see if they can fix the timing. To solve the second problem of the next command appearing too soon, I'd like to formally request that Waze delay the switch on ramps.
based on anecdotal previous testing by sketch, the speed assessment for prompt timing is not very robust. It calculates at a certain point as you approach the exit, what your speed is, and considering known or anticipated segment speeds ahead determines the appropriate times to deliver the prompts based on that. If you then change your speed after the calculations are performed, the timing does not adapt. This means if you were doing 75mph when the calculation was made, and then you slowed down, the prompt will come too early. If you speed up after the calculations, the prompt will come too late - i.e. you may miss the prompt as it may be overridden by the next prompt.

I would think asking waze to delay the switch on ramps is dangerous, as it runs the risk of no prompt being given in time when you are in a confusing interchange with successive ramps. This could easily lead users to get on the wrong highways and get delayed and very frustrated.
PesachZ
Wiki Master
Wiki Master
Posts: 4518
Has thanked: 1365 times
Been thanked: 1572 times
Send a message
https://s.waze.tools/gc.pngNYhttps://j.mp/1xPiWC8https://j.mp/1C9mUY2
Formal Mentoring, Wiki
Useful Wiki pages
URs & etiquette | WME | Editing Manual | Quick-Start Guide | Best Map Editing Practices | Junctions
State specific Wiki | Forum

Post by PesachZ
PhantomSoul wrote:Some of this may also just require editor intuition, too. I mean, if Waze doesn't consider how many lanes you may have to cross to get to an exit, the junction may need to be set back further for a highway with, say, 5 lanes than a highway with just 2, no?

Also, sometimes, we may have to cut a ramp name short so that its readout can finish in time to announce a quick subsequent turn/exit, but that's another topic, I think.
Didn't the timing auto adjust for longer names to start the prompt dinner, so they are timed to finish before the junction. This means the name length does not affect subsequent prompts really

Sent from Android using Tapatalk
PesachZ
Wiki Master
Wiki Master
Posts: 4518
Has thanked: 1365 times
Been thanked: 1572 times
Send a message
https://s.waze.tools/gc.pngNYhttps://j.mp/1xPiWC8https://j.mp/1C9mUY2
Formal Mentoring, Wiki
Useful Wiki pages
URs & etiquette | WME | Editing Manual | Quick-Start Guide | Best Map Editing Practices | Junctions
State specific Wiki | Forum

Post by PhantomSoul
The tight-angle bowtie looks much better at higher zoom levels, for sure, but I'd be concerned whether all those tight geometry nodes mess with any functionality. Also the complexity of having to know to zoom in all the way to see how the junction works...

I'd still rather see a way to functionally unite the 2 directions of a divided road so they can be treated as a single route as needed, but not tell you to simply turn left when you pass by your destination on the other side of the road.

Multi-way splits are toxic; last I've observed, all branches other than the leftmost one will announce "Keep/Stay/Exit right..." Instead, they need to be modeled as a series of quick two way splits, with the announcement for the route to the next split being silenced, if possible, and the geometry of each split reflecting the geometry of the junction (i.e., left vs right) as much as possible. Unfortunately, Waze only supports turning left, turning right, or continuing straight (no announcement) at any given junction, so if there are multiple lefts or rights, the driver is ultimately going to have to glance at the screen and figure out which one, especially if their voice doesn't read street names and/or street names aren't very well marked.
PhantomSoul
Local Champ Mentor
Local Champ Mentor
Posts: 1757
Has thanked: 311 times
Been thanked: 512 times
Send a message

Post by PhantomSoul
So just to clarify, we are no longer doing wayfinders for single lane drops on the right side where the approaching signs clearly indicate the right lane is for exit only unless the continuation path has more of an apparent curve than the exit path?
PhantomSoul
Local Champ Mentor
Local Champ Mentor
Posts: 1757
Has thanked: 311 times
Been thanked: 512 times
Send a message

Post by PhantomSoul
Some of this may also just require editor intuition, too. I mean, if Waze doesn't consider how many lanes you may have to cross to get to an exit, the junction may need to be set back further for a highway with, say, 5 lanes than a highway with just 2, no?

Also, sometimes, we may have to cut a ramp name short so that its readout can finish in time to announce a quick subsequent turn/exit, but that's another topic, I think.
PhantomSoul
Local Champ Mentor
Local Champ Mentor
Posts: 1757
Has thanked: 311 times
Been thanked: 512 times
Send a message

Post by qwaletee
There is still enormous value in having several different pages, besides any type-specific pages. Perhaps that's your intent., and I'm just not following the thread well. Regardless, here are my thoughts:

1) An overview to introduce the subject in a comprehensible manner. No matter how short you make individual interchanges within the guide, it will still be too much to use as a starting guide. It should explain concepts, simple examples, and provide links to further reading.

2) A highway interchange guide, because when an editor is trying to figure out how to do something, it tends to fall into highway/non-highway. The non-highway can be referenced here.

3) The non-highway guide

4) A specialty/rare cases/regional-only guide
qwaletee
EmeritusChamps
EmeritusChamps
Posts: 2939
Has thanked: 188 times
Been thanked: 958 times
Send a message
US Champ / Country Manager | State Manager NY, NJ, PA, CT, MA, RI, VT, ME, NH | Northeast ARC | Mentor | Responding to Map Issues

Post by qwaletee
I've also experimented with "sharp angle geonode" bowties. They look much better on the map/app. For segments not on the route, they're almost invisible.

For segments on the route, the route highlighter does show an indent at each intersection; it is subjective as to whether the on-route bump looks marginally better or marginally worse than standard bowties. By playing with the distance between the dual carriageways, especially in the intersection approach, I've been able to minimize the bump.

One advantage of this style is that it is less likely to get the angles into the junction wrong, since everything is almost square. The corresponding disadvantage is that you can only edit it properly when fully zoomed in, and may need to turn off arrows briefly for the finest control.

I find it takes about 75 clicks to convert a standard bowtie intersection to one of these, while a regular bowtie takes about 50.
qwaletee
EmeritusChamps
EmeritusChamps
Posts: 2939
Has thanked: 188 times
Been thanked: 958 times
Send a message
US Champ / Country Manager | State Manager NY, NJ, PA, CT, MA, RI, VT, ME, NH | Northeast ARC | Mentor | Responding to Map Issues