←back to thread

232 points ksajadi | 2 comments | | HN request time: 0s | source
Show context
phkahler ◴[] No.45139746[source]
It'd be pretty cool if busses and trains were local-first.
replies(2): >>45139769 #>>45140090 #
gjsman-1000 ◴[] No.45139769[source]
If you can't send updated schedules or emergency alerts through the system, I also don't want service started. It doesn't have to be an individualized problem to render local-first useless.

Also, what do you mean by trains being local-first? Trains by definition need to share the same tracks with catastrophic consequences for getting it wrong. You can't figure out if a train is going to possibly be on the same route locally, or if your route has been obstructed. Somebody gets a schoolbus stuck on a crossing, it takes over a mile to stop a train.

replies(5): >>45139826 #>>45140427 #>>45140633 #>>45140774 #>>45144247 #
zahlman ◴[] No.45139826[source]
>If you can't send updated schedules or emergency alerts through the system, I also don't want service started.

In the days before systems existed for publishing such schedules and emergency alerts, should public transit service not have been attempted at all?

> Trains by definition need to share the same tracks with catastrophic consequences for getting it wrong.

Just because it uses the same rail gauge as intercity freight doesn't require it to run on the same set of tracks. But if it did, I assume "local-first" entails other traffic just being excluded when an emergency in the local system necessitates it.

replies(6): >>45139832 #>>45139985 #>>45140030 #>>45140111 #>>45140165 #>>45140195 #
wrs ◴[] No.45140030[source]
You can go down a very deep rabbit hole learning about the history of train signaling. Trains and subways have had centralized signaling for…I’d have to look it up, but 100 years surely? It’s the only way to safely have more than one train running at a time (i.e., sharing the track) with a dense schedule. The “local first” procedure when it fails is to radically reduce service and slow down the trains.

Wikipedia has a good survey [0].

[0] https://en.wikipedia.org/wiki/Railway_signalling

replies(3): >>45140691 #>>45140782 #>>45140822 #
1. jsmith45 ◴[] No.45140691[source]
Block based automated signaling can technically be implemented as a primarily local system. Each block needs to know if there is a train in itself block (in which case all block entrance signals must show stop, and approach signals indicate that they can be entered, but the train must be slowing, so it can come to a stop by the block entrance signal). It must also know about a few preceeding blocks for each path leading into it, so as to know which contain trains that might be trying to enter this block, so it can select at most one to be given the proceed signal, and others to be told to brake to stop in time for the entrance signal. While it is nice if it knows the intended routes of each train so it can favor giving the proceed indicator to a train that actually wants to enter it, but if it lacks that information, then giving the indication to a train that will end up using points to take a different path doesn't hurt safety, just efficiency.

Of course, centralized signaling is better, allowing for greater efficiency, helps dispatch keep track better track of the trains, makes handling malfunctioning signals a lot safer, among many other benefits. But it doesn't mean local signaling can't be done.

replies(1): >>45141560 #
2. wrs ◴[] No.45141560[source]
Yes, block based signaling is what I interpreted “local first” to mean in this context. It works, but it slows everything way down.

I don’t know, but I would imagine, there’s still a block based setup as a failsafe backup in most or all modern rail systems.