Dosenpfand
commented
7 months ago First and foremost thanks for your feedback!
It bothers me a bit that the determined price for a connection in the travel journal doesn't necessary reflect the actual cost and, therefore, the Klimaticket gains may not be correct. Over a year, small differences might sum up to a larger amount.
You are totally right, the price determination is not the most accurate. It was designed with 3 goals in mind: being simple, fast and not causing too much load on ÖBB servers.
Currently, as far as I understand it, the price is calculated per origin and destination only once per user session
It's even more primitive than that. The price is only calculated once globally and then cached for a certain amount of time until it is updated in the background. This has the advantage that after the first query for a start and destination, the price should always be available instantaneously, considering that the ÖBB API is quite slow.
A simple enhancement would be to extend the date input field with a time, so users can indicate when they plan to or actually started traveling from the origin. This date and time would then have to be included in the price search (which the oebb.py util file already supports).
This change would indeed be quite simple, but increase the load on the ÖBB API as well as the wait times for users.
The more complicated change would be adding support connections for which no tickets can be bought for the whole distance between origin and destination via the ÖBB website. This would apply to Westbahn connections, for example. Using a different API could solve this problem as well, but I'm not sure which to use. For example, the VAO platform that concentrates public transit for the whole of Austria in one database supports pricing information for connections, but this only seems to work when no more than one Verkehrsverbund is concerned.
I didn't know about VAO, I will definitely check it out. If it has a suitable API it could be integrated into zug.lol.
Currently, I do not have much time to implement new features for zug.lol, but I would be happy to review and merge contributions if the stick more or less to the initial design goals.
It bothers me a bit that the determined price for a connection in the travel journal doesn't necessary reflect the actual cost and, therefore, the Klimaticket gains may not be correct. Over a year, small differences might sum up to a larger amount.
Currently, as far as I understand it, the price is calculated per origin and destination only once per user session, and doesn't really take into account even the date that is entered in the journey form. However, there is a difference depending on which connection one takes (e.g. a slower one over a longer distance, a bus instead of a train, or Westbahn instead of ÖBB).
A simple enhancement would be to extend the date input field with a time, so users can indicate when they plan to or actually started traveling from the origin. This date and time would then have to be included in the price search (which the
oebb.pyutil file already supports).The more complicated change would be adding support connections for which no tickets can be bought for the whole distance between origin and destination via the ÖBB website. This would apply to Westbahn connections, for example. Using a different API could solve this problem as well, but I'm not sure which to use. For example, the VAO platform that concentrates public transit for the whole of Austria in one database supports pricing information for connections, but this only seems to work when no more than one Verkehrsverbund is concerned.
The most powerful API I know of is provided by ÖBB of all things, in form of the wegfinder app, in which for one connection even multiple tickets for different legs using different transport operators can be bought:
Unfortunately, I'm not aware of any documentation of the API or any library using it... 😞 However, by implementing this issue, much of bullet point 1 of the whish list in #3 would be satisfied, because the concrete connection details could be stored in the database as well, not only the general origin, destination and price information.