Author Topic: Railways: Draft Manual  (Read 13491 times)

0 Members and 3 Guests are viewing this topic.

Offline Duke87

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1018
  • Last Login:Yesterday at 08:57:54 pm
Railways: Draft Manual
« on: July 21, 2023, 08:56:29 pm »
Note: this post contains the current active draft of the railway manual. If you would like to propose and changes, additions, or deletions, please post in the thread to do so. This post should be edited only when consensus in favor of a specific change has emerged.

Scope
- the purpose of this project is to map current regularly scheduled passenger rail services. Tracks which are not currently used by passenger trains in regularly scheduled revenue service should not be mapped, unless service is only temporarily suspended short-term. To qualify as "regularly scheduled service", service must operate at least once a week for at least three months of the year.
- Bus routes, including "trackless trolleys" and bus rapid transit routes, are out of the project scope even in cases where they are shown on the same official maps as rail services (e.g. we are not mapping the MBTA silver line).
- trains which run on rubber tires are allowed to be mapped so long as they follow a fixed guideway (e.g. Montreal Metro)
- in places where railcars are loaded onto ferries with passengers on board, the ferry routing should not be mapped and the ferry terminals should be considered terminals of the rail service
- Amusement park rides should not be mapped unless they provide a substantial transportation function (e.g. the Disney World monorails are okay)

System Tiers
Tier 1: intercity rail systems (e.g. Amtrak, Shinkansen)
Tier 2: commuter rail systems and tourist/heritage railroads
Tier 3: heavy rail rapid transit systems
Tier 4: light rail systems
Tier 5: streetcars and people movers
Monorails may fit in either tier 3 or tier 5 depending on function

Naming guidelines
- Each line should have a display name that is the name of the system plus what the agency operating the service refers to it as, e.g. "NYC Subway 6 Train", "London Underground Circle Line", "Amtrak Empire Builder"
- the list file name should be the region name the same as from Highway mapping plus the name of the service abbreviated per the same procedures that are used to abbreviate labels for highways, except that "Line" should be abbreviated "Ln" and the word "Train" or its equivalent in other languages can be omitted so long as no ambiguity results. e.g. NY 6, ENG CirLn, MT EmpBui
- waypoint labels should be the name of the station as it appears on official signs/maps, abbreviated per the same procedures that are used to abbreviate labels for highways with the exception that there is not a need to limit to truncate further than to three letters per word if there are more than two words other than a street name generic. e.g. "Atlantic Avenue - Barclays Center" -> AtlAveBarCen, "Termini" -> Ter, "Mornington Crescent" -> MorCres

Points to include
- former stations should be included if they were closed in relatively recent history, with their point labels preceded by * to indicate their closure. Use discretion, it is not necessary to include temporary stations or stations that last had a train stop at them in 1927.
- employee-only stations should not be included unless they were formerly open for public use
- shaping points may be added to improve route traces if the path of the tracks deviates substantially from a straight line between consecutive stations. Use discretion.
- only the current routing of a service should be mapped. If the service formerly took a different route and the point where the old route deviates from the new is not in proximity to a station, a point for the divergence point may be added following the same labeling guidelines as for rerouted roads.
- If a divergence point between two concurrent services is not in proximity to an a station, a point should be placed at the location of the divergence for the purpose of concurrency detection. This point should be labeled per the same principles as the endpoints of concurrencies for roads.
- the same "one point per interchange" rule used for roads applies with rails. e.g., wye junctions should be mapped as single points. As with roads, however, it is not necessary to have a graph connection at transfer points between two lines that have significant offset between where their platforms are.

