NOTICE: is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum


In this part of the map, the westbound lanes of Randolph Road are closed for construction from Parklawn Drive to Nebel Street until 2022-02-07, according to a sign I saw there on 2021-08-20. However, the sign has been removed since then, and I wouldn't be surprised if the end date changes by as much as a few weeks based on unpredictable factors affecting the progress of the construction project.

I'd like to map this closure in some form to help routers. I understand that there are two general approaches:

  1. Edit the ways (in this case, make them one-way eastbound rather than highway=construction) and edit them back once I confirm the lanes have reopened.
  2. Use time-based restrictions: something like oneway:conditional=yes @ 2021 Sep 06-2022 Feb 07.

On this wiki page, one question, and another question, I see that there are trade-offs and some debate about how to weigh the competing considerations and consequently what the best practice should be. If I'm certain of the end date (as well as the desired state of the map after that date, which I am in this case), then #2 is almost certainly better. But here I'm not completely certain of the end date, and at approximately 5 months, the length of the closure falls near the threshold that several users have said should decide between #1 and #2. Not finding any obvious local precedent, I believe I'm probably allowed the discretion to map the closure either way, but I thought it would be a good opportunity to solicit some more opinions here first. (Let me know if I should take this discussion to another place.)

Re "The original mapper may move or change hobbies by the time construction completes. The road will permanently be marked closed until someone else happens to notice": I hope I've already built some credibility by promptly reopening one closure for which I used approach #1, though of course, the community has the right not to believe me. The other serious concern with #1 is the concern that clients that use old data could see the road as closed for much longer than it actually is.

But ISTM #2 has problems of its own if the closure continues past the end date I originally enter: clients will start trying to route over the closed road until I have time to re-survey it and update the end date on OSM. If a new end date is not announced, I'm left to guess. In the worst case, ISTM we could end up with the road oscillating between open and closed from OSM's point of view, as I make a series of artificial updates to the guessed end date on OSM to try to keep up.

So I'd like a better sense of what is the least evil here and, if I go with #2, whether there's anything I can do to help manage the potential problem. (Might it make sense to deliberately enter an end date in OSM that is several weeks after the announced date and then update OSM if the road reopens before then?) I get the sense that the community doesn't have great data on how many users are using what update cycle for OSM data and how badly they would be affected by their app showing them a false positive versus a false negative road closure. I'd guess that a false positive (a suboptimal route) is less annoying than a false negative (being routed on a closed road and having to find a detour on the spot, though in this case, signs are posted for an adequate detour, so the impact would effectively just be a suboptimal route by the time the user takes the signed detour). But this is just based on my own experience as a user of OsmAnd with weekly live updates; I can't speak for all OSM clients.

Update 2021-09-08: Another problem with #2 is that some (most?) popular routers don't support oneway:conditional. OsmAnd does; I tested OSRM and it doesn't; and I think Valhalla doesn't based on a look at the source code. I don't know how heavily this consideration should be weighed. For now, I've gone ahead and used #2 with the OSM end date set to the originally signed end date of 2022-02-07, since I can't think of any sense in which that could be argued to be worse than the status quo, even if it isn't an ideal solution.

Thanks for your attention!

asked 06 Sep '21, 18:28

Matt%20McCutchen's gravatar image

Matt McCutchen
accept rate: 0%

edited 08 Sep '21, 18:20

3 There is also a third option. Oneway are mostly because of a oneway traffic_sign. But when other prohibited signs are used, you can get a similar effect.

you can use the direction

access:forward:conditional=yes @ (2021 Sep 06-2022 Feb 07) access:backward:conditional=no @ (2021 Sep 06-2022 Feb 07)

oneway:conditional -1 @ 2021 Sep 07-2022 Feb 07
You did not use @ ( )

permanent link

answered 08 Sep '21, 21:38

Allroads's gravatar image

accept rate: 10%

Interesting idea. I can see how access:{forward,backward}:conditional could be philosophically a better way to model the data, but is it actually accepted practice on OSM? Does any router actually support it? I tried loading a custom OSM file into OsmAnd and it doesn't support access:{forward,backward}, let alone access:{forward,backward}:conditional. And the use of all these tags on taginfo is tiny compared to oneway:conditional. So I think oneway:conditional is more practical than access:{forward,backward}:conditional for now. Both approaches present the same issues related to getting the end time right.

Re parentheses around the condition: you are right, that is best practice according to Fixed in

(08 Sep '21, 22:31) Matt McCutchen

It's a supported (eg by Graphhopper) practice, not necessary "best practice". Opposing argument in eg .

(09 Sep '21, 06:55) Kovoschiz

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 06 Sep '21, 18:28

question was seen: 989 times

last updated: 09 Sep '21, 06:55

NOTICE: is no longer in use from 1st March 2024. Please use the OpenStreetMap Community Forum