Travel Mapping
Railway Data Discussion => In-progress Railway Systems & Work => Topic started by: Duke87 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.
-
- 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 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.
-
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).
-
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.
-
- 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
MA I-90 NY/MA +X4
MA I-90 +X19 +X25
MA I-90 +X60 +X66
MA I-90 +X132 +X136https://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.
-
- 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 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).
-
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.
-
- 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.
-
Partial post move from other thread (https://forum.travelmapping.net/index.php?topic=444):
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.
-
- 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?
(https://forum.travelmapping.net/index.php?action=dlattach;topic=5635.0;attach=669)
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://forum.travelmapping.net/index.php?action=dlattach;topic=5635.0;attach=671)
https://tmrail.teresco.org/user/mapview.php?u=si404&sys=deusu
-
- 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?
-
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 (https://tmrail.teresco.org/hb/showroute.php?u=si404&r=eng.bakln)
Full name: ENG SATTS (https://tmrail.teresco.org/hb/showroute.php?u=si404&r=eng.satts) or AUS-SA BelLn (https://tmrail.teresco.org/hb/showroute.php?u=michih&r=aussa.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?
-
Truncating to one character: ENG BakLn (https://tmrail.teresco.org/hb/showroute.php?u=si404&r=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://forum.travelmapping.net/index.php?action=dlattach;topic=5635.0;attach=671)
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.
-
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?
I do see the benefit of the label including an easily queryable string, which this does and what I wrote doesn't.
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?
Too kludgy for my blood personally. Would rather just make getting mapview updated to render this properly a prerequisite for bringing TMrail out of "beta".
-
As much as I would like to spend some time to get the mapview/showroute rendering issues resolved to help both the 6lane.list side project and getting rail going, it's not realistically going to happen any time soon unless someone else is willing to dive into the code. It's probably best to use temporarily visible points to get the rail side of the project moving forward.
-
- 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
I fully agree. I will change this if there is consent: https://tmrail.teresco.org/hb/showroute.php?u=michih&r=deumv.02sch&lat=53.631149&lon=11.406861&zoom=17 @si404, fine for you?
-
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.
Here we have branch with station. The station marked in green is only served by line 4. The station in blue is served by line 1, 2 and 3. I tend to keep it as-is.
https://tmrail.teresco.org/hb/showroute.php?units=miles&u=michih&r=deumv.04sch&lat=53.603170&lon=11.429611&zoom=17
https://tmrail.teresco.org/user/mapview.php?u=michih&sys=deusnt
-
Here we have branch with station. The station marked in green is only served by line 4. The station in blue is served by line 1, 2 and 3. I tend to keep it as-is.
https://tmrail.teresco.org/hb/showroute.php?units=miles&u=michih&r=deumv.04sch&lat=53.603170&lon=11.429611&zoom=17
https://tmrail.teresco.org/user/mapview.php?u=michih&sys=deusnt
Personally I would still 1PPI this, having a point for all four lines in the green circle and a point for lines 1, 2, and 3 in the blue circle. Yes, lines 1/2/3 don't stop at the station in the green circle - that's fine, no different than an express service skipping a station.
Fundamentally I just think it's silly to have an implied expectation that all three legs of the wye must be ridden distinctly for a full clinch. We don't do this for roads, we shouldn't do it for rails.
Indeed, if this were a Y-interchange between two highways and highway 4 had an exit in the middle not accessible from highway 1/2/3... yep, we'd still have everything meet at one point there.
-
Yep, both wps for line 1,2,3 but skipping the „Green“ wp would make the trick. Like it. other opinions?
BTW, I travelled all legs albeit I lost a lot of Time waiting :D
-
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
Should metros be tier 3 or tier 4? I'm not an expert for railways. Thus, I don't get what's the different for your tier 3/4 suggestions.
I think that I miss a category between tier 1 and tier 2 for non-high-speed and non-urban regional railway systems.
Edit: Found this:
Tiers were as follows:
1 (not used) for dedicated HSR operators,
2 for continental systems (like Amtrak),
3 for Commuter/Regional Rail,
4 for Subway/Metro,
5 for Light Rail (everything from basically-metro to piddly little street-cars).
I'd fully agree!
-
I reworked (https://github.com/TravelMapping/RailwayData/pull/2) the Schwerin system (https://tmrail.teresco.org/hb/index.php?sys=deusnt) according to how I got the manual proposal:
I truncated all wp labels.
I moved the main station wp from the regional station location to the actual stop of the tram.
I merged the above mentioned wp to a 1PPI by using "+SKIP_" label prefixes as suggested by Duke87.
I split line 2 into two routes since there are two one-way branches with stops at the branches.
I used the "+DIV_" label prefix where line 2 branches off line 1/4 routes. They are actually called +DIV_T2_W (line 1) or +DIV_T2_N (line 4). T = tram.
I used "(Main)" and "Stadthaus" as "abbrev" to distinguish the routes.
However, I struggle naming the branch wps though:
- The western divergence point at the stop is a no-brainer. I simply used the stop name.
- The eastern divergence point is between stops. I'm gone with T1/T4 now. Thoughts?
-
Tiers in this version at the moment:
(1) Intercity (I'd suggest limiting this to high speed operators would be too narrow)
(2) Regional
(3) Metro
(4) Tram
(5) PeopleMover
One issue I found is that nothing fits neatly into boxes. Even in Germany, which loves to categorise trains into various different boxes, its all a bit nebulous and ill-defined.
Another issue is that systems might cross several tiers: Southeastern . And even routes - eg The S1 in Karlsruhe (https://tmrail.teresco.org/hb/showroute.php?r=deubw.s01kar) - running as on-street tram, semi-segregated light rail, underground metro, and regional rail at various points along the route!
-
I'll have to email this one in, but once I do, would one of you be willing to take the Oregon rail data I compiled back in 2016 and look over what might need to be changed (ie, splitting the Streetcar Loop line into two, one for each direction), file name corrections, etc etc?
-
I reworked (https://github.com/TravelMapping/RailwayData/pull/2) the Schwerin system (https://tmrail.teresco.org/hb/index.php?sys=deusnt) according to how I got the manual proposal:
I truncated all wp labels.
I moved the main station wp from the regional station location to the actual stop of the tram.
I merged the above mentioned wp to a 1PPI by using "+SKIP_" label prefixes as suggested by Duke87.
I split line 2 into two routes since there are two one-way branches with stops at the branches.
I used the "+DIV_" label prefix where line 2 branches off line 1/4 routes. They are actually called +DIV_T2_W (line 1) or +DIV_T2_N (line 4). T = tram.
I used "(Main)" and "Stadthaus" as "abbrev" to distinguish the routes.
However, I struggle naming the branch wps though:
- The western divergence point at the stop is a no-brainer. I simply used the stop name.
- The eastern divergence point is between stops. I'm gone with T1/T4 now. Thoughts?
It's live now: https://tmrail.teresco.org/user/mapview.php?u=michih&sys=deusnt
-
Another issue is that systems might cross several tiers: Southeastern
I like the solution that was implemented for Boston where the Green Line light rail and Mattapan trolley are broken into a separate system from the heavy rail subway lines
And even routes - eg The S1 in Karlsruhe (https://tmrail.teresco.org/hb/showroute.php?r=deubw.s01kar) - running as on-street tram, semi-segregated light rail, underground metro, and regional rail at various points along the route!
That's a light rail (tram) line, based on photos of it. Belongs in tier 4.
I'm not an expert for railways. Thus, I don't get what's the different for your tier 3/4 suggestions.
There are multiple distinguishing features, but heavy rail rapid transit systems:
- always run on their own ROW, not in streets
- have high level floors and are typically boarded from high level platforms
- typically involve longer, higher capacity trains
Light rail systems meanwhile:
- run in a mix of their own ROW and in streets
- typically have lower floors and lower platforms
- typically involve shorter, lower capacity trains
These distinctions also have some functional implications because light rail trains can generally handle steeper hills and navigate tighter curves than their heavy rail counterparts, and also have shorter stopping distances (they have to, to safely run in streets).
"Light rail" is also admittedly an American term, but British English "tram" is used similarly.
Good rule of thumb is if it looks more like this (https://en.wikipedia.org/wiki/Light_rail#/media/File:Green_line_Trax_at_Gallivan_Plaza.jpg)it's light rail, but if it looks more like this (https://en.wikipedia.org/wiki/7_(New_York_City_Subway_service)#/media/File:R188_7_train.jpg) it's heavy rail.
-
Thanks!
Good rule of thumb is if it looks more like this (https://en.wikipedia.org/wiki/Light_rail#/media/File:Green_line_Trax_at_Gallivan_Plaza.jpg)it's light rail, but if it looks more like this (https://en.wikipedia.org/wiki/7_(New_York_City_Subway_service)#/media/File:R188_7_train.jpg) it's heavy rail.
That's tier 4 vs. tier 5. I asked for tier 3 vs. tier 4.
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
-
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.
I'm gone with +DIV but it's really a pain for maintenance. I was shocked what I messed up here when selecting "color by concurrencies": https://tmrail.teresco.org/user/mapview.php?u=michih&sys=deuulrs
It took time to realized that the yellow mistake is not my bad. Bordered in red. RS7 and RS71 run from center to SE, not from center to SW as it looks like. Users will face the same issues when marveling their travels on mapview.
Edit: Darn! +DIV is a hidden wp. I should replace it by plain DIV :pan: :pan: :pan: :pan: :pan: :pan: :pan:
-
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
I had fully agreed but then I redrafted deuulrs (https://tmrail.teresco.org/hb/?u=michih&sys=deuulrs). Let's have a look into - a very short since still regional route only - RS5 (https://tmrail.teresco.org/hb/showroute.php?u=michih&r=deubw.rs05). The route only has 17 stations but there are Herbrechtingen and Hermaringen. Both are one word. More than one syllable but only one word. "Her" is not a word for its own. Calling both Her is not possible. I'm gone with Heb and Her but could also call them Heb and Hem. Sure.
However, while road wps are mainly labeled according to road numbers, there are no exit nor rail track numbers for rails. That means, almost all wps will have truncated names. And yes, I want to truncate them because Herbrechtingen, BofingenOstpreussenweg or MunchenHauptbahnhof are way too long.
Is there any technical reason why we should truncate to three characters? Why not four or five? I think that the road limit is due to performance reasons. It is also dated back when users had to type the wps into their list file. I guess we wanted to reduce the risk of typos.
I think that the performance issues are gone now - for update process and on the production server. No one really needs to type anything into their list file but can use the .list Tool editor. Maybe we should promote the latter more prominentely to convince users to use it.
So, again, why not truncating wp labels to four or five characters to help maintainers and users to read the wpt files and list files?
-
Is there any technical reason why we should truncate to three characters? Why not four or five? I think that the road limit is due to performance reasons. It is also dated back when users had to type the wps into their list file. I guess we wanted to reduce the risk of typos.
I think that the performance issues are gone now - for update process and on the production server. No one really needs to type anything into their list file but can use the .list Tool editor. Maybe we should promote the latter more prominentely to convince users to use it.
So, again, why not truncating wp labels to four or five characters to help maintainers and users to read the wpt files and list files?
I agree there is no longer a reason to abbreviate/truncate names like was done in the CHM days for various reasons and which TM adopted.
In the DB, the current waypoint label length limit is 26. That can easily be changed if necessary, but I expect we can stay within that limit pretty easily.
-
I'm gone with visible DIV_ and SKIP_ prefixes now. SKIP_ must only be visible if routes are diverting there but I think it's better to have all visible to avoid confusion. And to ease replacement once the workaround will be superfluous.
Any comment to deusnt?
I reworked (https://github.com/TravelMapping/RailwayData/pull/2) the Schwerin system (https://tmrail.teresco.org/hb/index.php?sys=deusnt) according to how I got the manual proposal:
I truncated all wp labels.
I moved the main station wp from the regional station location to the actual stop of the tram.
I merged the above mentioned wp to a 1PPI by using "+SKIP_" label prefixes as suggested by Duke87.
I split line 2 into two routes since there are two one-way branches with stops at the branches.
I used the "+DIV_" label prefix where line 2 branches off line 1/4 routes. They are actually called +DIV_T2_W (line 1) or +DIV_T2_N (line 4). T = tram.
I used "(Main)" and "Stadthaus" as "abbrev" to distinguish the routes.
However, I struggle naming the branch wps though:
- The western divergence point at the stop is a no-brainer. I simply used the stop name.
- The eastern divergence point is between stops. I'm gone with T1/T4 now. Thoughts?
Is T1/T4 fine? Any other proposal?
-
Good rule of thumb is if it looks more like this (https://en.wikipedia.org/wiki/Light_rail#/media/File:Green_line_Trax_at_Gallivan_Plaza.jpg)it's light rail, but if it looks more like this (https://en.wikipedia.org/wiki/7_(New_York_City_Subway_service)#/media/File:R188_7_train.jpg) it's heavy rail.
That's tier 4 vs. tier 5. I asked for tier 3 vs. tier 4.
No that is tier 3 (heavy rail rapid transit, second link) vs. tier 4 (light rail, first link).
Tier 5 would be something like this (https://en.wikipedia.org/wiki/Morgantown_Personal_Rapid_Transit#/media/File:Morgantown_Personal_Rapid_Transit.jpg) (people mover) or this (https://en.wikipedia.org/wiki/SEPTA_Route_34#/media/File:4500_Baltimore_Avenue.jpg) (streetcar)
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
I had fully agreed but then I redrafted deuulrs (https://tmrail.teresco.org/hb/?u=michih&sys=deuulrs). Let's have a look into - a very short since still regional route only - RS5 (https://tmrail.teresco.org/hb/showroute.php?u=michih&r=deubw.rs05). The route only has 17 stations but there are Herbrechtingen and Hermaringen. Both are one word. More than one syllable but only one word. "Her" is not a word for its own. Calling both Her is not possible. I'm gone with Heb and Her but could also call them Heb and Hem. Sure.
However, while road wps are mainly labeled according to road numbers, there are no exit nor rail track numbers for rails. That means, almost all wps will have truncated names. And yes, I want to truncate them because Herbrechtingen, BofingenOstpreussenweg or MunchenHauptbahnhof are way too long.
Is there any technical reason why we should truncate to three characters? Why not four or five? I think that the road limit is due to performance reasons. It is also dated back when users had to type the wps into their list file. I guess we wanted to reduce the risk of typos.
I think that the performance issues are gone now - for update process and on the production server. No one really needs to type anything into their list file but can use the .list Tool editor. Maybe we should promote the latter more prominentely to convince users to use it.
So, again, why not truncating wp labels to four or five characters to help maintainers and users to read the wpt files and list files?
So, a couple things:
1) the existing waypoint labeling guidelines for roads allow for a fourth letter to be added if two points on the same route would abbreviate to the same three letters. These two stations could be abbreviated to Her and Herm (or Herb and Her, or even Herb and Herm) in order to disambiguate without extending the length of all other unaffected abbreviations and without changing the rules.
2) "shorten each word" was a guideline developed with the English language in mind. When dealing with aggluntative languages, some liberty is already necessary to deal with the fact that something which would be multiple words in English might be only one word. You will note for example in Iceland basically every street name is one word, with names like Njarðargata. But "gata" means "street" and is serving the function of a geneirc suffix, so the way I've handled it is to name that waypoint NjaGat.
I haven't poked around German names enough to be quite sure but it appears at a glance "ingen" might be serving a similar function here. If so, "HerIng" would also be a valid way of labeling one of those points.
Is T1/T4 fine? Any other proposal?
I think T1/T4 is the logical label there, yes.
That said, the "main" section of T2 should have "Hegelstraße bound" in the city field and the "Stadthaus" section of T2 should have "Lankow-Siedlung bound" there, with the latter extended to cover the entire route rather than showing just the split section.
My intention with the draft manual was that each direction should be mapped separately but for the whole route, and the names of the terminal station in each direction used to disambiguate. Though looking at what I wrote that perhaps wasn't clear, so what if we change:
- 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
to
- 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 (e.g. "HogExp (Hogwarts bound)" vs. "HogExp (Kings Cross bound)"). Each mapped direction should cover the entire length of the route from terminal to terminal.
That work?
-
Good rule of thumb is if it looks more like this (https://en.wikipedia.org/wiki/Light_rail#/media/File:Green_line_Trax_at_Gallivan_Plaza.jpg)it's light rail, but if it looks more like this (https://en.wikipedia.org/wiki/7_(New_York_City_Subway_service)#/media/File:R188_7_train.jpg) it's heavy rail.
That's tier 4 vs. tier 5. I asked for tier 3 vs. tier 4.
No that is tier 3 (heavy rail rapid transit, second link) vs. tier 4 (light rail, first link).
Tier 5 would be something like this (https://en.wikipedia.org/wiki/Morgantown_Personal_Rapid_Transit#/media/File:Morgantown_Personal_Rapid_Transit.jpg) (people mover) or this (https://en.wikipedia.org/wiki/SEPTA_Route_34#/media/File:4500_Baltimore_Avenue.jpg) (streetcar)
Your light rails (https://en.wikipedia.org/wiki/Light_rail#/media/File:Green_line_Trax_at_Gallivan_Plaza.jpg) and your Streetcar (https://en.wikipedia.org/wiki/SEPTA_Route_34#/media/File:4500_Baltimore_Avenue.jpg) examples are both called "Straßenbahn" in German. The term "Tram" is also quite common in German for it. However, they refer to both types. There are German systems where one line is served by "streetcars" and other lines by "light train". I've also seen both on the same line. So, it is hardimpossible to distinguish. To be honest, your streetcar example is often an old train generation while the "light trains" have just been purchased (decades) later.
Again, I'm happy with si404's approach.
We might also go differently for NA and Europe if there is a good reason to do so.
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
I had fully agreed but then I redrafted deuulrs (https://tmrail.teresco.org/hb/?u=michih&sys=deuulrs). Let's have a look into - a very short since still regional route only - RS5 (https://tmrail.teresco.org/hb/showroute.php?u=michih&r=deubw.rs05). The route only has 17 stations but there are Herbrechtingen and Hermaringen. Both are one word. More than one syllable but only one word. "Her" is not a word for its own. Calling both Her is not possible. I'm gone with Heb and Her but could also call them Heb and Hem. Sure.
However, while road wps are mainly labeled according to road numbers, there are no exit nor rail track numbers for rails. That means, almost all wps will have truncated names. And yes, I want to truncate them because Herbrechtingen, BofingenOstpreussenweg or MunchenHauptbahnhof are way too long.
Is there any technical reason why we should truncate to three characters? Why not four or five? I think that the road limit is due to performance reasons. It is also dated back when users had to type the wps into their list file. I guess we wanted to reduce the risk of typos.
I think that the performance issues are gone now - for update process and on the production server. No one really needs to type anything into their list file but can use the .list Tool editor. Maybe we should promote the latter more prominentely to convince users to use it.
So, again, why not truncating wp labels to four or five characters to help maintainers and users to read the wpt files and list files?
So, a couple things:
1) the existing waypoint labeling guidelines for roads allow for a fourth letter to be added if two points on the same route would abbreviate to the same three letters. These two stations could be abbreviated to Her and Herm (or Herb and Her, or even Herb and Herm) in order to disambiguate without extending the length of all other unaffected abbreviations and without changing the rules.
To be honest, I was not aware of it (https://tmrail.teresco.org/devel/manual/wayptlabels.php#differentnames) :o It would help in this case. I don't know if it would do the trick in case of long routes.
It is also more than just having a rule. When I enter "5" for highway exit 5, it is unique and clear to understand. When I enter a road number like "US123" it is also clear what it means. When there are more identical labels, we add suffixes like "US123_S" or "US123_N" or city names "US123_Chi". Anything else are less important junctions.
Our rail routes never use "exit numbers" nor "track numbers" at stations or stops (maybe at divergence point but those are not intended to be used). Thus, I think we should rethink the wp label numbering so that the labels are simpler to be read. si404 testd full names w/o truncating. That's easy to read but I think that it is over the top. I'm trying to find something in-between like truncating to 4 or 5 characters by default. I don't say we have to do it this way though. I only want, that we agree on it soon to avoid having to redraft too many routes. Definitely before we "go live for a broader public".
2) "shorten each word" was a guideline developed with the English language in mind. When dealing with aggluntative languages, some liberty is already necessary to deal with the fact that something which would be multiple words in English might be only one word. You will note for example in Iceland basically every street name is one word, with names like Njarðargata. But "gata" means "street" and is serving the function of a geneirc suffix, so the way I've handled it is to name that waypoint NjaGat.
I haven't poked around German names enough to be quite sure but it appears at a glance "ingen" might be serving a similar function here. If so, "HerIng" would also be a valid way of labeling one of those points.
Nope. "ingen" is not a word. And it has no meaning. It is a very common suffix though.
That said, the "main" section of T2 should have "Hegelstraße bound" in the city field and the "Stadthaus" section of T2 should have "Lankow-Siedlung bound" there, with the latter extended to cover the entire route rather than showing just the split section.
My intention with the draft manual was that each direction should be mapped separately but for the whole route, and the names of the terminal station in each direction used to disambiguate. Though looking at what I wrote that perhaps wasn't clear, so what if we change:
- 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
to
- 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 (e.g. "HogExp (Hogwarts bound)" vs. "HogExp (Kings Cross bound)"). Each mapped direction should cover the entire length of the route from terminal to terminal.
That work?
Thanks, got it. It makes sense to a certain degree. That said, I don't like the approach since drafting both routes completely would be a lot of effort for us. On creation and for maintenance. But again, it could make sense.... ;) :D Anyone else?
-
- 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 (e.g. "HogExp (Hogwarts bound)" vs. "HogExp (Kings Cross bound)"). Each mapped direction should cover the entire length of the route from terminal to terminal.
That work?
I love it but I hate it at the same time!
If we would implement it, we need an answer to situation like this: https://www.openstreetmap.org/#map=19/51.78078/14.34544
The northbound stop is north of the junction but the southbound stop is south of the junction. I know a lot of stops like this....
Just image that we had two routes because it would diverting anywhere along the route. One might call for having the wp at the right location. So, it would open the can of 1PPI nor not worms.... with having a "skip" wp at the other stop for keeping concurrencies.
-
Your light rails (https://en.wikipedia.org/wiki/Light_rail#/media/File:Green_line_Trax_at_Gallivan_Plaza.jpg) and your Streetcar (https://en.wikipedia.org/wiki/SEPTA_Route_34#/media/File:4500_Baltimore_Avenue.jpg) examples are both called "Straßenbahn" in German.
{...}
We might also go differently for NA and Europe if there is a good reason to do so.
Interesting. These types of systems are distinguished between in (American) English and the distinction is not purely age. Seattle has a couple streetcars that began operations in 2007 and 2016, and the Green Line in Boston is absolutely a light rail line even though it dates back to 1897.
But yes, I can see issues arising where the distinction gets lost in translation because... well, that happens. As an English speaker the words "shade" and "shadow" mean decidedly different things to me but in Italian (and probably many other languages) there aren't two different words for them (in Italian both are "ombra").
So... yeah, it becomes a judgment call whether any "Straßenbahn" in Germany belongs in Tier 4 or Tier 5, and if you'd rather just throw them all in Tier 4 go ahead, this seems an acceptable adaptation of doing things slightly differently in Europe.
If we would implement it, we need an answer to situation like this: https://www.openstreetmap.org/#map=19/51.78078/14.34544
The northbound stop is north of the junction but the southbound stop is south of the junction. I know a lot of stops like this....
Just image that we had two routes because it would diverting anywhere along the route. One might call for having the wp at the right location. So, it would open the can of 1PPI nor not worms.... with having a "skip" wp at the other stop for keeping concurrencies.
That's one station and I would put one point in the middle even if we had separate routes in the RB (Railway Browser) for each direction.
-
That's a light rail (tram) line, based on photos of it. Belongs in tier 4.
And if you find photos of it acting as an S-Bahn or as a U-Bahn, rather than the short street-running sections, it's not obviously dissimilar to other such systems. It's not as clear cut as you think. Here's a train running an RB service in another part of Germany (https://en.wikipedia.org/wiki/Die_L%C3%A4nderbahn#/media/File:I10_543_Bf_Plauen_ob_Bf,_VT_57_VB.jpg) - it doesn't look much different to the Karlsruhe light rail vehicles running on railways (https://en.wikipedia.org/wiki/Karlsruhe_Stadtbahn#/media/File:Stadtbahn_Karlsruhe_im_Karlsruher_Hauptnbahnhof_im_Dezember_2022.jpg).
There are multiple distinguishing features
Nope. These are alleged distinguishing features. I note that you at least used 'typically' for most of them, acknowledging that these are more rule of thumb than hard-and-fast.
Street-running / right-of-way is somewhere where's the more complexity. I don't think anyone would think that London-Weymouth trains until the 80s would be light rail due to, having travelled over 100 miles (initially as intercity-style service), the last mile being on-street (https://en.wikipedia.org/wiki/File:A_GW_Pannier_tank_heads_a_boat_train.jpg) to reach the port (https://en.wikipedia.org/wiki/File:33109_Weymouth_Harbour_Tramway_August_1981.jpg). There's quite a lot of this kind of thing for industrial usage (Trafford Park near Manchester was full of streets with train tracks running along them, but redevelopment has removed most), but it's not unheard of for passenger use. And there's also a difference between street-running (https://www.google.co.uk/maps/@49.0076175,8.4147261,3a,75y,224.73h,82.28t/data=!3m6!1e1!3m4!1srJbeSeyw2Dz4QdKVGB2XKQ!2e0!7i16384!8i8192?hl=en&entry=ttu), where there's no horizontal segregation and so sharing of the right-of-way with other traffic, and at-grade-running (https://www.google.co.uk/maps/@49.0064844,8.4309303,3a,29.1y,278.82h,87.59t/data=!3m6!1e1!3m4!1sHiFNI5SpA0DTj2artBWyLQ!2e0!7i16384!8i8192?hl=en&entry=ttu) where there is a dedicated right-of-way alongside/in the middle of a street, with at-grade crossings of the ROW (not that dedicated ROW can't have at-grade crossings). Looking at Karlsruhe, only the Strassenbahn has the former, with the Stadtbahn only doing the latter.
High-floor vs low-floor is one of those geeky obsessions (different electrical systems are also similar) that don't mean much for function. To give an example from the UK, where railways are all high-floor (which isn't the case in, say, Germany or the USA) - the Manchester Metrolink, Croydon Tramlink and Midland Metro (to give them all their original names) are similar concept systems from similar eras - build some street-running route in the centre (in the Midland Metro's case, a short bit in Wolverhampton, until much later when they bothered with a Birmingham bit) and convert rail line(s) to be part of the tram network. Manchester kept the old rail routes' high platforms and has high-floor vehicles. The other two demolished the pre-existing platforms (or, occasionally, raised the track height) and put in low ones and have low-floor vehicles. The three networks are all functionally the same thing, with Manchester not being different because of the type of vehicles.
These distinctions also have some functional implications because light rail trains can generally handle steeper hills and navigate tighter curves than their heavy rail counterparts, and also have shorter stopping distances (they have to, to safely run in streets).
Perhaps, but the DLR is undeniably functionally Metro, despite having 'Light Railway' in its name and using stock designed to do all the things that you cite here as being a Light Rail speciality due to the nature of the system.
Watching videos about the newly opened REM in Montreal this lunchtime, there was a subtle question of whether it's designation as 'Light' makes sense. The answer was so obviously 'no' they didn't bother talking about it much.
"Light rail" is also admittedly an American term, but British English "tram" is used similarly.
Yes and no - the Karlsruhe Stadtbahn would be seen in British English as light rail as opposed to being tram, rather than the terms being equivalent. I think I might have treated it as S-bahn when allocating a tier, rather than U-bahn (per the Stadtbahn in the Rhine-Ruhr) due to the use of Sx line designations rather than Ux ones, and thus it is perhaps a tier too high, but it's not at the same tier as the regular tram network in the city (which is not Streetcar).
And the LA Metro Light Rail lines - like the DLR/REM, stuff the Green and Crenshaw lines that are completely segregated and grade-separated and only are light rail because they use the same vehicles as the other Light Rail lines. And those other ones, which are Light Rail, I'd find easier to put into 'Metro' than 'Tram' - they don't have street-running, but rather at-grade-running (so their own ROW), and the great majority of time there's vertical-separation as well as horizontal-segregation - the at-grade running is short.
-
All this seems to come back to "it's a judgement call".
At any rate, the primary value of tiers 3/4/5 is the ability to have up to three different tiers of systems within the same city. We may be fussing too much over the broad distinctions when what really matters is the local distinctions. You mention LA Metro for example: I would say the LA Metro Subway lines (Red/Purple) absolutely belong as a separate system than the various LA Metro Light Rail lines because... well, they're physically distinct systems with very different rolling stock. Likewise for Montreal Subway vs. REM and London Underground vs. DLR. It is helpful for organizational purposes if one system goes in tier 3 and the other in tier 4; whether the tier 4 system meets some particular definition of "light rail" or not is moot - what matters is it is the lower grade of the two adjacent systems.
So how about this, to be less rigid:
System Tiers
Tier 1: intercity rail systems (e.g. Amtrak, Shinkansen)
Tier 2: commuter rail systems and tourist/heritage railroads
Tier 3: high-tier transit systems (e.g. subway/metro)
Tier 4: mid-tier transit systems (e.g. light rail/tram)
Tier 5: low-tier transit systems (e.g. streetcars, people movers)
That work better?
-
That sounds right, though there's no problem with having two systems at the same tier in the same city if there's multiple networks that match that level. The DLR, for instance, is going to remain tier 3 as its more tube-like than tramlink-like and the London Trams are tier 4.
they're physically distinct systems with very different rolling stock.
IRT vs IND/BMT vs PATH (the latter being a same-level, but different, system in the same city), rubber tyre Paris Metro lines vs standard ones, etc. ;)
-
Our rail routes never use "exit numbers" nor "track numbers" at stations or stops (maybe at divergence point but those are not intended to be used). Thus, I think we should rethink the wp label numbering so that the labels are simpler to be read. si404 testd full names w/o truncating. That's easy to read but I think that it is over the top. I'm trying to find something in-between like truncating to 4 or 5 characters by default. I don't say we have to do it this way though. I only want, that we agree on it soon to avoid having to redraft too many routes. Definitely before we "go live for a broader public".
I think about sticking with 3+ letters for street names but expanding to 5+ letters for cities and city districts. For instance, Frankfurt would be truncated to Frank, Berlin would Berlin, i.e. the main stations would be FrankHbf and BerlinHbf. More examples: DortmHbf, DuisbHbf, HambuHbf, HambuAltona, MunchHbf, MunchPasing, BerlinGesundBrunn
It might be a good idea for long-distance and regional services. Not for metro or tram services though.
Another examole: https://tmrail.teresco.org/hb/showroute.php?u=michih&r=eng.noreas
KinCro -> LondonKingsCross
Don -> Donca (Doncaster)
York keep as-is
Thi -> Thirsk
Nor -> North (Northallerton)
Eag -> Eagle (Eaglescliffe)
Har -> Hartl (Hartlepool)
Sun -> Sunde (Sunderland)
Thoughts?
-
Good rule of thumb is if it looks more like this (https://en.wikipedia.org/wiki/Light_rail#/media/File:Green_line_Trax_at_Gallivan_Plaza.jpg)it's light rail, but if it looks more like this (https://en.wikipedia.org/wiki/7_(New_York_City_Subway_service)#/media/File:R188_7_train.jpg) it's heavy rail.
That's tier 4 vs. tier 5. I asked for tier 3 vs. tier 4.
No that is tier 3 (heavy rail rapid transit, second link) vs. tier 4 (light rail, first link).
Tier 5 would be something like this (https://en.wikipedia.org/wiki/Morgantown_Personal_Rapid_Transit#/media/File:Morgantown_Personal_Rapid_Transit.jpg) (people mover) or this (https://en.wikipedia.org/wiki/SEPTA_Route_34#/media/File:4500_Baltimore_Avenue.jpg) (streetcar)
In that case would US airport people movers count as tier 5? That's what I thought of as soon as I saw the WVU transit thingie.
-
In that case would US airport people movers count as tier 5? That's what I thought of as soon as I saw the WVU transit thingie.
Yes
https://tmrail.teresco.org/hb/index.php?sys=usaairtrn
https://tmrail.teresco.org/hb/index.php?sys=usaatl
or, if you miss the US bit
https://tmrail.teresco.org/hb/index.php?sys=gbnstts
https://tmrail.teresco.org/hb/index.php?sys=gbnht5t
https://tmrail.teresco.org/hb/index.php?sys=gbnhprt
https://tmrail.teresco.org/hb/index.php?sys=gbngast
https://tmrail.teresco.org/hb/index.php?sys=gbndart
https://tmrail.teresco.org/hb/index.php?sys=gbnbarl
https://tmrail.teresco.org/hb/index.php?sys=fraval
https://tmrail.teresco.org/hb/showroute.php?r=deunw.skytrn
-
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
ENG/FRA is never a valid border label (and GBR/FRA is a bit of an odd border). Suggest changing the example to NY/CT.
Our rail routes never use "exit numbers" nor "track numbers" at stations or stops (maybe at divergence point but those are not intended to be used). Thus, I think we should rethink the wp label numbering so that the labels are simpler to be read. si404 testd full names w/o truncating. That's easy to read but I think that it is over the top. I'm trying to find something in-between like truncating to 4 or 5 characters by default. I don't say we have to do it this way though. I only want, that we agree on it soon to avoid having to redraft too many routes. Definitely before we "go live for a broader public".
I think about sticking with 3+ letters for street names but expanding to 5+ letters for cities and city districts. For instance, Frankfurt would be truncated to Frank, Berlin would Berlin, i.e. the main stations would be FrankHbf and BerlinHbf. More examples: DortmHbf, DuisbHbf, HambuHbf, HambuAltona, MunchHbf, MunchPasing, BerlinGesundBrunn
It might be a good idea for long-distance and regional services. Not for metro or tram services though.
There's certainly merit in this. I've stuck with 3 letters (and possibly a 4th disambiguating one - often the 5th letter!) in my conversion from 3-letter codes to 3-letter abbrevs, but I see it in say datacheck* and have to think where that is and I know the routes! eg I got 'SKIP_Ber' as a duplicate label on a route and I didn't guess what either of them (Berkswell and Berkhamstead - the latter being not far from where I live!) was until I put the route in the browser and went and saw the stations zoomed in.
*As I looked at this morning. LONG_UNDERSCORE and VISIBLE_DISTANCE are cluttering it up!
-
Our rail routes never use "exit numbers" nor "track numbers" at stations or stops (maybe at divergence point but those are not intended to be used). Thus, I think we should rethink the wp label numbering so that the labels are simpler to be read. si404 testd full names w/o truncating. That's easy to read but I think that it is over the top. I'm trying to find something in-between like truncating to 4 or 5 characters by default. I don't say we have to do it this way though. I only want, that we agree on it soon to avoid having to redraft too many routes. Definitely before we "go live for a broader public".
I think about sticking with 3+ letters for street names but expanding to 5+ letters for cities and city districts. For instance, Frankfurt would be truncated to Frank, Berlin would Berlin, i.e. the main stations would be FrankHbf and BerlinHbf. More examples: DortmHbf, DuisbHbf, HambuHbf, HambuAltona, MunchHbf, MunchPasing, BerlinGesundBrunn
It might be a good idea for long-distance and regional services. Not for metro or tram services though.
There's certainly merit in this. I've stuck with 3 letters (and possibly a 4th disambiguating one - often the 5th letter!) in my conversion from 3-letter codes to 3-letter abbrevs, but I see it in say datacheck* and have to think where that is and I know the routes! eg I got 'SKIP_Ber' as a duplicate label on a route and I didn't guess what either of them (Berkswell and Berkhamstead - the latter being not far from where I live!) was until I put the route in the browser and went and saw the stations zoomed in.
Thanks :) Has anyone else experienced the same?
*As I looked at this morning. LONG_UNDERSCORE and VISIBLE_DISTANCE are cluttering it up!
Yep, data check might also need some adjustments when rules have been settled.
You can also try hiding errors via the url for the time being:
https://tmrail.teresco.org/devel/datacheck.php?hide=VISIBLE_DISTANCE
https://tmrail.teresco.org/devel/datacheck.php?hide=VISIBLE_DISTANCE,LONG_UNDERSCORE
-
We are going to have to remove Long_Underscore and Underscore_Labels from the datacheck for rail systems as the formatting for DIV and SKIP labels means lots of these things will exist legitimately and this isn't an error we should be checking for.
I'm still very "if it ain't broke don't fix it" about abbreviating town names though. Adding more letters might be unobtrusive for place names that are one word but then you'd get things like SalisMillsCornw. SalMilCor is just so much tidier and no more ambiguous. And even for one-word names what difference does it make really.
-
That said, the "main" section of T2 should have "Hegelstraße bound" in the city field and the "Stadthaus" section of T2 should have "Lankow-Siedlung bound" there, with the latter extended to cover the entire route rather than showing just the split section.
My intention with the draft manual was that each direction should be mapped separately but for the whole route, and the names of the terminal station in each direction used to disambiguate. Though looking at what I wrote that perhaps wasn't clear, so what if we change:
- 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
to
- 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 (e.g. "HogExp (Hogwarts bound)" vs. "HogExp (Kings Cross bound)"). Each mapped direction should cover the entire length of the route from terminal to terminal.
That work?
https://github.com/TravelMapping/RailwayData/pull/13/commits/1c648b8f7a898ef7e8934a886a0da51920c55eaf
I'm gone with Hegelstraße bound and Lankow bound now. I thought about eastbound and westbound but dropped the idea very soon.
But how to call the wpt file? And the Abbrev? I'm gone with Lan for the Lankow bound route now. Thoughts?
Edit: It's even more complicated since we already use "Sch" abbreviation. Hmmm....
deusnt;DEU-MV;2;;Sch;Schwerin (Hegelstraße bound);deumv.02sch;
deusnt;DEU-MV;2;;Lan;Schwerin (Lankow bound);deumv.02schlan;
-
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
ENG/FRA is never a valid border label (and GBR/FRA is a bit of an odd border). Suggest changing the example to NY/CT.
Our rail routes never use "exit numbers" nor "track numbers" at stations or stops (maybe at divergence point but those are not intended to be used). Thus, I think we should rethink the wp label numbering so that the labels are simpler to be read. si404 testd full names w/o truncating. That's easy to read but I think that it is over the top. I'm trying to find something in-between like truncating to 4 or 5 characters by default. I don't say we have to do it this way though. I only want, that we agree on it soon to avoid having to redraft too many routes. Definitely before we "go live for a broader public".
I think about sticking with 3+ letters for street names but expanding to 5+ letters for cities and city districts. For instance, Frankfurt would be truncated to Frank, Berlin would Berlin, i.e. the main stations would be FrankHbf and BerlinHbf. More examples: DortmHbf, DuisbHbf, HambuHbf, HambuAltona, MunchHbf, MunchPasing, BerlinGesundBrunn
It might be a good idea for long-distance and regional services. Not for metro or tram services though.
There's certainly merit in this. I've stuck with 3 letters (and possibly a 4th disambiguating one - often the 5th letter!) in my conversion from 3-letter codes to 3-letter abbrevs, but I see it in say datacheck* and have to think where that is and I know the routes! eg I got 'SKIP_Ber' as a duplicate label on a route and I didn't guess what either of them (Berkswell and Berkhamstead - the latter being not far from where I live!) was until I put the route in the browser and went and saw the stations zoomed in.
*As I looked at this morning. LONG_UNDERSCORE and VISIBLE_DISTANCE are cluttering it up!
Should I give the 5+ city name idea a try?
-
We are going to have to remove Long_Underscore and Underscore_Labels from the datacheck for rail systems as the formatting for DIV and SKIP labels means lots of these things will exist legitimately and this isn't an error we should be checking for.
Another option, not sure if it's better, might be to use something besides an underscore in the DIV and SKIP labels.
-
Should I give the 5+ city name idea a try?
Worth having a look at it implemented, to help us decide whether it's worth it.
---
Branch handling
Mostly I've tended to treat branches like highways, where the branch ends when it reaches the main route. However I've noticed that the redone/new American systems that branches continue along the line (and so somethings are done like that).
For example:
Currently the London Underground Central line is split into:- CenLn (https://tmrail.teresco.org/hb/showroute.php?r=eng.cenln) - from West Ruislip to Epping (as the longest possible route)
- CenLnEal (https://tmrail.teresco.org/hb/showroute.php?r=eng.cenlneal) - from Ealing Broadway to North Acton (the junction station)
[li]CenLnHai (https://tmrail.teresco.org/hb/showroute.php?r=eng.cenlnhai) - from Leytonstone (the junction station) via Hainault to Woodford (the junction station)[/li][/list]
However the off-peak service pattern is the following 3 services (merging short turns in):
- 9tph West Ruislip - Epping and 3tph short-turning Northolt - Loughton
- 3tph between Hainault and Woodford
- 6tph between Ealing Broadway and Hainault with 3tph Ealing Broadway - Newbury Park and 3tph White City - Hainault short turns
Together with the idea that same-line extensions (cf New York commuter rail diesel islands like the NJ Coast Line and Port Jefferson line) should be merged in with the main route even though they are shuttle services at the end of the line (would the same apply to E-BART?), that gives two routes for the browser: West Ruislip - Epping and Ealing Broadway - Woodford.
So is it- Map the line like a road with branches ending when arriving on the mainline, or
- Map the line by services as two routes with a long overlap across the middle (on other routes this will escalate - the Northern line goes from 3 files to 6 and everything being at least 2 concurrencies)
-
Map the line by services as two routes with a long overlap across the middle (on other routes this will escalate - the Northern line goes from 3 files to 6 and everything being at least 2 concurrencies)
I'm not sure if I got it right. Is it similar to my Hegelstraße bound (https://tmrail.teresco.org/hb/showroute.php?r=deumv.02sch) and Lankow bound (https://tmrail.teresco.org/hb/showroute.php?r=deumv.02schlan) thing in Schwerin from yesterday?
-
Map the line by services as two routes with a long overlap across the middle (on other routes this will escalate - the Northern line goes from 3 files to 6 and everything being at least 2 concurrencies)
I'm not sure if I got it right. Is it similar to my Hegelstraße bound (https://tmrail.teresco.org/hb/showroute.php?r=deumv.02sch) and Lankow bound (https://tmrail.teresco.org/hb/showroute.php?r=deumv.02schlan) thing in Schwerin from yesterday?
A little, but effectively you have a line with two branches either side of a core section (and a shuttle at the end of one of them), rather than a one-way loop thing in the middle of a line.
-
We are going to have to remove Long_Underscore and Underscore_Labels from the datacheck for rail systems as the formatting for DIV and SKIP labels means lots of these things will exist legitimately and this isn't an error we should be checking for.
Another option, not sure if it's better, might be to use something besides an underscore in the DIV and SKIP labels.
We could go with DIV-AbcDef, DIV/AbcDef or DIVAbcDef. They are not indicated as error in wpt editor.
-
Map the line by services as two routes with a long overlap across the middle (on other routes this will escalate - the Northern line goes from 3 files to 6 and everything being at least 2 concurrencies)
I'm not sure if I got it right. Is it similar to my Hegelstraße bound (https://tmrail.teresco.org/hb/showroute.php?r=deumv.02sch) and Lankow bound (https://tmrail.teresco.org/hb/showroute.php?r=deumv.02schlan) thing in Schwerin from yesterday?
A little, but effectively you have a line with two branches either side of a core section (and a shuttle at the end of one of them), rather than a one-way loop thing in the middle of a line.
I'd keep the Ealing branch (https://tmrail.teresco.org/hb/showroute.php?r=eng.cenlneal) as-is.
I'm not sure if I got the Hainault loop (https://tmrail.teresco.org/hb/showroute.php?r=eng.cenlnhai) right. We might merge the loop into the main route and treat the extension to Epping as a branch?
-
We are going to have to remove Long_Underscore and Underscore_Labels from the datacheck for rail systems as the formatting for DIV and SKIP labels means lots of these things will exist legitimately and this isn't an error we should be checking for.
I've opened a GitHub Issue related to changes we might want to make to have the site update program enable/disable various datachecks as appropriate for different kinds of data.
https://github.com/TravelMapping/DataProcessing/issues/604
-
Should I give the 5+ city name idea a try?
Worth having a look at it implemented, to help us decide whether it's worth it.
It's crap for metros and S Bahn services which mostly run through one city. My city district proposal really sucks.
I've (mostly) implemented it for HH S Bahn now but not for HH U Bahn (metro).
https://github.com/TravelMapping/RailwayData/pull/15/commits/efabe446010a5470e765f6ddb317785754e931c7
https://tmrail.teresco.org/hb/?u=michih&sys=deuhhs
It's different for long-distance services which usually have one stop per city / town only. I don't have such route in Germany though.
-
Together with the idea that same-line extensions (cf New York commuter rail diesel islands like the NJ Coast Line and Port Jefferson line) should be merged in with the main route even though they are shuttle services at the end of the line (would the same apply to E-BART?), that gives two routes for the browser: West Ruislip - Epping and Ealing Broadway - Woodford.
So is it- Map the line like a road with branches ending when arriving on the mainline, or
- Map the line by services as two routes with a long overlap across the middle (on other routes this will escalate - the Northern line goes from 3 files to 6 and everything being at least 2 concurrencies)
Yeah so my thinking here is since we're mapping services, the mapped route should end where the train terminates. There is no such thing as a service on the NYC Subway that runs only from Ozone Park-Lefferts to Rockaway Blvd, that train runs all the way to Inwood 207th... so I made it do that.
This at least is the situation where you only have branching in one direction. Where you have branching in two directions I don't think every single possible service pattern necessarily needs to be mapped (in some cases that could get to be quite a lot) so long as every branch is included in some way. You'll see, for example, the way I've retooled LIRR, I've generally sorted the outward branches between Atlantic, Penn, Grand Central, and LIC based on which one the majority of trains on that branch go to, with a couple branches having both Grand Central and Penn versions because the number of trains to both is near parity. There are unmapped service patterns I could add, but they'd all be 100% concurrent with already mapped patterns and thus redundant.
Re: diesel islands, I'd keep them separate if they are true islands. Wassaic, Port Washington, and Long Branch all have nonzero direct trains to Manhattan which is why I combined them with the inner, electrified portions of their respective lines. Ronkonkoma-Greenport, you may note, is still mapped separately, because there are no direct trains to Manhattan from Greenport.
-
Also related:
There are two branches in Hamburg. Drafted by Si, redrafted by me yesterday.
The branches start at a station but branch off afterwards. At a DIV label. It looks odd on mapview when enabling "Color by concurrencies". Independent of the current "DIV visualization" issue:
https://tmrail.teresco.org/user/mapview.php?u=michih&sys=deuhhu
https://tmrail.teresco.org/user/mapview.php?u=michih&sys=deuhhs
It's fine for casual users but I don't like it for maintenance purpose. I always assume an error since it would most likely be an error for roads.
I don't like the idea but should we start a branch at a DIV wp?
-
I don't like the idea but should we start a branch at a DIV wp?
Hard no.
It will look less weird with the bringing it through.
-
Should I give the 5+ city name idea a try?
Worth having a look at it implemented, to help us decide whether it's worth it.
It's crap for metros and S Bahn services which mostly run through one city. My city district proposal really sucks.
I've (mostly) implemented it for HH S Bahn now but not for HH U Bahn (metro).
https://github.com/TravelMapping/RailwayData/pull/15/commits/efabe446010a5470e765f6ddb317785754e931c7
https://tmrail.teresco.org/hb/?u=michih&sys=deuhhs
It's different for long-distance services which usually have one stop per city / town only. I don't have such route in Germany though.
deuros (Rostock S-Bahn) (https://tmrail.teresco.org/hb/index.php?sys=deuros) is better for a test :)
https://github.com/TravelMapping/RailwayData/pull/16
Things I'd like to get feedback:
- I've implemented the 5+ label idea for the regional deuros system but not for the urban deurot system, i.e. identical wps have different names, e.g. S1's MarienEhe is T1's MarEhe or S1's RostoHbf is T2's Hbf (= Hauptbahnhof = main station)
- I added the "Rosto" prefix to stops of the deuros system in the city of Rostock which had only street names before
- I used the same city/town name abbreviations for DIV labels
- I've nixed the concurrency of the S and T lines in Evershagen since they are different systems on different tracks
Edit: I've also implemented it for Stuttgart S Bahn system (https://tmrail.teresco.org/hb/index.php?sys=deuss).
-
I don't like the idea but should we start a branch at a DIV wp?
Hard no.
Agree with the hard no. Route needs to end where train terminates.
Things I'd like to get feedback:
- I've implemented the 5+ label idea for the regional deuros system but not for the urban deurot system, i.e. identical wps have different names, e.g. S1's MarienEhe is T1's MarEhe or S1's RostoHbf is T2's Hbf (= Hauptbahnhof = main station)
My opinion in this is already on record, I won't harp on it.
- I added the "Rosto" prefix to stops of the deuros system in the city of Rostock which had only street names before
Do the official station names that appear on signs include "Rostock"? If not, this shouldn't be there.
If it's necessary to disambiguate otherwise duplicated names, the correct way to do this is with an underscored suffix: "_Ros"
- I used the same city/town name abbreviations for DIV labels
Not picky about this. Whatever works.
- I've nixed the concurrency of the S and T lines in Evershagen since they are different systems on different tracks
While this isn't currently what's broadly implemented it's... yeah this is probably the correct way. I'm good with eliminating concurrencies between physically incompatible systems that are in the same ROW but have no track connection.
-
- 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
To expand on this...
1 thing I've found is that some British operators have infrequent (say 1 to 4 times a day) extensions of long distance services to places that they wouldn't otherwise service, but are wholly concurrent with other operator's services (or even their own - eg GWR to Paignton to give a direct London service, but most trains are stoppers as part of the 'Devon Metro'). Do I implement a train-every-two-hours cut off for this? Certainly it would help with reducing concurrencies (cf Avanti West Coast to Blackpool, or TransPennine's Liverpool-Glasgow services). Obviously services using unique bits of track would get added (which I need to implement when it comes to some peak urban services), as would stuff like the Caledonian Sleeper that is, by nature, infrequent service.
London North Eastern Railway's wikipedia page (https://en.wikipedia.org/wiki/London_North_Eastern_Railway) implements this well, splitting its service table into 'Regular Services' (hourly or 2-hourly), and 'Irregular services' (1 to 3 trains per day). CrossCountry's wikipedia page (https://en.wikipedia.org/wiki/CrossCountry#Extensions) removes them from the service table and lists them in text form.
I don't know what the frequency cut-off for service being 'limited' is on Project Mapping's map (http://www.projectmapping.co.uk/Resources/TOCs%20AS%20v55%20July%202023.pdf) (used by National Rail), but it strikes me as perhaps a little too low as a cut off.
Also, if we're going by midday service, why did this get implemented?
This is fairly easy to resolve using some local knowledge of the administrative history: all the lines which pass through Newark Broad Street can be mapped as terminating in Hoboken, as historically they all did before the introduction of "MidTown Direct" service on these lines.
The only trains on the Morristown and Montclair-Boontown lines that go to Hoboken are the ones that extend beyond the electric network (the Gladstone branch usually goes to Hoboken though) and a couple of peak trains.
https://content.njtransit.com/sites/default/files/ME-WKDY-042323.pdf
https://content.njtransit.com/sites/default/files/MC-WKDY-042323.pdf
This strikes me as an odd move - more based in nostalgia than actual service. The solution done on the LIRR to reduce the concurrencies (most frequent wins) strikes me as a good one. The most-frequent terminus for two of the three Newark Broad Street lines is NY Penn and so they should go there. If you took a Hoboken train, you can map it as using the Gladstone branch - just as mapping a Huntington - Grand Central journey on a direct train the other side of the Hudson needs to use one of the routes going between Jamaica and Grand Central.
This at least is the situation where you only have branching in one direction. Where you have branching in two directions I don't think every single possible service pattern necessarily needs to be mapped (in some cases that could get to be quite a lot) so long as every branch is included in some way. You'll see, for example, the way I've retooled LIRR, I've generally sorted the outward branches between Atlantic, Penn, Grand Central, and LIC based on which one the majority of trains on that branch go to, with a couple branches having both Grand Central and Penn versions because the number of trains to both is near parity.
-
- I added the "Rosto" prefix to stops of the deuros system in the city of Rostock which had only street names before
Do the official station names that appear on signs include "Rostock"? If not, this shouldn't be there.
It depends.... The signs in the field usually have it for the S Bahn services. Timetables do often not have them. the city name is usually also omitted on the displays in the train itself. Official online services where you can book travels have the full name, of course.
There are also station which are served by different systems, e.g. by tram and by regional trains. Tram stations often omit the city name since its superfluous like a stop at an Hauptbahnhof (= main station) which is already a long word.
Dunno.... That's why I asked what's best practise.
-
1 thing I've found is that some British operators have infrequent (say 1 to 4 times a day) extensions of long distance services to places that they wouldn't otherwise service, but are wholly concurrent with other operator's services {...}
I don't know what the frequency cut-off for service being 'limited' is on Project Mapping's map (http://www.projectmapping.co.uk/Resources/TOCs%20AS%20v55%20July%202023.pdf) (used by National Rail), but it strikes me as perhaps a little too low as a cut off.
I support not mapping the infrequent wholly-concurrent extensions in concept. Where exactly the cutoff should be is a judgment call I don't have a strong opinion on.
Also, if we're going by midday service, why did this get implemented?
This is fairly easy to resolve using some local knowledge of the administrative history: all the lines which pass through Newark Broad Street can be mapped as terminating in Hoboken, as historically they all did before the introduction of "MidTown Direct" service on these lines.
The only trains on the Morristown and Montclair-Boontown lines that go to Hoboken are the ones that extend beyond the electric network (the Gladstone branch usually goes to Hoboken though) and a couple of peak trains.
https://content.njtransit.com/sites/default/files/ME-WKDY-042323.pdf
https://content.njtransit.com/sites/default/files/MC-WKDY-042323.pdf
This strikes me as an odd move - more based in nostalgia than actual service. The solution done on the LIRR to reduce the concurrencies (most frequent wins) strikes me as a good one. The most-frequent terminus for two of the three Newark Broad Street lines is NY Penn and so they should go there. If you took a Hoboken train, you can map it as using the Gladstone branch - just as mapping a Huntington - Grand Central journey on a direct train the other side of the Hudson needs to use one of the routes going between Jamaica and Grand Central.
Honestly... I think you're right about this and I'm going to add that to my list of things to redo. What I have in there for NJT currently does also have the problem that a journey between Newark Broad and Penn (which will be taken by many people) cannot be mapped without using DIV points, and if we're going to hide those that's no bueno.
-
Question on the tiers as I'm starting to draft things up, why are tourist/heritage railroads tier 2? At least in the US they're not very long and function more like a Tier 4/5 type system (as least as I conceptualize it).
-
Question on the tiers as I'm starting to draft things up, why are tourist/heritage railroads tier 2? At least in the US they're not very long and function more like a Tier 4/5 type system (as least as I conceptualize it).
I agree. Unless we're talking Land Cruise stuff like the Orient Express, or the Cross-Australia trains (arguably tier 1 due to their length and limited stops), the ones I can think of are lower tier and fit better in tier 4 or even 5.
-
I'm putting the tourist railroads I'm drafting into tier 2 for now, but I can shift them over easily enough.
-
I could see the Grand Canyon Railway being tier 2. Maybe the cutoff should be whether you can get on at either end and off at the other?
The Lookout Mountain Incline is an interesting case in that you're supposed to start at the bottom, but you can get off at the top and walk around the neighborhood before going back down. But if you get on at the top they don't check tickets, so I guess you could use it for transportation if you live up top. Not that it would be in tier 2 anyway, but it's an interesting case to think about.
-
I could see the Grand Canyon Railway being tier 2. Maybe the cutoff should be whether you can get on at either end and off at the other?
The cut off in general, or the cut off for tier 2? The former, certainly, but there's no way something like the Welsh Highland Heritage Railway (https://en.wikipedia.org/wiki/Welsh_Highland_Heritage_Railway) is above Tier 4, even though you can get off at both ends (a mile apart).
-
Question on the tiers as I'm starting to draft things up, why are tourist/heritage railroads tier 2? At least in the US they're not very long and function more like a Tier 4/5 type system (as least as I conceptualize it).
So, the thinking here is that tier 1 and 2 systems are systems that utilize the national railroad network or are built to its specifications while tier 3/4/5 systems are urban rapid transit systems that do not necessarily meet national rail specs.
Tourist/heritage railroads in the US are usually not "urban" in nature and are FRA-regulated the same as commuter railroads and Amtrak are.
And, well, look at the type of equipment they use: fullsize locomotives pulling fullsizes coaches. That resembles what commuter railroads use. It does not resemble a subway, light rail, streetcar, or people move at all.
I would be very against moving heritage railroads down from tier 2 broadly, however if a particular heritage railroad does not meet what I described above (e.g. narrow gauge, smaller equipment) then I could see it being placed in tier 4 or 5 instead.
-
I don't think tiers should depend on tracks or equipment. A state-numbered freeway is not the same tier as an Interstate freeway. As with roads, we should classify railways according to their function in the system.
-
I don't think tiers should depend on tracks or equipment. A state-numbered freeway is not the same tier as an Interstate freeway. As with roads, we should classify railways according to their function in the system.
This!
-
Question on the tiers as I'm starting to draft things up, why are tourist/heritage railroads tier 2? At least in the US they're not very long and function more like a Tier 4/5 type system (as least as I conceptualize it).
So, the thinking here is that tier 1 and 2 systems are systems that utilize the national railroad network or are built to its specifications while tier 3/4/5 systems are urban rapid transit systems that do not necessarily meet national rail specs.
Tourist/heritage railroads in the US are usually not "urban" in nature and are FRA-regulated the same as commuter railroads and Amtrak are.
And, well, look at the type of equipment they use: fullsize locomotives pulling fullsizes coaches. That resembles what commuter railroads use. It does not resemble a subway, light rail, streetcar, or people move at all.
I would be very against moving heritage railroads down from tier 2 broadly, however if a particular heritage railroad does not meet what I described above (e.g. narrow gauge, smaller equipment) then I could see it being placed in tier 4 or 5 instead.
I don't really know about other countries, but the ones I've found in the US (at least out West) don't interconnect to a national network and are usually the sole users of their tracks. I mean, when you compare the UTA FrontRunner in SLC and the Old Hill City Railroad in SD, they don't feel like they should be the same tier. Maybe the US ones could be moved down to Tier 4/5 (especially if we to go to one overall system format as discussed elsewhere)?
-
I don't really know about other countries, but the ones I've found in the US (at least out West) don't interconnect to a national network and are usually the sole users of their tracks.
Similar over here in the UK/Ireland (https://tmrail.teresco.org/user/mapview.php?sys=eurhr) - there's a couple of places where there's interaction, but everything else is isolated and mostly short.
*The Jacobite is a steam-run service on the national network. There's a couple of heritage lines that have previously seen through-running off the national network (Swanage Railway (https://www.youtube.com/watch?v=sK7YypqZ48g), West Somerset Railway (https://www.youtube.com/watch?v=G5SrWqO2mrg)) or runs trains on a short bit of it (eg the Swanage railway). Also some stations see both a heritage line and a regular line (eg Blaenau Ffestiniog (https://en.wikipedia.org/wiki/Blaenau_Ffestiniog_railway_station)).
-
Yeah, the line ending at a junction point ("Loop") is in line with the draft manual. You'll see this in Chicago too for all the L lines that terminate at the, um, loop.
I'd read that line in the draft manual differently and have one-way loops continue to the first station beyond (which was how I drafted them anyway). Logic being that you a stop is a consistent visible point to break your travels at. As you point out....
That said, if someone started a trip on the outbound side of the loop and didn't take a return ride in the opposite direction, they won't be able to map their travels properly without using a DIV point. This could be an argument in favor of running the line concurrent with itself to the first bidirectional station
Currently, if I'd travelled from Terminal 8 to Jamaica it would be
NY AirTrnJam T8 Loop
NY AirTrnJam <unknown div point>* Jam
*and I can't click to find its name as it's concurrent with the later point 'Loop'. It does work if I use the list tool to highlight the relevant sections - the point is +DIV_Loop
I would have it as
NY AirTrnJam T8 FedCir_2
NY AirTrnJam FedCir_1 Jam
but... it isn't actually feasible to avoid all cases where someone might need to put a DIV point in their rlist file, so we need a way of enabling that to the non-power user regardless.
Surely we ought to minimise the number of cases when using the somewhat hidden points is needed?
That said, the list tool does enable it...
-
I have a question about how lines like the Akita Shinkansen should be handled.
-- Service extends from Tokyo to Akita.
-- From Tokyo to Morioka the Akita cars are attached to the end of a Tohoku Shinkansen train running on the Tohoku Shinkansen tracks.
-- At Morioka, the Akita cars are detached and then run on regular lines to Akita.
Does the Akita Shinkansen start in Tokyo, or does it start in Morioka? I would assume Tokyo with a concurrency to Morioka.
-
Does the Akita Shinkansen start in Tokyo, or does it start in Morioka? I would assume Tokyo with a concurrency to Morioka.
I agree with your assumption.
-
Most metro stations in Japan have a station code that is based on the metro line that they service. These codes are listed on route signs and maps so they are known to the public (and from experience, are really useful if you can't decode some of the more esoteric station names). Could or should a station code be incorporated into a station's waypoint name?
I'm torn, because I would prefer not to, but English versions of Japanese place names when abbreviated all too often start with the same syllables -- e.g. Tak, Tok, Fuk, Shi -- so station name abbreviations can be very similar. The station code would help disambiguate the station name abbreviations. (The ideal solution would be using the station name kanji as the waypoint name because they are unique for that line and already short. Will multi-byte character text ever be supported?)
-
The station code would help disambiguate the station name abbreviations.
Our users can simply use the .list tool editor in showroute.php. Nonetheless, I have no strong feeling if we should add station codes or not.
-
Will multi-byte character text ever be supported?
I have no objection but also have no time available to make it happen. I think with the .list tool, we wouldn't need to worry about people having to type in the non-English characters if they did not want to/know how to do so.
-
I mean, SOP already accomodates this situation by allowing additional letters to be added to avoid duplicate labels, though I agree with a lot of would be duplicates this gets messy - which one is Osa and which one is Osak anyway?
One potential solution would be to interpret "first three letters" to mean the first three letters before transliteration into the Latin alphabet. So if you have a station named Fukushima, it would be labeled Fukushi. This reduces collisions while keeping label lengths reasonable.
I think with the .list tool, we wouldn't need to worry about people having to type in the non-English characters if they did not want to/know how to do so.
Ehhhh anyone editing their list files manually is still going to find it an annoyance to have to handle that though. I would prefer to continue sticking to the basic Latin alphabet for anything that goes in a list file.
Also note that other fields like system name and city name do already support non-ASCII characters (e.g. "Iceland Þjóðvegir").
-
I'm using the signed station codes in Singapore, which Tokyo seems to have copied the idea from. The important bit is that the code is signed.
Here's some Tokyo signs - pretty clear they are signed as part of the station name.
(https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQiwd0H0YwKpl93nyivTDs5SpMUTaj6WCD7QA&usqp=CAU)
(https://c8.alamy.com/comp/KB3C0W/japan-honshu-tokyo-ginza-underground-station-entrance-signs-KB3C0W.jpg)
Codes are perhaps an unhelpful term - they are station numbers and the analogue is junction numbers - which in highway systems trump any name-based label for waypoints.
-
Yeah, those look analogous to exit numbers.
-
Thanks to everyone for their comments. I'll use the station code when available (mostly metro and commuter rail), and try using the English version of the first 3 or 4 kana of the station name for stations lacking a code. Three kana will be 6 to 9 characters. For example かごしま (Kagoshima) would abbreviate to Kagoshi. Or I could use 4 kana and the entire name could be used. A lot of station names are four kana in length.
My next question is about named shinkansen routes. The Tohoku Shinkansen has four named services.
- Nasuno, a local from Tokyo to Koriyama
- Hayate, a local from Morioka to Shin Aomori
- Yamabiko, a rapid from Tokyo to Morioka
- Hayabusa, an express from Tokyo to Shin Aomori
All the services run entirely on the Tohoku Shinkansen line. Hayabusa travels the entire length of the line. Should there be four entries for the Tohoku Shinkansen, one for each named service, or only one entry?
-
All the services run entirely on the Tohoku Shinkansen line. Hayabusa travels the entire length of the line. Should there be four entries for the Tohoku Shinkansen, one for each named service, or only one entry?
One entry that includes every station is sufficient. Mapping distinct local and express services is only necessary if they diverge at some point.
-
All the services run entirely on the Tohoku Shinkansen line. Hayabusa travels the entire length of the line. Should there be four entries for the Tohoku Shinkansen, one for each named service, or only one entry?
One entry that includes every station is sufficient. Mapping distinct local and express services is only necessary if they diverge at some point.
But, at the same time, if they have separate designations, they may be mapped individually.
For instance the C in the NYC subway doesn't diverge from the A (which runs express), but we map both.
-
Propose adding the following to the "scope" section:
- train services that are subject to access restrictions such that the general public cannot casually just show up and ride them should not be mapped. Examples of access restrictions include trains contained within government facilities that may only be ridden by employees and authorized visitors, and trains located airside (beyond security) at airports such that they may only be ridden with a valid plane ticket to or from that airport. For the purpose of this rule, the need for a pre-reserved train ticket is NOT considered an access restriction, nor is the need for travel documents (passport, etc.) on trains that cross international borders.
Currently the draft manual does not address this issue. There has been some controversy (https://forum.travelmapping.net/index.php?topic=5698.0) about it. In the interest of having a written rule about it so the project can move forward, this proposed rule aims to simply codify the status quo given the lack of any consensus in favor of altering it.
-
Currently the draft manual does not address this issue. There has been some controversy (https://forum.travelmapping.net/index.php?topic=5698.0) about it. In the interest of having a written rule about it so the project can move forward, this proposed rule aims to simply codify the status quo given the lack of any consensus in favor of altering it.
It's sort of like the highways and people wanting a 'pure' thing of State/US/I- only. I feel that airside / Capitol Subway probably should be provided at some point, but as a 'bonus' style system, rather than a core thing. Other than the Capitol Subway, the access restrictions here seem less than the roads clinchable on military bases (though, tbf, we have tended to debate those and minimise to those where you'd have an reason for the guard at the gate beyond 'I want to clinch this road'). We also have bits of road mapped that you need a ferry ticket to drive.
As for stuff where you need ID to travel - I think the Spanish AVE trains have it (most don't cross the border, but even those that do never leave Schengen so wouldn't require passports for the actual travel - it's security theatre after the Madrid train bombings), so perhaps a bit of clarity there.
Also, when I went to the Zoo a month ago, was I not an authorised visitor - they let me in (after a bag search) onto their private land, and had the right to turn me away? Wasn't my valid zoo ticket an access condition to ride the train (at extra cost, so I didn't*) in the way a plane ticket is an access condition to ride airside people movers?
I have no problem with the status quo, but would like a bit crisper wording of what we're not/not yet including.
*A bit annoying as I can't make out from sources whether there's a second stop and thus something mappable. But not that annoying as all you get to see is some deer things a bit closer than if you were walking around.
---
Looking back through the thread, the only outstanding issue where there might not be consensus that I can see is the 3 letter labels, but the implementation of longer ones wasn't seen as that useful by the person who implemented them on the systems they did so:
It's crap for metros and S Bahn services which mostly run through one city. My city district proposal really sucks.
I've (mostly) implemented it for HH S Bahn now but not for HH U Bahn (metro).
https://github.com/TravelMapping/RailwayData/pull/15/commits/efabe446010a5470e765f6ddb317785754e931c7
https://tmrail.teresco.org/hb/?u=michih&sys=deuhhs
It's different for long-distance services which usually have one stop per city / town only. I don't have such route in Germany though.
-
I do still sit in the 'let's map the routes by infrastructure, not by service' boat. I found several supporters on that last year: panda80, bubaclex and bartpetat. They agree with me that the service approach is not reasonable for Germany, Ex-Yugoslavia or Romania when talking about regional or national connections.
-
For the creation of the TM Railways manual, how much overlap is expected between this manual and the TM Highways manual? This answer will determine if we should have some PHP conditions, like we do for the main web front end code, for the manual, or if an entirely new set of files should be created.
-
What's currently proposed is a completely separate document. Not sure where opportunity for overlap would be.
-
What's currently proposed is a completely separate document. Not sure where opportunity for overlap would be.
I'm thinking of things like the information on formats of files, "how to become a data manager", etc. But if it's substantially different overall structure and limited content overlap, it's probably not worth trying to create and maintain a common version with conditions to show differences.
-
I'm thinking of things like the information on formats of files, "how to become a data manager", etc. But if it's substantially different overall structure and limited content overlap, it's probably not worth trying to create and maintain a common version with conditions to show differences.
Oh I was thinking just of the manual outlining the rules of what is or isn't included and how things are drafted, which is all that's atop this thread.
The "how to participate" page... most of the verbiage can probably be reused, though it does still need to be altered to reflect rail vs. road.
I still think it's probably easier to just have a separate copy of the page though, rather than trying to make it morph itself depending on which subdomain calls it up.
-
Question on the tiers as I'm starting to draft things up, why are tourist/heritage railroads tier 2? At least in the US they're not very long and function more like a Tier 4/5 type system (as least as I conceptualize it).
{snip}
Tourist/heritage railroads in the US are usually not "urban" in nature and are FRA-regulated the same as commuter railroads and Amtrak are.
And, well, look at the type of equipment they use: fullsize locomotives pulling fullsizes coaches. That resembles what commuter railroads use. It does not resemble a subway, light rail, streetcar, or people move at all.
I would be very against moving heritage railroads down from tier 2 broadly, however if a particular heritage railroad does not meet what I described above (e.g. narrow gauge, smaller equipment) then I could see it being placed in tier 4 or 5 instead.
Actually, there are a few heritage light rail (trolley) lines in the US. Examples include the East Troy Electric Railroad (Milwaukee area) and the Seashore Trolley Museum in Maine, which both utilize isolated remnants of local trolley systems. There is also the Baltimore Streetcar Museum, which runs on a rebuilt segment of the former Maryland & Pennsylvania (Ma & Pa).
-
Quite often the bigger European tram systems run a heritage line as part of their operations.
And there's also the old vehicles on the F Markets and Wharves line in San Francisco