Transfer hub strategy - Revision history

Hannibal at 21:10, 5 December 2022

2022-12-05T21:10:42Z

← Older revision		Revision as of 21:10, 5 December 2022
Line 12:		Line 12:
	Consider network (2), and assume 2tph and exact 1h travel time between all nodes. Let's run red and yellow form X on quarters (00/30 + 15/45). Consider then two options for the other lines from P: either quarters as well, or quarters+7.5 (7.5,22.5,37.5,52.5). The shifted times will result in a 7.5m frequency between Y and Z. You may need this if that's very busy. But, you lose the realtime transfer in Y and Z. The lost time here is more than 7.5m - up to 15m theoretically!		Consider network (2), and assume 2tph and exact 1h travel time between all nodes. Let's run red and yellow form X on quarters (00/30 + 15/45). Consider then two options for the other lines from P: either quarters as well, or quarters+7.5 (7.5,22.5,37.5,52.5). The shifted times will result in a 7.5m frequency between Y and Z. You may need this if that's very busy. But, you lose the realtime transfer in Y and Z. The lost time here is more than 7.5m - up to 15m theoretically!

	[[Category:~~Guides~~]]		[[Category:Guide]]

Hannibal at 21:10, 5 December 2022

2022-12-05T21:10:34Z

← Older revision		Revision as of 21:10, 5 December 2022
Line 11:		Line 11:
	===Optimal same-time transfers sacrifice effective frequency on the core track ===		===Optimal same-time transfers sacrifice effective frequency on the core track ===
	Consider network (2), and assume 2tph and exact 1h travel time between all nodes. Let's run red and yellow form X on quarters (00/30 + 15/45). Consider then two options for the other lines from P: either quarters as well, or quarters+7.5 (7.5,22.5,37.5,52.5). The shifted times will result in a 7.5m frequency between Y and Z. You may need this if that's very busy. But, you lose the realtime transfer in Y and Z. The lost time here is more than 7.5m - up to 15m theoretically!		Consider network (2), and assume 2tph and exact 1h travel time between all nodes. Let's run red and yellow form X on quarters (00/30 + 15/45). Consider then two options for the other lines from P: either quarters as well, or quarters+7.5 (7.5,22.5,37.5,52.5). The shifted times will result in a 7.5m frequency between Y and Z. You may need this if that's very busy. But, you lose the realtime transfer in Y and Z. The lost time here is more than 7.5m - up to 15m theoretically!

			[[Category:Guides]]

Hannibal at 20:41, 5 December 2022

2022-12-05T20:41:09Z

← Older revision		Revision as of 20:41, 5 December 2022
Line 1:		Line 1:
	Here are some of the theoretical trade-offs to think about when timetabling a realistic long distance network with core/periphery portions, overlapping lines and transfers.		Here are some of the theoretical trade-offs to think about when timetabling a realistic long distance network with core/periphery portions, overlapping lines and transfers.

			[[File:Transfer hub strategy.png\|500px\|thumb\|center\|Three example networks]]

	===IRL networks are rarely optimal in game, because pax do not penalise transfers ===		===IRL networks are rarely optimal in game, because pax do not penalise transfers ===
Line 9:		Line 11:
	===Optimal same-time transfers sacrifice effective frequency on the core track ===		===Optimal same-time transfers sacrifice effective frequency on the core track ===
	Consider network (2), and assume 2tph and exact 1h travel time between all nodes. Let's run red and yellow form X on quarters (00/30 + 15/45). Consider then two options for the other lines from P: either quarters as well, or quarters+7.5 (7.5,22.5,37.5,52.5). The shifted times will result in a 7.5m frequency between Y and Z. You may need this if that's very busy. But, you lose the realtime transfer in Y and Z. The lost time here is more than 7.5m - up to 15m theoretically!		Consider network (2), and assume 2tph and exact 1h travel time between all nodes. Let's run red and yellow form X on quarters (00/30 + 15/45). Consider then two options for the other lines from P: either quarters as well, or quarters+7.5 (7.5,22.5,37.5,52.5). The shifted times will result in a 7.5m frequency between Y and Z. You may need this if that's very busy. But, you lose the realtime transfer in Y and Z. The lost time here is more than 7.5m - up to 15m theoretically!

	~~[[File:Transfer hub strategy.png\|500px\|thumb\|center\|Three example networks]]~~

