Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Analyzing Caltrain Delays

svds.com

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Analyzing Caltrain Delays

#21

Post by ThrustVectoring »

mtviewdave wrote: post #19
dasil003 wrote: post #16

Earlier quoted context omitted.

Not if it still runs at-grade and keeps killing someone every few weeks.

It's not as if Caltrain is required to run at grade. It's just a historical artifact of how the system evolved. If we had the money and political will to replace Caltrain with BART, we'd have the money and will to create a grade-separated Caltrain. What would be the advantage of BART over electrified, grade-separated Caltrain? I'm hard-pressed to think of one, and there's definitely one major disadvantage: the nonsta…

It'd remove an onboarding/offboarding/payment stop at the Millbrae station.

Re: Analyzing Caltrain Delays

#22

Post by ZanyProgrammer »

dasil003 wrote: post #16
ZanyProgrammer wrote: post #8

Earlier quoted context omitted.

Electrified Caltrain is infinitely preferable to BART.

Not if it still runs at-grade and keeps killing someone every few weeks.

A lot of Caltrain suicides are the result of people stepping off platforms when Baby bullets pass through or trespassing on the tracks. Grade sep won't help that.

Re: Analyzing Caltrain Delays

#23

Post by lifestil »

mattcaywood wrote: post #18

Data scientists blog about Caltrain data, come up with convoluted hypothesis about bias in sensors at two stations. Commenter on blog notices that Caltrain is occasionally single-tracking between those stations due to a bridge replacement. [1] "Data science" ends up with a bloody neck from Occam's razor. [1] http://www.caltrain.com/projectsplans/Projects/Caltrain_Capi...

'"Data science" ends up with a bloody neck from Occam's razor.'

Heh, I like the imagery. I wouldn't really call it Data Science with capital letters either. It's just plain-old exploratory analysis.

I wouldn't say the hypothesis is convoluted, especially since we see bizarre data coming out of Caltrain API at times, and experience has taught us to distrust our instruments when observing strong systematic bias. But single-tracking due to construction IS obviously a better explanation... because it's probably true.

What is still confusing is that the train is delayed several minutes, but then recovers at the very next station. That is odd behavior for a train to 'make up' that much time so quickly. Typical behavior is just to keep getting later.

Or maybe Occam will strike again in the comments with an obviously correct explanation!

Re: Analyzing Caltrain Delays

#24

Post by mtviewdave »

ThrustVectoring wrote: post #21
mtviewdave wrote: post #19

Earlier quoted context omitted.

It's not as if Caltrain is required to run at grade. It's just a historical artifact of how the system evolved. If we had the money and political will to replace Caltrain with BART, we'd have the money and will to create a grade-separated Caltrain. What would be the advantage of BART over electrified, grade-separated Caltrain? I'm hard-pressed to think of one, and there's definitely one major disadvantage: the nonsta…

It'd remove an onboarding/offboarding/payment stop at the Millbrae station.

You don't need to replace Caltrain to achieve that. A easier solution would be to convert Caltrain to a gated fare system (like BART is now), and then put a combined BART and Caltrain station behind one set of turnstiles at Millbrae.

Re: Analyzing Caltrain Delays

#25

Post by ubernostrum »

mtviewdave wrote: post #24
ThrustVectoring wrote: post #21

Earlier quoted context omitted.

It'd remove an onboarding/offboarding/payment stop at the Millbrae station.

You don't need to replace Caltrain to achieve that. A easier solution would be to convert Caltrain to a gated fare system (like BART is now), and then put a combined BART and Caltrain station behind one set of turnstiles at Millbrae.

While we're at it, why the hell isn't there all-day, every-day direct service from Millbrae to SFO? Having a massive multi-transit-agency station right by the airport, only to tell people "nope, can't get there from here, you have to go to San Bruno and change trains" is just dumb.

Re: Analyzing Caltrain Delays

#26

