[pgrouting-users] TRSP: rule vs via_path and other documentation
Max Weninger
max.weninger at gmail.com
Sun May 27 03:27:40 PDT 2012
Hi
Actually the problem is a little bit "academic"
I just found it for my test case.
In "real life" situation it is very unlikely that
it happens :)
I am only using the edge_id and position on edge "api"
In my test case there are no oneways
I will try if I can isolate it a little bit and provide
more information.
The "basic" setup would be e.g. (all ids are edge_ids)
to_id=1
via_id=2
from_id=3
If I call trsp with e.g. from_id=3 pos=0.5 to_id=1 pos=0.5 and
via_path=2,3 it will still "happily" calculate the route "over"
the restriction :) If I move the start and ed point to at least
a edge "before" and "after" it is correct.
If the test does not include a "second" via_id so via_path=3
it works also by using the from and end edge.
Thanks
max
On Sat, 26 May 2012 21:33:31 -0400
Stephen Woodbridge <woodbri at swoodbridge.com> wrote:
> 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
>
> _______________________________________________
> Pgrouting-users mailing list
> Pgrouting-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-users
More information about the Pgrouting-users
mailing list