|
Not too far from where I live is a national park with several trails of various degrees of difficulty. Some are designed as walking trails, and are quite easy. I've noticed that when I play with some OSM-based navigation apps and ask for walking directions, they will sometimes route me along these park trails, which makes sense, because those happen to be the shortest route between point A and B in my test, and can definitely shave a mile or more from the distance someone would have to use to walk using only roads. As they are part of a national park, the trails are open to everyone. However, the problem is that the park (and therefore the park trails) are only open between dawn-30m and dusk+30m (that is, 30 minutes before dawn and 30 minutes after dusk), so any routing that takes place outside of those hours should NOT use those trails. But of course, a nav app won't know this if it isn't in the map data. In another case, there is a private road that provides a nice shortcut between two other roads in an area with several office buildings; it is part of the property of one office building in that area. The building (and road) owner allows public traffic to use it most of the time, except during certain hours of the day, and closes a gate on the road to prevent through traffic during those periods. So, with those time restrictions in mind, is it appropriate to put opening_hours on those trails and roads (and gate?)? Of course it's still going to be up to the nav app to make proper use of the information. I would think that the trails and road should have access=permissive on them at the very least. |
|
Personally, I'd put opening_hours on anything that has opening hours. As you say in the question, many/most nav apps won't honour the tag, but it's there for when / if they do. I'll go with that, then. Thanks. It's always nice to get feedback from someone else.
(25 Jul '14, 22:44)
Jack the Ripper
|
|
I think that you should not use opening hours for trails. We have the community-approved "conditional restrictions" for that. It's almost the same as opening hours. But instead of you would write It may be a bit more complex, but on the other hand it is a lot more flexible. For example, you can also express time-dependent maxspeeds with it, or situations when only certain vehicle classes are excluded during that time. Hmm, good point. Thanks for the feedback.
(25 Jul '14, 23:10)
Jack the Ripper
4
Two points:
If you use the tagging with a default access of no, the above two points will lead to a lot of bad routing advice. So you should switch permissive and no.
(25 Jul '14, 23:44)
cartinus
3
@cartinus You are right that you should choose the default based on which makes more sense for applications that don't support time-based restrictions. Don't forget to invert the opening hours in that case, though. I'm not so sure about your first point. But time will tell.
(25 Jul '14, 23:52)
Tordanik
3
Time-based restrictions are hard to integrate into any router that preprocesses its data using Contraction Hierarchies, which includes OSRM and optionally Graphhopper. Effectively you need to prepare a new dataset for each time of day, and given that this can take many hours, it's not feasible in many circumstances. OSRM does have a new feature that can assist in this though at the cost of query time.
(17 Oct '16, 11:08)
Richard ♦
|
|
There is a gate across a heavily travelled road, which is opened only for evening traffic. It seems strange to me that this information cannot be captured and used. I put it as an opening_hours tag, even though I suspect routing programs will ignore it. 1
It can be captured, see the conditional restrictions tagging (which has been approved by community vote, so it's as "official" as it gets in OSM). The reason why routers have trouble supporting it is because the most common algorithms assume that a road is either accessible or not. That taking too long to reach a road might make it inaccessible (or vice versa) makes things more complex and prevents certain performance optimizations from being used.
(15 Oct '16, 18:56)
Tordanik
|
