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

[Stephen Woodbridge]

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