Support for conditional access tags #4231

Activity

1. daniel-j-h commented on Jul 4, 2017

   

   daniel-j-h

   on Jul 4, 2017

   Member

   More actions

   @karenzshea can you spec out the tasks that need to be done here?
2. MoKob

   added

   Feature Request

   on Jul 4, 2017
3. karenzshea commented on Jul 4, 2017

   

   karenzshea

   on Jul 4, 2017

   Contributor

   More actions

   We can expand the meaning of our existing conditional restriction flags to include access=conditional tags on non-relation features.

   • During way parsing in extraction, save ways tagged with access:conditional to disk like we do with restrictions with data node ids, is_only and opening hours.
     • this will probably require a new osrm file, or we'll need to figure out how to make them share the .osrm.restrictions file
     • we can maybe genericize the serializer for both restricted turns and ways
   • In the update handler (shared by contraction/customization) parse way restrictions and apply them if the condition is valid
   • Tests

   A lot of the hard work is already in place, like condition validation and time zone handling, so this shouldn't be as complicated of a lift as conditional turns.

   👍React with 👍2Reacted by Daniel J. H. and david
4. xuruiray commented on Dec 19, 2022

   

   xuruiray

   on Dec 19, 2022

   More actions

   Do we support conditional access now?
5. joaommartins commented on Dec 1, 2023

   

   joaommartins

   on Dec 1, 2023

   More actions

   Do we support conditional access now?

   Still not supported, tested today.

   This feature is referenced by:
   #4300
   #5801
   #6706
6. mcliquid commented on Oct 23, 2026

   

   mcliquid

   on Oct 23, 2026

   More actions

   I've start using OSMR in my StreetComplete-fork and I'd like to bring this issue back up, as support for access:conditional would be a useful addition to OSRM in my small project.

   In #6984, @SiarheiFedartsou suggested evaluating conditional access during osrm-customize/osrm-contract, similar to conditional turn restrictions and traffic updates.

   I had a look at the current code, and it seems that much of the required infrastructure already exists:

   • Conditional turns already provide parsing, opening-hours evaluation, time-zone handling and --parse-conditionals-from-now.
   • Zero-speed segment updates already prevent routing and snapping through affected segments.

   One possible approach could be to store conditional access restrictions during extraction and evaluate them during customization, reusing the existing zero-speed update mechanism.

   An initial implementation could focus on conditionally closing otherwise accessible ways, such as motor_vehicle:conditional=no @ (2026 May 1-2026 Oct 31).

   One potential challenge is restoring original segment weights when a condition expires, since the updater appears to modify its input files in place. This hasn't been verified at runtime.

   Would this be a reasonable direction to explore? Has anyone in the community already investigated or considered implementing something along these lines?