Worldwide routing with transitous.org

[Altonss]

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!

[michaelblyons]

Maybe put a link in the Markdown of the first post? 😜

[atollk]

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?

[Altonss]

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) :)

[atollk]

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.

[Altonss]

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 :)

[atollk]

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?

[jbruechert]

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

[Altonss]

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

Wow this sounds like great news 🎉 (I wasn't aware of this amaizing work) Thanks a lot, it looks promising :)

[jbruechert]

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?

[Altonss]

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)!

[ialokim]

@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.

[michaelblyons]

If/when there's a PR, can you link it for watchers? ♥️

[jbruechert]

I opened a Draft MR now: https://gitlab.com/opentransitmap/public-transport-enabler/-/merge_requests/12

[jakobcornell]

Hi folks! Is anybody working on direct GTFS support in Transportr or public-transport-enabler? I'm interested in adding my local metro which publishes GTFS, and setting up easy addition of other GTFS endpoints in the process. To my inexperienced eye at least it seems like a translation layer between GTFS and public-transport-enabler's API must be simple enough to be a better approach than passing through a separate service (whether run on the end user device or not).

[1Maxnet1]

Hi folks! Is anybody working on direct GTFS support in Transportr or public-transport-enabler? I'm interested in adding my local metro which publishes GTFS, and setting up easy addition of other GTFS endpoints in the process. To my inexperienced eye at least it seems like a translation layer between GTFS and public-transport-enabler's API must be simple enough to be a better approach than passing through a separate service (whether run on the end user device or not).

To my Knowledge, no. However if this feature is desired, it might need an additional implementation, as public-transport-enabler requires an external API. So two options that are soon available might be to ensure the GTFS data is loaded by transitous, so public-transport-enabler can request it or have a look at Transito: https://git.sr.ht/~mil/transito whi h is an App that solely works as you described.

[jakobcornell]

Neat, maybe I don't need to use Transportr at all if Transito satisfies my need; I'll check it out. If it doesn't I may come back to this and look more into adding support.

[michaelblyons]

I took a look at Transito yesterday. UI is not as good, but more importantly it could not give me routes between any of the points I tested. I tried multi-network routes, single network with walking, and single network on the same line. All failed to return results.

I like the idea, but it needs to work. YMMV

[traines-source]

Just my two cents:
@jakobcornell @atollk I don't think doing routing directly on the GTFS locally on a mobile device is a sustainable idea. With the network size, of course the size of the GTFS grows, and if you want to include realtime delay data using GTFS-RT, the device would need to download the entire feed of the current realtime situation every other minute (for e.g. Germany, if properly covered, the RT feed would be about 100 MB, and the GTFS feed, which also needs to be updated at least weekly, is compressed about 300 MB). That said, such an implementation with routing etc. is non-trivial, that's why projects like MOTIS and OTP exist (where the latter, while maybe easier to port at least to Android in theory, needs much more RAM). And that's why they are used to provide a server-run API in projects like https://transitous.org.

@jbruechert The maintainer of the upstream public-transport-enabler has expressed interest to implement support for Transitous so we should at least let him know that this work has already been done downstream so that he can merge it back.

[jbruechert]

Oh nice! I haven't made much progress on the pte implementation lately due to working on other things. I'll just briefly comment in the upstream repo.

[jakobcornell]

Thanks @traines-source, I didn't realize GTFS Realtime was a monolithic endpoint like Schedule. Trying to maintain an index on the client to be able to request specific chunks seems like a non-starter. It might be that for smaller metros like mine this is realistic (~100KB RT feed), but as this doesn't work in general an intermediate service is the practical choice.