Are requests with "composite" profiles possible?

openrouteservice directions
1

Hi there,

I have a question that may be a little off the trodden path.

Is it possible to put in requests with “composite” profiles? To explain: With given start- and endpoints, is there a way to request a path with a biking profile to the extent possible, and only then continue with a foot-hiking profile?

As an alternative, is there a way to request a path with a given profile to a point that is the closest to an ultimate target point?

Thx for your help Uli

2

Hi @UliE ,

this is not possible in one request.

But you could just send two, where the actual endpoint of the response for the biking is the start for the foot-hikin route while keeping the original endpoint for the second request.

→ This is what the routing algorithm is doing in the first place, with the restriction of a 350m search radius around the points you request.

This maximum snapping radius can be adjusted in a local installation.

Best regards

3

Thx a lot for your quick reply (on a Sun night, I find that remarkable!)

Splitting a request into two unfortunately does not work, as the app I am developing only has knowledge of the start- and the endpoint; points inbetween are not known. A potential workaround would be to determine the last intersection of a foot path supplied by ors with a road. Can you think of a way to find that point?

Thx again Uli

4

This is a rather specific usecase.

The openrouteservice backend does only offer waytypes and surfaces in that regard as extra information.
You can’t return the last intersection with a foot path.
It would be also difficult to determine, what you consider as a foot path (foot:yes, highway:path and many more).

Our backend code is open source so you could run your own instance and adjust it to your use case.

However if you are building the application, why you can’t let the app know of the endpoint of the first (bycicle) route?

Best regards

5

I do appreciate the time you are taking to deal with that “rather specific usecase”, “rather weird” may not be inappopriate either :upside_down_face:

In an attempt to automate route planning, the app randomly pick a peak from osm (via overpass) and then tries to link it with a user defined starting point. This is why points inbetween are not known.

Let’s put that question at rest, I do not want to steal your time with overly specific issues. Again, I do appreciate your feedback!

Best regards Uli

6

In case anyone is interested, I found a workaround for the “specific usecase” described above:

  1. Solicit a route from ors with profile “foot-hiking”
  2. Walk back incrementally on that track and fire an ors request with a “cycling-xyz” profile until that call no longer throws a “Not Found” error

@ors: This approach provokes numerous errors before a call returns an OK status message. Should you have any performance metrics / goals related to “Not Found” errors, pls let me know, and I will abandon that approach

Best regards Uli

7

Did you try to use the radiuses parameter?
You can set the search radius for the given input point which is by default only 350 m.
If you pass [350,-1] the search radius for the endpoint will be increased to about 2.5 km (see this issue).

You will get a route for the bycicle profile more often then.

8

Thanks a lot for the hint, I did not yet try (for the simple reason that I did not quite get the explanation for “radiuses” in the API playground when I went through the list of parameters). Will give it a try.

Best regards Uli

9

As suggested, I played around with the radiuses parameter. To my surprise, I get better results using the default values (increasing the endpoint search radius for the bike profile decreases the number of ors calls as expected, but occationally leads to dead end detours). It occurs to me that adjusting the “walk back” increments is a better approach.

Thanks again for the hint anyway, it did help to resolve a very different issue.

Best regards Uli

1 Like