Handling Branches
- If a service has multiple branches they should be differentiated per the same procedures used to differentiate road routes with the same designation, e.g. "NYC Subway A Train (Ozone Park)" NY AOzo vs. "NYC Subway A Train (Far Rockaway)" NY A.
- The word "branch" or its equivalent in other languages should not be used in differentiating names unless it appears in the official public name of the service, e.g. "Metro-North New Haven Line (New Canaan Branch).
- If a service runs exclusively in a closed loop, the whole loop should be mapped with two endpoints of the line having the same coordinates. The endpoint should be whatever is deemed the most prominent station in the loop.
- If a service runs in a loop at one end and hits multiple stations along the way, the entire loop should be mapped and the endpoint of the line should be the point where the loop closes and two-way service resumes.
- If a service takes a slightly different route in different directions at some point in the middle (e.g. light rail/streetcar runs one-way down adjacent streets) the mapped path should split the difference between the physical paths the two directions follow, same as with road routes following one-way pairs. All stations along the one-way pair should be included as distinct points even if they are only served in one direction. Stations with different names in each direction that serve the same cross street may be combined into a single waypoint with a slash separating their names in the waypoint label.
- If a service takes a substantially different route in different directions at some point in the middle (e.g. runs around different sides of a downtown loop depending on direction), the different directions of the service must be mapped separately and should have their names distinguished by the terminal station in each direction

Other Drafting guidelines
- Lines should be cut into different routes at each crossing of a region boundary, with points labeled as the names of the two bordering regions separated by a slash, e.g. ENG/FRA
- Where service patterns differ by time of day and/or day of week, mapping should follow weekday midday service, with the exception that tracks which only see service part time should be mapped regardless of when their part time service is
- It is not necessary to distinctly map express services separately from local services, skip-stop services distinct from each other, etc. if the different services run entirely along the same route and never diverge (e.g. local and express service on the SEPTA Broad Street line should not be mapped separately since they both run exclusively down Broad Street), however this may be done with discretion in cases where the local and express services do not have a single common name (e.g. it is okay to distinctly map the NYC subway A and C trains), and it must be done if the local and express services diverge (e.g. the CTA red and brown lines must be mapped separately)
- Where mapped, express services should not have visible waypoints for stations they skip. However, it will be necessary to include all local stations as hidden shaping points for the purpose of concurrency detection with the local service, unless express and local trains follow physically different routes (e.g. the NYC Subway M and R local trains following Steinway St and Broadway where the E and F express trains take a shortcut and follow Northern Blvd)

Misc
- The Wikipedia Policy of "ignore all rules" applies: if in a specific instance it makes more sense to do something other than what the rules stipulate, go ahead and do what makes sense and explain your rationale
- Where possible, local convention should be followed in sorting out any ambiguities.
« Last Edit: July 24, 2023, 04:58:24 pm by Duke87 »

Offline si404

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2067
  • Last Login:Today at 12:54:41 am
Railways: Draft Manual
« Reply #1 on: July 22, 2023, 04:21:04 am »
Quote
- If a divergence point between two concurrent services is not in proximity to an a station, a point should be placed at the location of the divergence for the purpose of concurrency detection. This point should be labeled per the same principles as the endpoints of concurrencies for roads.
That is going to be extremely messy. I've used hidden points because
1) you can't interchange between routes there - it's not a point people need visible (it's services we're mapping, not infrastructure)
2) there's so many of them and it would clutter stuff.

The more user-friendly solution would be to sort out dealing with travels that end at hidden points*. Something we want with roads for the 6-lane project anyway.

*Not that you would normally put these in your list (rare cases like diversions via curves rarely used by passenger rail) but the concurrency ending at a hidden point makes a mess on mapview.

Offline Jim

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2856
  • Last Login:Yesterday at 09:42:37 pm
Re: Re: Railways: thinking things through thread
« Reply #2 on: July 22, 2023, 11:29:30 am »
That is going to be extremely messy. I've used hidden points because
1) you can't interchange between routes there - it's not a point people need visible (it's services we're mapping, not infrastructure)
2) there's so many of them and it would clutter stuff.

The more user-friendly solution would be to sort out dealing with travels that end at hidden points*. Something we want with roads for the 6-lane project anyway.

*Not that you would normally put these in your list (rare cases like diversions via curves rarely used by passenger rail) but the concurrency ending at a hidden point makes a mess on mapview.

I think our most manageable solution here will be to put in visible points at the non-station points where tracks diverge/join but with the intent to support concurrencies ending at hidden points properly in the future so they could be converted to hidden.

Offline neroute2

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1142
  • Last Login:Today at 01:46:39 am
