OpenStreetMap
Temporary Road Closures Database and API - GSOC 2025
Posted by Archit Rathod on 24 May 2025 in English. Last updated on 30 May 2025.Introduction
Hi everyone! I’m Archit Rathod, a Computer Science Master’s student at the University of Illinois Chicago and a passionate open-source contributor. My interests lie at the intersection of geospatial technologies, backend systems, and applied machine learning. Over the years, I’ve built full-stack web platforms, worked on real-time traffic modeling, and contributed to research in social networks and AI ethics.
This summer, I’m thrilled to be a Google Summer of Code 2025 contributor with OpenStreetMap, where I’ll be building a system to make navigation smarter and safer through real-time road closure data. I’m deeply grateful to the OSM community and my mentors for this opportunity, and I’m excited to learn, collaborate, and give back.
Project Description: Temporary Road Closures Database and API
OpenStreetMap provides excellent static map data, but temporary road closures, like construction, accidents, or local events, are often missing or delayed. This project addresses that gap.
I’m developing a centralized platform for real-time road closures. Key features include:
- A geospatial database using PostgreSQL/PostGIS for efficient closure storage and queries.
- A RESTful API using FastAPI, with outputs in OpenLR format for location referencing.
- A web-based UI for users to submit and view closures on a live map.
- A prototype integration with OsmAnd, showcasing how routing can dynamically adapt to avoid closed roads.
The goal is to have a fully working, open-source prototype by the end of the summer that enables OSM apps to respond to temporary disruptions, making navigation more reliable for everyone.
Weekly Progress Report
Coming Soon….
Contact Me
Feel free to reach out — I’d love to connect!
- 📍 Location: Chicago, IL, USA
- 📧 Email: [email protected]
- 🌐 Portfolio: archit-rathod.vercel.app
- 💼 LinkedIn: linkedin.com/in/archit-rathod
- 💻 GitHub: github.com/Archit1706
Discussion
Comment from Mxdanger on 28 May 2025 at 22:19
Is the long term goal to eventually get agencies to add this to their pipeline? Similar to agencies reporting data to Waze or Google.
Unless there is direct integration in apps like OsmAnd to make reports on closures while driving, I doubt the usefulness of a web based UI for submitting closures.
Regardless, I’ll keep my eye on this project!
Comment from stanton on 8 June 2025 at 11:37
You might be interested in some work I’ve done previously.
I have drawn up a data exchange format for traffic information. This covers road closures but also has support for other event types like temporary speed limits, hazards and congestions.
There is also a web API for the transfer of feeds. Details on both at http://traffxml.org. The full specification is at https://gitlab.com/traffxml/traff.
TraFF does not use OpenLR but is based on end points (from/to), with at most one intermediate point, plus optional attributes (road ref, highway type) to aid matching. The idea is to make location references simple, and translatable from other formats. (Some other formats do not translate well into OpenLR linear locations unless you have a full map at hand for decoding and re-encoding.)
The web API is currently session-based (called subscriptions in TraFF). Apps (called consumers) subscribe to a certain region of the map, get an initial feed of the situation and can poll for updates. (Probably less of a concern with planned road closures, but vital if the data also includes unplanned events.) One-shot queries could be added if needed (right now one can just subscribe and unsubscribe after receiving the first feed).
There are some code resources at https://gitlab.com/traffxml, mostly in Java. They include a support library for the TraFF format, conversion libraries for a few agency-specific formats. There is also a server, but it is very much in it infancy, buggy and Java might not have been the best technology.
I’m aware of at least one other effort to implement a traffic server, though I am not sure if they are still active. See https://github.com/TobiPeterG/OSMTraffic and https://github.com/TobiPeterG/OSMTraffic-server.
https://gitlab.com/traffxml/roadeagle/-/wikis/Data-Sources has a list of potential data sources.
TraFF support has been added to Navit; I am currently adding it to the Organic Maps/CoMaps codebase (CoMaps is a fork of Organic Maps, and my work is based on code just before the fork, thus it could theoretically be added to both).
Take a look at TraFF and see if it suits your needs. The spec is still under development and can be extended if needed. If you have any questions regarding implementing location matching to a navigation app, I may be able to help – I am just doing this for the second time.
So, in short – the one thing we will need but don’t have yet is a central server, and it will make sense to have a universal server, not tied to one particular navigation app. Osmand is a major player but doesn’t seem to have any traffic support yet – adding that will certainly help the DB and API in achieving critical mass.
If any of this sounds interesting, drop me a message!
Comment from 4004 on 15 June 2025 at 20:34
Sounds interesting! Magic Earth has reporting functionality for road events, but doesn’t actually use it in routing. I suppose the easiest way to implement this in OSM is through some parser that would translate event info into conditional tags?
Comment from stanton on 22 June 2025 at 19:30
I would, in fact, keep event information in TraFF format, separate from OSM data, and map the location to OSM segments as needed: map data may change and people may inadvertently break tags they don’t understand. Also, some events are short-lived in nature (e.g. if roads are closed for a marathon, the closure lasts less than a day), which would clash with the OSM rule of anything that lasts for at least a week. To use this information in a renderer, navigation software or other, the location would need to be decoded to OSM ways (or parts thereof). This can be done using a plain old routing algorithm (Dijkstra, A* or similar) – cost would be way length with a penalty factor, based on how closely the attributes of the message location and the way match. Then, one way to provide this information would indeed be to map the OSM feature ID to generated tags. This, together with the way attributes, could then be used by a renderer, e.g. to produce a traffic layer on top of OSM, or a traffic map.
Comment from Archit Rathod on 15 August 2025 at 00:34
Hello All,
Thank you for your thoughtful comments and suggestions!
Note: The GitHub link has been updated: https://github.com/Archit1706/temporary-road-closures
Reply to Mxdanger: You raise excellent points about agency integration and in-app reporting! While we initially planned OsmAnd integration, we’ve now pivoted our approach. Instead of direct OSM integration, we’re building a closure-aware routing system that can handle multiple transportation modes (car, bicycle, pedestrian). This means users can get optimal routes that account for temporary closures—regardless of their preferred mapping platform.
Reply to stanton: Thank you for the detailed information about TraFF! Your work on traffic information exchange formats is impressive, and I appreciate you sharing the specification. You’re absolutely right about keeping event data separate from core OSM data—this aligns perfectly with our new direction. The TraFF format could be very valuable for data exchange between systems.
Reply to 4004: Thanks for mentioning Magic Earth! You’ve highlighted exactly why we changed direction. Instead of relying on OSM conditional tags or parsers, we’re creating a dedicated closure-aware routing engine. This allows us to provide real navigation that avoids closures, rather than just displaying them.
Reply to stanton (second comment): Your note about the OSM rule for temporary features (lasting at least a week) reinforces why we’ve moved away from direct OSM integration. Our new approach keeps closure data completely separate and offers closure-aware routing as a service, which can work with any map data source.
We’re now focused on building a routing system that can intelligently handle temporary closures for cars, bikes, and pedestrians—making it more practical for real-world navigation scenarios.
Thanks again for all the valuable feedback and support! —Archit