Support OSM objects with opening hours for street network routing

[optionsome]

One common issue with routing on street network is that paths are suggested to users that are not viable at certain hours of the day because a mall or a park is closed, for example. This type of a simple restriction can be modeled with opening_hours. There are also more complex situations where, for instance, the opening hours only apply to driving on a street but pedestrians can still walk on the road. However, I'm not sure if there is a way to model this type of a restriction with OSM and it's perhaps not something we want to support as OTP isn't optimized for car routing.

We had a short discussion about this topic with @abyrd @hannesj @t2gran where we identified some potential issues. For example, how we should take into account the time restrictions when we don't know when the user will pass a time restricted area as it can depend on the transit routing results.

More discussion and potential viable solutions can be discussed under this issue.

Expected behavior

OTP takes into account in routing the opening_hours definitions from OSM for street network routing. In other words, if a park is closed at night, OTP will not suggesting walking through it if the opening hours are defined in OSM data.

Observed behavior

OTP ignores opening_hours.

Version of OTP used (exact commit hash or JAR name)

Affects both OTP 1 and 2 but perhaps should be primarily fixed in OTP 2.

[JohanEntur]

Just adding that I know that opening hours is a constant issue (questions asked with difficult answers given) in OSM. Mostly because some opening hours can so complex. Both in time restrictions (sometimes conditional) but also because certain areas within an area might have different hours - and as you say, certain modalities may be affected individually.

https://wiki.openstreetmap.org/wiki/Key:opening_hours

Semi amusing example:

So, a user of StreetComplete came across the following complicated opening hours for a shop (prettified):

Jun-Sep: Mo-Sa 10:00-18:00;
Jun-Sep: Su 10:00-12:00;
Nov-Mar: Mo,Tu,Th,Fr 10:00-12:00, 15:00-17:00;
Nov-Mar: Sa 10:00-12:00;
Apr-May: Mo-Fr 10:00-12:30,15:00-18:00;
Apr-May: Sa 10:00-12:30;
Apr-May: Su 10:00-12:00;
Oct: Mo-Fr 10:00-12:30,15:00-18:00;
Oct: Sa 10:00-12:30;
Oct: Su 10:00-12:00

Unfortunately, this does not fit into the opening_hours value, as this is limited to 255 characters. What can we do?

[t2gran]

It would be nice if OTP had limited supported for opening hours, at least for WALKING, BICYCLE and CAR. WALKING is most important, and support for big parks like the botanical garden in Oslo is the most important geographical thing to support. A short street section can be ignored - at least for the first implementation. I think we should start with the simplest possible thing that gives us value. OTP is not build to be a sophisticated street router, but some support for opening hours would be great.

Suggestions/possibilities

• In a depart-after search we only have the latest-departure-time, but not the earliest-arrival-time. We can add a slack and find the access-paths, but it would be difficult to do the egress search. We could guess when we will arrive, but it would at best be a rough estimate. For a arrive-by-search we have the latest-arrival-time, but not the departure-time.
• @abyrd Mentioned that in Italy they have some areas that is restricted-to-traffic and we should probably just avoid these for CAR routing.
• It is OK to simplify the opening-hours by adding a slack (e.g. extra 40 min or makWalkDistance/walkSpeed) to make sure we can route on the street when it closes or opens.
• For access and egress we can as @hannesj suggested: Do two searches for access and egress with and without the opening hours constraint. Then we can filter these for each RangeRaptor depature-time for the access. And as @gmellemstrand said we can add an extra criteria for the egress, or just check each egress and fallback to the "safe" option if outside the opening hours.
• Adding support for this for transfers is step 2. We can do so with a smal cost of finding a "safe" alternative to fall back to for time dependent transfers.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

[hannesj]

Related to #4355

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

[JohanEntur]

Serial stale-issue

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days