Skip to content

BayesianBahn 0.2.0

Choose a tag to compare

@github-actions github-actions released this 24 Aug 18:47
· 64 commits to main since this release

Added

  • A German interface, used on a phone set to German; English stays the default
    and the fallback. Every text the app shows is now a translatable resource,
    including the failures raised while planning a journey, which used to be
    written out in English deep in the planner. Android 13 and newer can set the
    language for this app alone.
  • The forecast collector polls a second tier of stations: where the trains
    leaving the twenty pre-registered ones end up. A journey with a change ends
    at the far end of the second leg, IRIS serves forecasts one station at a
    time, and without a reading there DB's answer for that arrival cannot be had
    at all — which is why the evaluation could score the parts of a two-leg
    journey but never the journey. The tier is derived from the timetable rather
    than chosen (tools/build_destinations.py), it is recorded per poll so a
    later edit to the station files cannot re-label data already collected, and
    it never originates a scored arrival or connection: the pre-registered set is
    unchanged. Each departure's whole onward path is now kept as well; only its
    next stop was, which is what made the far end unrecoverable after the fact.

Changed

  • DB's live number is only used when it reports a delay. DB states a stop
    in four shapes and three of them mean "on time"; only one is an observation.
    Over seven collected days, DB called a train on time for 69% of stops ten
    minutes before departure and 99% of stops three hours out — and 26% of that
    last group arrived more than two minutes late. Reports of "early" are ignored
    on the same grounds: those trains averaged 1.0 minute late. Measured over the
    first three days, anchoring the forecast on that number cost 0.53 minutes of
    CRPS on trains that have history and left the stated 80% range covering 55%
    of arrivals; with the rule in place that range covers 78-89% of arrivals,
    day by day. The app will now disagree with the platform display for most
    trains, and the prediction screen says why.
  • The connection model applies the same rule to a live departure report. It
    had been treating one as fact — reported later than the passenger can arrive
    meant missed, otherwise caught, with no distribution in between — so a train
    with a history of leaving late became a certainty on the strength of a
    restated timetable.
  • The evaluation report shows the distribution of the errors, not only their
    averages: a box plot per lead-time bucket and the tail as figures. The
    medians of the two forecasts are close and the difference between them is in
    the large errors, which an average cannot show. With a weekend in the data it
    also splits working days from the weekend, which had been a caveat it could
    not check: DB's own mean error is 3.14 minutes from Monday to Friday against
    1.84 at the weekend, so the two are different problems.
  • Over the seven days published in
    the evaluation, this
    release scores 0.523 minutes of CRPS below DB's own forecast (95% interval
    0.489 to 0.556) across 121,395 predictions, and 0.211 Brier below it on the
    7,246 connections that were actually missed. Without the rule above the same
    model is 0.310 below DB on arrivals and cannot be separated from it on missed
    connections at all. Two caveats travel with those numbers: seven days is a
    small sample for something that clusters by line and by incident, and every
    feasible change counts as a connection, including ones nobody would make.

Fixed

  • The English interface says "Platform" where it said "Gl." — the German
    abbreviation for Gleis. It had been hardcoded in two screens since long
    before there was a German translation for it to belong to, and the
    extraction into resources carried it across faithfully.
  • A forecast drawn from a single past run no longer reads "1 past runs". Both
    sentences that count runs are plurals now, in both languages, and so is the
    effective-run count one of them ends on — a plural chooses on one number,
    and either of those two can be 1. The English wording carried this from the
    start; translating it is what made it visible.