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