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

[Stephen Woodbridge]

Max,

This is correct which is why there are to versions of 
turn_restrict_shortest_path(), see below.

One you pass in node ids and the other pass edge id and percent along 
the edge.

The reason for the second api is that if you pass node_ids we do not 
have enough inforamtion about the direction of travel because we are at 
a node.

But if we pass the edge id, and say the mid point of the edge, and it is 
a oneway edge then we can determine if this edge plays a part in a 
restriction of not and potential which direction we are traveling in.

-Steve

On 5/26/2012 5:39 PM, Max Weninger wrote:
> Hi again
>
> I think I found the problem
>
> It seems that trsp is not using such a turn restriction
> correctly if the start and end point of the route is
> "on" target_id and from_id.
>
> If I "extend" start and end it works as expected.
>
> This does only apply to restrictions with more then
> one via_path entry. "Simple" restrictions also work
> in such cases.
>
> Can someone confirm this?
>
> Thanks
>
> max
>
> On Sat, 26 May 2012 23:02:16 +0200
> Max Weninger<max.weninger at gmail.com>  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