Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mk-fg opened this issue Sep 9, 2017 · 8 comments
Closed

Comments

@mk-fg
Copy link
Contributor

mk-fg commented Sep 9, 2017

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.

@mk-fg
Copy link
Contributor Author

mk-fg commented Sep 9, 2017

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.

@linusnorton
Copy link
Collaborator

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.

@mk-fg
Copy link
Contributor Author

mk-fg commented Sep 10, 2017

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.

linusnorton added a commit that referenced this issue Sep 10, 2017
@mk-fg
Copy link
Contributor Author

mk-fg commented Sep 10, 2017

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?

@linusnorton
Copy link
Collaborator

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.

@linusnorton
Copy link
Collaborator

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

@mk-fg
Copy link
Contributor Author

mk-fg commented Sep 10, 2017

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?

@mk-fg
Copy link
Contributor Author

mk-fg commented Sep 10, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants