kunsi / package-hafas Goto Github PK

The current code assumes we always have an exact match or none at all.

In big cities (think, Berlin) all the bus lines are using a common colour, only some lines get special handling.

The ideal solution would be (i think) to check for an exact match first, if none exists check for a type match (aka "buses in VBB get this colour"), if that also doesn't exist fall back to either a default colour or the current computational logic.

(Keep in mind that some lines are inverted, aka white background with coloured line number, for example all ICE lines at DB, so we might need to rework the code altogether to include font colours as well.)

It would be nice if this package would not only support HAFAS, but also some other common API flavours.

• HVV (Hamburg) uses "Geofence": https://www.hvv.de/de/fahrplaene/abruf-fahrplaninfos/datenabruf
• KVV (Karlsruhe) uses "TRIAS": https://www.kvv.de/fahrplan/fahrplaene/open-data.html
• VRN (Rhein-Neckar and Südwestpfalz) uses "TRIAS" or "RapidJSON": https://www.vrn.de/opendata/API

It would be nice if this could be used as a plugin for the scheduled-player package.

Many conferences are next to some public transport stops, so it would be nice to be able to also show departures from those stations in the usual rotation.

For example, multiple ICE lines running together for some time.

The current code simply ignores everything apart from the first product.

Currently we only display the departure (or arrival) stop for a given service when more than one stop is given in the config file. However, larger stations may have multiple services departing from different parts of the station (e.g. S-Bahn, U-Bahn, a bus stop outside the station building), each with their own stop ID's, which are merged into a single stop by the API. This could lead to some confusion if it's not clear which part of the station different services depart from, especially if platform numbers get re-used by different services.

We should change the logic for displaying multiple stop names to account for the different stop names returned by the API instead of what's returned in the configuration file.

(The motivating example for this issue is Bahnhof Berlin-Lichtenberg. The S-Bahn and U-Bahn both depart from platforms 1 and 2, but the U-Bahn platforms are in a different part of the station and have a different stop ID and name.)

https://info-beamer.com/doc/package-services#scratchdirectory

There's a lot of duplicate code due to us differentiating between "less than 10 minutes into the future" and "more than 10 minutes into the future".

We should probably get rid of that duplicate code. I'd be willing to get rid of the differentiation altogether, if deduplication is too difficult otherwise.

PR #5 introduces HAFASEvent.id, which could be used to determine if departures are listed multiple times. This would remove the need to have a lot of the logic we currently have for detecting duplicates.

Ideally, we'd have two modes of duplicate detection:
a) Only show the first event (depending on departure/arrival time)
b) Prioritize stops according to their order in stop_ids, so if a journey travels through multiple stops, the event gets prioritized by the order of stop_ids, so listing a stop earlier will prioritize it.