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

[Max Weninger]

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
>