Last year KDE Itinerary got an indoor map view for airports and train stations, using a specialized map renderer and using raw OSM data as source. Improving that by contributing to upstream OSM data as well as our MapCSS styles now got a bit easier.

KOSMIndoorMap Demo App

The component used by KDE Itinerary for this, KOSMIndoorMap, is a library and as such not really useful without being embedded in an application. Having to create dummy itineraries covering all locations you want to check so you can look at the map is however very inconvenient e.g. when working on OSM data upstream.

To address this one of KOSMIndoorMap’s test programs has been expanded to a little stand-alone demo/test app, and more importantly, packaged for KDE’s nightly Flatpak and Android builds.

Flatpak:

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak remote-add --if-not-exists kdeapps --from https://distribute.kde.org/kdeapps.flatpakrepo
flatpak install kdeapps org.kde.kosmindoormap

Android:

Note that this is not meant as a user-facing application at this point, and as such misses things like translations and contains a number of features only useful for contributors. It doesn’t even have all the features and controls yet the indoor map integration in KDE Itinerary has at this point.

Screenshot of the KOSMIndoorMap demo app's location selection dialog.
KOSMIndoorMap standalone demo app offering different means of selecting a location.

Should somebody be interested in creating a generally useful indoor map app, that could certainly be done on top of KOSMIndoorMap (and we should talk :) ), but that’s currently not the scope here.

Reviewing OSM Data

The most important use-case for now is reviewing (and improving) OSM data. The crucial difference between regular (outdoor) maps and indoor maps is the floor level topology. Whether that data is correct is hard to judge on a map renderer that doesn’t split floors.

In OSM, floor levels are modeled using the level tag, anything not on the ground floor should have that. In the most simple case the value is just an integer number, and the most common issue is that this is missing on a few elements.

Screenshot of a side-by-side comparison of floor levels 0 and 1 of Brussels South station, showing railway tracks on the wrong level.
Side-by-side comparison of two floor levels showing railway tracks on the wrong level at Brussels South station.

Slightly more elaborate are elements connecting multiple floor levels, such as stairs, elevators or escalators. For those the level tag should contain a range or semi-colon separated list of floors. In our indoor map renderer this results in the ability to change floors by clicking on the corresponding element. This information being incomplete is also common, resulting in stairs only shown on a single floor for example.

Screenshot of an underground section of Munich central station with a few stairs highlighted that are only assigned to a single floor level.
Some stairs in Munich central station being non-interactive due to only being assigned to a single level.

After identifying and fixing such issues in the OSM data you should see the new data in the app within a week or two, as it propagates through the server-side and local caches.

Improving MapCSS Styling

When editing and improving our MapCSS map styles, the stand-alone app is equally useful. The app allows you to load an external MapCSS stylesheet, as well as reload one previously opened, so you get immediate feedback of your changes.

This does work fine on Linux, on Android this is a bit more complicated due to the file system sandboxing mechanisms. So I’d expect problems there when using stylesheets spread over multiple files (for which we need access to the entire directory). KDE Itinerary works around that in development mode with allowing to “upload” changed stylesheets into its internal storage space, but that’s still missing in the stand alone app.

What you get on both platforms though is the “diagnostic” style, showing the raw geometry of all elements, and the ability to show all OSM tags in the element information dialog (enable “Debug Info Model”).

Testing and Feedback

A third use-case of course is general testing of the indoor map renderer and its higher-level functions like properly identifying train station platforms or airport gates, or the matching of OSM elevator/escalator data with the corresponding realtime status information.

There’s a workboard for identified issues, proposed extensions or any other feedback.