OSM Hack Weekend February 2024

Saturday, 2 March 2024 | Volker Krause

Last week I attended the bi-annual OSM Hack Weekend in Karlsruhe again, hosted by Geofabrik, focusing on indoor routing as well as Transitous.

Structured Email / Semantic Web

But first to something different (skip to the next section for OSM content).

While traveling to Karlsruhe anyway I used the opportunity to meet with people working on Structured Email, something that has a lot of overlap with the travel document extractor used by KDE Itinerary.

There’s plenty of aspects for collaboration here:

  • Sharing of test data. I learned about Web Data Commons for example, which is a giant corpus of structure data extracts from crawling the web by the University of Mannheim.
  • Sharing of lessons learned, approaches and quirks/workarounds for processing structured data. We are currently lacking a forum for that.
  • A standardized way for applications to register for handling a specific schema.org type. That way email clients or Plasma Browser Integration could dispatch objects they encounter to the respective application in a generic way, similar to how this is done for files based on MIME types. Ideally this is done on the XDG level, and while at it it’s probably worth looking at other areas where the same need came up (URLs, ActivityPub, barcode content, etc).

What we do in Itinerary for importing events, restaurants or hotels from websites is meanwhile also found in the Nextcloud Cookbook app, using the schema.org recipe data embedded in websites. And that’s still just scratching the surface, combining this with e.g. Open Food Facts could open very interesting possibilities. Very cool to see things like this being done :)

Indoor Routing

A month ago I had shown indoor routing running integrated in KDE’s indoor map demo application. That’s an important milestone, only the final 80% of the work remain now, namely making sure this produces reliable and useful results in a variety of locations.

Prefer corridors over rooms

Giving a computer the task of finding the shortest path will usually not yield practical results. That’s because human expectations around this contain many implicit assumptions, constraints and nuanced cost considerations that we all have to implement as well.

One example is shown below. The shortest path here crosses through two conference rooms or lecture halls, however you most likely don’t want to disturb whatever is ongoing in those rooms but rather take the slightly longer corridor around.

Two routes through an university building in side-by-side comparison.
Shortest path (left), preferring corridors (right).

Giving different room types different routing cost factors helps with this.

Along the same line other details have been fixed or improved, such as:

  • Emergency exists are not the same as regular doors.
  • Not all OSM barrier types are actually blocking your way (eg. bollards, but also gates/turnstiles).

Data level of detail

Another aspect to deal with is that the OSM data in some places doesn’t have the necessary level of detail needed for routing. Examples include:

  • Missing “cut outs” in the ground for stairs coming up from the floor below.
  • Missing doors to rooms, staircases or elevator cabins.

Either of those can result in significant detours or even entirely inaccessible areas.

While augmenting the OSM data is the proper solution eventually, that is quite a large task. Fortunately we have a few workarounds and heuristics to deal with some of these issues:

  • Stairs are now implemented as “off-mesh links” everywhere, rather than as 3D geometry as done previously, which allows “teleporting” through any obstacle on the way.
  • We now drop walls around any elevator or staircase if there are no door nodes at all. That may lead to routing into those areas from the wrong side, but that’s still better than not being able access those at all.

With these improvements we can now also find a way out of the most complex test labyrinth so far, the Paris Metro.

One floor level of the complex underground maze of the Paris Metro.
Paris Metro station at Gare de l'Est.

Data modelling

This work also identified a few issues where the OSM indoor data model is ambiguous or cannot express relevant details yet:

  • There’s a significant difference between implicit walls on indoor=corridor elements in the Simple Indoor Tagging (SIT) scheme and usage in reality. No matter how you interpret that for routing you either end up either with unreachable areas or routes through walls.
  • Similarly, there’s ambiguities on how (implicit) outer building walls should be mapped/interpreted.
  • There is no way to model service counters that you might find at ticket offices or fast food stands. This matters to route towards the right side of a building/room.

See also the corresponding mailing list post for details, as well as the the upcoming quarterly OSM Indoor Meetup (Wednesday March 6th, 18:00 CET, online).

Transitous

Transitous, an effort to set up a free and open public transport routing service, also involves a lot of OSM data and software, so that was the other big topic for me.

Intermodal routing

While the public transport routing part for this works quite well already, enabling the intermodal routing has proven challenging. That is routing the first and last mile to and from public transport stops by foot/bike/scooter/car or a combination thereof, possibly considering things like available parking spaces or rental vehicles.

That is build on top of existing OSM routing engines, and MOTIS supports different options there as well. We haven’t found a combination yet that can import planet-wide data or at least data for all of Europe on the hardware we have (ie. needing significantly less than half a TB or RAM), offers the feature set needed by MOTIS for intermodal routing (1:1, 1:N and N:M routing, customizable profiles) and deliver all that with sufficient runtime performance. Bonus points for at least having the option for other advanced routing features (elevation support, realtime traffic support, etc).

There was a clear recommendation from the people running and developing those things professionally for GraphHopper. MOTIS has no support for that one yet, but it seems doable to add that. The bigger problem here is potentially that GraphHopper’s “Matrix API” (the part doing very efficient N:M routing) is apparently not available in the open source release. So we still don’t have a proper solution for this.

Geocoding

Another component needed for all this is address and POI search and as-you-type completion. There was an equally clear recommendation for Photon. That comes in an easy to get started package with a single binary and a pre-built database for a single country or the entire planet, but also allows to transition to a more complex setup enabling incremental data updates and offering a ton of options to fine-tune and customize the results (support more languages, bias towards certain types of locations, etc).

MOTIS integration for this also yet has to be done, but should be quite straightforward. Without intermodal routing this doesn’t gain us much on its own though.

Public transport coverage

Meanwhile the public transport coverage on Transitous is growing rapidly, see Jonah’s blog post on how to get your region included.

Map of (parts of) Europe, with many small colored markers showing current train/bus positions.
Transitous coverage in Europe.

If you are interested in collaborating on this, join the #opentransport Matrix channel and the Transitous Github project.