Hacker News new | past | comments | ask | show | jobs | submit login

To review:

You said that delaying the start of the new line until PTC was installed seems pretty reasonable.

roywiggins replied that the line being replaced also didn't have PTC, so that switching to the new line meant swapping a line without PTC for another line without PTC, which is a net wash.

You replied "It's possible that this was just a horrible coincidence, but it seems more likely that something about the new line made it riskier. Maybe just the fact that the driver is less familiar with it?" I presume that you're still arguing here for waiting until PTC was installed.

I replied. Since you didn't seem to understand my reply, let me try again.

There are lots of things that could make a new line more dangerous. Some of them could be fixed by PTC. Some of them would not. So unless you know that the cause of the crash is something that PTC would have prevented, then "the new line is more dangerous" does not imply "wait for PTC".

Why is the new line more dangerous? Is it because it has a curve? The other line had far more. Is it because the new line had a curve that was lower speed than the rest of the line? It's possible that the other line had so many curves that there never was a place for fast running, and therefore that there never was a curve that you could be suckered into coming into too fast.

Is the new line more dangerous because people aren't familiar with it? Well, that's what months of training runs are for. (They did do months of training runs, didn't they?)

It's possible that the cause is a combination of all of this: A tight curve in the middle of a fast stretch, and engineers unfamiliar with the route ran into the curve too fast. If that's all true, then yes, PTC probably would have prevented the crash.

Also note that all this is hindsight. When making the decision to open the new line, was it obvious that the new line (without PTC) was more dangerous than the old line (also without PTC)? Probably not. If anything, I suspect that the thinking was that the new line would be less dangerous - it wouldn't be cluttered up with a bunch of freight trains, running on a line without PTC, where a mistake could squish a passenger train. So if the thinking in advance is that the new line is at least as safe, and plausibly safer, even without the safety equipment, why would you wait?




That's pure speculation with a million seemingly unfounded assumptions behind it.

My reasoning is pretty simple: since this crash happened on the very first run, and PTC would have prevented it, it looks probable that the danger of PTC-preventible crashes was substantially higher on the new line. I don't know about the reasons or causes or potential mitigations, I'm just looking at the outcome.

It is possible that it's just a horrible coincidence. But that's not the way to bet.

You're right that it's all hindsight. We can't go back in time and push back the opening of the new line or push forward the installation of PTC. What we can do is convert this hindsight into foresight for the next time.


> and PTC would have prevented it

Objection, your honor. Assumes facts not in evidence.

At the moment, it looks likely that your statement is correct. But I've seen at least one source claiming that the speed data (where they got the 81 MPH from) isn't continuous data, and therefore isn't necessarily reporting the speed from when the train entered the curve. Note well: I do not know the truth of this claim. (I also don't know the truth of the 81 MPH claim.)

We'll know if PTC would have prevented it when the NTSB produces some concrete conclusions. Until then, I think you're taking speculation and regarding it as concrete data.

You could be right, though. You could be right in every detail. But I think you're stating your case as if it's certain, and I don't think certainty is warranted yet.


Ah, I stand corrected. NTSB has already stated that the speed was 80 MPH as a confirmed fact.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: