Extended event support
While transport-related tickets are most often in focus when talking about Itinerary, it can also handle other bookings relevant on the road, such as hotel reservations and event tickets. In particular the handling of events received a number of updates.
Data import and data extraction:
- Opening an event URL from Mobilizon with Itinerary will import the corresponding event. This doesn’t even use ActivityPub yet, supporting that eventually will give us even more event details and will allow automatic updates.
- Generic iCal data without semantic annotation can now also be imported directly.
- There’s new and/or improved data extractors for Eventim, Indico, Kinoheld, Meetup and Pretix.
Displaying event information in the app:
- Seat reservations are now shown in the full level of detail when available.
- Event websites and descriptions are shown on the event details page.
- Apple Wallet event tickets are now rendered correctly also when containing image assets that are outside the specified sizes, by applying downscaling or tiling.
Improved barcode scanner
Importing tickets by scanning their barcodes has been available for some time, but didn’t always work reliably under poor light conditions. For those cases the barcode scanner now allows to turn on a torch light if available (which is the case on most phones).
After three years there will be an in-person FOSDEM again, starting tomorrow, with the KDE stand in building K as usual.
To address the persisting problem of Google blocking updates to Itinerary in the app store due to the health certificate feature there’s now a plan to move that feature to a separate app. That would then of course not be available in the Google store, but would be limited to free platforms.
Several train and bus operators offer Wi-Fi on their vehicles, and often this comes together with a portal website showing current journey information. The latter is typically power by some form of onboard API which reports the current speed and position of the vehicle as well as information about the route and possible disruptions.
Work has started on a new library to make use of this. For this we are monitoring which Wi-Fi network we are currently connected to, and if it’s one we know the onboard API for continuous updates of the current position and journey are retrieved.
While Wi-Fi names differ from operator to operator there’s only a few vendors of onboard information systems, so we can often cover many operators with the same code. Still we have to look at each operator and add the necessary configuration. That’s where we again need help from everyone traveling, please note Wi-Fi names and capture communication between the portal website and its backend when encountering such systems!
So far we have CD Railjet, DB ICE, FlixBus coaches, SNCF Inoui and Thalys covered.
Showing this information in the app is straightforward and can be useful, but the real value comes from using this for further assistance features:
- Are you on the right train? That’s not always as obvious as one might think, considering for example multi-set trains that split up along the way.
- Are we there yet? That is obvious for the traveler, but it’s tricky for the app. Especially disruptions shortly before arrival can get lost, as the online routing services we query for this simply might not have that information fast enough. This then results in not getting further updates on the estimated arrival time, and no support in finding an alternative for a missed connection.
And that’s not even all that can be done here, there’s already suggestions to use this data to assist with connecting to the right Wi-Fi when detecting a corresponding access point, or to extend the same approach to airport and train station Wi-Fi systems.
Finding traveler names
There are a few ticket barcode formats that predate Unicode and as such only contain ASCII transliterations of passenger names. Flight boarding passes are the most prominent example, being even limited to a maximum of 20 uppercase ASCII letters.
Unless your name happens to be compatible with those restrictions, that leads to more or less mutilated and truncated spellings. And that’s not only a cosmetic issue, it makes merging data from different sources much harder.
Often the properly spelled name is found in the same document containing the bardoe though. For this case we now have a new component in the extractor that uses names found in barcodes and then searches for their proper spelling in PDF documents and Apple Wallet passes.
While this tends to produce good results on many airline documents it is still limited to Latin scripts. It’s probably possible to extend that to other scripts using ICU’s transliteration capabilities, but we’d need enough sample documents for those cases for testing first.
Itinerary’s accessibility with assistive tools such as screen readers has a lot of room for improvements to put it mildly. With KDE having made software accessibility an explicit goal and with the recent work on using the AT-SPI interface also for automated testing it’s high time we change that.
A number of improvements have been implemented already, both in the app as well as in underlying libraries, to improve the structure exposed over AT-SPI and to add textual information to icon-only elements. But there is still a long way to go.
Static extractor builds
For use in e.g. Nextcloud we have the ability to do a full static build of the travel document extractor, as that significantly simplifies server-side deployment.
This used to be done with a custom Docker image manually and now has been redone as a Gitlab job on KDE’s CI infrastructure. While at it, a few more things were improved:
- Static linking against zlib, so the extractor is independent of the zlib version installed on the target system.
- Switch the build job to CentOS 7, which reduces the required glibc version down to just 2.17.
- Set search paths for translation catalogs automatically, so deployment requires no further step than unpacking the archive generated by the CI job in an arbitrary location.
Further improvements are being worked on, such as making KI18n use embeded iso-codes caches, something that would also benefit e.g. Android APKs.
Fixes & Improvements
Travel document extractor
- Improved extractors for MÁV, Trenitalia, NH and Premier Inn hotels as well as the caesar-data and onepagebooking booking engines.
- Fix determining the year of travel from context for RCT2 tickets that don’t contain the year.
- Improve merging of different reservations for the same train trip when there are slight variations in arrival time or destination spelling.
Public transport data
- Support new GBFS v2.3 vehicle and propulsion types such as cargo bikes and hybrid engines.
- Fix filtering of floating vehicles by distance. This makes rental bikes show up on the station map correctly again.
Rendering engine improvements:
- Support rendering icons using real-world rather than screen sizes. Sizes can be specified explicitly in the MapCSS style or taken from OSM tag values.
- Support MapCSS tag setting expressions. This allows styles to overwrite OSM tag values and have those values considered in the subsequent style evaluation.
- Consider pen width when computing polyline bounding boxes. This fixes interacting with near horizontal or near vertical ways.
- Kate can now highlight MapCSS styles.
- Don’t search for the next opening time arbitrarily into the future. This fixes a potential infinite loop in certain “always closed” opening hours expressions.
Map content improvements:
- Override suspicious layer tags on building elements. Those can exist in the OSM data due to optimizations for the general outdoor renderer but result in wrong stacking orders in the indoor view, with building (background) elements covering foreground details.
- Show building and room entrances, barrier blocks and trees.
- Also consider the building tag for determining the element name.
- Show element description texts when available.
- Handle more tagging variants for disused/closed amenities/shops.
- Floor level topology fixes in OSM for major railways stations in Brussels, Vienna and Dresden.
- Continue the transition to the Kirigami Mobile Forms UI component, the generic ticket and program membership pages use those as well now.
- Determine proper time ranges for the map view on non-transit elements (events, hotels, restaurants, etc). This is necessary for opening hours to be taken into account on the map display.
- Also allow reverse geo coding in the place editor, that is look up the address based on an already available geographic coordinate.
- Fix too aggressive merging of generic Apple Wallet passes.
- Do not accept rotation gestures on the location picker map, making it behave more predictably on touch interactions.
How you can help
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.