I am no bike rider, but I am a pgRouting developer, I can tell you that we are doing efforts to incorporate all of BGL algorithms to pgRouting, unfortunately the one you ask is not there yet.

• We have pgr_dijkstra one to one, one to many, many to one and many to many based on the cost value you give.
• We also have pgr_KSP (k shortest paths) that give you the K shortest paths from one point to another.
• We also have pgr_drivingDistance that given a "distance" cost, gives all the points that are reachable with in that "distance", (if your cost is in time units, the distance must also be in time units)

There is going to be a pgr_dijkstraVia, where you give the order of vertices and gives you the shortest path, the documentation shows how you can inspect if you "passed" in front of a particular vertex.

But, from what is already there and from what we are documenting for what is going to be version 2.2 I would do something like: #Data preparation: Have a column that indicates which roads are forbidden to bicycles so that when you make a query, those roads are not included. Calculate what is going to be your cost of each edge,

• can be length,
• or can be time, t=x/s where x is length and s is speed. (I would use this)

The speed of an edge can be in terms of the angle of the edge, you might need to know the slope of the edge to penalize the speed if you are going up, and that improves the speed if you are going down based on a speed of a flat surface.

You can also penalize the speed in terms of type of road, etc. Once you have your time set, you would have a graph that is from the point of view of a cyclist.

(source, target, length(m), speed(m/s), r_speed time(s), r_time(s))

• (1, 2, 120, 10, 30, 12, 4)
• (2, 3, 120, 20, 20, 6, 6)
• (3, 4, 120, 5, 5, 24, 24)

In the above example:

• going from 1 to 2 is slower because its going "up hill" and takes 12 seconds,
• 2 to 3 & 3 to 4 are in a flat surface, but 3 to 4 is slower because it is a road made of sand.

After you prepared your data, play around with the functions, and see whats best, Start with pgr_drivingDistance to rule out "unreachable vertices" withing a time bound.

Hope it helps. P.D. we are working on the documentation of 2.2, the code is done, so visit us in Github.

I am no bike rider, but I am a pgRouting developer, I can tell you that we are doing efforts to incorporate all of BGL algorithms to pgRouting, unfortunately the one you ask is not there yet.

• We have pgr_dijkstra one to one, one to many, many to one and many to many based on the cost value you give.
• We also have pgr_KSP (k shortest paths) that give you the K shortest paths from one point to another.
• We also have pgr_drivingDistance that given a "distance" cost, gives all the points that are reachable with in that "distance", (if your cost is in time units, the distance must also be in time units)

There is going to be a pgr_dijkstraVia, where you give the order of vertices and gives you the shortest path, the documentation shows how you can inspect if you "passed" in front of a particular vertex.

But, from what is already there and from what we are documenting for what is going to be version 2.2 I would do something like:

Data preparation:

Have a column that indicates which roads are forbidden to bicycles so that when you make a query, those roads are not included. Calculate what is going to be your cost of each edge,

• can be length,
• or can be time, t=x/s where x is length and s is speed. (I would use this)

The speed of an edge can be in terms of the angle of the edge, you might need to know the slope of the edge to penalize the speed if you are going up, and that improves the speed if you are going down based on a speed of a flat surface.

You can also penalize the speed in terms of type of road, etc. Once you have your time set, you would have a graph that is from the point of view of a cyclist.

(source, target, length(m), speed(m/s), r_speed time(s), r_time(s))

• (1, 2, 120, 10, 30, 12, 4)
• (2, 3, 120, 20, 20, 6, 6)
• (3, 4, 120, 5, 5, 24, 24)

In the above example:

• going from 1 to 2 is slower because its going "up hill" and takes 12 seconds,
• 2 to 3 & 3 to 4 are in a flat surface, but 3 to 4 is slower because it is a road made of sand.

After you prepared your data, play around with the functions, and see whats best, Start with pgr_drivingDistance to rule out "unreachable vertices" withing a time bound.

Hope it helps. P.D. we are working on the documentation of 2.2, the code is done, so visit us in Github.