Hey ORS Team,
thanks for this amazing service that you provide!
As I was playing around with routes provided by the ‘foot-hiking’ profile in the directions API, I noticed that the returned route often did not make use of the hiking paths which are there in reality.
To give a specific scenario, where I would expect a different route would be here:
Screenshot is taken on Waymarked Trails, which, to my knowledge, fetches the data from OSM. I would expect for the directions service under the ‘foot-hiking’ profile to take the route marked in orange.
What it actually does is route completely around the mountain, as seen in the following screenshot:
Here again marked in blue what I would expect the route to be.
Starting Coordinates are: 49.2656977512429, 20.11615684743734
Ending Coordinates are: 49.155060644060455, 20.07952840676279
It’s also worth to note that however I tried to add middle points between the start/goal markers it always only routed around the whole mountain complext, indicating that it does not take any hiking route in that mountainuous area into account.
Is that expected behaviour or am I missing something?
I think there are three things in play here:
- profile: recommended in the routing settings
sac_scale=demanding_alpine_hiking (and above), e.g. on this way
access:conditional=no@(Nov 01-Jun 14), e.g. on this way
Firstly, the hiking profile is by default using recommended settings. Have a look at this post that explains a bit about the differences.
Secondly, the hiking profile excludes the
sac_scale= tags above T4. This is documented in our backend docs.
Thirdly, the seasonal access restrictions (here, some ways being closed from November onwards) are being respected at graph building time. This is a bit unclear and indeed not documented properly. I opened an issue regarding the documentation.
We are working on correctly parsing
access:conditional-tags, so in the near future you could for example start sometime in August and get the route you’d expect.
I would guess that these factors lead to the road going completely around the area. If you manage to find a route that has none of the mentioned tags and is still not routed, please do report on that and we’ll help you find out why it happens.
thanks for the quick response!
That explains a lot. I searched the area for alternative routes, but was not able to find one that was not restricted through the
access:conditional=no@(Nov 01-Jun 14) or the
So if I read that right, in the future there will be the possibility to set the start time whenever, and I effectively could disregard these seasonal restrictions?
Also, is there a way to overwrite the tag filtering process? Meaning, if I wanted to include paths that are tagged as
sac_scale=difficult_alpine_hiking I could kind of overwrite the existing restriction or is the only way to accomplish something like that hosting my own instance of the service locally and implement it myself?
yes, that would be the idea, though there is no explicit time frame for this yet.
For the live API, there is currently no way of doing that.
lf you were to host your own instance, that should be a rather easy fix in the
that clears everything up, and I will look into that!
Thanks so much for your time and answers.