Maybe this is obvious to you, but I only noticed recently (or rather, was made to notice) that a single trip may have multiple HAFAS tripIds (at least in DB HAFAS)... This may somehow be related to train splitting/merging or changing train numbers or international trains, but it's not only at the place where it splits. And I think this only really gets surfaced on the arrival/departure boards. For instance, RE 1 departing 19:19 from Koblenz Hbf today will have two different tripIDs toggling over the entire trip until Trier Hbf. On the arrival boards (e.g. /stops/8001340/arrivals?when=2024-07-24T17%3A52%3A00, the id will be:
2|#VN#1#ST#1721675456#PI#0#ZI#275247#TA#0#DA#240724#1S#8000206#1T#1919#LS#8000134#LT#2040#PU#80#RT#1#CA#RE#ZE#4342#ZB#RE 4342#PC#3#FR#8000206#FT#1919#TO#8000134#TT#2040#
On the departure boards (e.g. /stops/8001340/departures?when=2024-07-24T17%3A53%3A00), the id will be:
2|#VN#1#ST#1721675456#PI#0#ZI#1682887#TA#0#DA#240724#1S#8000206#1T#1919#LS#8200100#LT#2129#PU#80#RT#1#CA#RE#ZE#4342#ZB#RE 4342#PC#3#FR#8000206#FT#1919#TO#8200100#TT#2129#
An that is the case on all stops from Koblenz until Trier. This is already the case in the raw HAFAS response, so nothing that we can fix (but maybe understand why/when this occurs?)
Since I do need to identify trips, I now tentatively switched to a combination of line.id and line.fahrtNr and only fall back to tripId if these are not set. This may be (more?) brittle, in particular since I think usually the fahrtNr will be reused every day.
In that context it may be useful to expose trainStartDate (representing the date when the trip started) from the HAFAS response in hafas-client, because then at least in theory with the combination of these three attributes one could uniquely identify a trip again. I could make a PR that adds that field, but I was wondering how the procedure is regarding adding random fields without them being present in the FPTF "standard".
Maybe this is obvious to you, but I only noticed recently (or rather, was made to notice) that a single trip may have multiple HAFAS tripIds (at least in DB HAFAS)... This may somehow be related to train splitting/merging or changing train numbers or international trains, but it's not only at the place where it splits. And I think this only really gets surfaced on the arrival/departure boards. For instance, RE 1 departing 19:19 from Koblenz Hbf today will have two different tripIDs toggling over the entire trip until Trier Hbf. On the arrival boards (e.g.
/stops/8001340/arrivals?when=2024-07-24T17%3A52%3A00, the id will be:2|#VN#1#ST#1721675456#PI#0#ZI#275247#TA#0#DA#240724#1S#8000206#1T#1919#LS#8000134#LT#2040#PU#80#RT#1#CA#RE#ZE#4342#ZB#RE 4342#PC#3#FR#8000206#FT#1919#TO#8000134#TT#2040#On the departure boards (e.g.
/stops/8001340/departures?when=2024-07-24T17%3A53%3A00), the id will be:2|#VN#1#ST#1721675456#PI#0#ZI#1682887#TA#0#DA#240724#1S#8000206#1T#1919#LS#8200100#LT#2129#PU#80#RT#1#CA#RE#ZE#4342#ZB#RE 4342#PC#3#FR#8000206#FT#1919#TO#8200100#TT#2129#An that is the case on all stops from Koblenz until Trier. This is already the case in the raw HAFAS response, so nothing that we can fix (but maybe understand why/when this occurs?)
Since I do need to identify trips, I now tentatively switched to a combination of
line.idandline.fahrtNrand only fall back totripIdif these are not set. This may be (more?) brittle, in particular since I think usually thefahrtNrwill be reused every day.In that context it may be useful to expose
trainStartDate(representing the date when the trip started) from the HAFAS response in hafas-client, because then at least in theory with the combination of these three attributes one could uniquely identify a trip again. I could make a PR that adds that field, but I was wondering how the procedure is regarding adding random fields without them being present in the FPTF "standard".