Re: Re: Railways: thinking things through thread
« Reply #3 on: July 22, 2023, 03:42:08 pm »
May I suggest using a junction name if there is one? Something like SilStar_S is probably less intuitive than DurJct (not a real name).

Offline Duke87

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1018
  • Last Login:Yesterday at 08:57:54 pm
Re: Re: Railways: thinking things through thread
« Reply #4 on: July 22, 2023, 04:21:39 pm »
May I suggest using a junction name if there is one? Something like SilStar_S is probably less intuitive than DurJct (not a real name).

The thought occurred to me. These junction names are not necessarily known to the common traveler but then they might be more likely known to someone interested in tracking what trains they've clinched. Overall I'm indifferent.
« Last Edit: July 24, 2023, 05:01:16 pm by Duke87 »

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4849
  • Last Login:November 20, 2024, 11:21:09 am
Re: Re: Railways: thinking things through thread
« Reply #5 on: July 23, 2023, 02:01:38 am »
Quote
- If a divergence point between two concurrent services is not in proximity to an a station, a point should be placed at the location of the divergence for the purpose of concurrency detection. This point should be labeled per the same principles as the endpoints of concurrencies for roads.
That is going to be extremely messy. I've used hidden points because
1) you can't interchange between routes there - it's not a point people need visible (it's services we're mapping, not infrastructure)
2) there's so many of them and it would clutter stuff.

The more user-friendly solution would be to sort out dealing with travels that end at hidden points*. Something we want with roads for the 6-lane project anyway.

*Not that you would normally put these in your list (rare cases like diversions via curves rarely used by passenger rail) but the concurrency ending at a hidden point makes a mess on mapview.

That's very important for me as already mentioned in the 6+ lane freeway discussion:

I don't like the approach since it is quite inaccurate as long as we cannot map segments between shaping points.

I have created a small, tempoary list file called 6lanetest.list, and populated it with a few segments of I-90 in Massachusetts that use shaping points in various ways to try to claim travels.  You can see that, for example, a portion of the segment between exits 10 and 41 that is claimed by two of the shaping points in between does not show up on mapview or showroute views.

Anyone interested in welcome to experiment with additional entries in 6lanetest.list if you'd like to see how things are handled by our current infrastructure when shaping points are used as segment endpoints.  I would, however, like to remove the extraneous list file when experiments are complete.

https://github.com/TravelMapping/UserData/blob/master/list_files/6lanetest.list
Code: [Select]
MA I-90 NY/MA +X4
MA I-90 +X19 +X25
MA I-90 +X60 +X66
MA I-90 +X132 +X136
https://travelmapping.net/hb/showroute.php?u=6lanetest&r=ma.i090
https://travelmapping.net/user/mapview.php?u=6lanetest&rg=ma

yep, it doesn't work with our current infrastructure.
However, it is interesting that showroute and mapview deal with it differently!

As long as we don't have a solution in the code, any workaround should be easy to spot, i.e. not using shaping point but using any other key word in the label name, e.g. DIV prefix in capital letters like DIVxyz, DIV_N, DIV_A etc.

I still wonder why showroute and mapview deal differently.

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4849
  • Last Login:November 20, 2024, 11:21:09 am
Re: Re: Railways: thinking things through thread
« Reply #6 on: July 23, 2023, 03:58:28 pm »
- the same "one point per interchange" rule used for roads applies with rails. e.g., wye junctions should be mapped as single points

On first thought, I had fully agreed. However, I don't think that merging a tramway station with a regional train station makes sense, see Cottbus main station:
https://tmrail.teresco.org/user/mapview.php?u=si404&sys=deuctt
https://tmrail.teresco.org/hb/showroute.php?u=si404&r=deubb.04cot&lat=51.749302&lon=14.326692&zoom=17

Offline Bickendan

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 553
  • Last Login:Yesterday at 09:47:18 pm
