Worldwide routing with transitous.org
Opened this issue · 13 comments
Worldwide, cross-border, routing would be an ultimate goal for Transportr. Thankfully transitous.org is already providing such a service!
The only thing lacking is the implementation of transitous.org (MOTIS) in public-transport-enabler, see schildbach/public-transport-enabler#555 .
This would also enable us to remove the networks depending on Navitia (see schildbach/public-transport-enabler@f2617c2), that have a very uncertain future!
It is also easy to contribute to the Transitous project, by simply adding gtfs files for missing networks!
Maybe put a link in the Markdown of the first post? 😜
You mentioned in another comment that this would "simplify the maintenance" of Transportr - how so?
It's not clear to me what "Transitious" actually is. It looks to me like that's just a very simple static site that redirects to other sites, most importantly routing.spline.de, which seems to be an example hosting of the MOTIS project?
You mentioned in another comment that this would "simplify the maintenance" of Transportr - how so?
It would simplify maintenance in the sense that we would rely on a single "network/provider" instead of having to do maintenance for each network individually (that can disappear or need updates). You can have a look at the commit history/PRs/changelogs to see all the network maintenance.
It's not clear to me what "Transitious" actually is. It looks to me like that's just a very simple static site that redirects to other sites, most importantly routing.spline.de, which seems to be an example hosting of the MOTIS project?
Here a quote from their website, Transitous is a community-run provider-neutral international public transport routing service. Essentially it's a community project maintaining a worldwide feed database, and also providing a publicly accessible API for routing (through MOTIS) :)
we would rely on a single "network/provider" instead of having to do maintenance for each network individually
Sorry, but this is a terrible idea.
Unless I am completely misunderstanding something, Transportr currently relies entirely on https://github.com/schildbach/public-transport-enabler for its transport data. Since that is a JVM library, it is offline and part of the app itself. The only connection to online sources happens to the actual traffic network operators, which can be considered the ground truth and has to be involved at the very least.
Moving away from that to instead use something like transitious.org not only adds a new point of failure, which could arguably be an acceptable trade-off. It adds a single point of failure that is out of direct control of anyone working on Transportr. Even more, it is apparently a student project based in a single university (in Berlin) that has existed for less than a year. So there is no track record of reliability on the project and no guarantee that it will not just be dropped at some point, making Transportr completely useless.
The only reasonable option to reach that goal would be to host an instance of the server for Transportr itself but that would introduce running costs to the app.
I don't see any issue with offering transitious.org connection as yet another provider akin to the others in Transportr.
Sorry, but this is a terrible idea.
Unless I am completely misunderstanding something, Transportr currently relies entirely on https://github.com/schildbach/public-transport-enabler for its transport data. Since that is a JVM library, it is offline and part of the app itself. The only connection to online sources happens to the actual traffic network operators, which can be considered the ground truth and has to be involved at the very least.
This is false, some "networks" in PTE are for example based on Navitia which isn't an official source. And in the first message of this thread, I explain that the goal is to add Transitous simply as new provider in PTE.
Moving away from that to instead use something like transitious.org not only adds a new point of failure, which could arguably be an acceptable trade-off. It adds a single point of failure that is out of direct control of anyone working on Transportr. Even more, it is apparently a student project based in a single university (in Berlin) that has existed for less than a year. So there is no track record of reliability on the project and no guarantee that it will not just be dropped at some point, making Transportr completely useless.
I don't want to move away from the current networks, but we have to move away from one of our current, and by now proprietary, "point of failure" : Navitia. We will keep all other as it is today, just add Transitous as an additional backend in PTE. I'm much more reassured by adding a new dependency to a reliable and competent open-source project..., than by continuing to depend on a proprietary project whose immediate future is more than uncertain and already in decline.
And Transitous is a fresh project, but certainly not only a student project: folks from KDE, Gnome and other projects are already working on it, and integrating it in their apps.
The only reasonable option to reach that goal would be to host an instance of the server for Transportr itself but that would introduce running costs to the app.
No that's not an option IMHO, to much cost and effort. It is better to share resources, which is the whole point of Transitous. You are free to try and host a server on you own, but that's out of scope of the current Transportr project.
I don't see any issue with offering transitious.org connection as yet another provider akin to the others in Transportr.
That's exactly what my idea is :)
That's exactly what my idea is :)
Okay, I misunderstood your goal then.
And Transitous is a fresh project, but certainly not only a student project: folks from KDE, Gnome and other projects are already working on it, and integrating it in their apps.
About 2/3 of all commits in the repository are made by single person, Jonah Brüchert, who appears to be a student in Berlin. Sure, some commits have been made by other people as well but would those people be willing to become full maintainers and pay for the hosting of the server, if the university decides to drop the project at some point?
It doesn't matter that much if Transitious is just another option but there shouldn't be too much reliance on the project.
I feel like long-term goals, if desired, would still be to move away from third-party online services entirely. It could be worth a shot to try and run a MOTIS server on the phone itself; while not an optimal option, I know of some cases where this has been done. Alternatively, was it ever considered to do what MOTIS does and access the GTFS format?
Maybe I can give some context here:
While I'm a student, the project is not bound to a research project or anything like this. Instead I'm part of a group of students who host a number of services (Spline) on donated hardware.
If it is beneficial or necessary, the main Transitous instance could be hosted somewhere else as well, but doing this kind of routing (including footpaths) over larger distances requires more than RAM than is cheaply available from the usual cloud providers (~60GB), so without a sponsor offering to host this kind of hardware or VM, the student group is the only option.
I've recently looked into adding support for the upcoming MOTIS 2 API which will be used for Transitous relatively soon in public-transport-enabler together with other people from Spline. Initially we were aiming at Öffi, but I guess Transportr would also benefit from it.
There is some work left to upstream the changes, primarily making them compatible with the older android toolchain that Öffi uses. The reason for that is that we wanted to work in a modern Android Studio.
You can find the non-legacy toolchain compatible version here: https://gitlab.com/jbb/public-transport-enabler/-/tree/transitous
I've recently looked into adding support for the upcoming MOTIS 2 API which will be used for Transitous relatively soon in
public-transport-enablertogether with other people from Spline. Initially we were aiming at Öffi, but I guess Transportr would also benefit from it.
There is some work left to upstream the changes, primarily making them compatible with the older android toolchain that Öffi uses. The reason for that is that we wanted to work in a modern Android Studio.
You can find the non-legacy toolchain compatible version here: https://gitlab.com/jbb/public-transport-enabler/-/tree/transitous
Wow this sounds like great news 🎉 (I wasn't aware of this amaizing work) Thanks a lot, it looks promising :)
It looks like there is virtually nothing being merged upstream in public-transport-enabler. Do you think the work of supporting the ancient toolchain Öffi uses is even worth it? I noticed you already use a fork of pte which merges a few more pull requests, but is there a requirement to try upstream first?
I noticed you already use a fork of pte which merges a few more pull requests, but is there a requirement to try upstream first?
No there is no requirement having merged something upstream first :) It is quite the opposite acutally, we use https://gitlab.com/opentransitmap/public-transport-enabler (maintained by @ialokim) to merge PRs ealier than upstream, so we can use it in Transportr. So feel free to open a merge request there (and once merged, we can still try to get it merged upstream)!
@jbruechert that's great news! I was having MOTISv2 implementation for PTE on my todo for these days. Please go ahead and open a PR at our staging repo, and I'll invest some time in reviewing it.
If/when there's a PR, can you link it for watchers?
I opened a Draft MR now: https://gitlab.com/opentransitmap/public-transport-enabler/-/merge_requests/12