Okay, let's see if that works. Yes. So thank you very much for having me. I'm
curious, I work at DB Infrago, which is Germany's infrastructure operator for railway
infrastructure and I work in the passenger station department of it. We also have a track
department. And yeah, long story short, that's also the title of the presentation at DB
Infrago. We have a new API for data on our station data, which is called Open Station,
which we released in December of last year. So on the one month ago, basically, which
is based on European standards, networks and Siri and an open data API, which we did not
have in this form before. And I want to take the chance today to show you a bit what we did.
And also maybe for those of you that don't know too much about networks or Siri, a bit
do what it looks like in detail, to get a first impression of, yeah, what it makes
might feel like. Maybe to integrate a bit with a talk from this morning, not really. From
one or two hours ago, where Mr. Eugret presented, we have some reasons to release our data.
Some of them are regulatory, some of them are own desire. But mainly, regulation, why we have
the amount of regulation that you already heard about that's valid for the whole, or
applies to the whole transportation sector. And then we also have the TSIPRM regulation,
which is one of the TSIs. It was mentioned before, which applies only for heavy method
as we call it, so the real rayways, which specifies that we need to report, which of our
stations are accessible in which way. It also indicates how to build new stations that they
have to be accessible. But it says, for existing stations, you have these have to report
how accessible they are. And both of these regulations indicate that you should use
NITX for data publication. And then the last thing is, did we infagirl the GO actually
stands for for the common good? And so we decided that we actually also do want to release
our data to the public to create some transparency on our infrastructure and to allow some
use cases that we probably don't don't figure out ourselves. So you might feel like this about
NITX or Siri, so I want to take a brief moment to introduce a bit on this. I think last
year, and the year before we had some talk, this time is the scam, by the way, I didn't start
at five before. Okay, so NITX is derived from the so-called Transmodest standard, which is
the common vocabulary, for example, they agreed that what is the trip in public transport?
That's a bus going from A to B, for example, you could define a trip in a different way.
And then from that, they derived much of a standard for us, most important NITX and Siri,
which are used for scheduled and real-time information respectively. Both of these standards
then have a ton of sub standards of which not all of are really important for every use case.
So for us, for example, the network topology case is important and then some profiles.
What that means I will go into in a bit. And then if you look into the NITX standard,
it looks a bit confusing because it's a big mess of XSD files, which are nested, so it's really
hard to find sort of what attributes you need to deliver, at least for us that was the case.
But there's some tools in case you want to do this yourself, for example, this from data
for public transport, which sort of visualizes how the XMS structure looks and I really recommend
using a tool like this if you work with NITX or Siri, even though it hurts to admit.
What does actually NITX data look like? This is a really simple example, but yes, it's XML.
It's maybe not the most convenient, but in the end, you sort of get what it does.
And it's quite easy to understand, actually, if you just look at NITX data itself.
I'll skip this for now. So what we did, we just mapped our entire station infrastructure
to the NITX concepts that are sort of representing it. So we're like, okay, what's the state?
What's the station? That's called a stop place in NITX. What's a level? Okay, that's sort of like ground
flow or whatever. What's a platform that's called a key and so on and so forth.
And we also mapped all of our equipments to their respective NITX equivalents.
So that in the end, we get this sort of graph for a station, which is what we want to release
in this open station API. So basically it allows you to do some routing without the geo data.
So just can I get from A to B and not how fast can I get from A to B? Because we don't have the data yet.
To be fair, we also don't have that data yet, but this is sort of the goal for us for this here
to internally collect all that data and our API, which is released now, sort of already supports it.
So once we put it into our internal system, you will get this graph out of the API.
This is also some data I can skip. This is what the API looks like, just really pretty NITX ML files
that go into a lot of data. Also, we have Siri for our elevators, which you can combine then to basically
have this graph and add some real time information on top of it to know if you can actually go from
A to B even though the elevators broken at the moment or so on. And our goal is that everyone in the
public transportation sector, the infrastructure operator does it similarly, also your local bus operator
for example, for the local bus stop for the metro stop. Unfortunately, they're not mandated to do
everything that we do at the moment, so that's still lacking. How you can you get the data?
We have this in for it is GitHub repo where there's different links to the ways you can
obtain the data you can download directly without looking or get it from the API marketplace.
And the cool thing that I'm really proud of is we somehow managed to convince our management to
release it as CC0 for the first time I think ever. So yeah, maybe last point, how does it integrate
into the existing infrastructure, it releases maybe you heard of some regular stations or so on
our idea for the futures that we have this sort of infrastructure raw data block and
Open Station is in for those raw data block about this is what our infrastructure looks like
and then people like DB can build their MMT system on top of it, but you could also build your own
MMT system and for example, motors or transition. This is also an MMT system and then the end users
or the end applications have a choice which MMT system they want to use, which is probably also
why the regulations got MMT. I think they had the same goal in mind and Open Station sort of fits
in that architecture. Last point, what have we do we have planned for this year? I think most
important for some people here, we are considering doing a proposal for a JSON variant of NITX,
maybe someone was to talk to us about this, maybe someone was to collaborate on this and also from
as I mentioned our main point is data quality and completeness because we build the technical framework
now, but the data itself as you might have seen in some situations is still lacking a bit.
So that's our big focus for this year and with it being said, thank you very much. There's
a link to our documentation and if you want one or version of this talk in which I don't like
speak three times as fast as normal you can check this thing. Thank you very much.