The alternative journey selection for unbound or delayed train reservations finally works for the whole journey rather than just one the selected journey segment, and is now also able to properly save a new journey with more or less segments than the previously selected one. It is now also possible to search for earlier or later journeys if the corresponding backends support that.
In order to know when you have to look for an alternative journey, about to be missed connections are now highlighted in the timeline, based on available real-time data.
The navigation options offered per location also got a bit smarter. The “navigate to” action now uses the assumed location from the itinerary as a starting point for future elements, rather than the current location. This means that you can look at how to get to your hotel from the train station, rather than getting a route from your home to the hotel directly, for example. (On Android, this is only available with OsmAnd, not with the system map.)
At arrival locations, the navigation actions now also offer a real-time departure schedule for local public transport. This allows you to check how much you need to hurry to catch the next bus or train home from the airport for example, as a stop-gap measure until the app is smart enough to know where “home” is and offer the appropriate journey directly.
Back fields of Apple Wallet passes are now also viewable in the app, not just in KMail.
There’s quite a few interesting changes in the data extractor engine and its tooling too:
One of the biggest changes is the newly added support for vector barcodes in PDF files, see the post on this subject for details.
The airport disambiguation got improved for cases of very short distances and for ambiguities on both ends of the journey. The recent Plasma sprint in València provided the following example: A flight from “Frankfurt” to “Valencia” ends up with FRA and HHN as candidates for the departure airport, and VLC and PPN for arrival. Based on the duration of the flight we can exclude PPN, as it wouldn’t be a viable option for either departure location candidate. We also know that FRA and HHN are in the same timezone, so that we can ultimately determine the timezones for the entire flight.
The UIC 918.3 train ticket parser now supports ticket layouts other than the European standard ones (RCT2). That’s a somewhat ASCII-art like representations of tickets that can be present in the large UIC 918.3 Aztec barcodes. The local transport operator in Nürnberg is using such barcodes for example, as encountered during the recent multi-sprint there. To support this, KItinerary Workbench is now also able to visualize UIC 918.3 ticket layouts.
Custom extractor scripts got new convenience API to reduce the amount of boilerplate code needed to create new reservation objects, as well as access to more properties of iCalendar input objects.
KItinerary Workbench now has a XPath evaluator with result highlighting in its DOM view, to help debugging XPath queries in custom extractor scripts. HTML to plain text conversion in the extractor now correctly skips stylesheet elements.
KPublicTransport, the frameworks providing access to real-time public transport data received several improvements as well:
- There is now support for handling license and attribution information. While probably one of the more boring features, it’s crucial to be compliant with the Open Data licenses of the source data, and access to that source data is ultimately what enables all the exciting things we build on top. The app will show these information now in the about page, and under the journey and departure views.
There is ongoing work to make query results accessible incrementally, even if not all backends have responded yet. Initial results are available quicker with this, but it can lead to results changing or reordering as more information come in. The new real-time departure view in the app is already using this.
KPublicTransport can now carry address information in its Location data type. Those are not provided by all backends, and hardly ever complete, but it allows the app to augment its knowledge about a station if address information are available.
Backends can now have two different location identifier types, typically one backend-specific one and one standardized one (e.g. UIC station codes or IBNRs). This addresses the fact that not every stop or station has one of the standardized identifiers, but we still want to get the standardized identifiers whenever present (as those allow augmentation with Wikidata information, and robust location comparison).
Fixes & Improvements
There are also plenty of smaller changes that are noteworthy:
- Trip grouping in the app now also considers layover time as an additional criteria. A very short time between two elements likely indicates they belong to the same trip.
- Importing data from Nextcloud/DavDroid works again with recent DavDroid versions. DavDroid changed the way they store custom iCal properties, which we rely on. The new way however is much easier to handle for us, eventually avoiding the dependency on the iCal4j library even.
- The alternative journey view now shows the number of changes correctly.
- Day changes on overnight flights are now automatically fixed in post-processing in many cases, as this turns out to be often wrong in the input data.
- Calendar events generated from restaurant reservations no longer contain empty fields for optional information.
- New or improved extractors for simplebooking.it, booking.com, easyJet, Travelport Galileo and VGN, based on booking information from the Plasma and KDE Connect sprints, and for Akademy.
As usual a big thanks to everyone who donated test data, the samples from participants of the Plasma sprint in València resulted in the most extractor engine improvements this time I think :)
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 Freenode.