Times for splitting train at split-association stop set from incorrect fields

Question

Times for splitting train at split-association stop set from incorrect fields

Closed this issue 7 years ago · 8 comments

Looking at W34496_W34952 association with pre-latest timetable data (ttis653.zip):
https://gist.github.com/mk-fg/93a5acda3e710d215665d2a7657dcef5

For date 2017-09-10:

cif schedules/stops:
  ...
  W34496  110466 O 2017-09-10 2017-09-10 ......7 A GRT 13:42 13:43 T
  W34496  110466 O 2017-09-10 2017-09-10 ......7 A SAL 13:56 13:57 T
  W34496  110466 O 2017-09-10 2017-09-10 ......7 A TIS 14:11 14:11 T
  ...
  W34952  110619 O 2017-09-10 2017-09-10 ......7 A SAL --:-- 13:55 TB
  W34952  110619 O 2017-09-10 2017-09-10 ......7 A WMN 14:14 14:15 T
  ...
cif associations:
  ...
  W34496 W34952 1023 N VV - SAL 2017-09-10 2017-09-10 ......7
  ...
gtfs trips:
  [110619] headsign=W34496_W34952 svc=284 svc_days=1:
    <TS ......7 [2017-09-10 2017-09-10] {}>
    stop sequence:
      ...
      GRT 13:42 13:43 PD
      SAL 13:56 13:56 PD
      WMN 14:14 14:15 PD
      ...

southeasternrailway.co.uk has (or had) 13:55 as a departure time for that SAL stop, which seem to make sense here - it looks like W34952 might split from W34496 before latter makes public stop, hence public arrival for W34496 is after W34952.

Which is why I think in case of splitting trains, it'd seem to be more correct to only use arrival/departure times of the splitting part on that stop, completely ignoring times for other - potentially already separated - part, and not combine arrival/departure like it's currently done.

Answer 1 · 2017-09-09T16:34:16.000Z

Same thing repeats for W34557_W34958 association of likely same trains, apparently splitting at the same stop in similar fashion later in the day:
https://gist.github.com/mk-fg/b22916dfb3007dba643df4f4c0657e58

EDIT: and in many other places actually - definitely mismatch in how times are handled, not underlying data.

Answer 2 · 2017-09-10T09:03:24.000Z

I believe it's because I'm only storing one time (public if it's available, scheduled if not) the arrival of the W34557 at SAL is 13:56 and therefore the W34557_W34958 cannot depart SAL at 13:55 as it's departure time would be earlier than the arrival time.

I guess I could just always assume that the first stop of the assoc service will always have the correct time but then the arrival time will always be inaccurate as the first stop of any service never has an arrival time.

Answer 3 · 2017-09-10T09:16:39.000Z

Btw, southeasternrailways api only returns one time for stops, which matches departure times, so those are the only ones that get checked.
If arrival times are inaccurate, they'd never be reported like that, unfortunately.

Answer 4 · 2017-09-10T09:18:47.000Z

always be inaccurate

Guess that'd be only different if splits can happen after the public stop, in which case setting arrivals from base train will sometimes be accurate.
I don't know enough about railways, but can that be the case?
Or maybe trains always separate before boarding/unloading passengers?

Answer 5 · 2017-09-10T09:19:59.000Z

But of an ugly fix, but I've changed the behaviour so that it uses the arrival and departure time of the assoc schedule stop if my merge doesn't make sense.

Answer 6 · 2017-09-10T09:21:14.000Z

As far as I know passengers are always allowed off the train before and split or join happens

Answer 7 · 2017-09-10T09:22:55.000Z

As far as I know passengers are always allowed off the train before and split or join happens

Hmm, that's interesting, looks like a mismatch/bug in the atoc data then, or how'd there be an arrival time before departure then?

Answer 8 · 2017-09-10T09:23:40.000Z

And setting minimal departure time in this case sounds like a safer fix, indeed.