WEBVTT
00:00:00.000 --> 00:00:20.310
36c3 preroll music
00:00:20.310 --> 00:00:27.660
Herald: So, hey, we're finally ready to
start, we have Volker Krause here with a
00:00:27.660 --> 00:00:32.210
privacy by design travel assistant and
it's going to be about building Open
00:00:32.210 --> 00:00:38.449
Source travel assistants, I think, and
this talk will be in English. And if you
00:00:38.449 --> 00:00:43.600
want translations, wenn ihr eine deutsche
Übersetzung haben wollt, haben wir hier
00:00:43.600 --> 00:00:48.750
hinten auch ganz tolle Übersetzer in
unserer Kabine, da könnt ihr auf
00:00:48.750 --> 00:00:54.330
c3lingo.org mal reinhören, wie die alles
live mitreden. Genau. Now. Let's have
00:00:54.330 --> 00:00:58.270
a warm welcome for Volker here and have
fun with his talk.
00:00:58.270 --> 00:01:00.480
Applause
00:01:00.480 --> 00:01:06.400
Volker Krause: Thank you. OK, so what is
this about? You probably know those
00:01:06.400 --> 00:01:13.729
features in, most prominently Google
Mail, but I think TripIt was the one that
00:01:13.729 --> 00:01:21.130
pioneered this. So GMail reads your
email and then detects any kind of booking
00:01:21.130 --> 00:01:27.430
information in there, like your boarding
passes, your train tickets, your hotel
00:01:27.430 --> 00:01:34.609
bookings and so on. And it can integrate
that into your calendar and can present
00:01:34.609 --> 00:01:44.311
you a unified itinerary for your entire
trip and monitor that for changes. And
00:01:44.311 --> 00:01:51.529
all of that doesn't cost you anything.
Maybe apart from a bit of your privacy.
00:01:51.529 --> 00:01:58.850
Well, not too bad, you might think. But if
you look at what kind of data is actually
00:01:58.850 --> 00:02:06.280
involved in just your travel. Right.
The obvious things that come to
00:02:06.280 --> 00:02:12.440
mind, your name, your birthday, your
credit card number, your passport number,
00:02:12.440 --> 00:02:21.620
that kind of information. Right. But that
isn't even the worst part on this,
00:02:21.620 --> 00:02:27.590
because those operators don't just get to
see your specific data for one trip,
00:02:27.590 --> 00:02:33.099
right? They get to see every… everyone's
trip. And now if you combine that
00:02:33.099 --> 00:02:39.980
information, that actually uncovers a lot
of information about... relations
00:02:39.980 --> 00:02:45.030
between people, your interests, who
you work for, where you live and all of
00:02:45.030 --> 00:02:52.340
that. Right. So pretty much everyone here
traveled to Leipzig for the last four days
00:02:52.340 --> 00:03:00.099
in the year. If that happens for
two of us, once, right, that might be
00:03:00.099 --> 00:03:05.580
coincidence. If that happens two or three
years in a row, that is some kind of
00:03:05.580 --> 00:03:13.260
information. But yeah, what to do
about that, right? The easy solution
00:03:13.260 --> 00:03:22.450
is, just not use those services. It's like
first world luxury stuff anyway. That
00:03:22.450 --> 00:03:26.200
works until you end up in a foreign
country where you don't speak any of the
00:03:26.200 --> 00:03:31.940
local languages and then get introduced to
their counterpart of Schienenersatzverkehr
00:03:31.940 --> 00:03:39.200
or Tarifzonenrandgebiet. And at that
point, you might be interested in actually
00:03:39.200 --> 00:03:46.019
understanding what's happening on your
your trip in in some form that you
00:03:46.019 --> 00:03:50.329
actually understand and that you are
familiar with, ideally without installing
00:03:50.329 --> 00:03:54.650
15 different vendor applications for
whatever you actually might be
00:03:54.650 --> 00:04:02.780
traveling, right? So we need something
better. And that obviously leads us to,
00:04:02.780 --> 00:04:10.680
let's do it ourselves. Then, we can at
least design this for privacy right from
00:04:10.680 --> 00:04:16.299
the start. Build it on top of Free
Software and Open Data. Well, of course,
00:04:16.299 --> 00:04:23.780
we need to... at least it's not entirely
obvious that this will actually work,
00:04:23.780 --> 00:04:30.450
right? The Google and Apple, they have a
total different amount of resources
00:04:30.450 --> 00:04:37.320
available for this. So, can we actually
build this ourselves? So let's have a look
00:04:37.320 --> 00:04:46.360
at what those services actually need to
function. And it turns out it's primarily
00:04:46.360 --> 00:04:54.200
about data, not so much about code.
There are some difficult parts
00:04:54.200 --> 00:04:58.850
in terms of code involved as well, like
the image processing and a PDF to detect a
00:04:58.850 --> 00:05:03.310
barcode in your boarding pass. But all of
that exists as ready-made building blocks.
00:05:03.310 --> 00:05:11.160
So you basically just need to put this
nicely together. So let's look at the
00:05:11.160 --> 00:05:16.860
data. That's the more interesting part.
And in general, that breaks down to
00:05:16.860 --> 00:05:22.560
three different categories. The first one
is what I call personal data here. So
00:05:22.560 --> 00:05:29.530
that's basically booking information,
documents or tickets, boarding passes,
00:05:29.530 --> 00:05:33.350
specific for you. So there at least you
don't have a problem with access because
00:05:33.350 --> 00:05:40.390
that is sent to you and you need to have
access to that. But it comes in all kinds
00:05:40.390 --> 00:05:47.800
of forms and shapes. So there are the
challenges to actually extract that . The
00:05:47.800 --> 00:05:55.420
second kind of data is what I would call
static data. So, for example, the location
00:05:55.420 --> 00:06:02.300
of an airport. Now, you could argue that
that could change and there is rumors
00:06:02.300 --> 00:06:07.310
that some people apparently managed to
build new airports. I live in Berlin, so I
00:06:07.310 --> 00:06:15.630
don't believe this. Jokes aside, so,
"static" refers to within, static within
00:06:15.630 --> 00:06:22.360
the release cycle of the software. So
several weeks or a few months. So this is
00:06:22.360 --> 00:06:26.880
stuff that we can ship as offline
databases. And offline, of course, helps
00:06:26.880 --> 00:06:32.440
us with privacy because then you're not
observable from the outside. And the third
00:06:32.440 --> 00:06:41.570
category is dynamic data. So stuff that is
very, very short lived, such as delay
00:06:41.570 --> 00:06:46.410
information. There is no way we can do
that offline. If we want that kind of
00:06:46.410 --> 00:06:54.530
information, we will always need some kind
of online querying. Then let's look
00:06:54.530 --> 00:07:02.960
through those three categories in a bit
more detail. For the booking data, google
00:07:02.960 --> 00:07:08.380
was faced with the same problem, so they
used their monopoly and defined a standard
00:07:08.380 --> 00:07:16.360
in which operators should ideally have
machine readable annotations on their
00:07:16.360 --> 00:07:21.330
booking information. And that's awesome,
because we can just use the same, the same
00:07:21.330 --> 00:07:26.840
system. That's what nowadays became
schema.org, which I think Lucas mentioned
00:07:26.840 --> 00:07:33.910
in the morning as well. At least in
the US and Europe, you'll find
00:07:33.910 --> 00:07:41.860
that in about 30 to 50% of booking emails
you get from hotels, airlines or event
00:07:41.860 --> 00:07:49.600
brokers. So that's a good start. But then
there's the rest, which is basically
00:07:49.600 --> 00:07:57.150
unstructured data, random PDF files or
HTML emails we have to work with. There's
00:07:57.150 --> 00:08:03.611
Apple wallet boarding passes. They are
somewhat semi structured and most
00:08:03.611 --> 00:08:16.340
widespread for flight tickets. Well,
that's somewhat usable. And barcodes, so
00:08:16.340 --> 00:08:23.030
that's what you, again, see on boarding
passes or train tickets. I could
00:08:23.030 --> 00:08:29.420
probably fill an entire talk just with the
various details on the different
00:08:29.420 --> 00:08:35.120
barcode systems, the one for boarding
passes, I think, Karsten Nohl had to talk
00:08:35.120 --> 00:08:40.970
at Congress a few years back, where he
showed how they work and what you can do
00:08:40.970 --> 00:08:50.280
with them. Instagram #boardingpass is a
very nice source of test data. The one
00:08:50.280 --> 00:08:54.670
that you find on, on German railway
tickets is also pretty much researched
00:08:54.670 --> 00:09:00.451
already. The ones we actually had to
break ourselves were the one for Italy. I
00:09:00.451 --> 00:09:04.680
think to my knowledge, we are the first
ones to publish the content of those
00:09:04.680 --> 00:09:13.070
binary barcodes. And we are currently
working on the VDV Kernapplikation
00:09:13.070 --> 00:09:18.451
E-Ticket, which is the standard for German
local transportation tickets. That
00:09:18.451 --> 00:09:24.170
actually has some crypto that you need to
get around to actually see the content. So
00:09:24.170 --> 00:09:30.550
there is, if you're interested in that
kind of stuff, there is quite some
00:09:30.550 --> 00:09:39.180
interesting detail to be found in this.
But let's continue with the
00:09:39.180 --> 00:09:47.660
static data. There, of course, we have
Wikidata. That has almost everything we
00:09:47.660 --> 00:09:54.600
need. And we are making heavy use of that.
And that's also why I'm here today on the
00:09:54.600 --> 00:10:07.360
Wikimedia stage. One thing that
Wikidata doesn't do perfectly is timezone
00:10:07.360 --> 00:10:15.640
information. That's why we're using the
open street map data for this. There's in
00:10:15.640 --> 00:10:23.090
Wikidata, three different time zone… or
ways of specifying the time zone. UTC
00:10:23.090 --> 00:10:29.520
offsets, some kind, of coarse, human
readable naming like Central European
00:10:29.520 --> 00:10:37.890
Summer Time, and then the actual IANA time
zone specifications like Europe/Berlin.
00:10:37.890 --> 00:10:42.200
And that's the one we actually need
because they contain daylight saving time
00:10:42.200 --> 00:10:47.270
transitions. And that is actually crucial
for travel assistance, because you
00:10:47.270 --> 00:10:52.810
can have a flight from, say, the US to
Europe, at the night where there is
00:10:52.810 --> 00:10:57.720
daylight saving time transition on one
end. And if we get that wrong, right, we
00:10:57.720 --> 00:11:01.261
are off by one hour. And that could mean
you miss your flight. So that we
00:11:01.261 --> 00:11:07.120
need to get absolutely right. And
Wikidata there mixes the three timezone
00:11:07.120 --> 00:11:16.860
variations. So that's why we fall back to
OpenStreetMap there. Another area
00:11:16.860 --> 00:11:23.420
that still needs work is vendor specific
station identifiers. So there's a number
00:11:23.420 --> 00:11:28.850
of train companies that have their own
numeric identifier, or alphanumeric
00:11:28.850 --> 00:11:34.870
identifiers, which you find, for example,
in barcodes of tickets. So that's our
00:11:34.870 --> 00:11:39.281
way to actually find out where people are
traveling. So that's something we are
00:11:39.281 --> 00:11:47.430
trying to feed into Wikidata as we get our
hands on those identifiers. For airports,
00:11:47.430 --> 00:11:51.420
that's easy because they are
internationally standardized. For train
00:11:51.420 --> 00:11:59.220
stations, that's a bit more messy. And
finally, the dynamic data. That's again,
00:11:59.220 --> 00:12:08.410
an area where we benefit from Google using
their monopoly. They wanted to have local
00:12:08.410 --> 00:12:15.430
public transportation information in
Google Maps. So they defined the GTFS
00:12:15.430 --> 00:12:25.820
format, which is a way for local transport
operators to send their schedules to
00:12:25.820 --> 00:12:31.330
Google. But most of the time, that is done
in a way that they basically publish this
00:12:31.330 --> 00:12:40.300
as Open Data. And that way, all of us get
access to it. And then there's Navitia,
00:12:40.300 --> 00:12:46.170
which is a Free Software implementation of
like a routing and journey query service
00:12:46.170 --> 00:12:51.270
that consumes all of those Open Data
schedule information. And that then in
00:12:51.270 --> 00:13:00.270
turn, we can use again to, yeah, find our
departure schedules, delays and that
00:13:00.270 --> 00:13:06.760
kind of live information. Apple Wallet
also has some kind of live updating
00:13:06.760 --> 00:13:15.060
polling mechanism. But that is somewhat
dangerous because it leaks personal
00:13:15.060 --> 00:13:21.500
identifiable information. So the,
basically, a unique identifier for your
00:13:21.500 --> 00:13:28.240
pass is sent out with the API request to
to pull an update. So that is basically
00:13:28.240 --> 00:13:34.130
just a last resort mechanism if you have
nothing else. And then there's a bunch of
00:13:34.130 --> 00:13:40.410
vendor specific, more or less proprietary
APIs that we could use. They are
00:13:40.410 --> 00:13:46.010
unfortunately not often compatible with
Free Software and Open Source, because,
00:13:46.010 --> 00:13:50.520
they might require API keys that you're
not allowed to share, or they have terms
00:13:50.520 --> 00:13:54.540
and conditions that are simply
incompatible with what we are trying to
00:13:54.540 --> 00:14:03.610
do. So for some, this works, but there's
still some room for improvement in those
00:14:03.610 --> 00:14:12.089
vendors' understanding the value of proper
Open Data access. OK, so that's the
00:14:12.089 --> 00:14:23.480
theory, let's have a look at what we have
actually built for this. So there's two,
00:14:23.480 --> 00:14:32.120
ya, backend components, so to say there is
the extraction library that implements the
00:14:32.120 --> 00:14:38.020
schema.org data model for flights,
for trains, for hotels, for restaurants
00:14:38.020 --> 00:14:49.230
and for events. It can do the structured
data extraction. That might sound easy at
00:14:49.230 --> 00:14:56.040
first, but it turns out that for some of
the operators, doing proper JSON array
00:14:56.040 --> 00:15:01.350
encoding is somewhat hard. So, I mean, you
need to do a... need to have a comma in
00:15:01.350 --> 00:15:09.020
between two objects and brackets around
it. Some of them struggle with that. So we
00:15:09.020 --> 00:15:18.290
have to have lots of workarounds in, in
parsing the data we receive. Then we have
00:15:18.290 --> 00:15:26.240
an unstructured extraction system that's
basically small scripts per provider
00:15:26.240 --> 00:15:33.470
or per operator that then, yeah, use
regular expressions or XPATH queries
00:15:33.470 --> 00:15:40.120
depending on the input and turn that into
our data model. We currently, I think,
00:15:40.120 --> 00:15:46.010
have 50, slightly more than 50 of those. I
know that Apple has about 600, so that is
00:15:46.010 --> 00:15:56.899
still one order of magnitude more. But
it's not impossible. Right. So I think we,
00:15:56.899 --> 00:16:03.899
we have the means there with Free Software
to come to a similar result than
00:16:03.899 --> 00:16:10.140
people that have an Apple or Google scale
budget for this. The service coverage is
00:16:10.140 --> 00:16:14.730
actually quite different. So, for Apple,
I've seen their custom extractor.
00:16:14.730 --> 00:16:20.839
So they have a lot of like US car rental
services. We have somewhat more important
00:16:20.839 --> 00:16:26.550
stuff like CCC tickets. So the Congress
ticket is actually recognized and I
00:16:26.550 --> 00:16:32.600
managed to get in with the app. What
the expection engine also does is it
00:16:32.600 --> 00:16:37.279
augments whatever we find in the input
documents by information we have on
00:16:37.279 --> 00:16:43.640
Wikidata. So we usually have time zones,
countries, geo coordinates, all that
00:16:43.640 --> 00:16:51.990
useful stuff for then offering assistance
features on top. And input formats is
00:16:51.990 --> 00:16:58.200
basically everything I mentioned. The
usual stuff you're getting in an email
00:16:58.200 --> 00:17:06.730
from a transport operator or any kind
of booking document. The second piece on
00:17:06.730 --> 00:17:12.209
like, on backend components is the public
transportation library. That's basically
00:17:12.209 --> 00:17:19.709
our client API for Navitia mainly, but
also for some of the proprietary
00:17:19.709 --> 00:17:25.819
widespread backends like HAFAS. That's the
stuff Deutsche Bahn is using. And it can
00:17:25.819 --> 00:17:31.451
aggregate the results from multiple
backends. And if you're using Open Data in
00:17:31.451 --> 00:17:36.640
the backend - interference noise - it
propagates the attribution information
00:17:36.640 --> 00:17:44.200
correctly. So. And just a few days ago, it
also gained support for querying train and
00:17:44.200 --> 00:17:52.360
platform layouts or "Wagenstandsanzeiger"
in German so we can have all of that in
00:17:52.360 --> 00:18:03.610
the app. And now of course there's the KDE
Itinerary app itself. So it has, oh… it's
00:18:03.610 --> 00:18:09.940
very hard to read here. It's basically a
timeline with the various booking
00:18:09.940 --> 00:18:16.370
information you have grouped together by
trip. It can insert the live weather
00:18:16.370 --> 00:18:22.059
information. Again, that's online access,
so it's optional, but yeah, it's kind of
00:18:22.059 --> 00:18:29.990
useful. And this is… you probably can't
read that. But that's my train to Leipzig
00:18:29.990 --> 00:18:35.929
this morning and that's actually the
Congress entry ticket. And the box at the
00:18:35.929 --> 00:18:47.559
top is the collapsible group for my trip
to Leipzig for Congress. And it can
00:18:47.559 --> 00:18:56.070
show the actual tickets and barcodes,
including Apple Wallet passes. So, if you
00:18:56.070 --> 00:19:01.929
sometimes have a, like a manual inspection
at an airport where they don't scan your
00:19:01.929 --> 00:19:07.769
boarding pass, but look at it, apparently
that looks reasonable enough that you can
00:19:07.769 --> 00:19:15.770
board an aircraft with it. At least, I
wasn't arrested so far. And then we have
00:19:15.770 --> 00:19:22.110
one of my favorite features, also powered
by Wikidata. It's the power plug
00:19:22.110 --> 00:19:27.759
incompatibility warning. interference
noise - So, I mean, if you're traveling
00:19:27.759 --> 00:19:32.889
to, say, the US, or UK, you're probably
aware that they have like incompatible
00:19:32.889 --> 00:19:38.730
power plugs. But there are some
countries where this isn't – at least to
00:19:38.730 --> 00:19:44.320
me, isn't that obvious, like Switzerland
or Italy, where only half of my power
00:19:44.320 --> 00:19:49.929
plugs work. So this is the Italy example.
It tells me that my Schuko plugs won't
00:19:49.929 --> 00:20:06.701
work, only my Europlugs and. interference
noise - And the right one is, I
00:20:06.701 --> 00:20:13.169
think for the U.K., where nothing is
compatible. If you occasionally forget
00:20:13.169 --> 00:20:20.809
your power plug convertor while traveling,
that is super useful. And then, of course,
00:20:20.809 --> 00:20:27.570
we have the integration with real
time data. So we can show the delay
00:20:27.570 --> 00:20:34.879
information and platform changes. The part
in the middle is the alternative
00:20:34.879 --> 00:20:39.450
connection selection for trains. So
if you have a, like a train ticket that
00:20:39.450 --> 00:20:46.100
isn't bound to a specific connection,
right, then the app lets you pick the one
00:20:46.100 --> 00:20:49.940
you actually want to take. Or if you're
missing a connection, you need to move to
00:20:49.940 --> 00:20:55.960
a different train, you can do that right
in the app as well. The screenshot on the
00:20:55.960 --> 00:21:02.280
right hand side is the, like your overall
travel statistics. So if you're interested
00:21:02.280 --> 00:21:08.529
in, like, seeing the carbon impact off of
all your trips and the year over year
00:21:08.529 --> 00:21:15.769
changes, right, the app shows that to you.
And I wasn't really successful, but that's
00:21:15.769 --> 00:21:20.919
largely because the old data is
incomplete. So if you're interested in
00:21:20.919 --> 00:21:27.039
that, right, since we have all the data,
that can help you see if you're
00:21:27.039 --> 00:21:34.159
actually on the right track there. And
then to get data into that, we also have a
00:21:34.159 --> 00:21:41.049
plugin for email clients. This one is for
for KMail. So it basically then runs the
00:21:41.049 --> 00:21:45.059
extraction on the email you're
currently looking at and it shows you a
00:21:45.059 --> 00:21:52.690
summary of what's in there. In this case,
my train to Leipzig this morning,
00:21:52.690 --> 00:21:57.299
including the option to add that to the
calendar or send it to the app on the
00:21:57.299 --> 00:22:06.090
phone. We also have the browser extension.
So this is the website of the yearly KDE
00:22:06.090 --> 00:22:10.840
conference, which has the schema.org
annotations on it. And the browser
00:22:10.840 --> 00:22:18.169
extension recognizes that. And again,
offers me to to add that either to my
00:22:18.169 --> 00:22:27.389
calendar or to the itinerary app. And that
also works on many restaurant websites or
00:22:27.389 --> 00:22:33.759
event websites. They have those
annotations on the website for the Google
00:22:33.759 --> 00:22:41.080
search. So again, we benefit a bit from
the, Google incomprehensible. OK, then
00:22:41.080 --> 00:22:47.159
we get to the more experimental stuff that
basically just was finished in the last
00:22:47.159 --> 00:22:54.850
couple of days, that we haven't shown
anywhere else publicly yet. The first one
00:22:54.850 --> 00:23:03.259
is, and that's a bit better to read, at
least, if you saw the timeline earlier,
00:23:03.259 --> 00:23:08.129
right, it had my train booking to Leipzig
and then the Congress ticket. But that
00:23:08.129 --> 00:23:14.059
still leaves two gaps, right. I need to
get from home to the station in Berlin,
00:23:14.059 --> 00:23:19.840
and I need to get from the station in
Leipzig to Congress. And what we have now
00:23:19.840 --> 00:23:24.999
is a way for the app to automatically
recognize those gaps and fill them with
00:23:24.999 --> 00:23:31.239
suggestions on what kind of local
transport you could take. So here the one
00:23:31.239 --> 00:23:41.559
for Leipzig to Congress is expanded
and shows the tram. That still needs
00:23:41.559 --> 00:23:47.769
some work to do live tracking so that
it accounts for delays and changes your
00:23:47.769 --> 00:23:53.399
alarm clock in the morning if there's
delays on that trip. But we have
00:23:53.399 --> 00:23:59.119
all the building blocks to make the
whole thing much more smart in this
00:23:59.119 --> 00:24:09.029
area now. And that, I think was literally
done yesterday. So that's why the graphics
00:24:09.029 --> 00:24:19.859
still are very basic. That's the train
layout, coach layout display for
00:24:19.859 --> 00:24:26.629
your trip. So that you know where your
reserved seat on the train can actually be
00:24:26.629 --> 00:24:38.440
found. Then, I only showed the KMail
plugin so far. We also have a work-in-
00:24:38.440 --> 00:24:43.409
progress Thunderbird integration, which is
probably the much more widespread email
00:24:43.409 --> 00:24:51.519
client. Featurewise, more or less the same
I showed for KMail, so it scans the email
00:24:51.519 --> 00:24:57.479
and displays your summary and offers you
to put that into the app or, possibly
00:24:57.479 --> 00:25:04.080
later on also into the calendar.
This one is even more experimental. I can
00:25:04.080 --> 00:25:08.769
only show you a screenshot of Web
Inspector proving that it managed to
00:25:08.769 --> 00:25:17.059
extract something. That's the integration
with Nextcloud. I hope we'll have an
00:25:17.059 --> 00:25:24.929
actual working prototype for this in
January then. Those two things are, of
00:25:24.929 --> 00:25:32.330
course, important for you to even get
to the data, the booking data, that then
00:25:32.330 --> 00:25:45.239
the app or other tools you built on top
can consume. OK, so where to get this
00:25:45.239 --> 00:25:55.470
from? There's the wiki link up there. The
app is currently not yet in the Play Store
00:25:55.470 --> 00:26:00.919
or in the F-Droid master repository. We
have an F-Droid nightly build repository.
00:26:00.919 --> 00:26:09.230
I hope that within the next month we'll
get actual official releases in the easier
00:26:09.230 --> 00:26:16.279
to reach stores than what we have
right now. If you are interested in
00:26:16.279 --> 00:26:23.749
helping with that, there's some stuff in
Wikidata where improvement on the data
00:26:23.749 --> 00:26:33.251
directly benefits this work, and that is
specifically around train stations. I
00:26:33.251 --> 00:26:36.700
think in Germany, last time I checked, we
still had a few hundred train stations
00:26:36.700 --> 00:26:45.460
that didn't have geo coordinates or even a
human readable label. So that's something
00:26:45.460 --> 00:26:50.679
to look at. Vendor-specific or even the
more or less standard train station
00:26:50.679 --> 00:26:56.139
identifiers is something to look at. So
UIC or IBNR codes for train stations,
00:26:56.139 --> 00:27:03.940
that helps a lot. Yeah. And then, we kind
of need test data for the extractions. So,
00:27:03.940 --> 00:27:11.249
forget everything I said about privacy. If
you have any kind of booking documents or
00:27:11.249 --> 00:27:17.950
emails you want to donate to support this
and get the providers you're using
00:27:17.950 --> 00:27:23.479
supported in in the extraction engine,
talk to me. That would be extremely
00:27:23.479 --> 00:27:30.769
useful. Yeah, that's it. Thank you.
00:27:30.769 --> 00:27:33.169
Applause
00:27:33.169 --> 00:27:37.309
Herald: Hello, hello? Yeah. That's a very
impressive project, I think, do we have
00:27:37.309 --> 00:27:43.869
questions then I'll hand you my
microphone. Yes.
00:27:43.869 --> 00:27:51.440
Q: Would it be possible to extract
platform lift data for train stations?
00:27:51.440 --> 00:27:57.179
A: Sorry? Platform….
Q: Platform lift data.
00:27:57.179 --> 00:28:08.299
A: Oh, I think Deutsche Bahn has an Open
Data API for the live status of lifts.
00:28:08.299 --> 00:28:15.739
That would, of course, in theory be
possible. What we are trying to do is to
00:28:15.739 --> 00:28:21.820
be generic enough so that this might not
be applicable in just one country,
00:28:21.820 --> 00:28:29.220
although it is very European focused
because most of the team is there. But
00:28:29.220 --> 00:28:33.770
lifts is something that is easy enough to
generalize in a data model, right? Its
00:28:33.770 --> 00:28:39.139
location on the platform, and, are they
working or not? So, yeah, that that would
00:28:39.139 --> 00:28:49.059
be a nice addition. That goes into the
entire direction of, ya, indoor navigation
00:28:49.059 --> 00:28:54.529
or navigation around larger train stations
and airports. So that's probably something
00:28:54.529 --> 00:29:00.620
where we could use a better overall
display with the OpenStreetMap data and
00:29:00.620 --> 00:29:07.460
then augment that with, like the, where
exactly is your train stopping and in
00:29:07.460 --> 00:29:11.559
which coach is your seat, and then have
the lift data so we can basically guide
00:29:11.559 --> 00:29:17.240
you to the right place in a better
way. Yeah.
00:29:17.240 --> 00:29:25.869
Herald: Any more questions? Yes.
Q: It's the mobile app written in Qt as
00:29:25.869 --> 00:29:31.080
well?
A: Yes, most of this is C++ code, because
00:29:31.080 --> 00:29:39.390
that's what we use at KDE. The mobile
client as well. There's a bit of Java for
00:29:39.390 --> 00:29:45.899
platform integration with android. I don't
think anyone has ever tried to build it on
00:29:45.899 --> 00:29:52.879
iOS, but of course it works on Linux based
mobile platforms as well, thanks to Qt and
00:29:52.879 --> 00:29:57.159
C++, yeah.
Q: So you mostly talked about the mobile
00:29:57.159 --> 00:30:02.470
app so far, which is understandable, but
as it's a QML application does it also run
00:30:02.470 --> 00:30:08.399
on desktop? And, a second question, how
do, how do all the plugins and the
00:30:08.399 --> 00:30:14.840
different instances of the app share their
data?
00:30:14.840 --> 00:30:22.239
A: So, yes, the app runs on desktop. I was
trying to see if I can actually start it
00:30:22.239 --> 00:30:31.489
here. I'm not sure on which screen it will
end up. That's where we do most of the
00:30:31.489 --> 00:30:42.809
development. Let me see if I can move it
over. Oh, thank you. And I need to find my
00:30:42.809 --> 00:30:56.950
mouse cursor on the two screens. Uh. I
think I need to end the presentation
00:30:56.950 --> 00:31:10.580
first, but, yeah, short answer, of course.
There we go. And let me switch to… to…
00:31:10.580 --> 00:31:19.429
yeah, so that's it, running on
desktop. It has a mobile UI there. That
00:31:19.429 --> 00:31:27.609
could, of course, be extended to be more
useful on the desktop as well. And in
00:31:27.609 --> 00:31:33.539
terms of storage, that is currently
internal to the app, there is no second
00:31:33.539 --> 00:31:42.029
process accessing the actual data storage.
That would just unnecessarily complicate
00:31:42.029 --> 00:31:47.570
it for now. But if there is a use for
that, yeah, we'll need to see.
00:31:47.570 --> 00:31:53.700
Q: Yeah, but, but, but there was an
option, in the e-mail plugin, for example,
00:31:53.700 --> 00:31:57.749
to send it to the app. Can I then only
send it to my local app and not to the
00:31:57.749 --> 00:32:02.739
mobile app?
A: Oh, the central app, that's using
00:32:02.739 --> 00:32:08.059
KDE Connect. That's an integration
software that allows you to remote control
00:32:08.059 --> 00:32:11.359
your phone from the desktop. So that's
basically bundling up all the information
00:32:11.359 --> 00:32:17.049
and sends it to the app on the phone. And…
or it can import it locally, so.
00:32:17.049 --> 00:32:26.820
Herald: OK, do we have other questions?
No, we don't have time? So then, thank you
00:32:26.820 --> 00:32:32.049
very much, Volker, maybe you can tell
people where they can find you if they
00:32:32.049 --> 00:32:34.240
have anything more they want to talk
about. But….
00:32:34.240 --> 00:32:41.219
A: Yeah, I mean, there's my email
address and otherwise I'll be around all
00:32:41.219 --> 00:32:44.669
day, all four days.
Herald: Around where?
00:32:44.669 --> 00:32:48.630
Volker Krause: Probably somewhere. So it
just is a bit tricky.
00:32:48.630 --> 00:32:52.649
Herald: …catch him before he runs away,
then! All right. So give a round of
00:32:52.649 --> 00:32:55.100
applause again and thank you, Volker!
00:32:55.100 --> 00:32:58.805
Applause
00:32:58.805 --> 00:33:06.560
postroll music
00:33:06.560 --> 00:33:26.000
Subtitles created by c3subtitles.de
in the year 2021. Join, and help us!