Okay, please have a seat, we have to begin, do as you can, all right, hi everybody again,
we meet Volker Kosser, he will explain us what he's doing on Caddy E and he's come from Germany
and we're very pleased to welcome him. Go on. Thank you. Okay, so yeah, I'll talk a bit about
how we use public transport information in Caddy itinerary. So what is this? Caddy is a big open
source community, so not a transport operator for once here. We do all kinds of stuff, you can
find us in the K building on the second level to look at a few things we do and one of the things
we do is an transport assistance app called itinerary. So in that you can import any kind of
travel related things like flights, train trips, bus trips, hotel reservations, event tickets, etc.
and that is then grouped together and put into a timeline so you have all the relevant information
at hand when you need them and we augment that with whatever might be helpful along the way,
like the weather forecast as the obvious example. Since we don't really have a lot of time, I'll
have to dive right into what we do with public transport data, you'll see some of the features
along the way. So the first problem is we need to actually understand where you want to go,
ideally without you having to enter that manually but by reusing documents or material you already
have. In the best case scenario, that material has machine readable annotations about your trip,
there's something that Gmail has been promoting but outside of airlines I think in Europe at least
we have only seen that for Flix, bus and train line so none of the major railway operators for
example have that. But there is a second best thing and that is the ticket barcodes. Most,
not all of them but luckily most contain some information about the trip and especially in
international use they are somewhat standardized so we actually have a chance to understand what's
in them. The probably most well-known one is the one from airline boarding passes that is a single
standard that works globally so that is the absolute best case scenario, only one thing we
have to implement. For railways we don't have that luxury but the European Railway Agency has at
least defined a few standards that are in use in Europe for international travel and in some
countries also domestically. The complexity of those standards varies greatly. The airline
boarding passes for example that is a simple ASCII string that is almost human readable,
that's as easy as it gets. The latest iteration from the European Railway Agency for the international
tickets here, the flexible content barcode, that is 2,000 lines of ASN1 specification defining
300 or so mostly optional fields with some unaligned packed encoding representation so awesome to
debug but extremely powerful. That's the ultimate other end of complexity then. Just because it
is standardized doesn't automatically mean this is also all openly available. Again,
the European Railway Agency is the good example here, they have that on the website. If something
is missing you ask them, they put it on the website, perfect. Some of the other organizations ask you
for unreasonable amounts of money to get a PDF or require you to be a member and for that you
need to be an airline or railway agency which we are not. Some of those systems have cryptographic
signatures which we usually don't care about because we only care where you travel not if the
ticket is actually valid but in one case the 44E ticket used in some areas in Germany in Luxembourg
the signature and the content is somewhat intermixed so we actually need to decode that and just
because something is called a public key doesn't mean it's actually public on the website. In this
case we got lucky. Extensive internet search found a hundred page PDF in a location where
probably shouldn't have been containing a screenshot where we found an URL pointing to an
ill-app server on which we found the keys so it can be quite messy to work with this stuff. Most
of the standards have operator specific extensions, those of course are not documented. For the final
point is there anyone from Tranitalia here? Too bad I have questions for them. Then of course
there's also a set of proprietary codes where our only option is reverse engineering. For that we
rely on donations of sample tickets because I mean everything we do is very much focused on
privacy so once on your own device we never get your actual tickets so we need them donated
right to work with them. There were ones listed here for those we have more or less understanding
some we get enough out of it to work already for some we can barely prove that there is
actually travel relevant data in there but we have no way of decoding that. For me the most
frustrating one is SBB because that is a fairly comprehensive format we understand most of it
apart from the daytime fields and without of that it is pretty much useless right so if there's
anyone here from SBB who has hints or information on how those tickets work I would be very interested.
Then once we actually know where you're going and we have that in the timeline we augment that with
real-time public transport information. The most obvious example is delays and disruptions,
cancellations, platform changes, that kind of stuff right so we notify you about that. Another
thing we do is filling gaps in the itinerary right so I to get here I book a train from Berlin
to Brussels but I actually need to go from my home to the station then take the train and then in
Brussels somehow get from the station to my hotel with using the respective local public transport
so and that that is something we we can fill in automatically. And then the third thing is when
you miss a connection right we offer you to to find alternatives for getting to the same destination.
In order to implement that kind of stuff we kind of need to get to that data and there's
unfortunately not a single global service that gives us to us right so we need to query many many
different sources depending on where we currently are which backend can actually provide us this
information. So we have a bit of an abstraction layer over all those sources which basically
offers three basic operations searching for locations by by name or coordinate searching
for arrival and departures at a specific stop and searching for journeys from from A to B.
And on top of that we then build the the higher level features. In terms of supported backends
that is basically three different categories the fully open source ones those are the easiest
ones to work with like Navisha, OpenTrip planner. Motors is still missing on that list simply because
there is currently no production deployment we have access to as soon as there is one we'll add
that as well. Second category is things where the protocol is at least documented like the
open journey planner used in Switzerland and the third one the most annoying ones to work with
is the proprietary legacy backends. But just having the protocols of course is not enough we also
need to know where exactly are those and the respective services for that. For that there is
the transport API which is three that's a collaboration with others having that same
problem like Janice and that is basically a collection of machine readable information about
those those services. Both where exactly do I need to connect there which protocol do they use
specific parameters I need to use but also information like the coverage area because
in for most of those services that is kind of implied right if I have the Belgian transport app
right the scope of that is implicit. Navisha is the exception that actually has API for querying
this but if I want to pick the right back end right I of course need that information. Very
similar problem all of what you see here is what journey query would describe as metro line one
but the signage is very very different depending on where you are and the signage is something
that is very prominent locally right so if I I should show the right thing in the app in order
to to help the user to to find the right thing. But this isn't this isn't really unique right so
finding the right logo is somewhat tricky. What we do there is we get the logo and the colors
and all of that information from Wikidata. The Wikidata entry is linked to an OpenStreetMap
route relation from that we get the geographic bounding box and the combination of geographic
bounding area name and mode of transport is mostly unique and that is then good enough to to find
the right logos. Okay then a few more things we integrate one is available rental vehicles so
rental bikes electric kick scooters that kind of stuff. What you maybe can see in the screenshot
here is a few available kick scooters some shown in green some shown in yellow the yellow ones are
those with a remaining range of less than five kilometers. All of this is is coming from GBFS
that is a nicely developing open standard for for that kind of information and it is very actively
evolving. Just one or two years ago we wouldn't have that level of detail available so that's a
very nice example of open standards and open sourcing in that field. Coverage for that is
somewhat biased towards Europe and North America though. I know that those systems exist in Asia
as well but I have no idea if they if they use GBFS as well or if there's any other system so
again something where I would be interested in in information. Another thing we integrate on the
train station maps is the real-time status of elevators and escalators so I think in this case
they're all shown in green so they are actually functional. This is of course something very
relevant if you're traveling say with heavy luggage a stroller or in a wheelchair. The
data source for that is accessibility cloud that is the backend behind realmap.org. That's
also free software and they aggregate these kind of information from from many different sources.
There is a bit of a coverage bias towards Germany so similar data from other countries would be
more than welcome. Another thing where we have a coverage problem is train coach layouts. I think
there's currently two or three countries where we are getting this. Still is widely different
data models so it's not quite clear yet how we best abstract that and that is also somewhat
relevant on especially only the long distance trains which can get up to 400 meters so you
want to know where exactly you need to go on a platform especially if you're in a hurry. One
challenge there is that the especially in the countries where we have that open street map
doesn't contain many of the platform section informations and that is the key to match those
two data sets together to have the the proper train layout displayed correctly on the actual
station map. If you think further towards say indoor navigation in a train station like that is
kind of relevant. Pushing this topic even further would be to also show insights of the train.
At least Deutsche Bahn has very detailed PDFs for human consumption of the of the interior
but there is currently to my knowledge no machine readable format say like OSM for trains and that
is again relevant for accessibility for example right so I need to know which parts I can go
to and which parts I can't go to and then the the last part that is very very recent a lot of
work on that happened just yesterday is using the onboard APIs on trains. So if you connect to
the onboard Wi-Fi there is often some kind of portal page showing you information about the
current trip that's powered by some API that we can use as well. Typically this gives you
current position speed and heading and information about the journey with delays on on each stop.
Just showing that is of course the easiest way to to integrate that but the real value comes
when when we use that for higher level features again for example checking if you're on the
right train might seem obvious but if you're traveling in the country where you don't speak
the local language or in case of a multi-set train that splits up along the way. Zugteilung
in Hamm as we say in German right it's it's quite helpful if the software double checks that same
for detecting if we have arrived yet that is something very very easy to realize for the
human but it's actually surprisingly tricky for for the software to know. Yeah so all of these
things I've shown you are not tied to the app specifically but are available as reusable libraries
and for example next cloud is using the ticket data extraction in their email client so you
can automatically add calendar entries for your ticket when you get them by email and I think
there is much more that can be built on top of all this. I mean the itinerary app is basically for
the irregular explicitly booked kind of travel but doesn't touch the commute use case at all.
If you happen to know about any kind of relevant APIs or data sets or have the documentation for
those or for ticket formats like we would be very very much interested same if you have travel
documents past present or future that you are willing to donate to develop the extractor on
that we are happy to take those as well. Yeah thank you.
You're talking about getting live train data from the train. Can you do it from the location of the phone?
The position information we get on the train is essentially GPS just with a GPS receiver on
the train. In theory you could do that from the phone and the problem is that reception
inside a metal train is somewhat limited so you usually get better results by using the API for
that but it is essentially GPS data you get there so it's it's the same.
Yeah that is an annoyingly complicated topic.
The modality is awfully undefined. I mean there's neither a technical nor like a product level
definition on what is a subway or a metro or a tram and it can be all kinds of hybrid things.
That is one of the metadata we carry from Vicky data alongside the logos and so on so if in doubt
we use that but even that is there is some loss in there. I mean there's some cities where you
have trams that go on long distance railway outside of the city and yeah I mean we will
never be able to capture these extreme special cases that a region or operator specific app
can capture. So I mean that is the price we pay for that abstraction right and the one app that
works everywhere approach. One question you showed the data about the scooters and how it has
you said it's getting better and the coverage is better. What is driving this improvement? Is that regulation or why it's getting better?
That is a good question I don't know for sure. I know that in some cities it is regulation so if you
want to permit to operate your rental system in that city right you are required to publish your
feeds as GBFS and we then happily consume that. I think another part is that somehow started very
early by some US cities requiring that to to give out the permits for those systems and then that
kind of became the standard mode of operation for those services right. So if you get in very
early that works. I don't think there is like national or EU-wide regulation so this is usually
something that differs from city to city.
Regarding on demand traffic some of the routing engines have that in their results so we can show
that but we currently have nothing regarding actively booking things on demand or otherwise
because that is something where there is there's practically no API available for external users.
I don't think the the railway operators or the especially the inverse with the private operators
they they give that to to smaller users like us if they give it to to anyone at all.
You mentioned computing what about the case when I don't yet have a ticket but I want to make the
journey so for instance in Germany I had a bank card 100. Is there a possibility already to enter
that somehow? We also have like a general route search so you just specify where you want to go
and it offers you depending on where you start right the options from Deutsche Bahn or S&CF or
wherever you are and then you can add that to the timeline as well. So there is the the ability to
do manual entry for for that scenario but that would be quite cumbersome to do this every day
for your commute right. So there you would want something that I know I usually go to your office
between 8 and 9 in the morning so inform me if there any if there's any deviation on my usual
route but not necessarily make me enter this right.
You mean the checks for delays yeah that is polling there is none of those services we use
has a push service that we could use. Okay.