FOSSGIS Conference 2026

Last week I attended this year’s FOSSGIS-Konferenz in Göttingen, Germany, focusing on public transport and indoor navigation topics.

OSM indoor mapping

As it is tradition by now, Tobias and I hosted the Indoor OSM BoF.

The (translated) session notes are in the wiki. There’s some recurring themes, such as increasing the level of detail in the third dimension, as well as how to properly map inclined areas and two-dimensional walls. None of that has a good solution yet, so we are trying to get the right people together for a multi-day in-person workshop to finally progress those topics.

I’m also increasingly wondering whether we need to replace the term “indoor” in this context, as that means different things to different people:

• Mapping physically within a building. That separation is all but clear-cut though, in particular in and around train stations.
• Mapping using areas rather than ways. That’s also not unique for being “indoor”.
• Using the level tagging from SIT. While referring to “floor levels”, this is the best way we have to place features vertically, and that’s also something that isn’t limited to buildings.

Kate getting syntax highlighting for ISO 10303-21 STEP files, a file format used in building information modeling (BIM) (ie. the best possible data source for importing building geometry into OSM) is of course purely coincidental.

Indoor routing

Triggered by talks on indoor navigation in previous years which weren’t as forthcoming with actually publishing their code or papers as one might expect for a conference with “FOSS” in the name already, I presented the work we did in KDE for OSM-based indoor routing for Itinerary and Kongress.

The implementation is part of the KOSMIndoorMaps library and uses Recast Navigation under the hood. This works solely on areas, without needing an explicit routing graph. And it allows for routing to/from any arbitrary point, which is a requirement for localization/navigation use-cases. There’s drawbacks as well, directional cost on inclined ways are hard to consider with this for example.

Richard from TU Dresden presented an alternative approach for indoor routing, semi-automatically generating routing graphs inside areas. This provides visually nicer results in narrow corridors, but becomes more challenging in open areas. By pure chance both our talks used the same building for demonstration, quite useful for discussing the strength and weaknesses of both ways.

Another topic of discussions was how to scale this up from working on a single building to something a planet-scale router such as MOTIS could integrate. Neither approach is well suited for that out of the box.

Transitous

Transitous was featured in Felix’ and Robin’s talk about new developments in MOTIS. Many of the new features presented there can already be seen in use on Transitous.

The conference provided the opportunity to talk to data providers about what we would need or would like to have for Transitous, as well as to data consumers, such as CoMaps, who are exploring integrating public transport routing.

And with several Transitous contributors around we also discussed a bunch of topics being currently looked into:

• How to integrate the Danish Siri-over-AMQP feeds.
• Parsing issues with the Swiss aerial lift NeTEx feed.
• Sorting out the API key handling for the Baden-Württemberg Amarillo ride sharing feed.
• Implementing spport for temporary POIs such as events.
• Getting “DIID” elevator identifiers into OSM, for matching SIRI-FM realtime status feeds to OSM data for routing.
• How to integrate empirical delay data into the MOTIS API.

KDE Itinerary

I also met a few Itinerary users and got feedback on current issues. An area that needs work is the fallback handling in the KPublicTransport library. We aren’t very good (yet) at switching to different sources when the primary one fails to deliver useful results. With the DB API becoming increasingly unreliable due to randomly blocking access (not just our apps, also affects their website), this becomes increasingly visible.

FOSSGIS e.V.

FOSSGIS e.V. is the German local chapter for OSM, and the organizer of the FOSSGIS-Konferenz. Given the significant overlap in topics (and some overlap in people) FOSSGIS e.V. has been one of the obvious organizational umbrellas for both the Open Transport Community Conference and Transitous.

This has been moving forward recently, and will solve a few practical problems:

• Allow us to hold assets like domains independent of individual contributors, removing single points of failure.
• Allows us to receive and spend money in a clean way.

This is rather important for the long-term sustainability of both initiatives. Being able to handle money is especially pressing for the Open Transport conference, as given the rather expensive location this year we’d like to offer some form of travel support for people who aren’t attending this as part of their job.

Dynamic traffic data

Following a joined HeiGIT/BKG talk on routing quality there were a lot of hallway discussions on dynamic traffic data, as well as a session during the unconference part, all focusing on a proper free and open solution for this.

Dynamic traffic data includes:

• (Aggregated) realtime traffic flow data (ie. current traffic jams).
• Raw traffic flow sensor data, ie. sensors counting vehicles or floating vehicle position/speed vector data.
• Statistical traffic flow data (ie. high traffic expected during specific times).
• Dynamic traffic sign data, such as adaptive speed limits.
• Temporary closures due to construction work, accidents, etc.
• Realtime availability data for bike or car parking spaces.

This is crucial information for road routing, traffic planning and research. However currently this data is collected and owned by a few proprietary vendors. Google is a particularly big player here, using the position data submitted by Android phones.

In order to build a free and open replacement the only chance we have is to do that jointly, between all parties with any interest in this, otherwise this wont gather the necessary critical mass. Doing this under the OSM umbrella seems to be the obvious choice, especially since this needs to be mapped on to the static OSM road network data anyway.

It would certainly be an ambitious project, but there’s a bunch of building blocks to work with already:

• Sensor data from some public authorities, with various levels of processing applied.
• A few cases of realtime data for dynamic traffic signs from their operators.
• (Planned) construction site data in Datex II format by public authorities,
• Floating vehicle information from GTFS-RT vehicle position feeds for busses (which we consume for Transitous already).
• A community maintained road closure/construction database from SOSM.
• Realtime parking data, partially even in standardized ParkAPI or Datex II formats.
• Crowd sourcing in end user apps like CoMaps is likely also a viable option, similar to the work on crowd sourcing delay information for Transitous.

While this is mostly affecting roads (and thus cars and busses), construction work can also affect pedestrian and bike routing, either entirely or by changing e.g. relevant accessibility properties for wheelchair routing. There was agreement that any free and open effort should equally consider those modes of transportation.

The open source routing engines either already have support for integrating dynamic traffic data, or have adding support on their roadmap, Transitous would certainly integrate that as well. Public agencies were equally interested in open traffic data, but not all of them did show quite the same enthusiasm for also contributing to that yet.

All this gave me a slight déjà vu to the state of public transport routing prior to FOSSDEM 2024, there seems to be a critical amount of interest and willingness to join such an effort, somebody™ just needs to kick-start it.