Routing for Hiking Paths

openrouteservice
1

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:

OSM_Hiking_Path
OSM_Hiking_Path814×769 160 KB

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:

ORS_Result
ORS_Result622×550 261 KB

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?

Best regards
Marius

2

Hey,

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.

Best regards

3

Hey jschnell,

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 sac_scale.

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=demanding_alpine_hiking or 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?

Best regards
Marius

4

Hey,

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 HikingFlagEncoder.

Best regards

5

Hey,

that clears everything up, and I will look into that!

Thanks so much for your time and answers.

Best regards
Marius

1 Like