[pgrouting-users] TRSP: rule vs via_path and other documentation

[Stephen Woodbridge]

Hi all,

If you are interested in using TRSP, or have already used it, please 
look at the following wiki page.

> https://github.com/pgRouting/pgrouting/wiki/Turn-Restricted-Shortest-Path-%28TRSP%29

I'm sure it is not complete, but it does provide SQL to create a simple 
graph and example queries to run TRSP along with the query results.

This should get you started. If you have already used TRSP and find that 
this is missing something or needs more clarification, please add to the 
page and/or post some comments to the list.

Hope this helps,
   -Steve

On 5/26/2012 9:11 PM, Stephen Woodbridge wrote:
> Hi Max,
>
> As luck would have it, I have started a documentation page for TRSP on
> the wiki. It is not complete yet, and the final piece (ie: the queries)
> that you need to answer your question are missing, but should be there
> tomorrow sometime once I have worked them out and tested them again.
>
> https://github.com/pgRouting/pgrouting/wiki/Turn-Restricted-Shortest-Path-%28TRSP%29
>
>
> Let me know what you think and I will add more content and improve the
> page as I work on it.
>
> Thanks,
> -Steve
>
> On 5/26/2012 5:02 PM, Max Weninger wrote:
>> Hi
>>
>> Today I tried the first time to add turn restrictions
>> which contain of more then one edge in via_path
>>
>> I already tried both "orders" but still the turn restriction is
>> not correctly evaluated from trsp. So it routes over such
>> a restrictions.
>>
>>> target_id: 1, via_path: 5,4,3,2
>>
>> So just that I understand it correctly :)
>> The correct order is for the following simple example
>>
>> target_id=1
>> from_id=3
>> via_id=2
>>
>> via_path must be
>> 2,3
>>
>> correct?
>>
>> Thanks
>>
>> max
>>
>> On Thu, 08 Mar 2012 09:55:55 -0500
>> Stephen Woodbridge<woodbri at swoodbridge.com> wrote:
>>
>>> Hi all,
>>>
>>> For those people that are using or trying to use the new trsp
>>> function, I want to highlight the difference between rule and
>>> via_path.
>>>
>>> I unfortunately implemented via_path to be a list of edges in the
>>> reverse order of rule.
>>>
>>> IF for RULE:
>>> target_id: 1, rule: 2,3,4,5
>>>
>>> THEN for via_path
>>> target_id: 1, via_path: 5,4,3,2
>>>
>>> What I do in my turn restriction tables is to have both columns and
>>> if you already have a rule column here is some SQL to create a
>>> via_path column:
>>>
>>> -- add a new column via_path
>>> alter table my_turns add column via_path text;
>>>
>>> -- need a helper function for the update
>>> CREATE OR REPLACE FUNCTION array_reverse(anyarray)
>>> RETURNS anyarray AS
>>> $BODY$
>>> SELECT ARRAY(
>>> SELECT $1[i]
>>> FROM generate_series(
>>> array_lower($1,1),
>>> array_upper($1,1)
>>> ) AS s(i)
>>> ORDER BY i DESC
>>> );
>>> $BODY$
>>> LANGUAGE sql IMMUTABLE STRICT
>>> COST 100;
>>>
>>> -- populate the via_path column
>>> update my_turns set
>>> via_path=array_to_string(array_reverse(string_to_array(rule,',')),',');
>>>
>>> One more common issue that is easy to get caught up in, is
>>> consistency of edge ids. When data is imported via shapefiles, you
>>> get a handy "gid" as the primary key and a lot of people use this to
>>> reference records. If you also load a restriction table or assemble
>>> it from your vendors data edges will typically be referred to be some
>>> edge_id that is NOT the "gid" the the shapefile loader dynamically
>>> adds when the data is loaded.
>>>
>>> So if you vendor data uses a column "object_id" as the edge
>>> identifier, then it is likely that your restriction data will be
>>> defined in terms of "object_id" also. Therefore when you construct
>>> your query it needs to be something like:
>>>
>>> select * from turn_restrict_shortest_path(
>>> 'select object_id as id, source, target, ...',
>>> 1234, -- start NODE_ID
>>> 5678, -- end NODE_ID
>>> true,
>>> true,
>>> 'select to_cost, object_id as target_id, via_path from my_turns');
>>>
>>> I would also recommend the people use the following version of trsp
>>> because it can handle oneway conditions and restrictions at the start
>>> and end of the route that can not be detected using the above.
>>>
>>> select * from turn_restrict_shortest_path(
>>> 'select object_id as id, source, target, ...',
>>> 1234, -- start EDGE_ID
>>> 0.5, -- position along edge
>>> 5678, -- end EDGE_ID
>>> 0.5, -- position along edge
>>> true,
>>> true,
>>> 'select to_cost, object_id as target_id, via_path from my_turns');
>>>
>>> Notice that this uses EDGE_IDs and not NODE_IDs as the first does.
>>> Also position along the edge is a float from 0.0 to 1.0 where 0.0 is
>>> the start of the edge and 1.0 is the end of the edge. The postGIS
>>> linear referencing functions will return a value suitable for this by
>>> dropping a point on and edge and returning the percentage along that
>>> edge.
>>>
>>> I hope this helps people use this new function.
>>>
>>> Thanks,
>>> -Steve
>>> _______________________________________________
>>> Pgrouting-users mailing list
>>> Pgrouting-users at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>>
>> _______________________________________________
>> Pgrouting-users mailing list
>> Pgrouting-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>
> _______________________________________________
> Pgrouting-users mailing list
> Pgrouting-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-users