cover Europe with API clients & static data

[derhuerst]

What if… one could use one app to get from Helsinki to Barcelona? And what if that app operated on open data, so that local changes to the public transport infrastructure can be reflected in the data quickly be the community? Why not have a set of API clients and/or datasets that fit together?

• as least one common format
• compatible, machine-readable identifiers for every station, stop, track, line, operator, etc.
• APIs that can either handle foreign data or know all of Europe (including tiny local buses)

[derhuerst]

public-transport-enabler is an open source Java library that can query over 70 public transport APIs in the world, with most of them being in central Europe.

@juliuste has started to cover national railway and some other companies in Europe.

[derhuerst]

Figuring out how to merge station IDs, stop IDs, line IDs, etc. will be hard. Most likely, this will require individualised algorithms to identify them and a manual check.

[pietercolpaert]

Figuring out how to merge station IDs, stop IDs, line IDs, etc. will be hard. Most likely, this will require individualised algorithms to identify them and a manual check.

In Belgium we’re now linking our stop identifiers with open street map through wikidata. Works great! https://github.com/iRail/iRail/issues/334

[Bertware]

I think we really need URIs for entire Europe. Can we generate these automatically based on UIC station codes for railways? This way we have unique identifiers which can be shared through multiple countries, datasets, ...

[derhuerst]

UIC station codes should already uniquely identify stations worldwide, but if you want, you can define a URI schema.

I don't know too much about how UIC station codes work though what UIC station codes consist of, maybe someone can share knowledge.

Also, keep in mind many transportation data sets don't use the globally unique IDs.

[pietercolpaert]

Me neither... Wonder whether there’s a central authority that publishes UIC codes /cc @skinkie

Wikidata provides already an interesting list though!

https://query.wikidata.org/#SELECT%20%3Fs%20%3FsLabel%20%3Fuic%20WHERE%20%7B%0A%20%20%3Fs%20wdt%3AP31%20wd%3AQ55488%3B%0A%20%20%20%20%20wdt%3AP722%20%3Fuic%20.%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22en%22.%20%7D%0A%7D%20LIMIT%201000

[ialokim]

Why not have a set of API clients and/or datasets that fit together?

• at least one common format

There are already quite a lot of modules generating the common FPTF. Comparing them, some do pretty much the same thing: retrieving data from different official public transport APIs, converting it and producing an JSON following the FPTF spec (e.g. hafas-client, deinbus, eurolines-de, interrail, flix, sncf, ...).

I've now noticed that they all expose pretty the same methods (e.g. journeys, stations or locations, some of them departures, ...), but every module expects slightly different arguments. I see that every API offers different options to query, but I think it would really make sense to standardize (at least some of) the arguments to pass to e.g. journeys so that it would be much easier to use different modules (and thus different APIs) in the same project without caring about the specific expected arguments.

We could discuss this in a seperate issue, but I thought it would fit here.

[juliuste]

@ialokim Thank you very much for this comment! I was actually thinking about the same thing when fixing the eurolines-de module yesterday, we should definitely do something like this. We should open another issue for that, even though we could discuss if FPTF is even the right scope (it could rather be FPTI (friendly public transport interface) or something similar).

[skinkie]

NeTEx is the mandatory format from the European Commission to exchange schedules. OJP / DJP is the mandatory format from the European Commission to exchange journey planner results in a distributed fashion.

Given the entire industry will move to these formats, the first thing to do from a community perspective is get producers and clients handle these formats. Entur from Norway is implementing NeTEx in OpenTripPlanner, PlannerStack is focused on OJP/DJP in OpenTripPlanner and R5.

[juliuste]

I started working on a draft for a Friendly Public Transport Interface in JavaScript today (see fpti-js), you're all very much invited to contribute there!

Disclaimer: The fact that I wrote a first draft on my own absolutely doesn't mean that I see this as some sort of “personal project“ I wouldn't want anyone to participate in. After writing lots of JS public transport libraries I just felt that I knew enough to propose something, and I figured that if I didn't write some kind of draft to kick things off, nobody would 😄 Long story short: I'm perfectly happy to change any part of this draft if someone proposes changes, so please contribute! 🙃 We could also move this repo from my account to the GitHub organization at some point, if you people approve of that.

(Special mention for @ialokim since she/he brought this issue up in the first place 🙂)

[juliuste]

For those of you interested in further discussion regarding the EU ITS legislation mentioned by @skinkie, have a look at this issue as well.

[derhuerst]

In Germany, I've made small steps to connect individual endpoints with find-hafas-leg-in-another-hafas and hafas-linked-connections-server.

[skinkie]

@derhuerst no small steps. VDV TRIAS is doing great. Especially pulling eveyone in via Eu-Spirit.

[derhuerst]

VDV TRIAS is doing great. Especially pulling eveyone in via Eu-Spirit.

That's great to hear! Where can I get the data? Where's the API for it?

[skinkie]

@derhuerst any verkehrsverbund that has the service is place, could be a starting point. But before you ask where is the data? Have you seen the NeTEx publication of Germany?

[derhuerst]

Have you seen the NeTEx publication of Germany?

No, where is it?

[juliuste]

No, where is it?

Here. However, if your mail provider rejects the platform's emails because it classifies them as spam - as did mine - you won't be able to register. I had to use a different mail address for registration now (which doesn't reject spam / has a different filter).

[pietercolpaert]

NeTEx is the mandatory format from the European Commission to exchange schedules. OJP / DJP is the mandatory format from the European Commission to exchange journey planner results in a distributed fashion.

Small nuance: transmodel is the mandatory reference domain model we should be compatible with in a machine readable fashion. However, not to get distracted from the main message of your comment: I agree that we could potentially see vendors moving to that standard. However, they do not say anything about which identifiers to use. I think moving to wikidata for that is a sound approach.

I started working on a draft for a Friendly Public Transport Interface in JavaScript today (see fpti-js), you're all very much invited to contribute there!

@juliuste that looks awesome! DJP can indeed be an inspiration, but I’d recommend keeping it close enough to your own use cases, otherwise you’ll reinvent a query language. It would be cool to see your interface work with wikidata as a back-end

[skinkie]

However, they do not say anything about which identifiers to use. I think moving to wikidata for that is a sound approach.

Technical Identifiers are also standardized. The format to make IDs unique in the own codespace.

[Bertware]

Technical Identifiers are also standardized. The format to make IDs unique in the own codespace.

But the combination of a codespace URL with an ID forms a URI, even if the NeTEx standard doesn't consider it that way, right? Could these URIs be used to link with Wikidata?

There are drafts for GTFS 2.0 which also start adopting Wikidata for vehicle types and details: https://docs.google.com/document/d/156RiBjI6FnWJvO8_XWX11Q9nLdOiBdS_rilA-oamlv8/edit#heading=h.ac0wjxpkjnfo (bottom of page 10). While these drafts don't mention wikidata on a service level (yet), they might include it if more and more formats and applications start moving towards it.

[derhuerst]

A general "manifesto" on why linked open transit data would be highly beneficial for public transportation networks: https://github.com/public-transport/why-linked-open-transit-data .

I moved this into a repo in order to a) let everyone contribute and b) be able to link to it from other projects.