Hannibal at 20:40, 5 December 2022

2022-12-05T20:40:56Z

← Older revision		Revision as of 20:40, 5 December 2022
Line 10:		Line 10:
	Consider network (2), and assume 2tph and exact 1h travel time between all nodes. Let's run red and yellow form X on quarters (00/30 + 15/45). Consider then two options for the other lines from P: either quarters as well, or quarters+7.5 (7.5,22.5,37.5,52.5). The shifted times will result in a 7.5m frequency between Y and Z. You may need this if that's very busy. But, you lose the realtime transfer in Y and Z. The lost time here is more than 7.5m - up to 15m theoretically!		Consider network (2), and assume 2tph and exact 1h travel time between all nodes. Let's run red and yellow form X on quarters (00/30 + 15/45). Consider then two options for the other lines from P: either quarters as well, or quarters+7.5 (7.5,22.5,37.5,52.5). The shifted times will result in a 7.5m frequency between Y and Z. You may need this if that's very busy. But, you lose the realtime transfer in Y and Z. The lost time here is more than 7.5m - up to 15m theoretically!

	[[File:Transfer hub strategy.png]]		[[File:Transfer hub strategy.png\|500px\|thumb\|center\|Three example networks]]

Hannibal at 20:40, 5 December 2022

2022-12-05T20:40:17Z

← Older revision		Revision as of 20:40, 5 December 2022
Line 1:		Line 1:
	Here are some of the theoretical trade-offs to think about when timetabling a realistic long distance network with core/periphery portions, overlapping lines and transfers.		Here are some of the theoretical trade-offs to think about when timetabling a realistic long distance network with core/periphery portions, overlapping lines and transfers.

	IRL networks are rarely optimal in game, because pax do not penalise transfers IRL long distance mainline rail networks often look like example 1 in the picture with lots of point to point lines at low frequencies. In the game, this design is less successful, because pax just turn up and don't plan their trip in advance to coincide with the timetable. For example if all lines are 1tph, for three quarters of the hour, passengers from X to anywhere will just hop on the first train to Y for a transfer. So all point to point lines end up carrying 75% transfer traffic and not much point to point at all. And all your stations will be full with transfer passengers, up to the 10k limit depending on how big your build is.		===IRL networks are rarely optimal in game, because pax do not penalise transfers ===
			IRL long distance mainline rail networks often look like example 1 in the picture with lots of point to point lines at low frequencies. In the game, this design is less successful, because pax just turn up and don't plan their trip in advance to coincide with the timetable. For example if all lines are 1tph, for three quarters of the hour, passengers from X to anywhere will just hop on the first train to Y for a transfer. So all point to point lines end up carrying 75% transfer traffic and not much point to point at all. And all your stations will be full with transfer passengers, up to the 10k limit depending on how big your build is.

	~~Just as IRL, the~~ optimal transfer is a real-time transfer between two trains stopped at the same time in the same station In this way trains can exchange passengers in both directions. This will require a reasonably long stop time (2-3 minutes) as in IRL which is partially but not fully overlapping. (Fully overlapping would mean all trains want to enter and exit at the same time, which will lead to signalling delays). This is also the effective answer to the 10k pax limit: a train inside a station can also warehouse passengers.		===The optimal transfer is a real-time transfer between two trains stopped at the same time in the same station===
			In this way trains can exchange passengers in both directions. This will require a reasonably long stop time (2-3 minutes) as in IRL which is partially but not fully overlapping. (Fully overlapping would mean all trains want to enter and exit at the same time, which will lead to signalling delays). This is also the effective answer to the 10k pax limit: a train inside a station can also warehouse passengers.

	Optimal same-time transfers sacrifice effective frequency on the core track Consider network (2), and assume 2tph and exact 1h travel time between all nodes. Let's run red and yellow form X on quarters (00/30 + 15/45). Consider then two options for the other lines from P: either quarters as well, or quarters+7.5 (7.5,22.5,37.5,52.5). The shifted times will result in a 7.5m frequency between Y and Z. You may need this if that's very busy. But, you lose the realtime transfer in Y and Z. The lost time here is more than 7.5m - up to 15m theoretically!		===Optimal same-time transfers sacrifice effective frequency on the core track ===
			Consider network (2), and assume 2tph and exact 1h travel time between all nodes. Let's run red and yellow form X on quarters (00/30 + 15/45). Consider then two options for the other lines from P: either quarters as well, or quarters+7.5 (7.5,22.5,37.5,52.5). The shifted times will result in a 7.5m frequency between Y and Z. You may need this if that's very busy. But, you lose the realtime transfer in Y and Z. The lost time here is more than 7.5m - up to 15m theoretically!

	[[File:Transfer hub strategy.png]]		[[File:Transfer hub strategy.png]]

