Okay, we are ready for the second last talk of this day, so I'm very happy to have a combination
of community projects here, so yeah, this is your stage, talking about transitions,
Felix Marcus, you know, please go ahead.
Thank you.
We will tell you a bit how we collaborate on making public transport more accessible in our
apps and projects together, and I'll start first with the transition side of things.
Okay, let's try to speak a bit up.
Okay, I'll give my best.
Okay, so the general problem we are trying to solve here is finding routes across different
countries, which is usually not something that just works.
The reason for that is that there's a lot of different providers and operators who
all do their own thing, have their own apps and APIs that don't really connect well,
then there's also things like the Interrail Railplaner app, which only has trains, which
does that fairly well, but the data is old and there's a little, or there's no real
time information at all, and then there's Google Maps who solve the problem of combining
and getting all the data fairly well, but then they display it in a UI that is not very
well-suited for long distance travel planning, because there's just very little details.
For example, in Germany, it often just doesn't even display the track where train is going
and things are just absolutely necessary if you are going to find the train at all.
So of course we wanted to fix this with open source software, and the first approaches
that were done were to just pick the correct API based on the region and try to combine
what exists as good as possible.
This works occasionally well, but the problem is of course that there can't be any rules
that traverse different API regions that way, and for example, cities like Paris don't
have a single main station, but you often have to switch between different stations,
and then you absolutely need integration with a local transport, and that's just not part
of any of the existing APIs like Dutch urban, or so.
The other option would, of course, be to use the Google Transit API, but it's not actually
free to use, and therefore also unrealistic for open source projects.
So our conclusion was to just run our own service since the data is at this point mostly
there.
The idea came up last first term, we just discussed a bit, and noticed that it should
actually be possible.
Previously this was mostly thought of as a bit too much work, and possibly not so easy
to do, but we then realized it could work, and so we had the first service running about
I think a month later, and then just kept adding more data to our collection and have fairly
good coverage now.
In the EU, we have most of what I currently know about, so in many countries it's actually
really complete, including local transportation.
In some maybe it's not complete, but we have most of the long distance stuff at least,
and then we have some coverage islands, of course, as well.
But in the EU it's fairly complete, and some other countries in Europe as well, and it's
fairly quickly growing in the US as well, and it's distributed into very, very small
feeds, but people have gone all the way to collect them all.
The set of the services that it's now running fairly well, but it could still be faster,
and that's probably mostly things we need to do in software there.
This is the map of the current coverage in Europe based on trains and buses, running
at some random point where I made this screenshot, so yeah, obviously not completely
representative, but it shows in which areas we have coverage at all.
It's kind of visible where the EU ends here, but some other places as well are starting
to come up.
So in numbers we have 14 and 94 regions, regions as our slightly special definition of things
that are oversized that a few people can collect all the data for it, which usually means
a country in Europe, but usually is state in the US.
We have 39 people responsible for updating the data for their regions.
We have 1117 timetables, which are of varying size based on what people have been doing
previously, and we have 167 real-time feeds, which means updates to the timetables based
on delays and so on.
Finally, we have now five apps using train searches, not all of them maybe well now,
but it's used.
Our data sources are mostly GGS and GGSRT.
The reason why we chose that is that it has fairly good support and existing software,
and that is the same format that is already used for Google Maps, which means the data
already exists, and lots of places we just need to collect it, or get people to publish
it, if they don't yet, and then added to our own metadata, which currently is just
JSON based, and can, for example, look up the feed from existing databases like a transit
land.
In that case, you can just add the transit land ID there, and a data that will appear on
the live.
For instance, if there's, if it's not known anywhere, then you can also edit by URL.
It's fairly flexible, and of course the problem with just adding everything that we can
find is that the quality is not always amazing.
This is rotated, but the part on the left is France and the part on the right is somewhere
in Africa.
So this is probably not real, and from the color, you can see that this is supposed to
be a regional train, which, yeah, maybe not.
So we need to find a way to filter such things, at least, so it doesn't break routing entirely.
If there's a train that takes such a shortcut, it will always be taken, and it doesn't
make sense, and it will remove all the useful connections.
The other problem is that sometimes coordinates are just missing, and people just write
0, 0 there, because they don't actually know and think that it's so careful, and it's
some context, it may be, but it causes lots of problems for us as well, so we need to filter
these things as well.
Sometimes the GTFS data has also just invalid, because people don't actually validate
it, and then we just pick all the entries that we can make sense of and drop the rest.
We do that by using a GTFS tidy, or in practice our own staging for a QTFS clean, because
we didn't really manage to get our stuff merged upstream quickly enough, and it's exposed
as a fixed option in our JSON metadata, so you can turn it on in case the feed isn't
immediately possible.
If you want to add more about the traces, and there's just a side of things you can have
to look at the website, fendershes.org, that you can find API documentation if you want
to use it in your own project, or a developer documentation if you want to help us collect
more data or improve our routing.
So, yeah, so I'm Marcus, and I'm the maintainer of Gnome maps, and it is, oh, yeah, okay,
so I'm the maintainer of Gnome maps, and Gnome maps is the maps application in Gnome,
it's a core app in the Gnome project.
File, basically JSON file, describing the regions and the plugin to use, so we have support
for, for example, Rias Robotein, Sweden, and also open-trip planner, for example, Portland
Oregon, but yeah, so this has some of the problems that Yuna mentioned earlier, but this
island of transit, or transit island problem, or we have, like, islands without any connection
between them, you cannot route between the different providers, yeah, so then, at first
on the last year, this transition project was born, so to speak, so during spring, I implemented
support for MOTIS, that was version 0, it takes the time, and challenges to get it working,
but now with the new MOTIS 2, API is more in line with the open-trip planner API that we have
our internal database, or data structure is based on, so it's way easier, yeah, and this
is just a screenshot of, for good, yeah, and trip, so yeah, that's basically it, it's not that
deep, it was very detailed at much time, okay, so you've already heard the name MOTIS,
so for all of you who don't know already what it is, I'll just give a quick introduction,
so basically it's aiming to provide everything you need to offer a public transport routing
platform or a general mobility platform, so it's not just the routing, it's also
geocoding, it's also background map tiles, reverse geocoding, and a lot of more endpoints,
for example, get departure table boards and trips and all the other APIs, so some of you might
have seen the presentation at first in 2023, and might ask what's new, and basically everything
is new, so we made everything way more scalable, so currently the scope of MOTIS is to provide
planet wide routing before our target was to provide routing for a country like Germany,
so we were mostly working with the German data, so if you change your scope, usually you
need to throw away all the algorithms and data structures yet that you had before, and that's
what we did, so we introduced a new data model, very efficient data model for public transport,
routing, and all the other APIs that we power with this data model, we rewrote our
speed routing from scratch, and we also introduced a new geocoder, so here we have some numbers,
so routing fits in around 16 gigabytes of RAM, same for planet wide speed routing, including
all modes, so car routing, pedestrian routing, and combinations, for example, for iscouter routing,
you need to walk to the scooter, you need to take the scooter, and then you need to walk to
walk again, so all these things are now part of the routing, so yeah that's it,
I think now we have some time for questions, we have a couple of minutes for questions here,
you were? My question is, where are you discussing like there's like trains, buses,
what other forms of transportation are you working on, are you working on the plan
important in the future? So I can answer technically what motors trying to support is everything that
has a timetable, so you could add or I think they are all already airplanes, long distance buses,
tram subway, all this kind of stuff, and in the street routing part I already mentioned
e-scooters, so we I think the goal is to in the end also like motors already
supports it, we are exactly bike sharing e-scooters, all this sharing mobility stuff,
soon maybe like we will we will be working on ride sharing, so you can pick up someone else,
and this will be integrated, so basically everything that brings you from A to B is in our
scope.
Yeah, technically we want to do this, it's just a matter of development resources,
we have a funding proposal for NLNet, let's see.
And you said that all is now supported by routing, you have any plans for interplanetary routing.
Probably we would need to throw away our algorithms again, so not for now.
I am planning to move out this sub kind of unified routing information,
because I'm out in the situation, we have to resources to run the routing myself,
but just getting all the data feeds together in a unified way is quite the pain when you do
the cross-field problem.
So we already republished the GJFS files we use in a slightly collected way,
sorted by countries at least, so if you wanted to hire countries, you can get the data fairly
easily, we currently don't merge it because that would mean, yeah, merging files with different
licenses in a single file, and that would just be complex, probably possible in many cases,
but needs more thinking before we can do that, I think.
The technical side is not the problem that the license compatibility is, and if you do it yourself,
that should be fine.
So unfortunately, we are running out of time, so thanks again for your support.