Post by chiggins »

mattcaywood wrote: post #18

Data scientists blog about Caltrain data, come up with convoluted hypothesis about bias in sensors at two stations. Commenter on blog notices that Caltrain is occasionally single-tracking between those stations due to a bridge replacement. [1] "Data science" ends up with a bloody neck from Occam's razor. [1] http://www.caltrain.com/projectsplans/Projects/Caltrain_Capi...

Single-tracking should have a symmetric effect, i.e. the distribution of delay for both northbound and southbound trains through the track segment containing the bridge repair should both be positive. Instead, the southbound (and to a lesser extent the northbound) trains traveling through the segment actually have "negative delay"--completely inconsistent with the alternative hypothesis. You don't need data science to show that single-tracking doesn't explain the observed data--just common sense.

Re: Analyzing Caltrain Delays

#27

Post by jsweojtj »

mattcaywood wrote: post #18

Data scientists blog about Caltrain data, come up with convoluted hypothesis about bias in sensors at two stations. Commenter on blog notices that Caltrain is occasionally single-tracking between those stations due to a bridge replacement. [1] "Data science" ends up with a bloody neck from Occam's razor. [1] http://www.caltrain.com/projectsplans/Projects/Caltrain_Capi...

There are a couple of reasons that this isn't the explanation.

To pick one, the random data selection in the blog post showed data from October 2015 -- Feb 2016, and this Caltrain link appears to show the bridge work starting Feb 26th, 2016.

So, no the just-so story doesn't appear to be just-so.

Re: Analyzing Caltrain Delays

#28

Post by mtviewdave »

ubernostrum wrote: post #25
mtviewdave wrote: post #24

Earlier quoted context omitted.

You don't need to replace Caltrain to achieve that. A easier solution would be to convert Caltrain to a gated fare system (like BART is now), and then put a combined BART and Caltrain station behind one set of turnstiles at Millbrae.

While we're at it, why the hell isn't there all-day, every-day direct service from Millbrae to SFO? Having a massive multi-transit-agency station right by the airport, only to tell people "nope, can't get there from here, you have to go to San Bruno and change trains" is just dumb.

Every day direct BART service between SFO and Millbrae was the original intent, and they provided that level of service when the station opened. But ridership fell well below expectations, and BART eventually limited that service to nights and weekends only.

Re: Analyzing Caltrain Delays

#29

Post by nulltype »

avuserow wrote: post #15
nulltype wrote: post #10

Earlier quoted context omitted.

Why electrified vs normal caltrain? Will that decrease the variance or door to door time of using caltrain?

Faster acceleration. Each stop will cost less time, and Caltrain has a surprising amount of stops between SF-SJ (22 weekday) for its length (47 miles). You can see this effect already with the amount of express schedules that Caltrain has and their varying trip times.

Yeah I couldn't find any estimates about how much time though. It seems like the express train would not be affected much at all.

Re: Analyzing Caltrain Delays

#30

Post by jnty »

lifestil wrote: post #23
mattcaywood wrote: post #18

Data scientists blog about Caltrain data, come up with convoluted hypothesis about bias in sensors at two stations. Commenter on blog notices that Caltrain is occasionally single-tracking between those stations due to a bridge replacement. [1] "Data science" ends up with a bloody neck from Occam's razor. [1] http://www.caltrain.com/projectsplans/Projects/Caltrain_Capi...

'"Data science" ends up with a bloody neck from Occam's razor.' Heh, I like the imagery. I wouldn't really call it Data Science with capital letters either. It's just plain-old exploratory analysis. I wouldn't say the hypothesis is convoluted, especially since we see bizarre data coming out of Caltrain API at times, and experience has taught us to distrust our instruments when observing strong systematic bias. But si…

Train companies often put "buffer time" in schedules to make up for predictable delays like this one. That could show up as a train being late at one station then suddenly on time at the next. Could that be it?
Post reply on HN