It has been a packed two month again around KDE Itinerary! Nextcloud Hub integrated the itinerary extraction engine, a presentation at 36C3 and working towards more elaborate assistance features are just some of the highlights since the last report.

New Features

One of the biggest recent feature additions is of course the integration with Nextcloud Hub, see the separate post on that.

A Deutsche Bahn train ticket display in Nextcloud Mail (screenshot by Nextcloud).
Nextcloud Mail showing a Deutsche Bahn train booking.

That’s far from all though, last month work also started on a major new assistance feature, automatic suggestions on how to fill the gaps in your itinerary, between elements extracted from reservations or tickets. That is, when do you need to leave home to be at the train station on time? How do you get from the airport to your hotel? Etc.

For this KDE Itinerary can now insert transfer elements into the timeline, and fill them with local public transport journeys retrieved via KPublicTransport.

KDE Itinerary showing local transportation details from a train station to a booked hotel.
KDE Itinerary showing local transportation details from a train station to a booked hotel.

Technically transfer elements can either be attached to the beginning or end of a booked element, with a stored time difference (ie. how much before departure do you want to be at the station, or how much time is needed to collect your baggage on arrival). This makes them move along if things change due to delays for example.

This feature is still very much work in progress, there are currently still a number of limitations on where such elements can be added, as well as only a single home location that can be configured. This should become more powerful as we gather feedback on how this behaves in use, maybe to the point where it automatically adjusts your alarm clock based on delays on early morning departures :)

Another notable new feature is the ability to show the platform and vehicle layout for (some) departures. That’s particularly useful for the big multi-part long-distance trains with seat reservations, to guide you to the right place to board the train. As a side-effect it can also show you to way to some onboard amenities.

KDE Itinerary showing a train section layout in KDE Itinerary.
Layout of a double segment Deutsche Bahn ICE train with the reserved coach highlighted in KDE Itinerary.

This currently only works for ICE and IC trains in Germany, simply because that’s the only trains we have API endpoints for which provide the necessary information. We found another one for India, but there we still need to implement support for the more basic public transport information queries first. It’s very likely similar API exists for other operators too, but it might not be discoverable without knowing the local language, any hints very welcome!

Like many other parts of KDE Itinerary this would also benefit heavily from some more attention to the visuals, with graphics done by professionals rather than myself, as well as fixes for a few remaining high DPI glitches.

And finally KDE Itinerary got a new statistics page that shows you a few information about all your trips, as well as the year over year changes.

KDE Itinerary statistics page showing data for 2019 and changes to the previous year.
KDE Itinerary statistics view showing data from a single year.

This includes a CO₂ metric using simple average emission values per means of transport. That’s obviously far from accurate and could probably improved by taking more trip parameters into account, but it’s a good start if you want to monitor the environmental impact of your travel over time.

Infrastructure Work

Many things happened in the background as well of course, around both the data extraction engine as well as the real-time public transport data retrieval.

  • The extractor now has the ability to decrypt VDV e-Ticket barcodes. Those are used by a number of German local transport providers, and contain a few hundred bytes of binary payload describing what they are valid for. While we don’t understand much of the content yet (due to missing documentation, and due to needing operator-specific coding tables), this already works as a reliable trigger for custom extractors (such as the one for Deutsche Bahn, which works on some of those tickets). It’s also a good basis for further research into privacy aspects of those tickets, given we found fields for traveler name, birthday and gender in there (not always filled though). Probably worth a dedicated post.

  • We made some progress in decoding binary ticket barcodes of VR (Finish railway). They seem to contain 43 bytes of payload with unaligned bit fields, and a 64 byte signature. The current state is documented in the wiki, the biggest remaining mystery is understanding the encoding of the departure and arrival station codes.

  • Custom extractor for iCal files can now trigger on iCal event properties, and got new API for safely extracting date/time values from iCal events without losing the timezone information (working around a JavaScript limitation).

A major addition to KPublicTransport has bees the support for OpenTripPlanner based backends. OpenTripPlanner is an open source trip planning server, deployed by a number of commercial operators as well as a few community projects. There’s unfortunately not a single version of it, but there seem to be three major variants: The original REST API, the GraphQL API added by Digitransit, and the GraphQL API added by Entur. KPublicTransport can now deal with all of them.

In practice this means we gained national coverage in Finland, Norway and Tunisia, as well as a few more European and US cities. Digitransit based backends seem to be popular with community-run public transport services, such as the one in Münster, Germany or Ulm, Germany. Non-commercially run services can be preferable from a privacy point of view, so it’s great we can interface with those as well now.

Fixes & Improvements

There’s plenty of smaller but still noteworthy changes as well of course.

Extractor engine:

  • New extractors for Indian Railways SMS confirmations, CCC tickets, RegioJet iCal attachments, Kintetsu Railway tickets, Norwegian bookings and boarding passes, SNCB and Thalys tickets, and DB seat reservations.
  • Renfe tickets now also benefit from Wikidata station data augmentation.
  • Bus trips on Deutsche Bahn tickets are now correctly handled.
  • Applet Wallet passes have a proper icon in the file browser now.
  • We fixed merging of train tickets and ticket-less train seat reservations, as well as merging of conflicting seat information for flight bookings and boarding passes.

KDE Itinerary app:

  • Calendar import on Android works again with newer DavDroid versions.
  • Journey views for alternative connection searches are now sorted correctly by departure time (rather than by departure time of the first transit section).
  • Journey elements with suspicious properties (such as too long walks) are highlighted in red in the journey icon summary view.
  • The public transport backend configuration page now has section headers per country, to deal with the increasing numbers of backends.
  • Finding of some optional dependencies has been fixed, so the nightly Android builds have working notifications and day/night mode computation for the weather forecasts again.
  • Disabling the weather forecast actually hides forecast elements now in the timeline rather than showing outdated information for the next nine days.
  • The flight page shows airport names correctly even if we only have partial information.
  • The ticket selector shows better labels for anonymous tickets now.
  • We fixed saving the result of an alternative connection search.

KPublicTransport:

  • Negative results for departure and journey queries are now also cached, reducing the amount of network queries a bit.
  • Routes can now also have a destination property alongside the existing direction property, which allows better data aggregation when available (e.g. circular lines do not have a destination).
  • Journey sections got a distance property, which is filled by backend information where available or otherwise computed from geo coordinates. That’s particularly useful for walking sections.
  • Location queries can also select appropriate backend services based on already known country information now, for example for address searches.

Get in touch!

If you’ll be at FOSDEM this weekend and want to learn more about all this, drop by the KDE stand in building K, the Nextcloud stand in building H or my talk about KDE Itinerary (Saturday 17:00, room H.2215).

This work continues to rely on donated data samples, thanks to everyone who has helped with this so far! If you happen to have Thalys tickets with Aztec barcodes in them, those would be especially interesting at the moment as we are trying to decode their binary content.

If you want to help in other ways than donating test samples too, see our Phabricator workboard for what’s on the todo list, for coordinating work and for collecting ideas. For questions and suggestions, please feel free to join us on the KDE PIM mailing list or in the #kontact channel on Matrix or Freenode.