[pgrouting-users] Shortest Path Shooting-Star Ignore Reverse Cost

Stephen Woodbridge woodbri at swoodbridge.com
Mon Jan 30 16:28:38 EST 2012


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 at swoodbridge.com
>> <mailto:woodbri at 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>
>>
>> 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>
>>
>> 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 at lists.osgeo. org
>> <mailto:Pgrouting-users at 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 at lists.osgeo. org
>> <mailto:Pgrouting-users at 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-users



More information about the Pgrouting-users mailing list