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

pgRouting pgrouting-users
1

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,
    '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,
    '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

2

Hello,

I sort of have a beginner problem. I want to use A* and SHOOTING* algorithms on a roads network; At some point, I use create_graph_tables function (I follow the documentation instructions) but it appears this function does not exist on PGROUTING 1.03.

ERROR: function create_graph_tables(unknown, unknown) does not exist LINE 17: SELECT create_graph_tables(‘troncon_route’, ‘int4’); ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts.

When I check in routing_core.sql the function is missing. However in version 0.9 the function is implemented.

Could you please enlighten me ? I am working on version pgRouting-1.03 with postgre 8.3.7. Thanks

Best regards, Gallien Labeyrie

3

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 :slight_smile:
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@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

4

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@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 :slight_smile:
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@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@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-users

5

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-(TRSP)

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 :slight_smile:
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@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,
     '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,
     '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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

6

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@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 :slight_smile:
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@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,
     '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,
     '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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

7

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-(TRSP)

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-(TRSP)

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 :slight_smile:
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@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,
'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,
'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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

8

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 :slight_smile:

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 :slight_smile: 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@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@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 :slight_smile:
>> 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@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@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>>
>
> _______________________________________________
> Pgrouting-users mailing list
> Pgrouting-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users