Steve,
This is my route:
http://cl.ly/2v3G05442o3h2H0G2L0l
i have restricted turn going from 9151, 9082.
how i need to set this in my table restricctions.
SQL:
drop table if exists routing.route;
create table if not exists routing.route(
nid serial not null
) with oids;
Select AddGeometryColumn('routing', 'route', 'geometry', '4326',
'LINESTRING', 2);
insert into routing.route(geometry)
SELECT
routing.network.geometry
FROM
(
SELECT
*
FROM
turn_restrict_shortest_path(
'SELECT
routing.network.segment as id,
routing.network.source,
routing.network.target,
routing.network.length as cost,
routing.network.reverse_length as reverse_cost
FROM
routing.network',
-- node_from, node_to
9151,
9082,
--15242,
false, -- directed
true, -- reverse_cost
'SELECT
routing.restrictions.target_id,
routing.restrictions.to_cost,
routing.restrictions.via_path
FROM
routing.restrictions'
)
) as route inner join routing.network on
route.edge_id = routing.network.segment
;
Table looks like:
target_id to_cost via_path
9082 1000 9151, 9083
i missing somehting?
Yes, eventually we will have documentation. TRSP uses nodes (currently) to define the the route start and end points, but restrictions are defined in terms of edges. So you restriction table should look like:
So read this as traveling from edge 12832 to 12736 costs 1000.
If you wanted to say that you can not make a U-turn from 12829 to 12736 via 12832 then you could create a restriction like
2012/1/30 Stephen Woodbridge <woodbri@swoodbridge.com
<mailto:woodbri@swoodbridge.com>>
On 1/30/2012 4:20 PM, Stephen Woodbridge wrote:
The turn restrictions are handled differently in TRSP. You need
to have
a table like:
target_edge_id (int4), to_cost(float8), via_path (text)
This is a replacement for the rule and at the moment
via_path := reverse(rule)
so if your rule = 1,2,3,4 then via_path = 4,3,2,1
I think that this will eventually change to be consistent with
shooting_star and the rule.
I believe that the way to interpret this is to apply the to_cost
if the
current edge it target_edge_id and prior edge was 4, and 3
before that,
and 2 before that, and 1 before that. So the cost would NOT be
applied
given this rule if the path was current_edge, 4, 3, 7 for example.
You may have multiple rules for a given target_edge_id.
In my database, I have a table like this:
CREATE TABLE trsp_rest
(
to_cost double precision,
target_id integer,
via_path text,
the_geom geometry,
"rule" text,
CONSTRAINT enforce_dims_the_geom CHECK (ndims(the_geom) = 2),
CONSTRAINT enforce_geotype_the_geom CHECK (geometrytype(the_geom)
= 'LINESTRING'::text OR the_geom IS NULL),
CONSTRAINT enforce_srid_the_geom CHECK (srid(the_geom) = 4326)
)
WITH (
OIDS=FALSE
);
the geometry is just a copy of the target_id geometry that I can use
to spatially restrict the restrictions to that of my query, but it
is not required. You could also use a join to do the same thing.
And then for the turn_restrict_sql you can pass something like:
'select to_cost, target_id, via_path from trsp_rest'
'select to_cost, target_id, via_path from trsp_rest
where the_geom && <bbox of query>'
-Steve
-Steve
On 1/30/2012 4:00 PM, Jorge Eliécer Osorio Caro wrote:
Hi Steve,
I compile that version but i dont know very well the params
that i need
to send to:
now we have via_path, means that edges where i can have
access? its in
replacement of rule?
now we have that parameter to:
sql text,
source_id integer,
target_id integer,
directed boolean,
has_reverse_cost boolean,
turn_restrict_sql text)
turn_restrict_sql what i need to pass there?
i have something like this:
SELECT * FROM turn_restrict_shortest_path( 'SELECT
routing.network.segment as id, routing.network.source,
routing.network.target, routing.network.length as cost,
routing.network.reverse_length as reverse_cost,
routing.network.x1,
routing.network.y1, routing.network.x2, routing.network.y2,
routing.network.rule as via_path, routing.network.to_cost FROM
routing.network', -- node_from, node_to 15365, 15366,
--15242, false, --
directed true, -- reverse_cost 'ż?' )
thanks steve.
2012/1/30 Stephen Woodbridge <woodbri@swoodbridge.com
<mailto:woodbri@swoodbridge.com>
<mailto:woodbri@swoodbridge. com
<mailto:woodbri@swoodbridge.com>>>
Jorge,
I have posted a few times on this problem, you can check the
archives. The short story is the shooting star is broken. I
think
the last version that worked is 1.03. In my posts is also some
information on a new algorithm turn_restricted_shortest_path
(trsp)
that is in a branch. The current code in a git branch works
but is
likely to see changes before it is released, but we do not
have a
release plan yet.
-Steve
On 1/30/2012 2:30 PM, Jorge Eliécer Osorio Caro wrote:
Im having a issue when try to calculate the shortest path
using turn
restricctions this functions ignores the reverse_cost param.
here the SQL:
|SELECT
*
FROM
shortest_path_shooting_star(
'SELECT
routing.network.segment as id,
routing.network.source,
routing.network.target,
routing.network.length as cost,
routing.network.reverse_length as reverse_cost,
routing.network.x1,
routing.network.y1,
routing.network.x2,
routing.network.y2,
routing.network.rule,
routing.network.to_cost
FROM
routing.network',
-- node_from, node_to
15365,
15366,
--15242,
false, -- directed
true-- reverse_cost
)
|
this generate that route:
http://cl.ly/ 242E2T0A2C410F1S0F3g
<http://cl.ly/ 242E2T0A2C410F1S0F3g
<http://cl.ly/242E2T0A2C410F1S0F3g>>
that method generate the route but it ignores the one_way
restriction ,
the restriction is ok, but take a route where ignores that.
now in the next image i need the marked red lines are the
correct route
because the 15229 and 15228 has both ways.
http://cl.ly/ 3t2O38343F0F0C0o3P2c
<http://cl.ly/ 3t2O38343F0F0C0o3P2c
<http://cl.ly/3t2O38343F0F0C0o3P2c>>
here how look my table:
id source target cost reverse:cost rule to_cost x1, y1, x2, y2
15245 9082 9150 0.02 100.00021 15214 101.00021 -74.79981
10.94605
-74.7996 10.94605
how i cant fix that i compiled the last version of pgrouting
from git repo.
______________________________ _________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo. org
<mailto:Pgrouting-users@lists. osgeo.org
<mailto:Pgrouting-users@lists.osgeo.org>>
http://lists.osgeo.org/ mailman/listinfo/pgrouting- users
<http://lists.osgeo.org/ mailman/listinfo/pgrouting- users
<http://lists.osgeo.org/mailman/listinfo/pgrouting-users>>
______________________________ _________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo. org
<mailto:Pgrouting-users@lists. osgeo.org
<mailto:Pgrouting-users@lists.osgeo.org>>
http://lists.osgeo.org/ mailman/listinfo/pgrouting- users
<http://lists.osgeo.org/ mailman/listinfo/pgrouting- users
<http://lists.osgeo.org/mailman/listinfo/pgrouting-users>>
______________________________ _________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo. org
<mailto:Pgrouting-users@lists.osgeo.org>
http://lists.osgeo.org/ mailman/listinfo/pgrouting- users
<http://lists.osgeo.org/mailman/listinfo/pgrouting-users>
______________________________ _________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo. org
<mailto:Pgrouting-users@lists.osgeo.org>
http://lists.osgeo.org/ mailman/listinfo/pgrouting- users
<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