So, we can start with the next presentation.
Right pronunciation.
That's right.
We will talk about the rough libraries, public transport, so the stage is yours.
Yeah, hello. Thank you. And I want to thank you, the people before, because Transmodel
helped a lot to make like a nice model of how transit should be called, what's the stop
point, stop area, a trip. So, if you ever work with public transit, read the Transmodel model.
It helps a lot just to make things clear. And also, OpenTrip planner works quite well.
We've been experimenting recently using it in whole France, so it's a bit bigger than Norway,
and it seems to be working, so they do some nice things when we have to talk afterwards.
So, I'm talking about the very other extreme end of public transit data. So, some very small tools
and libraries to manipulate this data. And it's in Rust, because, well, if you're handling
a few gigabytes of data and want real-time data, Rust might be an option, and that's what we've done.
And, yeah. So, we are a very open and informal organization. So, in GitHub, it's Rust Transit,
and we want to make some lot of small breaks just to get started using public transit data,
and then you can do whatever you want to do. So, it's not very formal. We have no status,
nothing, and it's just focused on implementing things. So, gradually adding more implementation
and getting more things working. And this presentation is kind of a call saying,
we're looking for some projects to add to it and maintain us, and maybe some people will say,
okay, I have this very specific need, come and see us and let's talk.
Right now, it's mostly, but that only maintained by voluntary in a cooperative where I work,
which is called Coup de l'Hon liberté, and there's a colleague over there who can also answer your questions.
So, the first one is GTFS structures. So, the most important part, the biggest one,
so I will be spending a lot of time on it, and the other breaks are a bit smaller.
So, GTFS, I was told before, is the fact of the standard used to publish static transit data.
So, what time will the bus run next week? And at what stops it will stop and so on.
So, we started initially for our own project as defining the types in Rust, so the structs and so on.
And for those who do work with Rust, it's basically just baking third serialization and serialization annotations.
And with the time going on, we added some sugar, like reading directly from an URL,
which was a common need because, let's say, no way publish it on this website,
and we just downloaded and have the data immediately.
We started making some integrity checks because it's just plain CSV files,
so identifiers might not reference data that doesn't exist, so we added those checks.
And we tried to make it easier to access the data from one object to another.
I want to mention one alternative, which is Transit Model, which is made by a French company
who is now called HOD, which was used to be called Kizio Digital and which was used to be called CanalTP,
depending how old you are in the transit world.
It's an AGPL, so it's a library, as AGPL, so it might be a problem.
It does much more things like file conversion, is able to convert GTFS to netx and other way around.
It has very nice query functions, like tell me all the lines that go through this point.
But it's a bit more complex to use. It's mostly done for the own tools, so it's not always very documented
and you have to read to know how it works to get it working.
And in a perfect world, it would be based on GTF structures.
So we start discussing with them, but it break too many little things on their end
and they didn't want to bother, just say, it's work for us, don't bother with it.
So some user examples are TrontoValidator, which is done for the French National Access Point,
what they were talking before. So the transport.data.gov.fr has a validator that checks that every GTFS file is valid.
It doesn't have buses that go over the speed of light, sorry, and things like that.
So it's based on GTFS structures.
It has also some own tool with the GTFS to geogesan.
Some people just didn't care about the timetable, so they take a file of timetables and just extract the topology of the network.
And another project is Ketrin Maps, which is kind of a big student project in American California, I think, from a university,
which are trying to make a whole system and they're contributing a lot.
So it's a very small vanity metric. We have like 15 contributors, which is a lot and small for a project that's not really publicized.
And we have regular people just happen to use it and make some contribution.
So it's living on a small pace, but it works.
So we had, what was also to say is quite performant.
We tried to find the biggest GTFS that is there on the wild and apparently is the German one.
So there are 600,000 stop points in Germany, at least in the GTFS files.
There are one million trips.
A trip is a bus doing his route, and if the bus runs 10 times a day, it's 10 trips.
32,000 stop points.
So it's quite a big file and just to get everything read from the GTFS file to everything in memory,
it takes about 16 seconds on this laptop, whatever it means.
It takes about 5 gigabit of RAM.
It means you can handle the whole data of Germany on your laptop or on a reasonable, affordable server.
It's also quite robust.
As I said, every file in transport data GovFR, which is a national access point, is passed using GTFS structures.
It has data that comes from a lot of different editors and vendors, which are present all around the world.
So we kind of work through all the quirks of all the weird things that people do.
Like in GTFS, you're allowed not to put the trading commas.
So if you have 10 columns in the CSV file and have data just in the first two columns,
you can just put one comma and leave everything empty at the end.
It's all the kind of things you went through.
And I'm using this as a side note, as I have an audience that might be interested.
Oh, sorry.
The GTFS file was created as a dump of a database.
Just dump all the tables, put the CSV file, bundle them in the zip file, which is a horrible thing to do.
It's nice to exchange with your colleague as a one-off time, but not to make a standard.
So in the future, if you ever work with this kind of things, don't make zips of CSV files, please.
Let's use, for example, a SQLite database.
You can have a schema, so you'll be sure that the data will be respect,
and into there will be an integer, a Boolean will be a Boolean, and so on.
You have foreign keys, so you won't have wrong references.
You have typed columns.
You have indexes, so you open the file and you can have fast queries immediately for free.
You have a crying languages integrated.
You just download, open it.
You can already make some statistics.
And you have kind of fun things.
You can put everything on an S3 server and make HTTP range requests.
You don't even have to download the whole gigabyte of file, just 10 megs, and you have all the data you need.
So, yeah, this was a thing.
Think about how you materialize your data at the end, because people will use it,
and it will bring a lot of pain if you don't think about the serialization of your data.
Okay, that's done about GTS structure, which was clearly the biggest part, and now some smaller projects.
One crate, so crate is a package in the Rust world, is Serialite.
So, as you told before, Serialite is a standard, it's a norm in Europe for real-time data,
and Serialite is kind of a more simpler version to use.
I think it's open to heated debates if it should exist or not.
So, Serialite was mostly used as a SOAP interface, so over XML,
and Serialite is the same data, but serialized as JSON and served over REST.
And we used it initially to convert from GTS-RT, so the real-time GTS data to CRI,
for the French National Access Point, to be able to expose the data in the European standard.
And I also worked this small toy project where I read all the French, sorry, not French Parisian,
big Paris area, Ilde-France data, to have some dashboards about real-time of this top
or this metro line on real-time.
So, it works also quite well with some big data.
I mean, Ilde-France is twice as big as Norway, so it works.
I mean, the standards are well done, and we get things working.
Another one, which started really as a toy project, is Wesson for Routing.
When people see OpenStreetMaps, they say, oh, nice, a road network.
Let's implement some Dijkstra algorithm on it, because I want to play around with it.
And if you go into the OpenStreetMap format, you see that it was meant for mapping and not for routing.
And the most simple example is a way, it can be a road that goes around 100 kilometers,
and it doesn't stop at every intersection.
So, if you want to do some routing with that, that's a very bad graph.
So, the idea of this small tool is to cut the graph into a topology,
as we learned as a student, to make some routing algorithm.
So, initially, I made it just for this toy project, was all the roads from,
it's like a tree spanning here from Tokyo to every corner of Japan,
and making this kind of tree-like structure, so it was nothing useful.
So, it's meant to toy around, like the project I told you.
If you want to just try some algorithm because you're a student
and you want to implement on real-world data, it's very nice.
It used also for WessonD.
I think there will be some presentation afterwards, which is the open-source railway designer.
Sorry.
I'm not worried just I'm new.
Yeah, I'm bad with acronyms.
And we want to do the same with railway, and with railway,
there was no tool to do it.
But be aware, don't use it if you want real-life routing on roads for pedestrian for cars.
There are much more better tools and there are tons of constraints
that's not able to handle, like a turn left, a slow as a turn right, and things like that.
So, use OSM for routing for turning around for very specific needs or for learning,
but don't use it for real-life routing algorithm,
and use those very nice open-source tools that exist.
And that's pretty much.
So, thank you.
If you want to say that we're working, everybody wants to work with Rust and transit data.
So, we're quite open. I hope we're friendly.
So, don't hesitate to contact us and let's slowly grow the space of Toolbox for your needs.
I saw a Chinese screenshot of the departure port.
Are you planning on also integrated outside of Europe?
Well, this was just a creative comment from Wikimedia picture.
In series, we are not specific to any region.
I mean, GTFS and Siri might be used anywhere.
While GTFS is quite used all over the world, and they take more European,
I think Siri has gained some traction around the world because it's more usable than the GTFS RT part,
which is very focused, very big infrastructures and not always used.
So, maybe it's possible.
More like an information, you might be happy that Siri Lite has been fully approved.
So, it's not kind of like a French version of Siri on the side,
because Interforce Mobility asked for it.
Okay. Thank you.
That's a nice approach about all this transport.
It's like making words vocabulary and being agreed on what this word means.
It makes it easier to cross boundaries or formats and things like that.
But it's always a bit tricky, but nice to hear.
How far away is Rust in the transit industry?
Like, there's another project, the transit model. Is that also Rust-based?
Yeah, Transponder is Rust-based, yes.
And it's used for...
Huff makes a routing algorithm, which is called Devisia, which is heavily used in France.
So, which is written mostly in Rust nowadays.
It started as C++, well, it started as Delphi, but that's a long time ago.
So, it's actually used, yes.
Okay, thank you very much.
Thank you very much.
Thank you.