At Akademy I’ve presented the current state of KDE Itinerary. Due to popular demand and since 25 minutes aren’t a whole lot of time I’ll try to write a few posts on this subject here too, beginning with how this all started.

When travelling regularly you probably have come across or are using the digital travel assistant features found on Android or iOS, or dedicated services for this like TripIt. Getting a unified itinerary rather than digging through ad-infested HTML emails for your departure gate, having a single place to look for your boarding pass rather than two dozen vendor apps and getting up to date information about changes to your trip are all very useful and convenient.

Most of this is available “for free”, that is you pay with your data rather than your money. In the extreme case (Google), you have those providers reading your entire email in order to extract your travel information. But even if you restrict this to just your travel-related communication there’s a lot of potentially sensitive information involved here:

  • name, address and birthday
  • credit card numbers and how much you spent on your trip
  • when and where your travel, and with whom
  • passport numbers

While I’d like to have all the nice digital travel assistant features, I’m not willing to pay with that much personal information for it. On they way home from the Randa meeting last year and unable to read my boarding time in a proprietary Apple Wallet pass file this lead to a little exploration into possible free software alternatives in this field. That got slightly out of hand, and a few month later we have some working components in the KDE Application releases already.

It turns out that the challenge in these systems is actually not so much code, but data. In particular there are three general categories of data to look at:

  • Personal data, that is your emails containing reservation or booking data, boarding passes, train tickets, etc. This part is easy to obtain, you have that data. Extracting structured information from this needs some work though.
  • Static data, that is information about the timezone and location of a certain airport or train station for example. For a lot of this we have excellent open data sources available, most prominently Wikidata and OpenStreetmap.
  • Dynamic data, that is live traffic information about delays, gate or platform changes, traffic jams, etc. This is the real problem, there are few open data sources available for this, and due to its nature this data is usually only available from the corresponding transport provider. And even where available without cost we hit practical issues for free software in the form of API keys.

While not perfect, that’s good enough to get started :) The next post will detail how far we got by now.