Handle conditional access tags for date ranges

[ivarbrek]

Issue

OSRM currently don't support conditional access tags. This is a very useful feature, especially in the context of roads being closed due to construction work or events.

Several people have requested this feature (#4231, #4300, #5801, #6706)

This PR takes a simple and lightweight approach to this problem, and handles it through the profile libs.

Note that we here only handle conditional time ranges, and require them to span for more than a week, using the format as described in the OSM wiki, e.g. motor_vehicle:conditional=no @ 2018 May 22-2018 Oct 7.

Tasklist

• CHANGELOG.md entry (How to write a changelog entry)
• update relevant Wiki pages
• add tests (see testing documentation)
• review
• adjust for comments
• cherry pick to release branch

Requirements / Relations

Link any requirements here. Other pull requests this PR is based on?

[SiarheiFedartsou]

Thanks @ivarbrek! Could you please also extend tests? Feel free to ask for a help if it is not clear what to update…

[ivarbrek]

I've tried to add a few test cases.

However, the tests seem to fail in the conan-linux-release step, and I'm struggling with proceeding from this point. I've downloaded the test logs, but don't find any clear direction from the logs of car/access.feature/.../309_car_conditional_restrictions.log. It's shutting down with SIGINT, but that's similar to all other log files I checked.

How do I proceed?

[SiarheiFedartsou]

@ivarbrek this test works locally, right? Try to bump cache key version here

osrm-backend/.github/workflows/osrm-backend.yml

Line 404 in 4930d2e

key: v4-test-${{ matrix.name }}-${{ github.sha }}

Sometimes it helps (you need to change v4 to v5 in 2 places there)

[ivarbrek]

Finally got the tests running locally 😊 And think it should be good now! Who can I tag for review @SiarheiFedartsou?

[DennisOSRM]

Happy to help with the review

[DennisOSRM]

Will this test break in 24 years? 😉

[ivarbrek]

Yep 😄 I can extend the ranges so they don't break that soon, but I don't see any simple way to get completely rid of this problem.

[ivarbrek]

Ah, this can be solved doing something similar to this. I'll try to do that.

[DennisOSRM]

This probably needs some explanation that the extraction result depends on the date the extraction is run. Also, the date is not checked once but for each case if I am not mistaken. A little of folks run data updates over night and this may lead to edge cases.

Consider pulling the date once at the start of extraction. Also, consider implementing an override, ie. supporting the use case of extracting data ahead of time.

[ivarbrek]

Good points 👍 Note that the current suggestion excludes date ranges that span less than a week, partly to avoid weird cases like this. But that choice can be discussed I think.

Anyways, I'll see if I manage to implement an overrride option in a reasonable way.

[ivarbrek]

Found a relevant example here, will try to implement something similar 👍

[ivarbrek]

I've looked into this a bit more now, and here's my summary/understanding of the current situation:

Some background I found out:
Conditional turn restrictions are already implemented at C++ level in the contract step (see test here). A good thing about this implementation is that the osrm-contract command supports arguments to set a custom time for the parsing conditional turn restrictions.

Next steps
Ideally we'd like the conditional access feature to be easily configurable, and here are the options as I see them:

• Make a date parameter in car.lua called date_used_for_conditional_access. If nil, we use the current date. This option is simple to implement, given that I've already started implementing this in Lua. But on the other hand, it does not provide the best interface for custom configuration.
• Implement in Lua, but make the date configurable through the osrm extract command. Requires some C++ coding and understanding of the code, so I would like some help if we decide to do this.
• Implement this in the same manner as conditional turn restrictions (see above). I think this would be the best solution, but I'm not very familiar with C++, so would need a great amount of help on that.

What I don't like about the two latter options is that we duplicate the date configuration we already have in the contract step. Would be interested to hear your take on that and your suggested next steps @DennisOSRM and @SiarheiFedartsou.

[SiarheiFedartsou]

@ivarbrek having it in osrm-customize/osrm-contract is indeed more preferable. In practice you would need to re-run this logic many times per day for the same dataset and such kind of things are done with these tools in OSRM(e.g. live traffic or conditional turn restrictions you mentioned are implemented using it)

[ivarbrek]

Allright, so we are maybe just closing this then?