OpenStreetMap User's Diaries
Wrapping up GSoC 2026: Making closures.osm.ch production ready
Wrapping up GSoC 2026: Making closures.osm.ch production ready
This summer I had the chance to spend my second Google Summer of Code working with the OpenStreetMap Foundation, this time on closures.osm.ch, a community platform for reporting temporary road closures in real time so that routing engines can actually route around them.
closures.osm.ch started life during GSoC 2025 as a soli
Wrapping up GSoC 2026: Making closures.osm.ch production ready
This summer I had the chance to spend my second Google Summer of Code working with the OpenStreetMap Foundation, this time on closures.osm.ch, a community platform for reporting temporary road closures in real time so that routing engines can actually route around them.
closures.osm.ch started life during GSoC 2025 as a solid prototype: a FastAPI backend, a Next.js frontend, OpenLR location referencing, and a first attempt at routing integration with Valhalla. My job this summer was to take it from “working prototype” to something closer to a real production service.
The routing problem
The biggest issue going in was architectural. The frontend was fetching closures, pulling out raw coordinates, and handing them to the public Valhalla instance as exclude_locations. It worked, sort of, but it had a hard 49-point cap, ignored one-way closures entirely, and duplicated business logic between two different frontend components. None of that scales.
Before writing any code, I actually went and discussed the right approach with the Valhalla maintainers themselves in a public GitHub discussion. That conversation confirmed the long-term correct architecture is Valhalla’s live traffic tile infrastructure rather than anything at the exclude_locations level. That’s a bigger undertaking than fits in one summer, so the plan became a two-stage one: build a solid stepping-stone now, leave the graph-level integration properly documented for later.
That stepping stone is what shipped: a self-hosted Valhalla instance, and a new backend endpoint that buffers closure geometries with Shapely and passes them to Valhalla as exclude_polygons instead. The frontend got a lot simpler as a result, it just asks for a route now and gets one back with closures already avoided, no more duplicated logic living in the browser.
OpenLR, for real this time
Somewhat embarrassingly, the OpenLR codes the platform was generating weren’t actually spec-compliant OpenLR, they used a custom marker byte that no standard decoder could read. That’s now fixed, with encoding going through Valhalla’s map-matching, so closures.osm.ch’s location references should now interoperate with other OSM-based navigation tooling that speaks real OpenLR.
Vector tiles
Active closures are now served as MVT vector tiles straight out of PostGIS with ST_AsMVT, so the map layer updates live instead of requiring a page reload. Small feature, but it makes the map feel a lot more alive.
What’s left
Government data ingestion is the piece I didn’t get to finish. The plan was CIFS and DATEX II importers so the platform could ingest authoritative closure data from municipal agencies directly, but partway through the summer that scope shifted: OST offered to push pre-processed Swiss ASTRA data to us directly instead of us having to parse it ourselves, which changes the shape of that work. I’ve made a start on it, but it’s genuinely not done, and I’ll be continuing on it after GSoC officially wraps up. UI internationalisation is also still untouched, it’s documented as deferred work for now.
Thanks
Huge thanks to my mentors Simon Poole and David Haberthür for the guidance this summer, and for trusting me to make real architectural calls on a project that real people depend on. Also thanks to the Valhalla maintainers for taking the time to talk through the routing architecture with a stranger on the internet before I’d written a line of code.
If you want the full technical rundown with links to every PR, I’ve written that up separately in the project’s final report.
Development on closures.osm.ch continues, I’m not stopping here.
This summer I had the chance to spend my second Google Summer of Code working with the OpenStreetMap Foundation, this time on closures.osm.ch, a community platform for reporting temporary road closures in real time so that routing engines can actually route around them.
closures.osm.ch started life during GSoC 2025 as a soli
Wrapping up GSoC 2026: Making closures.osm.ch production ready
This summer I had the chance to spend my second Google Summer of Code working with the OpenStreetMap Foundation, this time on closures.osm.ch, a community platform for reporting temporary road closures in real time so that routing engines can actually route around them.
closures.osm.ch started life during GSoC 2025 as a solid prototype: a FastAPI backend, a Next.js frontend, OpenLR location referencing, and a first attempt at routing integration with Valhalla. My job this summer was to take it from “working prototype” to something closer to a real production service.
The routing problem
The biggest issue going in was architectural. The frontend was fetching closures, pulling out raw coordinates, and handing them to the public Valhalla instance as exclude_locations. It worked, sort of, but it had a hard 49-point cap, ignored one-way closures entirely, and duplicated business logic between two different frontend components. None of that scales.
Before writing any code, I actually went and discussed the right approach with the Valhalla maintainers themselves in a public GitHub discussion. That conversation confirmed the long-term correct architecture is Valhalla’s live traffic tile infrastructure rather than anything at the exclude_locations level. That’s a bigger undertaking than fits in one summer, so the plan became a two-stage one: build a solid stepping-stone now, leave the graph-level integration properly documented for later.
That stepping stone is what shipped: a self-hosted Valhalla instance, and a new backend endpoint that buffers closure geometries with Shapely and passes them to Valhalla as exclude_polygons instead. The frontend got a lot simpler as a result, it just asks for a route now and gets one back with closures already avoided, no more duplicated logic living in the browser.
OpenLR, for real this time
Somewhat embarrassingly, the OpenLR codes the platform was generating weren’t actually spec-compliant OpenLR, they used a custom marker byte that no standard decoder could read. That’s now fixed, with encoding going through Valhalla’s map-matching, so closures.osm.ch’s location references should now interoperate with other OSM-based navigation tooling that speaks real OpenLR.
Vector tiles
Active closures are now served as MVT vector tiles straight out of PostGIS with ST_AsMVT, so the map layer updates live instead of requiring a page reload. Small feature, but it makes the map feel a lot more alive.
What’s left
Government data ingestion is the piece I didn’t get to finish. The plan was CIFS and DATEX II importers so the platform could ingest authoritative closure data from municipal agencies directly, but partway through the summer that scope shifted: OST offered to push pre-processed Swiss ASTRA data to us directly instead of us having to parse it ourselves, which changes the shape of that work. I’ve made a start on it, but it’s genuinely not done, and I’ll be continuing on it after GSoC officially wraps up. UI internationalisation is also still untouched, it’s documented as deferred work for now.
Thanks
Huge thanks to my mentors Simon Poole and David Haberthür for the guidance this summer, and for trusting me to make real architectural calls on a project that real people depend on. Also thanks to the Valhalla maintainers for taking the time to talk through the routing architecture with a stranger on the internet before I’d written a line of code.
If you want the full technical rundown with links to every PR, I’ve written that up separately in the project’s final report.
Development on closures.osm.ch continues, I’m not stopping here.
OpenStreetMap Blogs



Обеспечение загородного участка автономным водоснабжением — первоочередная задача для любого землевладельца. Традиционно для решения этой проблемы применяется крупногабаритная буровая техника на базе грузовых автомобилей (ЗиЛ, УРАЛ, КамАЗ). Однако на практике буровые бригады часто сталкиваются с объективными препятствиями: плотная застройка, наличие ухоженных газонов, проложенные подземные коммуникации, узкие ворота или линии электропередач, исключающие возможность подъезда и разворота тяжелых машин.














