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