Re: Re: Railways: thinking things through thread
« Reply #7 on: July 23, 2023, 04:12:28 pm »
I drafted out Oregon's Amtrak, TriMet's MAX, WES, Portland Streetcar, the OHSU Aerial Tram, and the Willamette Shore a long time ago.
Outside of .wpt naming and .csv compilation convention, MAX and streetcar pose a situation that should be addressed: They operate down one-way couplets through downtown Portland, with stations off set with each other and with different names. (Also, likely that the station waypoints in the .wpts would need to be streamlined. TriMet's station ID numbers could be used, but I think that's likely an unintuitive approach for mappers).

Offline cl94

  • TM Collaborator
  • Sr. Member
  • *****
  • Posts: 264
  • Gender: Male
  • Last Login:Yesterday at 09:38:08 pm
Re: Re: Railways: thinking things through thread
« Reply #8 on: July 23, 2023, 11:12:41 pm »
I drafted out Oregon's Amtrak, TriMet's MAX, WES, Portland Streetcar, the OHSU Aerial Tram, and the Willamette Shore a long time ago.
Outside of .wpt naming and .csv compilation convention, MAX and streetcar pose a situation that should be addressed: They operate down one-way couplets through downtown Portland, with stations off set with each other and with different names. (Also, likely that the station waypoints in the .wpts would need to be streamlined. TriMet's station ID numbers could be used, but I think that's likely an unintuitive approach for mappers).

This is not a unique situation, and as such, it definitely needs to be addressed. Newark Light Rail addresses this to some degree by pairing stations and allowing one direction to not have a pair with the other, but I don't necessarily want to make this universal because there are cases where pairs aren't clear. I'm also open to changing a few rules for the purposes of rail, as mentioned previously, because rails are not the same as roads and it makes the most sense to make decisions about this while still in preview.

Two solutions I see here that would have more universal applicability:
  • Map each direction independently in these areas. This differs from how we handle stuff on the road side, but rails aren't directly comparable and, if you're trying to count stations or segments of line (as many railfans do), clinching one direction doesn't necessarily count as clinching the other if the stations are completely separate
  • Map both directions together with a point for each station. This adds more points, but no need to try and make pairs or separate directions.

I'm not tied to either or any of these, but merely want to get some thoughts going.

Re: merging stations/segments of different levels/systems, I agree with some of the previous posters. For now, it is easier to combine them, but I think that there's less consensus on this in the community than there is with roads. My personal opinion, combining regional and intercity rail if they share tracks is one thing. Combining a subway line with a parallel intercity/regional line that has no direct connection is a different story. For example, I wouldn't count riding a section of the Washington Metro as riding the parallel section of MARC, because it's an entirely different system that shares nothing apart from a ROW boundary, but I understand that others feel differently and I think that we should make it possible to do both. There are different opinions on this in the rail world and I totally respect/understand that, but the "most inclusive" thing would probably be to default to "no concurrency" and make it so people can easily add those lines to the code if desired. Which yes, may mean including junction points on the list. Conversely, when it comes to roads, there's usually less ambiguity here. The only particularly questionable road cases that come to mind are the Dulles Access Road in Virginia and Beltway 8 in Houston.

IMO, this is different from excluding unsigned routes from TM, which is cleaner and easier to account for if you want to track unsigned stuff separately. Unsigned routes often aren't concurrent with other routes to the same degree. Like, not having NV 705 on TM doesn't mess with stats for the state if you want to drive unsigned routes, because unsigned routes are an addendum to what's on TM and I can easily track those separately for every state I visit. Including concurrencies between different rail systems will mess with stats by putting someone on a system they may not want to count and mess with using TM to count systems for those people.

Offline Duke87

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1018
  • Last Login:Yesterday at 08:57:54 pm
Re: Re: Railways: thinking things through thread
« Reply #9 on: July 23, 2023, 11:15:34 pm »
- the same "one point per interchange" rule used for roads applies with rails. e.g., wye junctions should be mapped as single points

On first thought, I had fully agreed. However, I don't think that merging a tramway station with a regional train station makes sense, see Cottbus main station

I was thinking primarily of wye junctions when I said this. When you have a transfer point between two lines that do not cross... well, that becomes a bit like trumpet interchanges exiting toll roads. We don't have graph connections there. I'd say the same principle should be applied here and yeah the graph connection should break.


