Since the last post two month ago KDE Itinerary has received improved support for overnight trains, severe weather warnings, an integrated barcode scanner and a new address format meta data system, and has been featured at the Wikidata Data Reuse Days 2022.

New Features

Overnight trains

The train coach layout now also shows information relevant for overnight train, such as couchette and sleeping cars.

Screenshot of KDE Itinerary's coach layout page showing an overnight train.
KDE Itinerary's coach layout view showing an overnight train.

Rendering issues for control and power cars on high DPI screens have been fixed as well, and more train types in Austria, France and Switzerland are supported now.

Severe weather condition warning

In case the weather forecast predicts severe weather conditions, that is wind, precipitation or temperature at potentially dangerous levels, both the corresponding timeline item as well as the per-hour entries on the weather details page are now shown with a red tinted background.

Weather forecast timeline entry from KDE Itinerary indicating a heavy storm.
Severe weather forecast due to heavy storm.

This currently is using simple thresholds, but since humidity values are also available in the weather forecast data we use, a proper heat index based threshold is in reach as well.

Integrated barcode scanner

Another new addition is the embedded barcode scanner, saving you the detour via a separate scanning app. This is not only a bit more convenient, most importantly it avoids issues with transferring binary content correctly, something many barcode scanning apps aren’t really prepared for.

Screenshot of KDE Itinerary's integrated barcode scanner showing a detect QR code which doesn't contain a travel ticket.
Integrated barcode scanner in KDE Itinerary.

If the scanned barcode contains a supported travel ticket or health certificate it is imported directly.

This hasn’t been integrated in the main branch yet though, as the necessary KDE Frameworks changes are still awaiting review.

Infrastructure Work

Behind the scenes the probably biggest change is the new address formatter in the KContacts framework. Unlike the previous system this now supports multiple format styles rather than exclusively producing postal addresses. The official postal style in many places upper-cases various address parts and/or adds additional empty lines, which isn’t necessarily the nicest way to display an address.

Additionally, the old system was limited to a single script, and made assumptions that only hold for Latin-like scripts. The new system can pick different formats based on whether an address is specified in a local script or a Latin transliteration, something particularly relevant in various Asian countries for example.

However, the actual address formatting is only scratching the surface here, the real power is in the address format meta data, which is also accessible to applications now. For example:

  • Which parts of an address are used in a given country? In some countries the country subdivision (region, state, etc) is not a part of the address, while in others it’s essential and mandatory. Address input forms can use this to hide or enforce the corresponding input field.
Screenshot of KDE Itinerary's address input showing the region being requested for a US address but not for one in Belgium.
Address input only requiring the country subdivision when needed.
  • What’s the postal code format? Many countries use some form of number there, but more complex schemes also exist. The KContacts API provides a regular expression for this, which can be used for input validation but also for detecting and extracting postal codes from unstructured text.
Screenshot of KDE Itinerary's address input showing postal code validation in the United Kingdom.
Postal code input being validated in KDE Itinerary.
  • In which order do the different address parts occur? Depending on the country you might find any kind of order between city, state and postal code for example. When trying to identify addresses in unstructured input that’s very useful knowledge.

The travel data extractor is using this to replace much too simple and Euro-centric hardcoded address extraction code for splitting up some address parts correctly.

All of this is of course not limited to KDE Itinerary, a few other KDE applications will benefit from this as well. And last but not least, by using a meta data format compatible with libaddressinput we also increased the country coverage from 35 to more than 190.

Fixes & Improvements

Travel document extractor

  • New Wikidata based lookup tables for Amtrak and IATA train station codes.
  • Use country subdivision code for determining the timezone as well when available.
  • Add extractor scripts for Spring Airlines bookings.
  • Improved extractor scripts for Air France, ÖBB and SNCF.

Indoor maps

  • Missing country/country subdivision information for addresses are now filled in based on geographic coordinates. This helps with address formatting and evaluating local public holiday based opening hours.
  • Fix formatting user visible numbers with the right locale.

Itinerary app

  • On Android, the native date/time picker is now used when adding a train trip manually.
  • Domestic Danish COVID certificates can now be imported as well, although not all of the information contained in those are shown yet. This also required some additions to the PDF extractor, as the official documents just contain a full page raster image.


Feedback and travel document samples are very much welcome, and there are plenty of other things that can be done without traveling as well. The KDE Itinerary workboard or the more specialized indoor map workboard show what’s on the todo list, and are a good place for collecting new ideas. For questions and suggestions, please feel free to join us on the KDE PIM mailing list or in the #kontact channel on Matrix.