WEBVTT 00:00.000 --> 00:11.400 Talk about it about the European standardization, what happens around the politics, and how 00:11.400 --> 00:21.880 we can use open APIs in the end, in the dump, trying to build some blocks there, trying 00:21.880 --> 00:28.080 to motivate you, also to see which opportunities can you do into this field. 00:28.080 --> 00:36.520 So, let's meet me, work for our state of company in Norway, using the tax money 00:36.520 --> 00:51.960 to build open source tools, try to also try to enhance the community, build trusted, trusted 00:51.960 --> 00:58.960 collaboration, build one, also try to do some politics stuff. 00:58.960 --> 01:02.960 Adam, come with me. 01:02.960 --> 01:09.960 Yeah, thank you, I turn on the belt, sorry for being a little bit overdressed. 01:09.960 --> 01:18.960 I'm a guy from the Netherlands, and I work on the top API that's no resource solution 01:18.960 --> 01:28.960 for the actual booking payment around any kind of mode, and yeah, really enthusiastic to inform 01:28.960 --> 01:36.960 you about how it works and what it's in there. 01:36.960 --> 01:46.760 Hello everyone, I'm Tutto, I'm the lead of the French standardization group, and I'm here to 01:46.760 --> 01:51.760 represent the fact that yes, standardization can be fun, and it's also welcoming of any 01:51.760 --> 01:57.760 genders, so I also represent a French non-profit woman in mobility, and I'll be here 01:57.760 --> 02:03.760 to be talking about how actually we can build standards all together, though it can sound 02:03.760 --> 02:08.760 very rigid at the first step. 02:08.760 --> 02:13.360 So, a little bit of that, the boring stuff, I promise, that's the only slide that is about 02:13.360 --> 02:20.360 legal framework, is just to remind the context in which we work, which is a European regulation 02:20.360 --> 02:27.360 that has one main spirit, help us all as travelers to move across Europe because that's one of 02:27.360 --> 02:34.360 the core values, and it was divided into two legal directive, one on public transport, to make sure 02:34.360 --> 02:40.360 that all the data describing public transport offers are open and expressed in netx for schedule 02:40.360 --> 02:51.360 data and Siri for real-time information, and we have the same thing for railway. 02:51.360 --> 02:57.360 And up to now, the rail, we have done each one thing on his own, and it's not linked to what 02:57.360 --> 03:01.360 we all other are doing in the public transport sector. 03:01.360 --> 03:09.360 What's happened in Europe now is that a new TSI, the legal framework for rail is adopting, 03:09.360 --> 03:15.360 so what's happened in the last five to ten years in the public transport, we'll know we 03:15.360 --> 03:18.360 are part of the EU regulation for rail. 03:18.360 --> 03:25.360 So, we are now trying to get the rail operators in Europe to produce the same kind of data 03:25.360 --> 03:32.360 that all the other mobility modes has done in the last years. 03:32.360 --> 03:42.360 So, that's both challenging and giving a lot of new opportunities. 03:42.360 --> 03:45.360 One right for two talks, that's not easy. 03:45.360 --> 03:48.360 Good luck also for the next ones who will share talks. 03:48.360 --> 03:53.360 So, one of these legal framework where they created is something that we think is very important. 03:53.360 --> 04:01.360 They created national access points, where you can access data if you're in one of the 27 EU 04:01.360 --> 04:02.360 statements, plus three. 04:02.360 --> 04:06.360 So, our affiliated, like Norway, that we love the remarks with the Netherlands. 04:06.360 --> 04:10.360 Also, it's portal where you can find data that is open. 04:10.360 --> 04:16.360 So, which means that you can use all the data in your own software, in your tools and so on. 04:16.360 --> 04:24.360 And these data on national access points, they regroup times timetables, but also pricing, 04:24.360 --> 04:29.360 but also routing information, network details and so on. 04:29.360 --> 04:35.360 And the way that it is built is you will have on one side the mobility or transport operators, 04:35.360 --> 04:39.360 or public transport authorities, who will coordinate to the mobility offers. 04:39.360 --> 04:50.360 They will aggregate their information and based on the European legislation, they have to open it and publish it through national access points for every single person, 04:50.360 --> 04:58.360 every single software developer, every single consumers can actually retrieve it but also be informed of the overall quality of the data. 04:58.360 --> 05:06.360 And which format it is represented, and that's the last colon used by a lot of data consumers. 05:06.360 --> 05:12.360 You would have your usual routing app or trip planning application, but you can have a lot more. 05:12.360 --> 05:18.360 And that's what the emphasis we have in the sense that once the data is open, you can create any open source tool you want. 05:18.360 --> 05:26.360 Even for example, to compare how accurate the information is between real time and schedule information. 05:26.360 --> 05:32.360 And that is the part that we want to actually really focus on is the data consumers. 05:32.360 --> 05:40.360 In the sense that if you produce data, if you put data out there, you always have to think about the people who are going to use the data. 05:40.360 --> 05:51.360 And for them, what is really important is that the data is standardized in the sense that it's easier to aggregate from different sources into one single solution. 05:52.360 --> 06:04.360 And it's also what will support, hopefully, the opening of ticketing systems across different local authorities, different regions and different member states. 06:04.360 --> 06:11.360 And that is actually why I think that working on standards and opening them to the entire community are important. 06:11.360 --> 06:16.360 And that's also why we here because Brad and I are little bit of the hikers of the European standards. 06:16.360 --> 06:21.360 If you need access to them, you can always reach out to us. And yes, it was said on the video. 06:25.360 --> 06:33.360 And this is one of the outcomes we see in Norway from a group panel perspective. 06:34.360 --> 06:42.360 And what we see mostly in Europe today is the group panel has one, two, two, a little timetable data. 06:42.360 --> 06:49.360 And two, three, the timetable data in that two to work in their own trip planning solution. 06:49.360 --> 06:54.360 What we have here in Norway today is that we have broken that up. 06:54.360 --> 07:02.360 So the group panel has a national stop-list of history where we maintain all the data of the stops. 07:02.360 --> 07:13.360 And it has the open street map. So it's got training on that so they can update the streets, path, ways and so forth. 07:13.360 --> 07:24.360 And they have the group planning system, very planned the routes. And if it's still wrong in the route planning, then we change that in a natural access point. 07:24.360 --> 07:30.360 So we want to have a great timetable data. And we get that in Norway today. 07:30.360 --> 07:40.360 And that's open up new possibilities to reuse that data to building new retirement systems, make the data available in all kinds of apps, 07:40.360 --> 07:48.360 and all different kinds of trip planning solutions. You will hear about the multis later today. We are using open trip planning. 07:48.360 --> 07:52.360 And it's also correct that up along the loop. 07:52.360 --> 07:59.360 So by standardizing a public transport in the correct way, you can achieve a lot of new opportunities. 07:59.360 --> 08:08.360 Make it easier for your citizens to find travel and information. 08:08.360 --> 08:12.360 This was also for me. 08:12.360 --> 08:20.360 Yeah, and this is the standard we have used in Norway and is more in adoption in Europe. 08:20.360 --> 08:30.360 It's based on a transport concept for data mall. So all the description and specifications are done there on how they are linked together. 08:30.360 --> 08:39.360 Then we have the data format exchange data from one system to another through networks for the planned data. 08:39.360 --> 08:45.360 And a series for a real time or dynamic data. 08:45.360 --> 08:50.360 And why we are done that is to have this common language. We all talk about the same thing. 08:50.360 --> 08:58.360 That's the issue of the rate. They are having a different standard. So we are talking about a train trip train wagon. 08:58.360 --> 09:02.360 We are talking about different things. 09:02.360 --> 09:06.360 Then we are trouble using the data. 09:06.360 --> 09:14.360 You have a common data to exchange data. So you want to have a neutral, netx data exchange. 09:14.360 --> 09:22.360 So don't tweak the data because you have a legacy system. You have to update the system. 09:22.360 --> 09:30.360 So we all can interchange and use the same data across Europe in the same way. 09:30.360 --> 09:34.360 I don't think it's shipped. 09:34.360 --> 09:37.360 That's about profiles. 09:37.360 --> 09:38.360 Yes, thank you. 09:38.360 --> 09:45.360 So as bread explained, transfer model is the reference data model that is used for public transport. 09:45.360 --> 09:53.360 And now we will be used also for rail in the sense that the TSI to the metadata regression required data that is expressed in netx, 09:53.360 --> 10:02.360 which is based on transfer model. And here what you have and that is interesting is to show you all the different possibilities you have with existing standards that you have. 10:02.360 --> 10:08.360 So transfer model covering all of the concepts and netx being really much on the left side. 10:08.360 --> 10:12.360 So the planning series during traveling. So the real time information. 10:12.360 --> 10:16.360 And then we also have upcoming opera that is more for calculation in history data. 10:16.360 --> 10:27.360 And you also have represented here what you can be more familiar with, which is usually GTFS, NGTFS real time for public transport, conventional public transport, 10:27.360 --> 10:32.360 NGBFS for shared mobility or new modes. 10:32.360 --> 10:39.360 Basically you're free-floating bikes, scooters and cars, car sharing and so on. 10:39.360 --> 10:45.360 So you see that they tend to overlap that also why we say that using them is complementary. 10:45.360 --> 10:54.360 You could do a same as the for open trip planner when you do have enzymes that work for both with both for example netx and GTFS. 10:54.360 --> 11:02.360 And enrich one another like that to have more accurate answers for your customers. 11:02.360 --> 11:07.360 Quick overview of netx. I want to be too long of that is just to show you how it has been divided. 11:07.360 --> 11:14.360 And as any of the European standards, the aim is not to read all 3,000 something pages. 11:14.360 --> 11:19.360 But just to locate the parts that you need is that the part is grabbing the network topology. 11:19.360 --> 11:22.360 So really the infrastructure, the points on routes and so on. 11:22.360 --> 11:27.360 Or is it more about the scheduling information or is it about the fare information? 11:27.360 --> 11:36.360 And for example, all the current talks about opening ticketing systems from both the public transport and around way to external stakeholders 11:36.360 --> 11:41.360 within part will be within part 3, which is the fare information. 11:41.360 --> 11:49.360 And then on the right side, what you have our profiles and profiles are seen as a subset of the actual standard itself. 11:49.360 --> 12:00.360 And what it does is it helps people use the standard by reducing the concepts that exist in the standard to one very specific target. 12:00.360 --> 12:03.360 So the part 4 would be for European passenger information. 12:03.360 --> 12:08.360 So that would be the closest, for example, to GTFS information. 12:08.360 --> 12:11.360 The part 5 is for alternative modes. 12:11.360 --> 12:13.360 Or as I said, share mobility, new modes. 12:13.360 --> 12:18.360 I know that bread is advocating for it to be fully replaced by GBFS. 12:18.360 --> 12:21.360 I have different perspectives, but that's why it's fun for us to work together. 12:21.360 --> 12:23.360 We can agree to disagree. 12:23.360 --> 12:31.360 And part 6 is my little baby, but also the one of SBB in Switzerland because it's all about accessibility. 12:31.360 --> 12:37.360 So how to describe very precisely how accessible your network and your vehicles are. 12:37.360 --> 12:42.360 And we also have Siri, that is the real-time information. 12:42.360 --> 12:45.360 And this time is a little bit different than netx. 12:45.360 --> 12:49.360 It refocus on what kind of service or what kind of real-time information you want. 12:49.360 --> 12:51.360 Is it about your vehicle monitoring? 12:51.360 --> 12:55.360 Is it about your estimated time tables, estimated time of arrival? 12:55.360 --> 12:58.360 Is it about facility monitoring and so on? 12:58.360 --> 13:02.360 And all of these can actually work together. 13:02.360 --> 13:05.360 You can also have stop monitoring, for example. 13:05.360 --> 13:10.360 So it really to show you that these standards, yes, they're massive. 13:10.360 --> 13:18.360 But it's also because they've been created to be very modular for you to use only the part that you need. 13:18.360 --> 13:24.360 And I think with that, now we are going to dive onto the top. 13:24.360 --> 13:27.360 Unless bread has some closing points. 13:28.360 --> 13:31.360 It is a discussion on a concave. 13:31.360 --> 13:33.360 I feel you hear back. 13:33.360 --> 13:37.360 It's two, three hours discussion. 13:37.360 --> 13:43.360 Between two to me, EU Commission and other mobility data was there as well. 13:43.360 --> 13:45.360 Discussing netx and give us. 13:45.360 --> 13:51.360 So Google concave, give us netx. 13:51.360 --> 13:53.360 You will find it. 13:58.360 --> 14:00.360 Okay, this one is all. 14:09.360 --> 14:12.360 Okay, thank you, Brad and Tutta. 14:12.360 --> 14:25.360 I'm going to stand on your shoulders, because what I'm going to tell you is actually one of the opportunities to really tell what is possible when you have standardized your data. 14:26.360 --> 14:33.360 First of all, I want to introduce this mass maturity model as it's called from Reza in Sweden. 14:33.360 --> 14:38.360 And where we are looking at five different layers. 14:38.360 --> 14:44.360 The lower layer is the one, if you're not doing any thing about standardization. 14:44.360 --> 14:47.360 Well, integration forget it. 14:47.360 --> 14:50.360 The first one is integration of information. 14:51.360 --> 14:56.360 This one is, yeah, sorry, we started with a numbering from zero. 14:56.360 --> 14:58.360 So the lower one is zero. 14:58.360 --> 15:01.360 The first one is the integration of information. 15:01.360 --> 15:07.360 When you have standardized stuff, you can do an exchange information about the finability. 15:07.360 --> 15:12.360 Where assets are, where the trains are, how are they, they depart, etc, etc, etc. 15:12.360 --> 15:19.360 Everything that's needed when you have information ready for motor model, travel planning. 15:19.360 --> 15:23.360 And that's where Siri and Nettex GBFS as whole. 15:23.360 --> 15:25.360 Resign it. 15:25.360 --> 15:30.360 If we go one up to the level number two, we have integration of services. 15:30.360 --> 15:39.360 And there is the actual stuff where you book something, you open a bike, you check in, you check out, you swipe in, you swipe out. 15:39.360 --> 15:45.360 Whatever all these functions that the travel does are in there. 15:45.360 --> 15:53.360 And then you have two other things, the integration of the service offer where you actually, yeah, 15:53.360 --> 16:03.360 as organizations want to have a kind of a business model, where you integrate different offers and give subsidies or use subsidies, etc. 16:03.360 --> 16:04.360 It's in level four. 16:04.360 --> 16:12.360 And of three and level four, the upper level is about standardized stuff, where you actually aim for the green deal. 16:12.360 --> 16:23.360 And this is more related with European goals where you have to sign as well for data spaces, that they're all, yeah, also technical related. 16:23.360 --> 16:33.360 If I put the modules of the top API beside it, I put them in the same colors as the maturity model. 16:33.360 --> 16:37.360 You see that external data sources are at the bottom. 16:37.360 --> 16:54.360 So that means if you have data in external formats, like netx or dbfs, means making for or APPDS, that's a parking standard, OCPI for charting polls, everything is actually standardized possibly. 16:54.360 --> 16:58.360 And when you have it standardized, you can start with doing the actions. 16:58.360 --> 17:04.360 And that's in the top colors we call it, where you can create offers, book them, we call it purchase. 17:04.360 --> 17:07.360 It's a transmobile term and execute. 17:07.360 --> 17:17.360 And there are a lot of other modules I'm not going to into today, because I want to focus on a minimal viable product. 17:17.360 --> 17:29.360 And that's using netx and how you apply netx in this API, where you can create offers based on netx, purchase them and execute them. 17:29.360 --> 17:36.360 We're going to a little bit more detail and technical detail than the presentations before. 17:36.360 --> 17:43.360 And therefore I need some knowledge and maybe we should raise some hands. 17:43.360 --> 17:50.360 Are there concepts on this list that you are not familiar with, which I should explain? 17:51.360 --> 17:56.360 Okay, please see something they want explanation of just raise your hand. 17:56.360 --> 18:04.360 And when I say transmobile, transmobile if you want, okay, transmobile, small explanation. 18:04.360 --> 18:12.360 Transmobile is actually more or less the dictionary where all the terms are explained about real wage. 18:12.360 --> 18:17.360 It's netx uses the words that are explained in transmobile. 18:17.360 --> 18:18.360 Very small. 18:19.360 --> 18:24.360 Of course, there's a lot of things to say that it's not completely correct, but this is the high level one. 18:24.360 --> 18:40.360 Netx, you probably, yeah, because you're here, you might know netx well, but netx is actually disstandard where you can exchange data about all the terms that two to just mentioned in netx and Siri. 18:41.360 --> 18:52.360 So a bus line, you can express in it, when it departs there, et cetera, et cetera, everything that's needed for multimodal travel planning. 18:52.360 --> 18:58.360 Due to a really bunch of tech guys, great. 18:58.360 --> 19:01.360 OGEC. 19:01.360 --> 19:06.360 Okay, this OGEC stands for Open Geospatial Consortium. 19:06.360 --> 19:18.360 It's a global organization, open source anyhow, and they specify how an API should be when you're exchanging geospatial information. 19:19.360 --> 19:28.360 And we're in the field of public transport, and we move from A to B, we're geospatial related. 19:28.360 --> 19:42.360 So it's not a very income and common to say that transport movements and also availability on locations should look at OGEC and OG features in special. 19:42.360 --> 19:48.360 OG features that way uses a lot of geospatial fabrication. 19:48.360 --> 19:53.360 So it's also reusing a lot of unknown standards. 19:53.360 --> 19:56.360 Tom PPI, a lot of them. 19:56.360 --> 20:06.360 Okay, very small short, Tom PPI is actually an open source community that was established in the Netherlands. 20:06.360 --> 20:13.360 During the mass pilots that were held there in the 2018 till 2022. 20:13.360 --> 20:19.360 And we created a common language to talk to each other. 20:19.360 --> 20:24.360 Two mass providers were actually the resellers and the operators. 20:24.360 --> 20:32.360 And that could be bike operators, scooters, jet cars, parking spots, trains, buses, everything is incorporated. 20:32.360 --> 20:37.360 So to do the perform to perform the operations, not exchange data. 20:37.360 --> 20:40.360 As we already mentioned, that's level one. 20:40.360 --> 20:42.360 We are on top of it, we're using this. 20:42.360 --> 20:53.360 And how we're going to do it, to do that, I just picked out a few end points that could have a could solve a complete minimum viable product. 20:54.360 --> 21:01.360 How to exchange, or now to book, to get offers to book an offer and get the ticket for it, 21:01.360 --> 21:06.360 a special normal use case in train operations. 21:06.360 --> 21:15.360 And yeah, as we, you can see, the end points always start with collections and end with items. 21:15.360 --> 21:22.360 That's one of the things that OGC demands and for the end points we require. 21:22.360 --> 21:26.360 And they're very intuitive for the most programs. 21:26.360 --> 21:29.360 They're very structural, they're having strict formats. 21:29.360 --> 21:32.360 If you want to go get information, you call a cat. 21:32.360 --> 21:37.360 If you do want to do something, you post an operation. 21:37.360 --> 21:42.360 And those things, those two basic rules we apply as well on here. 21:42.360 --> 21:48.360 As my, I always said, if you want to get something, you call a cat, and you get back georgation. 21:48.360 --> 21:57.360 So you can apply it on any technical component that's already in the market, because georgation is an accepted standard. 21:57.360 --> 22:10.360 So, in short, when you want to use a netx with these three different modules, in the top API, we need to have a landing page. 22:10.360 --> 22:13.360 That's a requirement from OGC. 22:13.360 --> 22:20.360 We only added one special thing, and that's why they actually actually trick is, I marked it in red. 22:20.360 --> 22:24.360 The low one, we supply as well, where the data is. 22:24.360 --> 22:33.360 So, if I'm, for instance, I'm delaying, here in the Belgium, in a bus operator, I can express all my data and netx. 22:33.360 --> 22:41.360 And when I want to book something, I can say, okay, I, in this case, this example is from a river from the Netherlands. 22:41.360 --> 22:53.360 So, we say, okay, if I refer to something that starts with the prefix R, AR, then it can be findable in the specified netx URL. 22:53.360 --> 22:59.360 So, there's somewhere on the internet, it completes a netx file from a river. 22:59.360 --> 23:05.360 And if I'm going to, I want to use the schedule stop point. 23:05.360 --> 23:13.360 As a starting point, I will say, okay, I'll start with R, schedule stop point, a tree dash, whatever. 23:13.360 --> 23:15.360 I have to look in this file. 23:15.360 --> 23:19.360 And there I can, the netx specification of the scheduled stop point. 23:19.360 --> 23:26.360 The same applies as well, not only for stop points, but actually for all concepts that we use. 23:26.360 --> 23:32.360 We use the bus lines, for instance, the surface journey, but we can actually, yeah. 23:32.360 --> 23:36.360 The netx exchange is also possible information about parking spots. 23:36.360 --> 23:38.360 We can provide the right to that as well. 23:38.360 --> 23:40.360 I'll refer to that as well. 23:40.360 --> 23:56.360 One important thing that is special to these OGC files, I try to depict complete geodation file. 23:56.360 --> 24:00.360 There's a bunch of features, and of course, at the bottom. 24:00.360 --> 24:03.360 It's not in any more of the other properties normally. 24:03.360 --> 24:08.360 There are the three things that are normal in a complete geodation. 24:08.360 --> 24:17.360 The features where all the special geodraphical items are in, and a properties body, where you specify what it is. 24:17.360 --> 24:22.360 And each feature in it, I picked them with a grey box. 24:22.360 --> 24:24.360 You can see is a geometry. 24:24.360 --> 24:29.360 And the pattern repeats, you have properties and a geometry. 24:29.360 --> 24:40.360 And geodation for OGC completory prescribes as well, that you have links, where you can have additional information or operations. 24:40.360 --> 24:52.360 So actually, what we in the top API do is we propose, if you call for offers, you get a geodation and each of them contains a complete offer. 24:52.360 --> 24:58.360 And at the bottom of the offer, you can see you can get details, or you can directly purchase it. 24:58.360 --> 25:05.360 And it refers to another endpoint in the top API way. You can directly book it. 25:05.360 --> 25:10.360 And of course, then the end user is somewhere. 25:10.360 --> 25:14.360 It has an interface to this geodation. 25:14.360 --> 25:21.360 And this app between it can use the different links to book or get details or whatever. 25:21.360 --> 25:24.360 But that's up to the implementer, what to put in there. 25:24.360 --> 25:29.360 You can even say, okay, I just provide the offer endpoint. 25:29.360 --> 25:34.360 And in the f, offer endpoint, I'll redirect you directly into my own app. 25:34.360 --> 25:37.360 It's possible. 25:37.360 --> 25:41.360 Okay, a little less detail. 25:41.360 --> 25:51.360 When you have the offer, you can execute the purchase endpoint that was already mentioned in the previous geodation. 25:51.360 --> 25:56.360 And you get back a purchase ticket actually. 25:56.360 --> 25:59.360 And you can, of course, execute it later on. 25:59.360 --> 26:08.360 But in the same termine, again, as the previous present day apart, you have to generate it again. 26:08.360 --> 26:13.360 And that represents a trip using the bus. 26:13.360 --> 26:15.360 And there you get in the links. 26:15.360 --> 26:20.360 The operations in there you can retrieve as well, the ticket. 26:20.360 --> 26:26.360 And then again, up to you. 26:26.360 --> 26:29.360 Follow us if you hold on. 26:29.360 --> 26:34.360 This is the last slide. 26:34.360 --> 26:41.360 Then the leaner pointed. 26:41.360 --> 26:45.360 Then we want to have some dialogue with you. 26:45.360 --> 26:49.360 We need something to change. 26:49.360 --> 26:55.360 How many of you have tried to use open data? 26:55.360 --> 26:57.360 Many. 26:57.360 --> 27:01.360 How many have succeeded using it? 27:01.360 --> 27:03.360 Quite a few. 27:03.360 --> 27:08.360 How many have tried it with the geodephas? 27:08.360 --> 27:12.360 And not text. 27:12.360 --> 27:16.360 Which is easiest? 27:16.360 --> 27:20.360 Yes. 27:20.360 --> 27:25.360 It's a geodephas. 27:25.360 --> 27:28.360 The quality and the richness is much better in that text. 27:28.360 --> 27:31.360 So we want to have that in Europe. 27:31.360 --> 27:37.360 So to succeed with that, we need to have net text native from the data sources. 27:37.360 --> 27:39.360 We are done that in Norway. 27:39.360 --> 27:40.360 Successfully. 27:40.360 --> 27:43.360 So it's possible for all of the countries as well. 27:43.360 --> 27:49.360 But we need maybe your help to push also internally in your country region. 27:49.360 --> 27:54.360 Behind me on the screen, you see the three different layers. 27:54.360 --> 27:59.360 The data producers, operators, within the transport, mobility. 27:59.360 --> 28:02.360 You see the national access point in the middle. 28:02.360 --> 28:09.360 And you see the data users on the other side. 28:09.360 --> 28:17.360 There are opportunities that are built open source tools in all those pillars. 28:17.360 --> 28:18.360 It's possible for you. 28:18.360 --> 28:21.360 So do you have any question for us? 28:21.360 --> 28:23.360 Before we. 28:23.360 --> 28:29.360 I haven't had to always have use cases where people are that interested in one, 28:29.360 --> 28:31.360 that we want to improve information. 28:31.360 --> 28:35.360 But the general overview where they can get my examples in American 28:35.360 --> 28:37.360 Google months ago into the new year. 28:37.360 --> 28:42.360 And it's totally confused of going from where can I go? 28:42.360 --> 28:45.360 I have the same issue with the Austin Open Association. 28:45.360 --> 28:49.360 But people just want to go to the mountain on the weekend. 28:49.360 --> 28:54.360 So my question is what's the current state of things like ice and cold maps? 28:54.360 --> 28:57.360 Why it just was that with general overview? 28:57.360 --> 29:03.360 Well, how long it's going to take to go from hospital to Budapest, 29:03.360 --> 29:07.360 or which is which is because of my use cases. 29:07.360 --> 29:13.360 People often ask in the details because if it doesn't know what's the name of the place. 29:13.360 --> 29:15.360 It's something like that. 29:15.360 --> 29:19.360 You can ask what you need. 29:19.360 --> 29:23.360 Do you repeat the question? 29:23.360 --> 29:24.360 Yes. 29:24.360 --> 29:28.360 So the question was about getting an overview of the data that exist. 29:28.360 --> 29:32.360 And especially if we take the perspective of a traveler that does not know the 29:32.360 --> 29:35.360 name of the mountain or the valley of the village where they want to go. 29:35.360 --> 29:38.360 But they just want to know where they can reach. 29:38.360 --> 29:40.360 Let's say if they arrive in Brussels. 29:40.360 --> 29:45.360 So that is one of the things that the European project, 29:45.360 --> 29:48.360 NAPCO, but also deep raw EMDS. 29:48.360 --> 29:51.360 That is more on the European mobility data space. 29:51.360 --> 29:52.360 But let's focus on NAPCO. 29:52.360 --> 29:57.360 NAPCO is trying to give as much as possible a lot of data in the text. 29:57.360 --> 30:05.360 And they have worked on metadata to describe roughly what is inside the data sets. 30:05.360 --> 30:11.360 Using the mobility decats, I think AP, that is for metadata. 30:11.360 --> 30:16.360 But on top of it, there is also a talk that some work will start in 2026. 30:16.360 --> 30:22.360 Inspired by the Norwegian registry of stop places to get one at the European level. 30:22.360 --> 30:28.360 So if we manage to do that within 27 plus 3 member states, 30:28.360 --> 30:32.360 at least if we get a global vision of all the stops are, 30:32.360 --> 30:35.360 I guess it will be the first step of making it easier for people. 30:35.360 --> 30:38.360 I'm not saying it's going to be so easy, but I, 30:38.360 --> 30:42.360 Brother has been very good to push the Norwegian solution into the European Union. 30:42.360 --> 30:45.360 So they're kind of like our best member state when it comes to that. 30:45.360 --> 30:48.360 And there's a second layer to that. 30:48.360 --> 30:52.360 Hopefully, in 20, at the end of 25, only 26, 30:52.360 --> 30:56.360 there will be a new regulation coming that is called MDMS, 30:56.360 --> 31:00.360 that will demand for ticketing system to get open, 31:00.360 --> 31:06.360 where we can actually see where are the different stop points and ticketing options 31:06.360 --> 31:09.360 from A to B throughout Europe. 31:09.360 --> 31:11.360 But again, this might take a little bit of time, 31:11.360 --> 31:13.360 and it's also where we need your help, 31:13.360 --> 31:17.360 because that needs to be filled with a lot of open data and open source solutions. 31:17.360 --> 31:22.360 Yep, do. 31:22.360 --> 31:23.360 I don't know. 31:23.360 --> 31:25.360 There's been great of the time. 31:25.360 --> 31:28.360 We've had the country having this own entity, 31:28.360 --> 31:31.360 how do you make sure that international journalists are in, 31:31.360 --> 31:34.360 like, coping everywhere or more. 31:34.360 --> 31:38.360 That's something that you see. 31:38.360 --> 31:44.360 Yeah, the question is, when you have a 30 different NAPs, 31:44.360 --> 31:48.360 how can we secure that data to be accurate useable? 31:48.360 --> 31:53.360 That's something that we work within the NAP core project. 31:53.360 --> 31:59.360 Up to now, every country has decided or produced their own net text on profile. 31:59.360 --> 32:03.360 So when they try to use net text data from our name-in-country, 32:03.360 --> 32:08.360 you're not possible to use without hard special integrations. 32:08.360 --> 32:11.360 So we are now talking about in Europe, 32:11.360 --> 32:17.360 to harmonize our national profiles into one joint profile, 32:17.360 --> 32:21.360 then we can share data that can be just downloaded and used 32:21.360 --> 32:26.360 as we are familiar with the GTFS data. 32:26.360 --> 32:29.360 In addition to this one. 32:29.360 --> 32:32.360 An additional thing that is confirmed in the market right now 32:32.360 --> 32:37.360 is that actually we want to create something of a federated system 32:37.360 --> 32:41.360 where national access points are derived from it, 32:41.360 --> 32:45.360 can, on a federated way, rely questions. 32:45.360 --> 32:49.360 So if I'm getting a question in the Dutch national access point for cars 32:49.360 --> 32:51.360 or trains in Spain, 32:51.360 --> 32:55.360 it's related to the Spain national access point and the answer is repeated back. 32:55.360 --> 32:57.360 But that's something that's different. 32:57.360 --> 32:59.360 It's not completely in NAP core. 32:59.360 --> 33:00.360 We're trying to do it. 33:00.360 --> 33:04.360 To get it into NAP core, maybe we have to succeed it right now, 33:04.360 --> 33:06.360 but let's see. 33:07.360 --> 33:09.360 This is a few months ago. 33:09.360 --> 33:13.360 I tried to make it to which for train, train, 33:13.360 --> 33:20.360 train, train, and I stumbled upon to get to the timetables. 33:20.360 --> 33:26.360 The official timetables you can find through the applications 33:26.360 --> 33:29.360 of the operators and so on and half fast and so on. 33:29.360 --> 33:34.360 Need to pay 15,000 euro a year to access to these data 33:34.360 --> 33:37.360 and it's in a format of the 1980s. 33:37.360 --> 33:41.360 Something is that soon to be replaced by this 33:41.360 --> 33:45.360 and is there will there be a fee to pay or something? 33:45.360 --> 33:49.360 Or is it like really for everyone? 33:49.360 --> 33:53.360 If I guess you try to use rail data, 33:53.360 --> 33:59.360 the rail is collecting all the accountable data 33:59.360 --> 34:02.360 into a U.S.E. merit database. 34:02.360 --> 34:06.360 That's data is something that they sell. 34:06.360 --> 34:11.360 There are not going to be any plan changes for that, 34:11.360 --> 34:14.360 but when we are talking about the national access point, 34:14.360 --> 34:17.360 there's a different data set. 34:17.360 --> 34:25.360 Today, Norway has opened a free rail data in NAPX. 34:25.360 --> 34:29.360 We send a NAPX data to the managed database, 34:29.360 --> 34:33.360 which take and work into the data format they use in merits. 34:33.360 --> 34:37.360 And in that process, the Norwegian data is destroyed. 34:37.360 --> 34:41.360 They are replacing all the ideas in Norway that are structured 34:41.360 --> 34:47.360 and unique is something that is unique in the mayor database. 34:47.360 --> 34:51.360 But when you start and try to add on real-time data 34:51.360 --> 34:54.360 from Norway and so on, it doesn't play. 34:54.360 --> 34:59.360 So what we need to do in Europe is to get better data 34:59.360 --> 35:01.360 also in a national access point. 35:01.360 --> 35:03.360 The managed database will continue to be there, 35:03.360 --> 35:06.360 as useful use cases. 35:06.360 --> 35:09.360 But the data should also be available in that text. 35:09.360 --> 35:11.360 In a national access point, 35:11.360 --> 35:16.360 and it's up to each member state if there is a fee on that or not. 35:17.360 --> 35:21.360 So in the 27 countries should be agreed, 35:21.360 --> 35:24.360 kind of compromise. 35:24.360 --> 35:28.360 We hope that all of them is providing a state of a free. 35:28.360 --> 35:34.360 But there's also a certain regulation that says that 35:34.360 --> 35:40.360 you have only allowed to take recent amount on cost for that. 35:40.360 --> 35:47.360 So you don't see that sums here. 35:47.360 --> 35:50.360 But if I can add to that, that's also the spirit of the TSI 35:50.360 --> 35:54.360 telematics that is upcoming that will try to support better open data 35:54.360 --> 35:56.360 for at least the public information. 35:56.360 --> 35:59.360 So the time table, which is the schedule information. 35:59.360 --> 36:02.360 In a text, some national access points have already moved forward. 36:02.360 --> 36:06.360 Anophysical for France, data from SNCF is available in both DTFS 36:06.360 --> 36:09.360 and the text on the national access point. 36:09.360 --> 36:13.360 You can don't know it for free, and you can, like, pay with it if you want. 36:13.360 --> 36:18.360 But every single country will have a different opinion on this. 36:18.360 --> 36:21.360 So one last question. 36:21.360 --> 36:23.360 Can you talk about that? 36:23.360 --> 36:26.360 Just like that. 36:26.360 --> 36:28.360 How is quality of data? 36:28.360 --> 36:30.360 Yeah. 36:30.360 --> 36:32.360 Okay, person. 36:32.360 --> 36:38.360 The problem of quality of data is there an activity to enforce the quality of data 36:38.360 --> 36:41.360 to avoid simple problem. 36:41.360 --> 36:42.360 Shit in, shit out. 36:42.360 --> 36:46.360 If the data is inaccurate, whatever we are doing, whatever we are doing 36:46.360 --> 36:48.360 is absolutely nonsense. 36:48.360 --> 36:51.360 If you have no accurate data, especially real-time data 36:51.360 --> 36:55.360 and for my perspective, current applications are showing a lot of information. 36:55.360 --> 36:58.360 But in a lot of cases, it's just not true. 36:58.360 --> 37:03.360 So you have application, you have information, but you can just watch the numbers. 37:03.360 --> 37:06.360 It doesn't give you the information you can use. 37:08.360 --> 37:11.360 Check it, regression. 37:11.360 --> 37:17.360 Up to now, it's not any good results there. 37:17.360 --> 37:21.360 In the new net correct starting next summer, 37:21.360 --> 37:25.360 there will be a working group of quality. 37:25.360 --> 37:29.360 I hope that we all see that we have the net access data 37:29.360 --> 37:34.360 that we can use on our online and make automatic analysis of the data 37:34.360 --> 37:44.360 and have visual ports that shows the quality level between different data sets. 37:44.360 --> 37:47.360 And compare different countries. 37:47.360 --> 37:52.360 And also to add to that, some national rights points have decided to go forward 37:52.360 --> 37:54.360 with the name and shame. 37:54.360 --> 37:58.360 So they are starting to roll out this summer using their validation tool 37:58.360 --> 38:01.360 on data sets for example in a text that if it's really bad, 38:01.360 --> 38:02.360 you'll have coloring. 38:02.360 --> 38:06.360 And we hope that it will force data producers to produce better quality 38:06.360 --> 38:09.360 if everything is dark red. 38:09.360 --> 38:12.360 Thanks a lot for the questions.