Discussion on coding turn restrictions using Boost

[woodbri]

The current pgr_trsp function does not use Boost in its underlying implementation, in part because Boost Graph does not support it natively. There has been some discussion about re-implementing the pgr_trsp like functionality using Boost Graph. I'm opening this issue to collect ideas and references regarding this.

• http://lists.boost.org/boost-users/2011/11/71549.php
• https://lists.osgeo.org/pipermail/pgrouting-dev/2011-May/000208.html
• https://github.com/mixedbredie/itn-for-pgrouting (extracting turn-restrictions for OS data)
• https://github.com/Ifsttar/Tempus/blob/master/src/core/road_graph.hh (routing supporting turn restrictions)
• https://groups.google.com/forum/#!topic/opentripplanner-dev/hrsa7V0OSKY (interesting discussion)

There are also two terms that I have come across in this research "turn-penalties" and "turn-restrictions". An infinite penalty can be considered a restriction. From an implementation point of view having penalties is probably preferable because applying a penalty allows you more flexibility like applying a cost to making a turn or applying a greater cost to make a turn across traffic, or at traffic lights ot stop signs, etc.

In my mind "turn-restrictions" could be viewed as dynamic modification to the graph, based on the first link above this might be problematic, while changing the costs to a particular node based on the path to get there might be less problematic.

Please add additional useful comments and research.

[dkastl]

I like the term "turn-penalties".
Describing "restrictions" as a special case for "penalties" reminds me a bit how one-way restrictions are handled. While in the beginning we said, that you just need to make the cost "very high" to apply one-way restrictions, it still means, that the route might violate the rule, if there is no other way.

I prefer to use -1 however rather than using high costs, so I would also like to handle turn-restrictions/penalties in a similar way.

[cvvergara]

Family of functions:

using acronyms

TRSP

pgr_TRSP(one to one, one to many, many to one, many to many)
pgr_TRSPCost(one to one, one to many, many to one, many to many)
pgr_TRSPCostMatrix
pgr_TRSPDD(single start point, multiple start point)
pgr_TRSPKSP()
pgr_TRSPVIA()

TRSPWithPoints

pgr_TRSPWithPoints(one to one, one to many, many to one, many to many)
pgr_TRSPWithPointsCost(one to one, one to many, many to one, many to many)
pgr_TRSPWithPointsCostMatrix()
pgr_TRSPWithPointsDD(single start point, multiple start point)
pgr_TRSPWithPointsKSP()
pgr_TRSPWithPointsVIA()

Not using acronyms (this is my preference)

turnRestricted

pgr_turnRestricted(one to one, one to many, many to one, many to many)
pgr_turnRestrictedCost(one to one, one to many, many to one, many to many)
pgr_turnRestrictedCostMatrix
pgr_turnRestrictedDD(single start point, multiple start point)
pgr_turnRestrictedKSP()
pgr_turnRestrictedVIA()

turnRestrictedWithPoints

pgr_turnRestrictedWithPoints(one to one, one to many, many to one, many to many)
pgr_turnRestrictedWithPointsCost(one to one, one to many, many to one, many to many)
pgr_turnRestrictedWithPointsCostMatrix()
pgr_turnRestrictedWithPointsDD(single start point, multiple start point)
pgr_turnRestrictedWithPointsKSP()
pgr_turnRestrictedWithPointsVIA()

[woodbri]

On 7/8/2016 9:38 PM, Daniel Kastl wrote:

I like the term "turn-penalties".
Describing "restrictions" as a special case for "penalties" reminds me a
bit how one-way restrictions are handled. While in the beginning we
said, that you just need to make the cost "very high" to apply one-way
restrictions, it still means, that the route might violate the rule, if
there is no other way.

I prefer to use |-1| however rather than using high costs, so I would
also like to handle turn-restrictions/penalties in a similar way.

The issue here has more to do with how the code is implemented. We use
-1 to remove the edge but with turn restrictions it is potentially much
more complicated because the same edges need to be there for some paths
through the intersection and not for restricted paths.

So until we understand how we want to build the graph and process it and
what constraints that puts on the code it is hard to determine what is
possible. Anyway, I hear what you are asking for and tend to agree that
that should be the plan if we can make it work that way.

---

This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[cvvergara]

-1 on the internal sql query cost & reverse_cost the corresponding (source, target), (target, source) edge is not inserted. (for one way)
Internally:
if the algorithm needs to remove it, it can be done.
if the algorithm needs to recover it, it can be done.
if the algorithm needs to change the value, it can be done.

[dkastl]

Don't take my comment as how you should implement it ;-)
I'm speaking from the user perspective and I find it better to assign -1 to apply a restriction than a very high cost. That's all. How this is applied internally is a different problem.

[cvvergara]

"no u-turn"
"no right turn"
"no left turn"

[cvvergara]

currently there is this way of representing "saving restrictions" in sample data

CREATE TABLE restrictions (
    rid BIGINT NOT NULL,
    to_cost FLOAT,
    target_id BIGINT,
    from_edge BIGINT,
    via_path TEXT
);

COPY restrictions (rid, to_cost, target_id, from_edge, via_path) FROM stdin WITH NULL '__NULL__' DELIMITER ',';
1,100,7,4,__NULL__
1,100,11,8,__NULL__
1,100,10,7,__NULL__
2,4,8,3,5
3,100,9,16,__NULL__
\.

and when passed as a parameter to pgr_TRSP

'SELECT to_cost, target_id,
        from_edge || coalesce('','' || via_path, '''') AS via_path
        FROM restrictions'

What would be the wish list for storing the restrictions so its easy to understand/use?
(I am asking for a wish list, so we can have options for analysis of pro & con)

[dkastl]

I would say:

• "no value" or 0 means no restriction and no penalty
• a value >0 would be a turn penalty
• -1 would be a turn restriction (prohibited)

Thoughts?

[cvvergara]

(rid, to_cost, target_id, from_edge, via_path)
(1, 0,7,4,NULL)
(1,100,7,4,NULL)
(1,-1,7,4,NULL)

(1, 0,7,4, {1,2,3}) <---
(1,100,7,4, {1,2,3})
(1,-1,7,4, {1,2,3})

this 7,4, {1,2,3} without looking at the documentation can you explain what it means?

[woodbri]

The definition of a restriction is:

• rid - unique id for restriction in table of restrictions
• to_cost - cost to be applied when the restriction is applied
• target_id - the id that we going to
• from_edge - the edge we are on when evaluating the target_id
• via_path - a comma separated list of ancestor edges to from_edge that the path came through

For simple restrictions, via_path is NULL as the whole restriction can be defined using target_id and from_edge. For more complex restrictions, you need to define a path of multiple edges that represent the restriction.

[woodbri]

We have the following pages in the wiki related to turn restrictions:

• https://github.com/pgRouting/pgrouting/wiki/Turn-Restricted-Shortest-Path-(TRSP)
• https://github.com/pgRouting/pgrouting/wiki/TRSP-Enhancements-Planning
• https://github.com/pgRouting/pgrouting/wiki/TRSP-for-railroads

Also the sample data was originally designed for test various simple and complex restrictions.

[woodbri]

Basically, our restriction model is identical to the OSM model:
http://wiki.openstreetmap.org/wiki/Relation:restriction

[woodbri]

Here are some references to various papers discussing turn restriction implementation:

• https://algo2.iti.kit.edu/download/turn_ch.pdf
• http://www.isprs.org/proceedings/XXXIV/part4/pdfpapers/410.pdf
• http://geo.fsv.cvut.cz/gdata/2013/pin2/d/dokumentace/line_graph_teorie.pdf