WEBVTT 00:00.000 --> 00:11.560 Okay, we are ready for the second last talk of this day, so I'm very happy to have a combination 00:11.560 --> 00:17.880 of community projects here, so yeah, this is your stage, talking about transitions, 00:17.880 --> 00:20.640 Felix Marcus, you know, please go ahead. 00:20.640 --> 00:23.120 Thank you. 00:23.120 --> 00:28.320 We will tell you a bit how we collaborate on making public transport more accessible in our 00:28.320 --> 00:36.400 apps and projects together, and I'll start first with the transition side of things. 00:36.400 --> 00:42.480 Okay, let's try to speak a bit up. 00:42.480 --> 00:49.080 Okay, I'll give my best. 00:49.080 --> 00:54.520 Okay, so the general problem we are trying to solve here is finding routes across different 00:54.520 --> 01:03.480 countries, which is usually not something that just works. 01:03.480 --> 01:08.720 The reason for that is that there's a lot of different providers and operators who 01:08.720 --> 01:16.800 all do their own thing, have their own apps and APIs that don't really connect well, 01:16.800 --> 01:23.000 then there's also things like the Interrail Railplaner app, which only has trains, which 01:23.000 --> 01:28.400 does that fairly well, but the data is old and there's a little, or there's no real 01:28.400 --> 01:34.320 time information at all, and then there's Google Maps who solve the problem of combining 01:34.320 --> 01:42.240 and getting all the data fairly well, but then they display it in a UI that is not very 01:42.240 --> 01:47.360 well-suited for long distance travel planning, because there's just very little details. 01:47.360 --> 01:52.400 For example, in Germany, it often just doesn't even display the track where train is going 01:52.400 --> 01:59.960 and things are just absolutely necessary if you are going to find the train at all. 01:59.960 --> 02:09.600 So of course we wanted to fix this with open source software, and the first approaches 02:09.600 --> 02:17.040 that were done were to just pick the correct API based on the region and try to combine 02:17.040 --> 02:20.600 what exists as good as possible. 02:20.600 --> 02:25.280 This works occasionally well, but the problem is of course that there can't be any rules 02:25.280 --> 02:33.000 that traverse different API regions that way, and for example, cities like Paris don't 02:33.000 --> 02:38.400 have a single main station, but you often have to switch between different stations, 02:38.400 --> 02:45.360 and then you absolutely need integration with a local transport, and that's just not part 02:45.360 --> 02:50.640 of any of the existing APIs like Dutch urban, or so. 02:50.640 --> 02:55.920 The other option would, of course, be to use the Google Transit API, but it's not actually 02:55.920 --> 03:01.360 free to use, and therefore also unrealistic for open source projects. 03:01.360 --> 03:08.680 So our conclusion was to just run our own service since the data is at this point mostly 03:08.680 --> 03:12.560 there. 03:12.560 --> 03:18.640 The idea came up last first term, we just discussed a bit, and noticed that it should 03:18.640 --> 03:20.440 actually be possible. 03:20.440 --> 03:26.160 Previously this was mostly thought of as a bit too much work, and possibly not so easy 03:26.160 --> 03:32.760 to do, but we then realized it could work, and so we had the first service running about 03:32.760 --> 03:40.360 I think a month later, and then just kept adding more data to our collection and have fairly 03:40.360 --> 03:43.880 good coverage now. 03:43.880 --> 03:51.400 In the EU, we have most of what I currently know about, so in many countries it's actually 03:51.400 --> 03:55.040 really complete, including local transportation. 03:55.040 --> 04:00.520 In some maybe it's not complete, but we have most of the long distance stuff at least, 04:00.520 --> 04:04.120 and then we have some coverage islands, of course, as well. 04:04.120 --> 04:09.920 But in the EU it's fairly complete, and some other countries in Europe as well, and it's 04:09.920 --> 04:17.440 fairly quickly growing in the US as well, and it's distributed into very, very small 04:17.440 --> 04:24.640 feeds, but people have gone all the way to collect them all. 04:24.640 --> 04:30.840 The set of the services that it's now running fairly well, but it could still be faster, 04:30.840 --> 04:36.800 and that's probably mostly things we need to do in software there. 04:36.800 --> 04:43.320 This is the map of the current coverage in Europe based on trains and buses, running 04:43.320 --> 04:50.920 at some random point where I made this screenshot, so yeah, obviously not completely 04:50.920 --> 04:56.160 representative, but it shows in which areas we have coverage at all. 04:56.160 --> 05:03.760 It's kind of visible where the EU ends here, but some other places as well are starting 05:03.760 --> 05:07.120 to come up. 05:07.120 --> 05:16.640 So in numbers we have 14 and 94 regions, regions as our slightly special definition of things 05:16.640 --> 05:22.760 that are oversized that a few people can collect all the data for it, which usually means 05:22.760 --> 05:27.600 a country in Europe, but usually is state in the US. 05:27.600 --> 05:34.600 We have 39 people responsible for updating the data for their regions. 05:34.600 --> 05:43.680 We have 1117 timetables, which are of varying size based on what people have been doing 05:43.680 --> 05:51.480 previously, and we have 167 real-time feeds, which means updates to the timetables based 05:51.480 --> 05:53.480 on delays and so on. 05:53.480 --> 05:59.400 Finally, we have now five apps using train searches, not all of them maybe well now, 05:59.400 --> 06:02.800 but it's used. 06:02.800 --> 06:08.040 Our data sources are mostly GGS and GGSRT. 06:08.040 --> 06:13.040 The reason why we chose that is that it has fairly good support and existing software, 06:13.040 --> 06:17.080 and that is the same format that is already used for Google Maps, which means the data 06:17.080 --> 06:22.520 already exists, and lots of places we just need to collect it, or get people to publish 06:22.520 --> 06:30.880 it, if they don't yet, and then added to our own metadata, which currently is just 06:30.880 --> 06:38.360 JSON based, and can, for example, look up the feed from existing databases like a transit 06:38.360 --> 06:39.360 land. 06:39.360 --> 06:44.680 In that case, you can just add the transit land ID there, and a data that will appear on 06:44.680 --> 06:45.680 the live. 06:45.680 --> 06:50.600 For instance, if there's, if it's not known anywhere, then you can also edit by URL. 06:50.600 --> 06:57.200 It's fairly flexible, and of course the problem with just adding everything that we can 06:57.200 --> 07:01.040 find is that the quality is not always amazing. 07:01.040 --> 07:09.680 This is rotated, but the part on the left is France and the part on the right is somewhere 07:09.680 --> 07:11.080 in Africa. 07:11.080 --> 07:16.280 So this is probably not real, and from the color, you can see that this is supposed to 07:16.280 --> 07:21.880 be a regional train, which, yeah, maybe not. 07:21.880 --> 07:27.880 So we need to find a way to filter such things, at least, so it doesn't break routing entirely. 07:27.880 --> 07:32.280 If there's a train that takes such a shortcut, it will always be taken, and it doesn't 07:32.280 --> 07:37.000 make sense, and it will remove all the useful connections. 07:37.000 --> 07:40.760 The other problem is that sometimes coordinates are just missing, and people just write 07:40.760 --> 07:45.280 0, 0 there, because they don't actually know and think that it's so careful, and it's 07:45.280 --> 07:51.080 some context, it may be, but it causes lots of problems for us as well, so we need to filter 07:51.080 --> 07:54.720 these things as well. 07:54.720 --> 07:58.680 Sometimes the GTFS data has also just invalid, because people don't actually validate 07:58.680 --> 08:05.320 it, and then we just pick all the entries that we can make sense of and drop the rest. 08:05.320 --> 08:13.280 We do that by using a GTFS tidy, or in practice our own staging for a QTFS clean, because 08:13.280 --> 08:18.880 we didn't really manage to get our stuff merged upstream quickly enough, and it's exposed 08:18.880 --> 08:26.040 as a fixed option in our JSON metadata, so you can turn it on in case the feed isn't 08:26.040 --> 08:29.400 immediately possible. 08:29.400 --> 08:34.320 If you want to add more about the traces, and there's just a side of things you can have 08:34.320 --> 08:39.840 to look at the website, fendershes.org, that you can find API documentation if you want 08:39.840 --> 08:46.040 to use it in your own project, or a developer documentation if you want to help us collect 08:46.040 --> 08:50.240 more data or improve our routing. 08:50.240 --> 09:05.240 So, yeah, so I'm Marcus, and I'm the maintainer of Gnome maps, and it is, oh, yeah, okay, 09:05.240 --> 09:12.240 so I'm the maintainer of Gnome maps, and Gnome maps is the maps application in Gnome, 09:12.240 --> 09:15.240 it's a core app in the Gnome project. 09:16.240 --> 09:22.480 File, basically JSON file, describing the regions and the plugin to use, so we have support 09:22.480 --> 09:29.000 for, for example, Rias Robotein, Sweden, and also open-trip planner, for example, Portland 09:29.000 --> 09:39.240 Oregon, but yeah, so this has some of the problems that Yuna mentioned earlier, but this 09:39.280 --> 09:49.720 island of transit, or transit island problem, or we have, like, islands without any connection 09:49.720 --> 10:01.240 between them, you cannot route between the different providers, yeah, so then, at first 10:01.240 --> 10:10.120 on the last year, this transition project was born, so to speak, so during spring, I implemented 10:10.120 --> 10:21.320 support for MOTIS, that was version 0, it takes the time, and challenges to get it working, 10:21.320 --> 10:29.240 but now with the new MOTIS 2, API is more in line with the open-trip planner API that we have 10:29.240 --> 10:38.960 our internal database, or data structure is based on, so it's way easier, yeah, and this 10:38.960 --> 10:51.960 is just a screenshot of, for good, yeah, and trip, so yeah, that's basically it, it's not that 10:51.960 --> 11:02.040 deep, it was very detailed at much time, okay, so you've already heard the name MOTIS, 11:02.040 --> 11:09.000 so for all of you who don't know already what it is, I'll just give a quick introduction, 11:09.000 --> 11:17.320 so basically it's aiming to provide everything you need to offer a public transport routing 11:17.320 --> 11:21.920 platform or a general mobility platform, so it's not just the routing, it's also 11:22.000 --> 11:29.360 geocoding, it's also background map tiles, reverse geocoding, and a lot of more endpoints, 11:29.360 --> 11:40.400 for example, get departure table boards and trips and all the other APIs, so some of you might 11:40.400 --> 11:49.200 have seen the presentation at first in 2023, and might ask what's new, and basically everything 11:49.280 --> 11:58.080 is new, so we made everything way more scalable, so currently the scope of MOTIS is to provide 11:58.080 --> 12:04.880 planet wide routing before our target was to provide routing for a country like Germany, 12:04.880 --> 12:12.640 so we were mostly working with the German data, so if you change your scope, usually you 12:12.640 --> 12:17.200 need to throw away all the algorithms and data structures yet that you had before, and that's 12:17.200 --> 12:23.360 what we did, so we introduced a new data model, very efficient data model for public transport, 12:24.240 --> 12:31.600 routing, and all the other APIs that we power with this data model, we rewrote our 12:32.960 --> 12:41.440 speed routing from scratch, and we also introduced a new geocoder, so here we have some numbers, 12:41.440 --> 12:51.200 so routing fits in around 16 gigabytes of RAM, same for planet wide speed routing, including 12:51.200 --> 12:59.920 all modes, so car routing, pedestrian routing, and combinations, for example, for iscouter routing, 12:59.920 --> 13:03.520 you need to walk to the scooter, you need to take the scooter, and then you need to walk to 13:03.600 --> 13:12.720 walk again, so all these things are now part of the routing, so yeah that's it, 13:15.200 --> 13:19.200 I think now we have some time for questions, we have a couple of minutes for questions here, 13:20.160 --> 13:36.880 you were? My question is, where are you discussing like there's like trains, buses, 13:38.320 --> 13:42.880 what other forms of transportation are you working on, are you working on the plan 13:43.440 --> 13:52.000 important in the future? So I can answer technically what motors trying to support is everything that 13:52.000 --> 14:00.160 has a timetable, so you could add or I think they are all already airplanes, long distance buses, 14:00.800 --> 14:07.760 tram subway, all this kind of stuff, and in the street routing part I already mentioned 14:07.840 --> 14:13.280 e-scooters, so we I think the goal is to in the end also like motors already 14:13.280 --> 14:21.120 supports it, we are exactly bike sharing e-scooters, all this sharing mobility stuff, 14:23.280 --> 14:31.120 soon maybe like we will we will be working on ride sharing, so you can pick up someone else, 14:31.120 --> 14:37.440 and this will be integrated, so basically everything that brings you from A to B is in our 14:37.520 --> 14:39.520 scope. 14:52.240 --> 14:58.480 Yeah, technically we want to do this, it's just a matter of development resources, 14:59.840 --> 15:03.840 we have a funding proposal for NLNet, let's see. 15:07.840 --> 15:12.720 And you said that all is now supported by routing, you have any plans for interplanetary routing. 15:16.320 --> 15:20.160 Probably we would need to throw away our algorithms again, so not for now. 15:23.280 --> 15:28.320 I am planning to move out this sub kind of unified routing information, 15:28.320 --> 15:33.520 because I'm out in the situation, we have to resources to run the routing myself, 15:33.520 --> 15:39.040 but just getting all the data feeds together in a unified way is quite the pain when you do 15:39.040 --> 15:40.080 the cross-field problem. 15:45.520 --> 15:51.840 So we already republished the GJFS files we use in a slightly collected way, 15:53.840 --> 15:59.440 sorted by countries at least, so if you wanted to hire countries, you can get the data fairly 15:59.440 --> 16:06.320 easily, we currently don't merge it because that would mean, yeah, merging files with different 16:06.320 --> 16:11.600 licenses in a single file, and that would just be complex, probably possible in many cases, 16:11.600 --> 16:15.440 but needs more thinking before we can do that, I think. 16:20.320 --> 16:27.280 The technical side is not the problem that the license compatibility is, and if you do it yourself, 16:27.520 --> 16:28.560 that should be fine. 16:30.160 --> 16:33.600 So unfortunately, we are running out of time, so thanks again for your support.