Last week I attended another OSM hack weekend, hosted by Geofabrik in Karlsruhe. Unsurprisingly my focuse there has been on topics related to our use of OSM data in KDE Itinerary.

The indoor map renderer used by Itinerary now has support for listing all amenities in the building or area currently looked at. This enables things like finding a place to grab a coffee in a big station or searching for a place to get food in the vicinity of your hotel, without any search term ever leaving your device.

Itinerary showing a list of restaurants and shops with names and opening hours and a search line.
Itinerary's amenity search in the vicinity of a train station.

All that data comes from OSM, and thanks to the use of raw data tiles it is already fully available locally in the moment you open the map. This includes names, categories, types of shops, cuisine offered in restaurants, opening hours, etc.

The exact selection and categorization requires a substantial number rules to deal with the great level of detail in the OSM data, and those might differ depending on specific usecases. We (ab)use MapCSS for this, which all the rendering is based upon as well. While not exactly made for this, it allows to easily specify complex matching rules for OSM data, which is exactly what we need here.

Most of this data is available in a more machine- than human-readable form and thus needs to be translated. This is necessary both for display but also for searching. Exchange with OSM developers working on editing tools turned out particularly valuable here, as the editors have to deal with the same issue, just the other way around.

One aspect worth exploring is the use of translated synonyms. For example, the English term “butcher” translates to German as “Metzger” or “Fleischer”, both equivalent but spelling-wise very different. When searching for such a shop in German we’d ideally match on both. The editors have existing datasets for synonyms that we might be able to reuse, and it would also be interesting to see if KDE’s translation infrastructure has ways to produce such synonym sets.

Map renderer

As mentioned in last week’s Itinerary post I have been working on rebasing the indoor rendering style onto a MapCSS adaption of the OSM Carto style known from the OpenStreetMap website. That would allow us to benefit from all the detail work in there while still being able to apply own color schemes or content customization/extensions on top.

One aspect I had been struggling with for this has been understanding how exactly z-ordering works for the Carto style. Our existing style is a bit sloppy in that regard by using semi-transparent fills in many places, but with opaque fills you have no choice but to get the order right.

A few conversations over dinner and breakfast before the official start even provided the necessary hints. That then finally also allowed implementing merging of casings for adjacent highway areas and lines, something we so far were not able to do at all.

Itinerary's map renderer using the Carto style showing a complex pedestrian consisting of lines and polygons, rendered with joined casings.
Itinerary's map using the Carto style rendering joined casing for pedestrian areas/lines.

Another long standing issue in our renderer were overlapping icons and text labels. Our existing styles worked around that by using relatively high zoom thresholds for showing those, at a point where overlaps are relatively unlikely. That’s far from ideal though, overlaps still occur and information density suffers on lower zoom levels.

With a better understanding on how the Mapnik renderer solve that there is some progress on this as well. We now have explicit MapCSS style controls for icon and label overlap, as there are map elements that are technically icons but which can be overdrawn by other icons (entrances, trees, etc) and that would potentially block too much content otherwise. While at it this also fixed a few issues with icon placements and icon/label hit detection for interactions.

Itinerary's map renderer using the Carto style showing densely packed amenity icons and labels without undesired overlap.
Densely packed icons/labels with explicit overlap control for the entrances.

A few performance optimizations made all that possible without compromising rendering speed, so this is all still done with runtime style evaluation (including for dynamic properties like opening hours evaluation) and with every element being interactive.

Indoor mapping meetup and mailinglist

Since the OSM Indoor Mapping workshop in Frankfurt last year I somehow got the task of organizing the OSM Indoor Mapping online meetups assigned. At the most recent edition of that we discussed turning this into a more regular thing, starting at a quarterly interval. There’s now also a brand new proper mailing list replacing the manually managed distribution list.

So we hopefully get to a setup here where we can get some work on indoor tagging/mapping related questions and proposals done. That’s the foundation for any rendering or routing to be built on top.

Raw data tiles

There wasn’t much time left to also cover topics around our raw data tile infrastructure, for which I yet have to deliver a standalone reassembly tool as discussed during the previous hack weekend in February.

There’s interesting developments for the longer-term evolution of this though, with osm2pgsql meanwhile being capable of producing full raw data output again as well as with its low-zoom generalization support. That might eventually become an alternative for parts of our current setup and could address shortcomings we have around low- and mid-zoom tiles.

You can help!

Hack weekends how this is called in the OSM community or sprints as this is known in KDE are immensely valuable and productive. There’s a great deal of knowledge transfer happening, and they are a big motivational boost.

Physical meetings incur costs though, and that’s where your donations help! KDE e.V. has a travel support program, and I’d assume the OSM Foundation and/or its local chapters have something similar as well.