So, welcome everybody. My name is Hannes Jornilla. I've worked with OpenTrip Planner, which is
an open source journey planner, quite similar to the MOTIS project for almost 10 years now,
a bit on and off, so with other projects as well, and for all kinds of different
organisations both in Finland and now at the moment in Norway. But before we talk about the
project itself, I would like to say a couple of words about Entur. So, I don't think Entur is
as famous company as some of the other ones that we have today, but it's actually, it used to be
a part of the Norwegian state railway company, and it was carved out when competition was introduced
in the Norwegian railway system, and nowadays it takes care of all ticketing, all public transit
timetable information in the whole country of Norway. And we use almost exclusively open source
software, at least in our team, which handles the incoming transit data, all the journey planning,
all the APIs that we provide for all of the railway companies, all of the other hobbyists
that want to have a journey planner, API, or like a screen at their home, any kind of API we can
provide that. And here in the middle is open tree planner, which is quite the key component.
So, first, I will talk a bit about the past. So, how did we come here? What was open tree
planner in the origin? How has it evolved over the years? What were some pain points in the
history? Then I will spend most of the time with open tree planner 2, which we released two years
ago, and have since continued to develop. And finally, I will have a couple of minutes to
discuss some topics that we will be implementing in the future. But before I start, I would like
to see in the audience, how many of you have heard about the project before? Can I have some
hands? So, about a half, I would say. How many of you have actually tested it yourself? So,
almost as many, which is a good sign, because I think it's very important for an open source
project that it's easy to get going with it. It's easy to take into use. And yeah, as I mentioned
already in the beginning, open tree planner or OTP, as I will probably reference it, is quite
similar project to the MOTIS project that we have had presenting. So, it's a passenger information
system for transit data and other multimodal services, and it handles journey planning,
but it also has APIs for just querying the data. So, here we can see how the number of
commits to the repository has been over the years. So, it started in 2009 in Portland, Oregon,
in the US, and they wanted to build a journey planner that was open source. So, they took in
people that had been contributing to other libraries or projects that involved journey
planning, transit data, other kinds of projects and took them into the room and said, okay,
we'll give you money, just build us the software. And then, about a year later, it was put into
production, and in 2013, the people involved started a company called Conveil, which took over
the maintenance. But over the years, that company has actually gone more towards the
direction of transit analysis, so doing software for the different cities, the different transit
authorities, similarity what we actually have already seen today. But in 2013, a really
important step was taken. There was a big project with the Dutch government for improving
multimodal transit data and real-time data. But at the same time, there was a second project
that was included in the bigger Dutch project called R4, which was implementing the Raptor
algorithm in an open source. And then, it was later rewritten in R5, which is a software
by Conveil. 2016, there was new deployments in Washington, DC, the New York State, Oslo,
Helsinki, so a bit all over the place, and there was some trials with nationwide scaling.
But then, the project kind of stagnated until 2018, 2019, when Entoor and Router two Norwegian
companies took over the responsibility and ported over the Raptor algorithm from the
R5 project into OpenTrip Planner. And then, in 2020, we released the OpenTrip Planner
2. And here you can see, if I overlay the commits for the R5 project, you can see that,
well, it was the project that took the focus in the meantime. So, what were the main pain
points with OpenTrip Planner 1? The core issue is the journey planning algorithm that was
selected. So, there was a time-dependent A-star search with trip banning that used over the
whole network. So, both street network, transit network, the multimodal stuff, everything was
in the same algorithm. And how it worked was that you run a search, then you get results,
you ban all the trips that you were using, and then you rerun. So, it didn't scale that
well when you wanted to have more results or a longer or larger graph. And also, it
was more focused towards research capabilities. But these were then later on taken over by
R5. And we removed quite a lot of this from OpenTrip Planner 2, focusing on the journey
planning part. Also, there was a lack of kind of vision of where it should go, how it should
be structured, everything. And also, there was development happening in many different
repositories, and it was not really well-coordinated. So, for example, HSL, where the Digitransit
project is, or who owns the Digitransit project, they have their own fork of the project that
has quite a lot of added development. But that has now been mostly ported back to OpenTrip
Planner 2. So, let's take a quick look at how it works. I think this is the main difference
between OTP-1 and OTP-2. In OTP-1, as I said, all of the routing was done inside one single
search. In OTP-2, we first get a request from the API. Then we run a street search. It's
basically an A-star search, but just with a single mode, or with different modes if you
want to have rental bicycle, rental scooters, parking your car, or anything like that. Then
we enrich this with flexible transit results for the last and first mile. Then we do a
transit search using the Raptor algorithm. And finally, we have two post-processing steps
that I will talk a bit about later on. And then we send the result out in the API. So,
the street search is actually pretty much the same as it was in OpenTrip Planner 1. There
is some improvements. There is, for example, free-floating vehicles, new types of vehicles,
so scooters, real-time parking information so that if you do a park-and-ride search,
it will actually only be suggested to park at a place where we know that there probably
will be space. And also, there is improved focus on this kind of quality of the routing,
so there is a walk safety score so that we prefer, for example, walking through nice
gardens or other paths that are not next to a big motorway. Yeah, so I mentioned flexible
routes. So, most of you would assume that this is, or think about this when you think
about transit timetables, so that you have fixed set of stops, fixed set of times. But
there is many other ways that transit can be structured. So, you can have, for example,
hail-and-ride sections where you actually don't have any stops, but you can just flag
the bus anywhere you want. Or you can have areas, just one, two, or as many as you like.
And the bus will deviate from its pre-assigned route and just drop you home or pick you
up from the door. Or it can be a group of stops, some kind of feeder services that take you
to the nearest railway station if there is no regular transit in the village. Or it can
be as complex services as we like with any kind of combination. So, after we have added
the flex results, we do a Raptor search where we insert all the street routing results,
all the flexible results, and then we operate only on trips with fixed schedules and fixed
stops. So, there is actually multiple levels of Raptor. So, Raptor is a algorithm that was
introduced in 2012 by a researcher from Microsoft Research. And the basic Raptor, it has two
criterias. So, it has arrival time and number of transit, and it departs at a fixed time.
Basically, what you do is that you find all of the stops that you can walk to or make
the street routing to, then you board all the vehicles from those stops, then you alight
at every possible stop and find where you have arrived. Then you find all of the transfers
from those stops to all other stops, and then you continue this in new rounds. So, this
finds your results with the two criterias, the one with the shortest arrival time and
the one with the least transfers. Then you can run this Range Raptor, which is basically
just running the Raptor algorithm, but you start at the minute and then you run it backwards
and adding new results to the beginning as you go. And then you get this tree criteria
result that has the departure time, arrival time, and number of transfers. And that creates
this kind of set where you have the departure time, arrival time, and number of transfers
are all optimal. Then you can insert one or more criterias, like we're talking about
that you want to optimize for CO2 usage or wheelchair accessibility or comfort that you
only want to use transit that is not too crowded, any kind of numerical value you can
add as a criteria, but that unfortunately has the downside that it quite heavily affects
the performance. Yeah, so this is basically how we do. This is the result of the one round
of Raptor search. This is of the two, three. You only add a few other leaves and then the
last you just basically prune the results so that there is some where it's optimal to
actually not use a trip with just one transfer, but you need to transfer many, many times.
Then we do a process called transfer optimization. And this is especially in the railways where
you can transfer between two trips at multiple stations. And it's actually the end result
will be the same, independently of where you transfer. You will get home at the same time,
but it might be nice to transfer somewhere where you have a roof over you, or maybe
you have, if you have like one hour of time, you want to spend somewhere where you have
access to a cafe, or then you want to make sure that you have a high probability of getting
your transfer. So the one that is has the longest waiting time. And a specific type
is this kind of back travel that you want to avoid that if you go from the blue dot
to the red dot, you don't want to ride all over the last stop and then all the way back
because that is most probably quite expensive. Then we do itinerary filtering and decorating.
So the aim from the Raptor is to get as much results as possible. And then here we can
make more intricate comparison between different results. And we can prune results that might
be optimal, but are really bad compared to other ones. So for example, you might want
to have, or you might have a result where you have just one, like no transfers, but
you are expected to walk 45 minutes. And that's not really you probably want to do if you
have a possibility to do it in 50 minutes less. Then a big thing in OpenTrip Planner
2 was the inclusion of a separate data model. So prior in OTP 1, the data model was based
on the GTFS vocabulary and all the data was imported as the GTFS objects. But in OTP 2
we have an internal data model that is built so that we can import transit data from both
netx and GTFS. So it's independent of data source and we can easily add new data sources.
So there was for example a Swiss data set that somebody was looking at in importing
into OpenTrip Planner. Then something that became really popular is the sandbox extensions.
So we introduced a mechanism for plugging in an optional plugin into OpenTrip Planner
2 and this has been really successful with currently 22 different extensions existing.
So you can provide new APIs, new data formats, new functionality that is maybe not ready
to take into the core OpenTrip Planner but there is something that is in the process
of development. Or you might want to have some functionality that is custom for your
deployment but you want to make sure that it keeps up to date and that it's maintained
and that if you do some changes in the data model or any code code that we have we will
keep those updated.
So one extension is that we now have two GraphQL APIs, one that is based on GTFS vocabulary
and one that is based on Transmodel Vocabulary. And you can use import data for example in
Skåne in the south of Sweden. They import Swedish timetables in netx and Danish timetables
that they use for trips to Copenhagen in GTFS. And then you can use this unified API where
you provide the data in standard format so that if you want to have the results in GTFS
vocabulary you can get that but you can also get in Transmodel Vocabulary if you want it.
And also GraphQL is really useful for this kind of journey planning purposes because
usually you want to fetch little information about very many objects. And if you have this
traditional very rest pure way you end up having like hundreds of queries that you need
to do but with GraphQL you can fetch exactly the things that you need and only those and
that also saves quite a lot of space for mobile apps where you can limit the number of downloaded
bytes. Then we have vector tiles so you can query all the geometric information that we
have just spatial information so all the stop stations, rental stations, even individual
rental vehicles, car and bike parking and so on. And you can add real time information
for those so that you can easily show a map where you have like the live availability
of all the rental systems. And then one feature that actually we bought back from OTP2 was
that that was removed as a sandbox extension and that is the travel time analysis. And
this is a feature that sits somewhere between pure journey planning and pure research applications
because this is really useful for some applications where you for example you are looking to buy
a house and you can easily see okay like the on the web page of the seller they can show
like this map that okay this is the area where you actually can get into with public transit
in 15 minutes or buy car in 15 minutes or buy rental bikes in 15 minutes. So all of
this is multimodal and you can export both geogasin so the borders of the areas or you
can get a geotiff with actual second values of how many seconds does it does it take to
get to this pixel on the map. One other big improvement that we did with OpenTriplanner2
is that we simplified the operations. OpenTriplanner1 expected that you always have a local file
system and that you always have all the files on the local file system. But we abstracted
this into a data source that is can be input or can be output or can be both. And currently
we have local file system so you can still have everything in the local file system
if you wish. You can fetch files over HTTPS and you can load and save data to all cloud
storage services or at least all the major ones and it's really easy to create your
own if you want. Yeah also there is improved monitoring support so you can get all the
timing data of the internal algorithms really easily. We improved quite a lot of the documentation
so you can find the link over there and actually with that new configuration structure this
is all that you need in order to fetch all the data and build the graph for the entirety
of the Belgian country. So you have four different operators. You just say that these are the
paths to these. You can also say if you would have like for example the German netx feed
you could have there as well and multiple open street map files. And with different
tag mapping so different countries have different rules and regulations of whether you are allowed
for example to walk on a bike path or if you are allowed to drive on the street if there
is a bike path next to it and so on and that's why we have this customizable tag mapping
so that each country or even city can have their own rules about how these things should
be mapped. Yeah then a bit about the future what we are planning to do next. We of course
continue all the time with feature development so we have built now during the winter via
search that was not part of the initial OTP to release so that you can say that oh I want
to go from here. I want to go to my hotel but actually I want to visit this bar in the
between so you can get all the connections that are from here to the bar then you say
that okay I want to spend about two hours in the bar and then you will get the results
about two hours later from the bar to your hotel. The second one is GBFS geofencing areas
so that you can limit where you can actually use your scooter if there is some places where
you don't if you can park it you will be instructed to actually park it just before
the zone starts or if you have speed limits it might be beneficial to drive around those
speed limits. Then performance is something that we think is very important we have been
focusing more and more of it and we started actually measuring it so we run a set of queries
after each commit and we store them in a Postgres database and then we have a nice dashboard
that's where you can go to and see how we have been doing over time and we have multiple
data sets. It's so that if somebody is using this in production we can add their data set
so that they can see how their data set is performing because different data sets have
quite different performance characteristics because you might have a very large network
or you might have a network with very strange timing conditions or other things that might
affect it. We are also working on new internal data model for the timetable data that is
better suited for Raptor that uses a virtual trip for heuristic calculations so that you
don't actually need to do any timetable lookups and it's better memory or it's more memory
efficient. So for example we noticed that most timetables actually only operate on full
minutes and are less than four hours and a quarter so you can store them in just one
daytime and an array of bytes. Then one thing that is actually touching there was a question
about the international deployment so we run currently in Norway we run a Nordic graph
that contains data for all the Nordic countries but we are working on this segmented or tiered
model where we actually separate the transit networks into local and long distance and
then we split those into smaller and we only take in the routing data that you need for
your search. Then there is this competition neutrality so in Norway we have commercial
bus operators and we have their data and unfortunately they do some awful tricks so for example they
might schedule a trip that starts one minute later than the competitors and arrives one
minute earlier and that way you actually drop the other operator completely from the results.
So what we are planning is to add a Raptor criteria where we have a bit set of the commercial
operators used and that makes it so that we will always suggest all the available options
even though they are not optimal as long as they use a different carrier. And we are also
planning for a unified GraphQL API where we would have one data model, one structure
but two dialects, one for GTFS and one for Trans model in order to lower the overhead.
So that was it, thank you very much. I think we might have time for one, two questions
so if there is anybody in the audience. Yeah.
Thank you for the presentation, that's very impressive regarding pedestrian routing. Yeah.
So we take the data from OpenStreetMap and some areas have it better mop, some have it
worse and we also use if you have in your GTFS we use this Pathways extension so you
can model the inside of the train railway station and then we just link not the innards
of the railway station but the entrances and then the inner model comes from the Pathways.
There is also something similar available in netx but that we don't import at the moment.
Yeah.
Do you understand correctly that you have demand responsive?
Yes.
Yes. So that was the part about the flex search that is the second part before the timetable.
So at the moment we only use it for first and last mile.
But you only interface with external APIs to do their calculations?
No, we don't do any availability so we just say that it might be possible to take this
but you need to plan but that is something that you can implement in a filter so that
the filter actually does the query of okay is this possible and then you can enhance
the result with that data.
Yeah.
Very short question because there is no time.
Yeah.
So let's tell you international point of view with a different aspect optimization.
Yeah.
And so speed of transport with high speed train between Brussels and Berlin you pay a lot.
Yeah.
So when you go with the train and with the pedestrian you have the cheaper solution.
Yeah.
The bicycle is the optimal solution for me.
Yeah.
But I can just answer quickly that price is something that you can use as a Pareto criteria
but the big problem is that there is so much dynamic fears that exist today that it's impossible
to use it because there would be the.