Hannibal at 20:39, 5 December 2022

2022-12-05T20:39:36Z

← Older revision		Revision as of 20:39, 5 December 2022
Line 6:		Line 6:

	Optimal same-time transfers sacrifice effective frequency on the core track Consider network (2), and assume 2tph and exact 1h travel time between all nodes. Let's run red and yellow form X on quarters (00/30 + 15/45). Consider then two options for the other lines from P: either quarters as well, or quarters+7.5 (7.5,22.5,37.5,52.5). The shifted times will result in a 7.5m frequency between Y and Z. You may need this if that's very busy. But, you lose the realtime transfer in Y and Z. The lost time here is more than 7.5m - up to 15m theoretically!		Optimal same-time transfers sacrifice effective frequency on the core track Consider network (2), and assume 2tph and exact 1h travel time between all nodes. Let's run red and yellow form X on quarters (00/30 + 15/45). Consider then two options for the other lines from P: either quarters as well, or quarters+7.5 (7.5,22.5,37.5,52.5). The shifted times will result in a 7.5m frequency between Y and Z. You may need this if that's very busy. But, you lose the realtime transfer in Y and Z. The lost time here is more than 7.5m - up to 15m theoretically!

	[[File:Transfer hub strategy.png]]		[[File:Transfer hub strategy.png]]

Hannibal: Created page with "Here are some of the theoretical trade-offs to think about when timetabling a realistic long distance network with core/periphery portions, overlapping lines and transfers. IRL networks are rarely optimal in game, because pax do not penalise transfers IRL long distance mainline rail networks often look like example 1 in the picture with lots of point to point lines at low frequencies. In the game, this design is less successful, because pax just turn up and don't plan t..."

2022-12-05T20:39:31Z

Created page with "Here are some of the theoretical trade-offs to think about when timetabling a realistic long distance network with core/periphery portions, overlapping lines and transfers. IRL networks are rarely optimal in game, because pax do not penalise transfers IRL long distance mainline rail networks often look like example 1 in the picture with lots of point to point lines at low frequencies. In the game, this design is less successful, because pax just turn up and don't plan t..."

New page

Here are some of the theoretical trade-offs to think about when timetabling a realistic long distance network with core/periphery portions, overlapping lines and transfers.

IRL networks are rarely optimal in game, because pax do not penalise transfers IRL long distance mainline rail networks often look like example 1 in the picture with lots of point to point lines at low frequencies. In the game, this design is less successful, because pax just turn up and don't plan their trip in advance to coincide with the timetable. For example if all lines are 1tph, for three quarters of the hour, passengers from X to anywhere will just hop on the first train to Y for a transfer. So all point to point lines end up carrying 75% transfer traffic and not much point to point at all. And all your stations will be full with transfer passengers, up to the 10k limit depending on how big your build is.

Just as IRL, the optimal transfer is a real-time transfer between two trains stopped at the same time in the same station In this way trains can exchange passengers in both directions. This will require a reasonably long stop time (2-3 minutes) as in IRL which is partially but not fully overlapping. (Fully overlapping would mean all trains want to enter and exit at the same time, which will lead to signalling delays). This is also the effective answer to the 10k pax limit: a train inside a station can also warehouse passengers.

Optimal same-time transfers sacrifice effective frequency on the core track Consider network (2), and assume 2tph and exact 1h travel time between all nodes. Let's run red and yellow form X on quarters (00/30 + 15/45). Consider then two options for the other lines from P: either quarters as well, or quarters+7.5 (7.5,22.5,37.5,52.5). The shifted times will result in a 7.5m frequency between Y and Z. You may need this if that's very busy. But, you lose the realtime transfer in Y and Z. The lost time here is more than 7.5m - up to 15m theoretically!
[[File:Transfer hub strategy.png]]