[New page] Path

Map Editors Community United States US Wiki Discussion
1

Hi everyone, I wrote a draft for a new page about paths. This [EDIT] does not include guidance for far lanes because there is no champ consensus on where to use them. It includes use cases for far turn instructions that are similar to what is on the current JB page. These two sections on far lanes and far turn instructions are transclusions, part of my unfinished updates to the lanes and turn instruction pages. They are also transcluded in my junction box draft, which is still in the works.

The guidance for far lanes comes from sketch, which he proposed to the champs a month or two ago and posted in Discord #wazeopedia_usa. Apparently there were no objections.

The guidance for far turn instructions is similar to the current JB page:

  • I attempted to clarify the use for exits with split signage, based on recent conversations about this.
  • I added the use case of continue straight movements at divided roads (per recent Discord discussion in #shields).
  • I added the use case of movements through an intersection where roads meet at an offset.

By the way, I have found in multiple places that far turns no longer use the name of the first road segment inside them by default; they instead use the name of the exit segment, as the interface indicates. This is very nice.

Please give me your feedback. I tried to make this accessible to anyone who has never tried using paths before, with clear guidance on where to use them.

2

There are two things I’m not a fan of and they are both related. This image could imply that paths should be widely used rather than only where they are necessary. I know editors who will take this as permission to put paths on every intersection. Maybe something with one or two paths shown? There are already five examples earlier on the page. Just reuse one of those?

Second, the text “Many simple paths grace the multi-lane turns of this downtown area.” Maybe something like “Paths are clearly visible with the layer enabled.”
Paths.png

3

That’s fair. I think they should be used at most multi-lane turns, as the proposed guidance for far lanes says, but that area is unusual, with multi-lane turns at pretty much every intersection.

I replaced this example with a little icon inside the text. Thanks Mike.

4

At this point I think it’s more important to understand how to map them, effects, etc. I think region coordinators are still figuring out when to map them. That aspect of guidance, if I’m not mistaken, usually starts at the Champ level.

5

Yes, exactly. I thought that the “when to map” stuff for far lanes (not every reason for paths) had already been proposed at the champ level several weeks ago, which is why I added it to the page, with some paraphrasing for readability.

Maybe I’m mistaken about that, since I’m not part of those discussions. Or if it was proposed, and there were no objections, that could mean agreement, or it could just mean that the discussion never took off. Regardless, any decision on the use of a big new feature like this needs a consensus from you guys, especially the RCs, who lead our editor communities. Even if I were to add it to the wiki, that just means it’s in the wiki, not that people will read it and follow it :slight_smile:

Here’s the proposed guidance for far lanes from my draft:

[quote=“draft” post_id= time= user_id=]
Use far lanes when necessary to provide one or both of the following benefits:

  1. More complete lane guidance at multi-node intersections that divided-road heuristics cannot combine.
  2. More specific, preferred lane guidance through a junction based on a later turn.

For combined lanes the question simply revolves around what constitutes a “single intersection.” If unsure, check street view and imagine if you as the driver would see all the roads meeting together as one large intersection or not. Check lane signage and pavement markings and try to match Waze to what the driver sees. The basic cases are # or H intersections, intersections with at-grade connectors, and combinations of the two.

Preferred lanes should be set for any multi-lane movement where you’re already getting an instruction and where the best lane to choose at the movement depends on which movement you’re going to make next. Any time you have two or more lanes going through the same turn, exit, or keep, you should consider preferred lanes. Look for applicable later movements which are close enough to make a difference about which lane to be in earlier. A good yardstick is “within about the next minute” for whether a later movement is close enough to need preferred lanes. This means about 1 mile on a 60-mph freeway, much shorter at surface speeds; use your best judgment.

Another valid use of preferred lanes is where you wouldn’t have otherwise received an instruction. For example, if you have two freeway exits on the same side about a mile or less apart, and the first one has an exit-only lane of any kind, then a view only straight at the first exit for the second exit’s lane(s) can be very helpful. If the second exit is multi-lane, you can even use that view-only to direct people into the correct lane for the 2nd exit.

This can also be done at a smaller scale on surface streets; if you have a series of hard to predict turn-only lanes then drivers can use the help.

Include the lanes that a driver actually uses through a far turn, even if overhead signage doesn’t point to them. If one lane merges into another after a turn, include both lanes to promote the merge at the proper point, rather than selecting only the continuing lane.

[/quote]

So let me know what you guys think. Do you want to discuss the guidance part here? Should I leave it out and let the community leaders continue to discuss it elsewhere? I am fine with publishing a purely informational page, but it looks like we need some wiki updates, so I’m trying to help with that.

6

Page looks nice and explains the process well!

(I know as of this comment time I’m only a L3, I’ve worked on FL in practice mode and sent to higher editors for them to add on my behalf)

I’d like to ask this, don’t remember where I heard/saw this but other than a path being easier to add, I think I remember hearing/seeing that if FLs can be added using a just a JB, to use that for the added benefit of extra data collection for different paths inside the JB, and to use paths only when a JB is not usable

I have the FL phase 1/2 how to google docs, but didn’t see them really go over into that

7

Thanks, yeah I planned to mention that aspect of the draft too but didn’t want to get into too much at once. Since you asked though, I inferred the preference for paths from a few things:

  • The US policy on junction boxes has always been to use them only where they’re necessary, and if you can accomplish what you need without a JB, to do that instead.
  • Paths are not only easier to create; they’re less risky, as they can’t mess up routing if you do something wrong.
  • Gil (I assume) said this in the Google doc about FL1 (JB far lanes):

[quote=“staff” post_id= time= user_id=undefined]
Can we map preferred lanes?
Preferred lanes are planned but not part of this phase 1 of the feature. This will be also useful for segments that do not currently have a JB.
[/quote]

That seemed like an oversimplification until I started actually adding them in an area. You’ll find that if you rely on JBs for preferred lanes you’ll run into problems very quickly, as they can’t be big enough to reach the turns that you want, and they block other JBs and paths. That’s why staff intended for us to use paths for this, and why they didn’t intend for us to add JBs just for far lanes.

Also, if you play around with route speeds and try to measure recorded turn delays through JBs, it’s actually somewhat rare to find cases where a JB makes a significant (more than a few seconds) difference in measuring average turn delays, even during rush hours. Take, for example, your typical divided road intersection. Going straight and left will take longer than going right, but within the cycle time of a light, you’ll usually get through it, and if traffic is backed up and taking multiple cycle to get through, usually that applies to everyone who has to wait at the light eventually, as the backed up cars for one of the movements end up blocking everyone else. Or, if an intersection could benefit from better data recording through a JB, the segments leading into it are broken up with too many nearby PLRs and side streets to get a JB big enough to help, without going over the connection limits.

In working on my draft update for the JB page I spent a good chunk of time yesterday looking around congested cities (Boston, Philly, NYC, LA) trying to find examples of junction boxes where the average turn delays were significantly better recorded by having a JB there, vs. just letting the simple turns record the data. There are certainly some, and I’m sure there are places where more JBs can help with turn delay recording, but I found a far fewer that do this now than I thought I would. I don’t think it’s accurate to assume that wherever you want far lanes, you’ll probably benefit from JB data collection.

8

Thanks for pointing this part out since I missed it the first time around. I found the conversation in the Champs channel. Because of how it was worded, I didn’t see it as champs formalizing guidance so much as identifying use cases. There was literally no request for consensus on any or all of it, and that’s not on you. That’s on us as champs.

Going to your draft, I do think far lanes 1 with JB needs to be included since it’s not included elsewhere and the two are mutually exclusive but functionally the same(ish). I also wonder if Paths is the right title for the article since the function changes depending on segment length.

9

Ah, that makes sense :mrgreen:

I agree that content about far lanes on JBs needs to be included somewhere. The far lanes section of my draft is a transclusion. My idea is to have this section live on the lanes page and to transclude it both on the path page and the JB page. That way it can be updated in one place as things change, without conflicting information. I wrote that section with both paths and JBs in view, and it contains examples of both, since they do work the same, no matter which container is used. Same idea with turn instructions. If a consensus develops around this draft, I plan on proposing updates to junction box, lanes, turn instruction and also the mapping considerations section in the interchange style guide. My JB draft is mostly done, but I’m waiting to see how this discussion goes, or if anyone has other ideas on how to organize the content.

10

I agree that this image shows an area that paths are very much overused. I think 90% of them are probably unnecessary. I would avoid guidance like this and just focus on the capabilities of paths for now. Reading further in this thread, I believe too much was inferred and put into this guidance and it will encourage overuse by editors. When you say, “I think they should be used at most multi-lane turns, as the proposed guidance for far lanes says” - that is solely your opinion and should not become guidance for the community based on that.

Also, with a lot of priorities right now, I would hope you wouldn’t publish this in the “7 days from posting” since a lot of folks probably haven’t had time to review it and weigh in. FYI, there was a draft started in the champ channel that still needs discussion at that level, so you probably won’t see the discussion here.

11

It’s a great start, however, I do agree with the others we need to nail down more concrete guidance on the when to map. That first image did scare me a bit :shock:
That’s something us Champs need to nail down, however, we have been bogged down by multiple new priorities/projects in the last few months

12

Thanks for your input, Lisa and Joe. I am aware that there is a lot of activity around EV charging stations, and I understand that many people don’t have the time to look at this or talk about it, so I appreciate that you found the time to do so.

Sorry to scare you both with that image. You can see that I took it out, because it could be misleading, implying at first glance that every intersection needs paths. I apologize for the implication. However, in our discussion in the lanes channel and others, since far lanes 1 and 2 came out several months ago, no one ever suggested that the various use cases exemplified in my current draft are “overuse”, or that the ideas behind them are wrong. I am curious what your standard for that is, Lisa. Some minimum level of traffic? Only very small distances to the next turn? Perhaps excluding a route that’s very unlikely to be offered? All those might be workable standards. Obviously, as with normal lane guidance, paths and far lanes should not be used where they make no difference, but that’s a pretty low bar to clear. Of course, without a clear standard, calling something overuse is merely an arbitrary judgment.

It’s clear that there is not the consensus around this that I thought there was. If there is an active discussion somewhere or will be soon, I am happy to wait until that’s concluded before publishing this draft. Or I can rework the guidance section into just the most obvious, non-controversial use cases (maybe split exit lanes, preferred lanes indicated by signs, non-perpendicular # junctions?). The point of publishing in the wiki is not just to wait a week and do it, but to make sure there’s reasonable consensus about what goes in there. Again, putting things in there that people, especially community leaders, haven’t agreed to doesn’t help our community.

13

+1
I have had this proposal open since it was posted and I want to comment, but I am bogged down with other stuff at the moment.

14

On another note, based on some feedback from a somewhat newer editor who has never tried paths, I reworked the intro and overview to try to make them more understandable, and I added an expandable, extended intro in the far lanes section, which shows an example of an intersection where standard lane guidance is inadequate, and how far lanes can be used stepwise to improve it. I would love to get any suggestions or feedback making this topic more understandable to less experienced editors

In particular, I remember during Gil’s office hours that Joe (and pretty much everyone else) wanted better documentation and visualization of the 50-meter rule for where the lanes get pushed. I have a section about that, but maybe it could be improved.

I also had forgotten to add a switch route section, so that’s in there too. From testing, it’s clear that more than 3 routes can be cycled through in the switcher, but they must be five segments or less, consistent with the requirement for automatic path creation. Probably doesn’t matter much, but it’s interesting.

15

I’m not going to any specific opinion/guidance here because it would be my own half-formed opinion, not a consensus of champs. There is not a currently active discussion right now as there are other priority items being worked (EVs being only one of them). IMHO, I wouldn’t put any guidance in there since what seems obvious or non-controversial to you may or may not actually be either.

16

OK I removed the guidance stuff

17

I know this is technically correct “Need not fit within a 0.001° by 0.001° bounding box.” I suggest clarification of 1km maximum. Not everyone understands those degrees are different than the angle between to segments.

18

Good point. I added a brief explanation and link to the relevant section of the JB page. I had extra zeroes in there too - whoops

19

Good point. I added a brief explanation and link to the relevant section of the JB page. I had extra zeroes in there too - whoops.

I also added some more images about where you need a JB for data, and an advantages section about how nested paths can help make the app less chatty in complex situations.

20

Hey Karto. Thanks for working on this. Here’s a few mostly small things. I’ll try to find time to dig into the content. I did DM you on Discord with one thought.

Editing
(old zoom 4) - Do we need old zoom levels? it seems like it’s been a couple years since zoom levels changed.

For the path icon images you may be able to use the original here
I wasn’t able to find the other icons in WME inspect.

Many of the images are small thumbnail images. Would it be possible to make these image larger so we don’t have to click on the image to see what is being presented? The problem I’m having with that is when I click an image to enlarge it, then X out to get back, the page scrolls to the top and I have lost my place. Which disrupts the train of though for my small brain capacity.

This section could benefit from an example. I find myself sending pictures to others to explain it. Also using “may” sounds like it might or it might not.

Thanks.