I am proposing updates and a general cleanup of the railroad section of the road types page. Some regions have started mapping all tracks instead of a single, central track, and adopting this guidance nationally complements a proposed overhaul of the RRC page.
Some of this page goes back as far as 2016, and there have been enough changes to the app rendering, the addition of RRCs, etc. that I believe make this a realistic shift in mapping standards. Some of the cleaned up information being removed no longer applies with changes to WME over the years.
Also, would this maybe be worth moving to its own page, similar to how pedestrian paths, ferries, and driveways have their own now? Just leave a short description on the road types page with a link to a railroads page.
Looks like a needed streamlining. As you say this page had accreted a fair bit of bits and pieces that no longer make sense.
Functionally, it would be helpful IMHO to explain that the reason we never use negative elevation for railroads is that, in any case where negative elevation would be appropriate, we wouldn’t map them at all.
Also, the language specifying junction nodes on either side of a railyard was puzzling. If there are other junction nodes nearby that will handle timing issues, we don’t need additional nodes at all. Meanwhile we don’t need to junction a drivable segment in order to place a RR crossing alert there. I don’t think you meant to say, place two RRXing hazards on either side of multiple-track grade crossings…?
Finally I’m apprehensive about mapping every track in a rail yard. It seems to me this adds a lot of complexity that the current app display is not designed to display in a human-friendly hierarchical way. For example, mapping every track at the terminus of the Caltrain tracks at the San Francisco station…
If formatting allows, put the examples (graphics) inline with (to the right or underneath) the associated text for clarity. I would do this for each recommended placement cited.
The number of possible examples that could be referenced (possibly thousands) should be limited to just enough so that editors can make a reasonable determination of placement, which I think you’ve done.
Where a single road has two parallel tracks, are you suggesting that each track be added to the map and connected to the drivable road segment? I’m unclear about this. To date, many RRCs have just one rail segment representing two parallel tracks.
@DwarfLord I’m good with the negative elevation update.
For junction nodes, that came from this thread - I wasn’t really looking to reopen that whole thing, but maybe we need to?
As for every track in a yard, it’s being done in some regions. It looks cleaner than you’d think, and the app groups all the similar names into a single label like it does with other roads.
@banished Are #1 and 2 in reference to the railroad road type update or the RRC update? Unfortunately, in-line doesn’t work great in Discuss. It’d be quite the long bullet point list if we added it below each point and likely hard to read/interpret being so broken up.
For #3, yes. Some regions have started mapping every track.
Thanks for the great examples. That level of detail, particularly for non-drivable segments, strikes me personally as unnecessary and distracting. But it doesn’t directly impact routing, so it’s really just a matter of taste.
I’ve brought the topic up in the SWR region. Maybe we’ll embrace the increased detail, maybe we won’t. If the latter we can always introduce region- or state-specific negating guidance.
(As an aside, I’ve often thought how useful it could be if we could poll drivers. As editors, we experience the map differently from ordinary people. Our taste in map detail is not guaranteed to be theirs. But, either way, many editors enjoy adding detail to the map, and that’s also important.)
Regarding the junction nodes, the old guidance is conceptually simple – the goal was to avoid introducing unnecessary junction nodes. The difficult-to-follow language tried to explain the circumstances under which adding a junction node could do any good.
But with Waze, I’ve noticed, the ground rules are always shifting. Perhaps there’s no longer any need to be judicious with junction nodes? Guidance would certainly be easier to understand if we just junctioned every track at every grade crossing. It’s been my understanding that the short segments would lead to poor speed averaging, but maybe they don’t any more? Or, even if they still do, maybe that’s a small price to pay for simple, clean guidance?
On the other hand, if we are still trying to minimize unnecessary junction nodes (?) I can try to clarify the old guidance.
Based on several meetups, there’s not as much concern about minimizing junction nodes like we had to 10 years ago. That said, we don’t want 4 nodes at a 4 track crossing, but have the end tracks as nodes allows traffic to detect traffic backed up due to a train crossing, as well as provides a means of closing just the crossing due to construction or derailment.
I think we would need to discuss a crossing junction style guide if we proceed, as 2 tracks likely won’t be spaced enough for a 6m minimum segment length, so choose 1. Then do you do the middle for 3 tracks, or each end for the reasons above? And then you always have the situations like this where you have one or more very close road intersections where you have to consider for speed data as well.
I thought of another exception this morning too - we probably don’t need to map multiple light rail tracks when they’re within the road traffic lanes. It’s already somewhat messy when it’s just a single track.
If segment length isn’t the issue it used to be, then I’d certainly favor simplified guidance.
At the same time, we don’t want to require editors to add junction nodes that won’t have any beneficial effect.
How about something like this:
In most situations where at least one junction node already exists very close to a grade crossing, adding a new junction at the grade crossing itself adds no benefit. It doesn’t help, for example, to add junction nodes where a railroad track running in the median between two opposing lanes of traffic crosses median segments. Nor does it help to add a junction node where a rural road crosses a track a few dozen feet before intersecting a highway parallel to that track.
Further, adding junction nodes at tracks that are abandoned, or only irregularly in service, also serves no purpose.
Regarding multi-track grade crossings, I don’t see value in having two or more junction nodes at a multi-track grade crossing. Junction nodes provide differential delineation of multiple outcomes of traversing a segment. Those outcomes include continuing, turning left or right, stopping at a destination along the segment, etc. A segment that has no differential outcomes – no destinations, and no choice of direction upon exiting – is a segment that doesn’t need independent existence from a timing standpoint.
Given that short segments within a multi-track grade crossing would not offer choice of outcome other than continuing, and would not have any destinations along them, I would think simply one junction node per grade crossing would be the maximum.
Which could be condensed simply as follows:
However, since the likelihood of material routing degradation from adding junction nodes is considered low, editors may err on the side of excess when junctioning railroad grade crossings. In any event, no more than one junction node should be necessary at any grade crossing, including multi-track grade crossings.
We should only be mapping rail that is conspicuous to an automobile driver (adjacent to or crossing a roadway) or carry passengers. Rail personnel are prohibited from using personal electronic devices, so only rail passengers would be corrupting speed data.
I’m happy with the current guidance of leaving railroads unnamed.
I like the wording, and I lean more towards the sentiment your last paragraph. More junctions allow for a shorter/more accurate closure of the crossing or an occurrence on the segments on either side of it. They’re not harming data collection, just breaking it into two segments of straight-ahead data and should be fairly similar to the original, uncut segment. Even if a line is exempt / irregular service, no harm in having it junctioned unless it’s an issue described in your first paragraph. I think this follows your reasoning for multi-track crossings, without the worry of a shorter, not-as-useful middle segment
Some regions are already mapping multiple tracks and adding some number of junctions at them - hopefully some one can chime in about that and their reasoning / experience.
I think we may also want to specify about situations where two different crossings are in close proximity, with their own sets of gates, lights, etc. They should be junctioned separately (and RRCs are proposed to be mapped since), since trains are going to come on the different lines at different times.
With that reasoning, we should only be mapping a few hundred feet of rail at each crossing (if there is no parallel road), since the rest of it wouldn’t be conspicuous to drivers. I’m not sure what you’re trying to propose?
I’m going to throw one thing about junctions out there…
During an editing session with Gil (I forget which one, but I think it was an office hours specifically with him), he questioned why we had railroad junctioned to street segments at all.
We can treat it more like some do a bridge where there are junctions at either end for closure purposes (and elevation for some).
Outside of helping with closures and TE…we found that adding junction nodes for draw bridges helped improve routing significantly. Most are on a cycle, like trains, and waze figures this out with the timing on each segment. I would assume the same can be applied to RR crossings and timing and that is the main reason I always knew about why we junctioned them. The algorithm will start to learn typical slow downs, etc if you have them with a junction. If it impacts traffic in some way, it needs to have a junction there (not talking about the super complex ones with multiple tracks all together).
Just to be clear, I was referring to the practice of having the railroad segment(s) connected to the drivable segments. Having a junction node for closures and timing data is different.
My understanding is that segment data track total average through delay as a function of time-of-day and day-of-week. If so, then a single junction node – or no junction node at all, if there are already other junction nodes quite close – will average together all driver-relevant timing data whether there is just one train or multiple asynchronous trains.
Maybe I’m missing something? But from a purely timing perspective, I don’t see value in having more than one junction node at a grade crossing. All the driver cares about is the average delay though the segment. Even if we enable Waze to measure different portions of the delay with increased granularity, the router will just average the delays together anyway.
From a NON-timing perspective, on the other hand, it’s an excellent point that sometimes one wants to be able to close a portion of a segment, like with bridges etc. That’s a good reason for multiple junction nodes at perhaps some grade crossings. But aren’t those cases limited? Isn’t it the exception rather than the rule? Maybe depends on what part of the country?
And yes, as turbomkt points out, all of this refers to junction nodes on the drivable segment. I can’t think of any functional reason to break the railroad segment and junction the drivable and railroad segments together. From a community standpoint, however, doing may be more intuitive and approachable for junior editors?
Ultimately, my primary concern is that our guidance does not come across as requiring editors to add junction nodes in situations where we know they won’t do any good. It would just be busywork, and ideally we want to encourage editors to focus their time on more beneficial edits. We certainly don’t want to light off an editing campaign to junction railroads everywhere and always, even by accident
After stewing on it, I’m inclined to agree with a single junction node per crossing. Summarizing, it can be beneficial for regular delays at crossings (regularly scheduled trains, crossings that are regularly, temporarily blocked by a train while stopped at a station, etc.), as well as creating a break where a closure can be added. I was under the same impression as driving79 as the reason we were junctioning in the first place.
For closures, it’s not uncommon to have a derailment, train-vehicle collision, vehicle stuck on tracks, track work/crossing upgrades, etc. where a closure is needed (there are 6 train-vehicle collisions per day on average). Though a non-junctioned drivable segment over the railroad could be closed, I have had situations where it was beneficial to close one side of a crossing or only enter node closures to maintain access to/from homes and businesses on either side (especially for multi-day crossing work or long lengths of segments on either side). Even where these situations are uncommon, it’s great to have them ready to go in the cases you do need them.
Building on the junctioning of roads and rails, I agree it would be more intuitive to have the nodes connect all of the segments, but if Gil was surprised, maybe it’s something we don’t need to do and it leads to cleaner guidance (no need to specify which track to attach it to). As a pro for connecting everything, in more rural areas, this may help prevent those >10km segments we try to avoid (though is that still a thing?). Some scripts junior editors use that may highlight a node overlapping or close node over an unbroken RR segment as a potential error (though scripts could always be updated)
I just also want to address your last part - One editor’s busywork is another editor’s favorite type of edit. It’s not welcoming or encouraging to junior editors to classify what they may enjoy doing as “busywork” if it’s an activity that keeps them engaged in editing and the Waze community. While we don’t want to start a campaign of overhauling every railroad, we also shouldn’t be shoving folks to “beneficial” edits if it’s going to disengage them. Let folks work on what they’d like to as long as it’s within the guidance - we need to shift away from that mindset that has caused previous editors to leave the community.
There’s not going to have a good way to be defined as a standard, as zoom levels and extent are going to change with speed, screen size, and screen orientation. We map out the boundaries of large state/national parks, military installations, etc. even if portions of said polygon would never be on screen while in a vehicle - having a rail line continuous isn’t going to add additional clutter or distract from the app’s main navigation goals and appearance.
This is probably a rare situation anyway, as most interstates were laid out generally following the railroads and easier lay of the land. And it may be moot as it is - based on what I’m seeing panning around Live Map, pretty much everything railroad has been mapped continuously. I followed several routes across the country from Maine to LA and Seattle to Miami and there were no breaks in mapping of any of the rail lines.
