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?