Outside of .wpt naming and .csv compilation convention, MAX and streetcar pose a situation that should be addressed: They operate down one-way couplets through downtown Portland, with stations off set with each other and with different names. (Also, likely that the station waypoints in the .wpts would need to be streamlined. TriMet's station ID numbers could be used, but I think that's likely an unintuitive approach for mappers).

As proposed:

- If a service runs in a loop at one end and hits multiple stations along the way, the entire loop should be mapped and the endpoint of the line should be the point where the loop closes and two-way service resumes.
- If a service takes a slightly different route in different directions at some point in the middle (e.g. light rail/streetcar runs one-way down adjacent streets) the mapped path should split the difference between the physical paths the two directions follow, same as with road routes following one-way pairs. All stations along the one-way pair should be included as distinct points even if they are only served in one direction. Stations with different names in each direction that serve the same cross street may be combined into a single waypoint with a slash separating their names in the waypoint label.

Offline Duke87

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1018
  • Last Login:Yesterday at 08:57:54 pm
Re: Railways: Draft Manual
« Reply #10 on: July 24, 2023, 05:02:05 pm »
Partial post move from other thread:

I think a fundamental issue here is that just like with highways, we specify the data and our travels by route, which in this case would be a railway line and the start and end stations.  And just like with highways, where when multiple routes share pavement, specifying travels on any one over a segment gives you credit for all of the routes that travel that segment, if you travel any railway line that uses a particular segment of track (or set of parallel tracks), you get credit for all railway lines that use that segment of track.  With highways this has bothered some people, but it makes sense.  With railways, this might bother people more.  For example, I've never been on a Gatwick Express train to Brighton, but since I took a ThamesLink there, I have travels showing that I've been on Gatwick Express there as well.  Personally, I think it still makes sense, but are people more likely to care which railway lines they've traveled more than which segments some train with them on board has covered?

The robust solution to this problem in the long term would be to have autodetection of concurrencies be a user-togglable option for both roads and rails.

In the meantime I'd favor proceeding with autodetection as-is both since it's simpler on account of being incumbent and since that's how I'd rather map my travels anyway (clinching the tracks regardless of on what train).

That is going to be extremely messy. I've used hidden points because
1) you can't interchange between routes there - it's not a point people need visible (it's services we're mapping, not infrastructure)
2) there's so many of them and it would clutter stuff.

The more user-friendly solution would be to sort out dealing with travels that end at hidden points*. Something we want with roads for the 6-lane project anyway.

Yeah, the primary reason I said visible points is because people's travels on a given line will in some cases end there and at this time travels ending at hidden points only sort of works. If we can make it fully work I am fine with leaving the junction points hidden. 
« Last Edit: July 24, 2023, 05:04:19 pm by Duke87 »

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4849
  • Last Login:November 20, 2024, 11:21:09 am
Re: Railways: Draft Manual
« Reply #11 on: July 27, 2023, 01:29:47 pm »
- the same "one point per interchange" rule used for roads applies with rails. e.g., wye junctions should be mapped as single points

On first thought, I had fully agreed. However, I don't think that merging a tramway station with a regional train station makes sense, see Cottbus main station:
https://tmrail.teresco.org/user/mapview.php?u=si404&sys=deuctt
https://tmrail.teresco.org/hb/showroute.php?u=si404&r=deubb.04cot&lat=51.749302&lon=14.326692&zoom=17

I think that the point in blue should be moved to the actual tram / streetcar station bordered in green. Anyone?


I found two extreme to the other way in Stuttgart where "ramps" are drafted separately. I'd merge both into each one point. Anyone?

https://tmrail.teresco.org/user/mapview.php?u=si404&sys=deusu

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4849
  • Last Login:November 20, 2024, 11:21:09 am
Re: Re: Railways: thinking things through thread
« Reply #12 on: July 27, 2023, 01:47:44 pm »
Quote
- If a divergence point between two concurrent services is not in proximity to an a station, a point should be placed at the location of the divergence for the purpose of concurrency detection. This point should be labeled per the same principles as the endpoints of concurrencies for roads.
That is going to be extremely messy. I've used hidden points because
1) you can't interchange between routes there - it's not a point people need visible (it's services we're mapping, not infrastructure)
2) there's so many of them and it would clutter stuff.

