Jon WorthToday and tomorrow I’m at #OpenTransport2025 in Wien. Friends and fellow regular rail travellers @moof @bovine3dom @maartje are also here. I’ll post as and when I can!
#OpenTransport2025 Yes ideas can happen in unlikely places. But to the person just scrolling on their phone while pissing at the urinal: that’s grim. Did you wash your phone too? 🤔
Talking to the @transitous people at #OpenTransport2025
One headache: data on international trains that is missing the other side of the border
My EN Dacia Hegyeshalom 🇭🇺 - Sighisoara 🇷🇴 is 1 train but shows as 2 on Transitous
Stefan Lindbohm@jon @transitous This can also be due to the EN actually technically being a coach group (kurswagen), or train that turns into a coach group. Often the carriers on either side don’t even have data on what happens outside their own country.
This is solved in MERITS with a lot of manual links in the form of ”at border station X, train number Y is to be linked with train number Z”
Even with perfect open data in each country (lol), any aggregation of international data needs this integration layer
@stefanlindbohm Yes, but having spoken to the @transitous people here, there are cases where *even with the same train number* the data is snipped at the border. Hungary and Romania are apparently notable for this.
@jon @transitous Yeah, because each country have only its own data. That’s where the integration needs to happen. The manual case is maybe not the main one, but the point of integration processes still stands.
@jon @transitous The crucial thing to regulate is that the open data needs to include the border point in the schedules from both sides (not for example the last passenger station before). Then integration will be possible.
@stefanlindbohm so @transitous would that work? Could train number & station (gr.) be used as means to combine?
Cycling on Rails@stefanlindbohm @jon @transitous but (presumably?) one can buy a single ticket for the whole night train journey, and if so that ticket would (very likely) be purchaseable directly at one (or both) of the operators. Meaning the operators must know about each other's data to some extent, no?
(Maybe only the ticketing department has access not the timetable department, maybe only ticket counters have access not the website, but that's all a question of data management *within* an operator, no?)
@cycling_on_rails @stefanlindbohm @transitous the operators have it. But the GTFS files are incomplete. Merits has it, correctly, too.
@jon @stefanlindbohm @transitous So "each country has only its own data" means each country *publishes* only its own data in GTFS, right?
@jon @cycling_on_rails @transitous Merits has it because of the integration process that is run on input data from each country. The input data is in this regard similar to what NAP’s give for each country.
Martin Hoffmann@stefanlindbohm @jon @cycling_on_rails @transitous I imagine the NeTEx data might be better in this regard and more suitable for integration work?
@partim Yep. NeTEx is hell to work with, but it does support A LOT richer data. Like for example marking a scheduled point as a non-passenger border crossing.
@cycling_on_rails Well, it kinda depends. Each operator’s sales systems might have data about the other country because that system use Merits data (after integration with the other countries). I don’t know exact details here though. But I do know that in practice some operators don’t export outside their own borders.
Not sure if this is the hill to die on anyway, because even if all data was published continuous, now you have deduplication to do as the integration instead
Transitous@jon @stefanlindbohm This is potentially something we can match based on the time and train number, but this would of course be highly heuristic (and therefore not 100%) correct.
It's significantly easier if cross border trains are just in the data twice.
It's significantly easier if cross border trains are just in the data twice.
@transitous @jon Doesn’t need to be that crazy. Date and train number (or linked number) is what it’s designed to be matched on.
But I don’t believe a journey planner project should do this at import. It should be a separate project that sorts out the aggregation/integration and outputs clean files that can be used by journey planning projects. I would be happy to advise (not develop - time constrains) such a project. I know others I can ask too (they haven’t spoken publicly on this yet).
@stefanlindbohm I think a conversation between you and @VolkerKrause of @transitous would be useful 😀
@jon @VolkerKrause Happy to do it!
Volker Krause@stefanlindbohm @jon @transitous Great, let's find a time next week maybe if that works for you? I'm still on the road all of this week for another conference.
@jon @transitous The question is who should do this integration work. If it is to be mandated, it needs to happen at a level higher than current legislation mandates. NAPCORE maybe? But they don’t have any data publishing of their own as of currently.
I tend to think there is an opportunity for someone either commercially or community driven to run this integration and sell it to whoever uses it for commercial purposes. Not sure how well anything else would work in reality.