I’m Emmanuel, a student from Germany interested in the “Make closures.osm.ch production ready“ project for GSoC 2026. I’ve been diving into the codebase and noticed that the local Docker environment had some minor issues (specifically around Pydantic V2/FastAPI dependency conflicts and Apple Silicon compatibility).
I’ve just opened a Pull Request that resolves these build blockers and modernizes the backend dependencies. I wanted to get the environment stable first, so I could understand the current architecture and plan out the next steps for successful production deployment.
I’m also particularly interested in the integration of the project with other routing applications, as described in the project ideas. Are there any specific bottlenecks you would prioritize for this summer?
Given that the application process is competitive it’s probably not the best idea to ask questions that are not of really general interest in a public forum, but OK, that is your choice.
WRT the PRs, we currently have the issue that the repo is “owned” by last years student and that bits of the CI are quite specific to how he worked on it. I’m working on moving things to the SOSM org and will discuss how best to proceed with the PRs asap.
In general the idea of this summers project is to fix the rough edges, some of which you have already discovered, then fully integrate with at least of one of the routing server implementations (this seems to be trending to Valhalla, but I would be just as happy with Graphhopper).
In any case this requires the routing server retrieving the relevant closure information from the API (likely caching it in some way) and then adjusting the weighting appropriately. Originally we were expecting a map matching stage from OpenLR to OSM data at this point because of the issues with OSM way segments, but I would entertain adding “current” OSM way ids to the API output (this would essentially mean we would do map matching on the closures server) as a short cut and making things easier for OSM based routing engines.
The other, but smaller thing is looking at importing third party data. There is already work being done at the OST in Rapperswil in matching Alert-C based locations to OSM and processing real time traffic data using Alert-C as localisation (which sucks BTW).
Thank you for the detailed feedback and the advice regarding the application’s competitive nature. I completely understand and will save my specific architectural plans for the formal application process.
I’m glad the PR was helpful. I’ll focus my research now on Valhalla and the implementation of OSM way IDs in the API, as that seems like the most efficient path for routing integration.
Looking forward to seeing the repo move to the SOSM!
A bit more on the way ids, I’m trying to be as even handed here as possible and give all applicants a fighting chance at having the same level of information:
There’s a trade off to made here: on the one side providing not just a geometry but a list of OSM way ids (there’s a problem in that you still need to be able to refer to partial OSM ways though) makes things easier for data consumers, on the other hand OSM way segmentation is likely the most unstable part of our data and you have the additional problem that not only may the ways have changed that you originally used to generate the geometry, the data consumers might have an older or newer set of OSM data.
As a result I’m not convinced that - storing- way ids, makes any sense, however if on the fly map matching is fast enough (perhaps with a liberal dose of caching), including them for the data consumer as the current OSM geometry could very well be a good idea.