Yes, I have had this happen in the past. Probably the only scalable way to get high-quality data about closures is to infer it from traffic data. But as long as OSM doesn’t have a “standard” solution for that (AFAIK), I think we should still consider mapping closures based on available information (notices and surveys) if the benefits exceed the costs.
- Of course, one cost is the contributor’s labor; they can judge that themselves.
- In principle, the churn in the OSM database has some cost: it increases the amount of data that downstream systems have to process and the chance of other mappers getting edit conflicts, and it clutters the element histories viewed by mappers. I think this cost is probably small.
The most interesting cost/benefit analysis is for data consumers that would route over the road in question. If a road is mapped as open when it’s closed, then users will encounter the closure and take a detour; the detour may or may not be much longer than the alternate route they would have taken if they knew about the closure, but the travel time will be longer than predicted. If a road is mapped as closed when it’s open, then users will take an alternate route; the alternate route may or not be much longer than the original route they would have taken if they knew the road was open, but in any case, the accuracy of the travel time is unaffected. To summarize:
| Actual road state |
Route taken if road is mapped as open |
Route taken if road is mapped as closed |
| Open |
Original |
Alternate (“false positive”) |
| Closed |
Detour (inaccurate travel time, “false negative”) |
Alternate |
Thus, the relative costs of a false positive and a false negative depend on the length of the alternate route compared to the original route and the detour:
| Length of alternate route |
Cost of false positive |
Cost of false negative |
| Similar to original |
Low |
High |
| Similar to detour |
High |
Low* |
(* Small difference in travel time compared to if the road were known to be closed. The inaccuracy in the travel time prediction is a separate harm.)
For a given closure, assuming some vague knowledge of people’s travel patterns, one could take a guess of where the average case lies between the “similar to original” and “similar to detour” extremes.
The next question is the likelihood of a false negative versus a false positive under different mapping strategies, given the update schedules of data consumers. Of course, if a closure isn’t mapped at all, there is a false negative for the duration of the closure. Mapping a short-term closure by changing unconditional tags and then reverting them is definitely a net harm to data consumers that update infrequently: the ones that see the change at all will apply it for much longer than the road is actually closed. (And then there is the risk that the contributor loses interest and doesn’t revert the change at the proper time.) My analysis would suggest that mapping a short-term closure by putting a best guess of the time period in access:conditional (which was my proposal in this thread) is a net benefit to data consumers if the probability that the road is closed during the mapped time period exceeds some threshold that depends on the relative costs of false positives and false negatives. Thus, mapping can be a net benefit even if the time period is uncertain. Does that seem right to others?
Granted, the benefit may be small because it only applies to data consumers that update frequently. And I don’t know how many users are using OSM seriously for routing in the first place. The fact that the detour for the Randolph Road closure in this thread was blocked by a turn restriction in OSM that I believe was removed on the ground in 2022 suggests not many; I just fixed that. I still mainly use Google Maps because it has traffic data and I haven’t sought out an OSM-based solution that does. So my interest in mapping temporary closures in OSM is mainly “just for fun” with a faint hope that it might eventually help the OSM ecosystem develop to a point where people can rely on it more for routing.
Much of the same analysis as for access:conditional would apply to posting closures on the OSM Road Closures service. Notable differences: Some OSM community members might object to the churn of putting temporary closures in the main OSM database, but no such objection could be made for the Road Closures service since that’s its whole purpose. On the other hand, I imagine more users are using routers that already honor access:conditional (e.g., OsmAnd with sufficiently frequent live updates) than the Road Closures service.
If a closure is expected to be short-term but no estimated end date is known, and a contributor is able to survey it frequently, one strategy would be to map the closure for some short time period extending beyond the next planned survey and then extend the period each time the road is resurveyed and found to still be closed. (This reminds me of the trick where Chromium stops enforcing the HSTS preload list 10 weeks after the build time if the browser isn’t updated.) This might be an unacceptable amount of churn for the main OSM database but might be a good strategy for the Road Closures service.
I went ahead and mapped the Randolph Road closure on OSM (since the license is OK and the change is otherwise within the bounds of acceptable practice) and on the Road Closures service. I’ve probably beaten this topic to death now, but it was something I’ve been curious about for a while and it was fun. Thanks to everyone on this thread for humoring me.
