1
00:00:00,000 --> 00:00:20,310
36c3 preroll music
2
00:00:20,310 --> 00:00:27,660
Herald: So, hey, we're finally ready to
start, we have Volker Krause here with a
3
00:00:27,660 --> 00:00:32,210
privacy by design travel assistant and
it's going to be about building Open
4
00:00:32,210 --> 00:00:38,449
Source travel assistants, I think, and
this talk will be in English. And if you
5
00:00:38,449 --> 00:00:43,600
want translations, wenn ihr eine deutsche
Übersetzung haben wollt, haben wir hier
6
00:00:43,600 --> 00:00:48,750
hinten auch ganz tolle Übersetzer in
unserer Kabine, da könnt ihr auf
7
00:00:48,750 --> 00:00:54,330
c3lingo.org mal reinhören, wie die alles
live mitreden. Genau. Now. Let's have
8
00:00:54,330 --> 00:00:58,270
a warm welcome for Volker here and have
fun with his talk.
9
00:00:58,270 --> 00:01:00,480
Applause
10
00:01:00,480 --> 00:01:06,400
Volker Krause: Thank you. OK, so what is
this about? You probably know those
11
00:01:06,400 --> 00:01:13,729
features in, most prominently Google
Mail, but I think TripIt was the one that
12
00:01:13,729 --> 00:01:21,130
pioneered this. So GMail reads your
email and then detects any kind of booking
13
00:01:21,130 --> 00:01:27,430
information in there, like your boarding
passes, your train tickets, your hotel
14
00:01:27,430 --> 00:01:34,609
bookings and so on. And it can integrate
that into your calendar and can present
15
00:01:34,609 --> 00:01:44,311
you a unified itinerary for your entire
trip and monitor that for changes. And
16
00:01:44,311 --> 00:01:51,529
all of that doesn't cost you anything.
Maybe apart from a bit of your privacy.
17
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
18
00:01:58,850 --> 00:02:06,280
involved in just your travel. Right.
The obvious things that come to
19
00:02:06,280 --> 00:02:12,440
mind, your name, your birthday, your
credit card number, your passport number,
20
00:02:12,440 --> 00:02:21,620
that kind of information. Right. But that
isn't even the worst part on this,
21
00:02:21,620 --> 00:02:27,590
because those operators don't just get to
see your specific data for one trip,
22
00:02:27,590 --> 00:02:33,099
right? They get to see every… everyone's
trip. And now if you combine that
23
00:02:33,099 --> 00:02:39,980
information, that actually uncovers a lot
of information about... relations
24
00:02:39,980 --> 00:02:45,030
between people, your interests, who
you work for, where you live and all of
25
00:02:45,030 --> 00:02:52,340
that. Right. So pretty much everyone here
traveled to Leipzig for the last four days
26
00:02:52,340 --> 00:03:00,099
in the year. If that happens for
two of us, once, right, that might be
27
00:03:00,099 --> 00:03:05,580
coincidence. If that happens two or three
years in a row, that is some kind of
28
00:03:05,580 --> 00:03:13,260
information. But yeah, what to do
about that, right? The easy solution
29
00:03:13,260 --> 00:03:22,450
is, just not use those services. It's like
first world luxury stuff anyway. That
30
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
31
00:03:26,200 --> 00:03:31,940
local languages and then get introduced to
their counterpart of Schienenersatzverkehr
32
00:03:31,940 --> 00:03:39,200
or Tarifzonenrandgebiet. And at that
point, you might be interested in actually
33
00:03:39,200 --> 00:03:46,019
understanding what's happening on your
your trip in in some form that you
34
00:03:46,019 --> 00:03:50,329
actually understand and that you are
familiar with, ideally without installing
35
00:03:50,329 --> 00:03:54,650
15 different vendor applications for
whatever you actually might be
36
00:03:54,650 --> 00:04:02,780
traveling, right? So we need something
better. And that obviously leads us to,
37
00:04:02,780 --> 00:04:10,680
let's do it ourselves. Then, we can at
least design this for privacy right from
38
00:04:10,680 --> 00:04:16,299
the start. Build it on top of Free
Software and Open Data. Well, of course,
39
00:04:16,299 --> 00:04:23,780
we need to... at least it's not entirely
obvious that this will actually work,
40
00:04:23,780 --> 00:04:30,450
right? The Google and Apple, they have a
total different amount of resources
41
00:04:30,450 --> 00:04:37,320
available for this. So, can we actually
build this ourselves? So let's have a look
42
00:04:37,320 --> 00:04:46,360
at what those services actually need to
function. And it turns out it's primarily
43
00:04:46,360 --> 00:04:54,200
about data, not so much about code.
There are some difficult parts
44
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
45
00:04:58,850 --> 00:05:03,310
barcode in your boarding pass. But all of
that exists as ready-made building blocks.
46
00:05:03,310 --> 00:05:11,160
So you basically just need to put this
nicely together. So let's look at the
47
00:05:11,160 --> 00:05:16,860
data. That's the more interesting part.
And in general, that breaks down to
48
00:05:16,860 --> 00:05:22,560
three different categories. The first one
is what I call personal data here. So
49
00:05:22,560 --> 00:05:29,530
that's basically booking information,
documents or tickets, boarding passes,
50
00:05:29,530 --> 00:05:33,350
specific for you. So there at least you
don't have a problem with access because
51
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
52
00:05:40,390 --> 00:05:47,800
of forms and shapes. So there are the
challenges to actually extract that . The
53
00:05:47,800 --> 00:05:55,420
second kind of data is what I would call
static data. So, for example, the location
54
00:05:55,420 --> 00:06:02,300
of an airport. Now, you could argue that
that could change and there is rumors
55
00:06:02,300 --> 00:06:07,310
that some people apparently managed to
build new airports. I live in Berlin, so I
56
00:06:07,310 --> 00:06:15,630
don't believe this. Jokes aside, so,
"static" refers to within, static within
57
00:06:15,630 --> 00:06:22,360
the release cycle of the software. So
several weeks or a few months. So this is
58
00:06:22,360 --> 00:06:26,880
stuff that we can ship as offline
databases. And offline, of course, helps
59
00:06:26,880 --> 00:06:32,440
us with privacy because then you're not
observable from the outside. And the third
60
00:06:32,440 --> 00:06:41,570
category is dynamic data. So stuff that is
very, very short lived, such as delay
61
00:06:41,570 --> 00:06:46,410
information. There is no way we can do
that offline. If we want that kind of
62
00:06:46,410 --> 00:06:54,530
information, we will always need some kind
of online querying. Then let's look
63
00:06:54,530 --> 00:07:02,960
through those three categories in a bit
more detail. For the booking data, google
64
00:07:02,960 --> 00:07:08,380
was faced with the same problem, so they
used their monopoly and defined a standard
65
00:07:08,380 --> 00:07:16,360
in which operators should ideally have
machine readable annotations on their
66
00:07:16,360 --> 00:07:21,330
booking information. And that's awesome,
because we can just use the same, the same
67
00:07:21,330 --> 00:07:26,840
system. That's what nowadays became
schema.org, which I think Lucas mentioned
68
00:07:26,840 --> 00:07:33,910
in the morning as well. At least in
the US and Europe, you'll find
69
00:07:33,910 --> 00:07:41,860
that in about 30 to 50% of booking emails
you get from hotels, airlines or event
70
00:07:41,860 --> 00:07:49,600
brokers. So that's a good start. But then
there's the rest, which is basically
71
00:07:49,600 --> 00:07:57,150
unstructured data, random PDF files or
HTML emails we have to work with. There's
72
00:07:57,150 --> 00:08:03,611
Apple wallet boarding passes. They are
somewhat semi structured and most
73
00:08:03,611 --> 00:08:16,340
widespread for flight tickets. Well,
that's somewhat usable. And barcodes, so
74
00:08:16,340 --> 00:08:23,030
that's what you, again, see on boarding
passes or train tickets. I could
75
00:08:23,030 --> 00:08:29,420
probably fill an entire talk just with the
various details on the different
76
00:08:29,420 --> 00:08:35,120
barcode systems, the one for boarding
passes, I think, Karsten Nohl had to talk
77
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
78
00:08:40,970 --> 00:08:50,280
with them. Instagram #boardingpass is a
very nice source of test data. The one
79
00:08:50,280 --> 00:08:54,670
that you find on, on German railway
tickets is also pretty much researched
80
00:08:54,670 --> 00:09:00,451
already. The ones we actually had to
break ourselves were the one for Italy. I
81
00:09:00,451 --> 00:09:04,680
think to my knowledge, we are the first
ones to publish the content of those
82
00:09:04,680 --> 00:09:13,070
binary barcodes. And we are currently
working on the VDV Kernapplikation
83
00:09:13,070 --> 00:09:18,451
E-Ticket, which is the standard for German
local transportation tickets. That
84
00:09:18,451 --> 00:09:24,170
actually has some crypto that you need to
get around to actually see the content. So
85
00:09:24,170 --> 00:09:30,550
there is, if you're interested in that
kind of stuff, there is quite some
86
00:09:30,550 --> 00:09:39,180
interesting detail to be found in this.
But let's continue with the
87
00:09:39,180 --> 00:09:47,660
static data. There, of course, we have
Wikidata. That has almost everything we
88
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
89
00:09:54,600 --> 00:10:07,360
Wikimedia stage. One thing that
Wikidata doesn't do perfectly is timezone
90
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
91
00:10:15,640 --> 00:10:23,090
Wikidata, three different time zone… or
ways of specifying the time zone. UTC
92
00:10:23,090 --> 00:10:29,520
offsets, some kind, of coarse, human
readable naming like Central European
93
00:10:29,520 --> 00:10:37,890
Summer Time, and then the actual IANA time
zone specifications like Europe/Berlin.
94
00:10:37,890 --> 00:10:42,200
And that's the one we actually need
because they contain daylight saving time
95
00:10:42,200 --> 00:10:47,270
transitions. And that is actually crucial
for travel assistance, because you
96
00:10:47,270 --> 00:10:52,810
can have a flight from, say, the US to
Europe, at the night where there is
97
00:10:52,810 --> 00:10:57,720
daylight saving time transition on one
end. And if we get that wrong, right, we
98
00:10:57,720 --> 00:11:01,261
are off by one hour. And that could mean
you miss your flight. So that we
99
00:11:01,261 --> 00:11:07,120
need to get absolutely right. And
Wikidata there mixes the three timezone
100
00:11:07,120 --> 00:11:16,860
variations. So that's why we fall back to
OpenStreetMap there. Another area
101
00:11:16,860 --> 00:11:23,420
that still needs work is vendor specific
station identifiers. So there's a number
102
00:11:23,420 --> 00:11:28,850
of train companies that have their own
numeric identifier, or alphanumeric
103
00:11:28,850 --> 00:11:34,870
identifiers, which you find, for example,
in barcodes of tickets. So that's our
104
00:11:34,870 --> 00:11:39,281
way to actually find out where people are
traveling. So that's something we are
105
00:11:39,281 --> 00:11:47,430
trying to feed into Wikidata as we get our
hands on those identifiers. For airports,
106
00:11:47,430 --> 00:11:51,420
that's easy because they are
internationally standardized. For train
107
00:11:51,420 --> 00:11:59,220
stations, that's a bit more messy. And
finally, the dynamic data. That's again,
108
00:11:59,220 --> 00:12:08,410
an area where we benefit from Google using
their monopoly. They wanted to have local
109
00:12:08,410 --> 00:12:15,430
public transportation information in
Google Maps. So they defined the GTFS
110
00:12:15,430 --> 00:12:25,820
format, which is a way for local transport
operators to send their schedules to
111
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
112
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,
113
00:12:40,300 --> 00:12:46,170
which is a Free Software implementation of
like a routing and journey query service
114
00:12:46,170 --> 00:12:51,270
that consumes all of those Open Data
schedule information. And that then in
115
00:12:51,270 --> 00:13:00,270
turn, we can use again to, yeah, find our
departure schedules, delays and that
116
00:13:00,270 --> 00:13:06,760
kind of live information. Apple Wallet
also has some kind of live updating
117
00:13:06,760 --> 00:13:15,060
polling mechanism. But that is somewhat
dangerous because it leaks personal
118
00:13:15,060 --> 00:13:21,500
identifiable information. So the,
basically, a unique identifier for your
119
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
120
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
121
00:13:34,130 --> 00:13:40,410
vendor specific, more or less proprietary
APIs that we could use. They are
122
00:13:40,410 --> 00:13:46,010
unfortunately not often compatible with
Free Software and Open Source, because,
123
00:13:46,010 --> 00:13:50,520
they might require API keys that you're
not allowed to share, or they have terms
124
00:13:50,520 --> 00:13:54,540
and conditions that are simply
incompatible with what we are trying to
125
00:13:54,540 --> 00:14:03,610
do. So for some, this works, but there's
still some room for improvement in those
126
00:14:03,610 --> 00:14:12,089
vendors' understanding the value of proper
Open Data access. OK, so that's the
127
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,
128
00:14:23,480 --> 00:14:32,120
ya, backend components, so to say there is
the extraction library that implements the
129
00:14:32,120 --> 00:14:38,020
schema.org data model for flights,
for trains, for hotels, for restaurants
130
00:14:38,020 --> 00:14:49,230
and for events. It can do the structured
data extraction. That might sound easy at
131
00:14:49,230 --> 00:14:56,040
first, but it turns out that for some of
the operators, doing proper JSON array
132
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
133
00:15:01,350 --> 00:15:09,020
between two objects and brackets around
it. Some of them struggle with that. So we
134
00:15:09,020 --> 00:15:18,290
have to have lots of workarounds in, in
parsing the data we receive. Then we have
135
00:15:18,290 --> 00:15:26,240
an unstructured extraction system that's
basically small scripts per provider
136
00:15:26,240 --> 00:15:33,470
or per operator that then, yeah, use
regular expressions or XPATH queries
137
00:15:33,470 --> 00:15:40,120
depending on the input and turn that into
our data model. We currently, I think,
138
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
139
00:15:46,010 --> 00:15:56,899
still one order of magnitude more. But
it's not impossible. Right. So I think we,
140
00:15:56,899 --> 00:16:03,899
we have the means there with Free Software
to come to a similar result than
141
00:16:03,899 --> 00:16:10,140
people that have an Apple or Google scale
budget for this. The service coverage is
142
00:16:10,140 --> 00:16:14,730
actually quite different. So, for Apple,
I've seen their custom extractor.
143
00:16:14,730 --> 00:16:20,839
So they have a lot of like US car rental
services. We have somewhat more important
144
00:16:20,839 --> 00:16:26,550
stuff like CCC tickets. So the Congress
ticket is actually recognized and I
145
00:16:26,550 --> 00:16:32,600
managed to get in with the app. What
the expection engine also does is it
146
00:16:32,600 --> 00:16:37,279
augments whatever we find in the input
documents by information we have on
147
00:16:37,279 --> 00:16:43,640
Wikidata. So we usually have time zones,
countries, geo coordinates, all that
148
00:16:43,640 --> 00:16:51,990
useful stuff for then offering assistance
features on top. And input formats is
149
00:16:51,990 --> 00:16:58,200
basically everything I mentioned. The
usual stuff you're getting in an email
150
00:16:58,200 --> 00:17:06,730
from a transport operator or any kind
of booking document. The second piece on
151
00:17:06,730 --> 00:17:12,209
like, on backend components is the public
transportation library. That's basically
152
00:17:12,209 --> 00:17:19,709
our client API for Navitia mainly, but
also for some of the proprietary
153
00:17:19,709 --> 00:17:25,819
widespread backends like HAFAS. That's the
stuff Deutsche Bahn is using. And it can
154
00:17:25,819 --> 00:17:31,451
aggregate the results from multiple
backends. And if you're using Open Data in
155
00:17:31,451 --> 00:17:36,640
the backend - interference noise - it
propagates the attribution information
156
00:17:36,640 --> 00:17:44,200
correctly. So. And just a few days ago, it
also gained support for querying train and
157
00:17:44,200 --> 00:17:52,360
platform layouts or "Wagenstandsanzeiger"
in German so we can have all of that in
158
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
159
00:18:03,610 --> 00:18:09,940
very hard to read here. It's basically a
timeline with the various booking
160
00:18:09,940 --> 00:18:16,370
information you have grouped together by
trip. It can insert the live weather
161
00:18:16,370 --> 00:18:22,059
information. Again, that's online access,
so it's optional, but yeah, it's kind of
162
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
163
00:18:29,990 --> 00:18:35,929
this morning and that's actually the
Congress entry ticket. And the box at the
164
00:18:35,929 --> 00:18:47,559
top is the collapsible group for my trip
to Leipzig for Congress. And it can
165
00:18:47,559 --> 00:18:56,070
show the actual tickets and barcodes,
including Apple Wallet passes. So, if you
166
00:18:56,070 --> 00:19:01,929
sometimes have a, like a manual inspection
at an airport where they don't scan your
167
00:19:01,929 --> 00:19:07,769
boarding pass, but look at it, apparently
that looks reasonable enough that you can
168
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
169
00:19:15,770 --> 00:19:22,110
one of my favorite features, also powered
by Wikidata. It's the power plug
170
00:19:22,110 --> 00:19:27,759
incompatibility warning. interference
noise - So, I mean, if you're traveling
171
00:19:27,759 --> 00:19:32,889
to, say, the US, or UK, you're probably
aware that they have like incompatible
172
00:19:32,889 --> 00:19:38,730
power plugs. But there are some
countries where this isn't – at least to
173
00:19:38,730 --> 00:19:44,320
me, isn't that obvious, like Switzerland
or Italy, where only half of my power
174
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
175
00:19:49,929 --> 00:20:06,701
work, only my Europlugs and. interference
noise - And the right one is, I
176
00:20:06,701 --> 00:20:13,169
think for the U.K., where nothing is
compatible. If you occasionally forget
177
00:20:13,169 --> 00:20:20,809
your power plug convertor while traveling,
that is super useful. And then, of course,
178
00:20:20,809 --> 00:20:27,570
we have the integration with real
time data. So we can show the delay
179
00:20:27,570 --> 00:20:34,879
information and platform changes. The part
in the middle is the alternative
180
00:20:34,879 --> 00:20:39,450
connection selection for trains. So
if you have a, like a train ticket that
181
00:20:39,450 --> 00:20:46,100
isn't bound to a specific connection,
right, then the app lets you pick the one
182
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
183
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
184
00:20:55,960 --> 00:21:02,280
right hand side is the, like your overall
travel statistics. So if you're interested
185
00:21:02,280 --> 00:21:08,529
in, like, seeing the carbon impact off of
all your trips and the year over year
186
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
187
00:21:15,769 --> 00:21:20,919
largely because the old data is
incomplete. So if you're interested in
188
00:21:20,919 --> 00:21:27,039
that, right, since we have all the data,
that can help you see if you're
189
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
190
00:21:34,159 --> 00:21:41,049
plugin for email clients. This one is for
for KMail. So it basically then runs the
191
00:21:41,049 --> 00:21:45,059
extraction on the email you're
currently looking at and it shows you a
192
00:21:45,059 --> 00:21:52,690
summary of what's in there. In this case,
my train to Leipzig this morning,
193
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
194
00:21:57,299 --> 00:22:06,090
phone. We also have the browser extension.
So this is the website of the yearly KDE
195
00:22:06,090 --> 00:22:10,840
conference, which has the schema.org
annotations on it. And the browser
196
00:22:10,840 --> 00:22:18,169
extension recognizes that. And again,
offers me to to add that either to my
197
00:22:18,169 --> 00:22:27,389
calendar or to the itinerary app. And that
also works on many restaurant websites or
198
00:22:27,389 --> 00:22:33,759
event websites. They have those
annotations on the website for the Google
199
00:22:33,759 --> 00:22:41,080
search. So again, we benefit a bit from
the, Google incomprehensible. OK, then
200
00:22:41,080 --> 00:22:47,159
we get to the more experimental stuff that
basically just was finished in the last
201
00:22:47,159 --> 00:22:54,850
couple of days, that we haven't shown
anywhere else publicly yet. The first one
202
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,
203
00:23:03,259 --> 00:23:08,129
right, it had my train booking to Leipzig
and then the Congress ticket. But that
204
00:23:08,129 --> 00:23:14,059
still leaves two gaps, right. I need to
get from home to the station in Berlin,
205
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
206
00:23:19,840 --> 00:23:24,999
is a way for the app to automatically
recognize those gaps and fill them with
207
00:23:24,999 --> 00:23:31,239
suggestions on what kind of local
transport you could take. So here the one
208
00:23:31,239 --> 00:23:41,559
for Leipzig to Congress is expanded
and shows the tram. That still needs
209
00:23:41,559 --> 00:23:47,769
some work to do live tracking so that
it accounts for delays and changes your
210
00:23:47,769 --> 00:23:53,399
alarm clock in the morning if there's
delays on that trip. But we have
211
00:23:53,399 --> 00:23:59,119
all the building blocks to make the
whole thing much more smart in this
212
00:23:59,119 --> 00:24:09,029
area now. And that, I think was literally
done yesterday. So that's why the graphics
213
00:24:09,029 --> 00:24:19,859
still are very basic. That's the train
layout, coach layout display for
214
00:24:19,859 --> 00:24:26,629
your trip. So that you know where your
reserved seat on the train can actually be
215
00:24:26,629 --> 00:24:38,440
found. Then, I only showed the KMail
plugin so far. We also have a work-in-
216
00:24:38,440 --> 00:24:43,409
progress Thunderbird integration, which is
probably the much more widespread email
217
00:24:43,409 --> 00:24:51,519
client. Featurewise, more or less the same
I showed for KMail, so it scans the email
218
00:24:51,519 --> 00:24:57,479
and displays your summary and offers you
to put that into the app or, possibly
219
00:24:57,479 --> 00:25:04,080
later on also into the calendar.
This one is even more experimental. I can
220
00:25:04,080 --> 00:25:08,769
only show you a screenshot of Web
Inspector proving that it managed to
221
00:25:08,769 --> 00:25:17,059
extract something. That's the integration
with Nextcloud. I hope we'll have an
222
00:25:17,059 --> 00:25:24,929
actual working prototype for this in
January then. Those two things are, of
223
00:25:24,929 --> 00:25:32,330
course, important for you to even get
to the data, the booking data, that then
224
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
225
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
226
00:25:55,470 --> 00:26:00,919
or in the F-Droid master repository. We
have an F-Droid nightly build repository.
227
00:26:00,919 --> 00:26:09,230
I hope that within the next month we'll
get actual official releases in the easier
228
00:26:09,230 --> 00:26:16,279
to reach stores than what we have
right now. If you are interested in
229
00:26:16,279 --> 00:26:23,749
helping with that, there's some stuff in
Wikidata where improvement on the data
230
00:26:23,749 --> 00:26:33,251
directly benefits this work, and that is
specifically around train stations. I
231
00:26:33,251 --> 00:26:36,700
think in Germany, last time I checked, we
still had a few hundred train stations
232
00:26:36,700 --> 00:26:45,460
that didn't have geo coordinates or even a
human readable label. So that's something
233
00:26:45,460 --> 00:26:50,679
to look at. Vendor-specific or even the
more or less standard train station
234
00:26:50,679 --> 00:26:56,139
identifiers is something to look at. So
UIC or IBNR codes for train stations,
235
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,
236
00:27:03,940 --> 00:27:11,249
forget everything I said about privacy. If
you have any kind of booking documents or
237
00:27:11,249 --> 00:27:17,950
emails you want to donate to support this
and get the providers you're using
238
00:27:17,950 --> 00:27:23,479
supported in in the extraction engine,
talk to me. That would be extremely
239
00:27:23,479 --> 00:27:30,769
useful. Yeah, that's it. Thank you.
240
00:27:30,769 --> 00:27:33,169
Applause
241
00:27:33,169 --> 00:27:37,309
Herald: Hello, hello? Yeah. That's a very
impressive project, I think, do we have
242
00:27:37,309 --> 00:27:43,869
questions then I'll hand you my
microphone. Yes.
243
00:27:43,869 --> 00:27:51,440
Q: Would it be possible to extract
platform lift data for train stations?
244
00:27:51,440 --> 00:27:57,179
A: Sorry? Platform….
Q: Platform lift data.
245
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.
246
00:28:08,299 --> 00:28:15,739
That would, of course, in theory be
possible. What we are trying to do is to
247
00:28:15,739 --> 00:28:21,820
be generic enough so that this might not
be applicable in just one country,
248
00:28:21,820 --> 00:28:29,220
although it is very European focused
because most of the team is there. But
249
00:28:29,220 --> 00:28:33,770
lifts is something that is easy enough to
generalize in a data model, right? Its
250
00:28:33,770 --> 00:28:39,139
location on the platform, and, are they
working or not? So, yeah, that that would
251
00:28:39,139 --> 00:28:49,059
be a nice addition. That goes into the
entire direction of, ya, indoor navigation
252
00:28:49,059 --> 00:28:54,529
or navigation around larger train stations
and airports. So that's probably something
253
00:28:54,529 --> 00:29:00,620
where we could use a better overall
display with the OpenStreetMap data and
254
00:29:00,620 --> 00:29:07,460
then augment that with, like the, where
exactly is your train stopping and in
255
00:29:07,460 --> 00:29:11,559
which coach is your seat, and then have
the lift data so we can basically guide
256
00:29:11,559 --> 00:29:17,240
you to the right place in a better
way. Yeah.
257
00:29:17,240 --> 00:29:25,869
Herald: Any more questions? Yes.
Q: It's the mobile app written in Qt as
258
00:29:25,869 --> 00:29:31,080
well?
A: Yes, most of this is C++ code, because
259
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
260
00:29:39,390 --> 00:29:45,899
platform integration with android. I don't
think anyone has ever tried to build it on
261
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
262
00:29:52,879 --> 00:29:57,159
C++, yeah.
Q: So you mostly talked about the mobile
263
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
264
00:30:02,470 --> 00:30:08,399
on desktop? And, a second question, how
do, how do all the plugins and the
265
00:30:08,399 --> 00:30:14,840
different instances of the app share their
data?
266
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
267
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
268
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
269
00:30:42,809 --> 00:30:56,950
mouse cursor on the two screens. Uh. I
think I need to end the presentation
270
00:30:56,950 --> 00:31:10,580
first, but, yeah, short answer, of course.
There we go. And let me switch to… to…
271
00:31:10,580 --> 00:31:19,429
yeah, so that's it, running on
desktop. It has a mobile UI there. That
272
00:31:19,429 --> 00:31:27,609
could, of course, be extended to be more
useful on the desktop as well. And in
273
00:31:27,609 --> 00:31:33,539
terms of storage, that is currently
internal to the app, there is no second
274
00:31:33,539 --> 00:31:42,029
process accessing the actual data storage.
That would just unnecessarily complicate
275
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.
276
00:31:47,570 --> 00:31:53,700
Q: Yeah, but, but, but there was an
option, in the e-mail plugin, for example,
277
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
278
00:31:57,749 --> 00:32:02,739
mobile app?
A: Oh, the central app, that's using
279
00:32:02,739 --> 00:32:08,059
KDE Connect. That's an integration
software that allows you to remote control
280
00:32:08,059 --> 00:32:11,359
your phone from the desktop. So that's
basically bundling up all the information
281
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.
282
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
283
00:32:26,820 --> 00:32:32,049
very much, Volker, maybe you can tell
people where they can find you if they
284
00:32:32,049 --> 00:32:34,240
have anything more they want to talk
about. But….
285
00:32:34,240 --> 00:32:41,219
A: Yeah, I mean, there's my email
address and otherwise I'll be around all
286
00:32:41,219 --> 00:32:44,669
day, all four days.
Herald: Around where?
287
00:32:44,669 --> 00:32:48,630
Volker Krause: Probably somewhere. So it
just is a bit tricky.
288
00:32:48,630 --> 00:32:52,649
Herald: …catch him before he runs away,
then! All right. So give a round of
289
00:32:52,649 --> 00:32:55,100
applause again and thank you, Volker!
290
00:32:55,100 --> 00:32:58,805
Applause
291
00:32:58,805 --> 00:33:06,560
postroll music
292
00:33:06,560 --> 00:33:26,000
Subtitles created by c3subtitles.de
in the year 2021. Join, and help us!