The more user-friendly solution would be to sort out dealing with travels that end at hidden points*. Something we want with roads for the 6-lane project anyway.

*Not that you would normally put these in your list (rare cases like diversions via curves rarely used by passenger rail) but the concurrency ending at a hidden point makes a mess on mapview.

As long as we don't have a solution in the code, any workaround should be easy to spot, i.e. not using shaping point but using any other key word in the label name, e.g. DIV prefix in capital letters like DIVxyz, DIV_N, DIV_A etc.

Is there consent on this?

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4849
  • Last Login:November 20, 2024, 11:21:09 am
Re: Railways: Draft Manual
« Reply #13 on: July 27, 2023, 01:57:51 pm »
Naming guidelines- waypoint labels should be the name of the station as it appears on official signs/maps, abbreviated per the same procedures that are used to abbreviate labels for highways with the exception that there is not a need to limit to truncate further than to three letters per word if there are more than two words other than a street name generic. e.g. "Atlantic Avenue - Barclays Center" -> AtlAveBarCen, "Termini" -> Ter, "Mornington Crescent" -> MorCres

Si tested different concepts:
Truncating to one character: ENG BakLn
Full name: ENG SATTS or AUS-SA BelLn

I'd prefer Duke87's proposal though. Or fully stick with the hwy data truncation rule.

Anyone?


Other Drafting guidelines
- Where mapped, express services should not have visible waypoints for stations they skip. However, it will be necessary to include all local stations as hidden shaping points for the purpose of concurrency detection with the local service, unless express and local trains follow physically different routes (e.g. the NYC Subway M and R local trains following Steinway St and Broadway where the E and F express trains take a shortcut and follow Northern Blvd)

I think that the rule belong to "Points to include", shouldn't it?
I fully agree that the points must be added for concurrency detection. However, if they are hidden, we are struggeling with mapview and showroute. I'd like to apply my approach for divergence points:
As long as we don't have a solution in the code, any workaround should be easy to spot, i.e. not using shaping point but using any other key word in the label name, e.g. SKIP or LOCAL prefix in capital letters like LOCALxyz, LOCAL_N, LOCAL_A etc.

Anyone?

Offline si404

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2067
  • Last Login:Today at 12:54:41 am
Re: Railways: Draft Manual
« Reply #14 on: July 27, 2023, 02:55:04 pm »
Truncating to one character: ENG BakLn
Any ABC-style three letter code is either the Network Rail 3lc or the TfL 3lc. It's not a straight truncation of station names. I'll probably get rid as they are a bit niche (though the NR ones are on every wikipedia article, appear on www.nationalrail.com and are used on www.realtimetrains.co.uk - but at the same time, various hobbyist discussions absolutely hate them being used instead of names as they are jargon that's regularly used by posters that needs decoding)

Full name I did mostly because it didn't want to make a decision (though label-too-long errors don't appear at all). I did not see it as an endstate.

I found two extreme to the other way in Stuttgart where "ramps" are drafted separately. I'd merge both into each one point. Anyone?

https://tmrail.teresco.org/user/mapview.php?u=si404&sys=deusu
I'd argue that the big wye is perhaps on the edge of splitting. I'd probably merge it if drafting the system now. The little one certainly would be merged.

Cottbus, perhaps. There's better examples where I've merged train/tram stations that I was uncertain about merging. Here I didn't doubt. But I can see the point of view of treating that as two separate stations.

Looking at the Bakerloo Line (simply as it's open due to you linking it), I split Charing Cross into three stations (Bakerloo, NR, Northern), as they were until the now-closed Jubilee line platforms were built uniting the tube station. Marylebone and Waterloo I've merged two stations - but there's direct entrances into the tube from the NR concourse (and platforms in the case of Waterloo). Elephant is either 2 or 3 (with two linked by an in-fare passageway), but I've collapsed it into one. Paddington I've merged 4 stations. The one I doubt is Charing Cross. I don't doubt the others.