[pgrouting-users] TRSP Problem
Stephen Woodbridge
woodbri at swoodbridge.com
Fri Mar 7 11:10:34 PST 2014
Hi Christophe,
Sorry you are having problems with this. I have a major deadline and
have not had time to look at this. Typically the large cost value means
that you are requesting a route and the only way to follow the route is
to go the wrong way down a one-way street.
This might be because you are missing some edges because your where
clause to not including enough edges or there is some other issue with
your graph like it is not noded correctly.
We have supplied some tools in the 2.0 release to help node a newwork
and to help analyze it for problems. Read the docs
http://docs.pgrouting.org/2.0/en/doc/index.html
Specifically the Tutorials on "Routing Topology" and Graph Analytics"
When I have some free time, I will look at your issue, but please don't
wait on me as it may be a while.
Best,
-Steve
On 3/7/2014 1:41 PM, Christophe Damour wrote:
> Hi,
>
> No answer... I am stuck with this one.
>
> Is it possible that there is a conflict between the where clause
> processing and the cost / rev_cost ?
>
> I have the same behaviour with edge start / target instead of vertex
> start / target.
>
> Here is the wrong query result :
> seq id1 id2 cost
> 0 19314 23805 25.2230680696244
> 1 16327 15869 200.551744693165
> 2 16328 30606 1000000
> 3 22180 30607 12.1375967381755
> 4 14374 28286 249.361944927019
> 5 14371 18295 111.604786405456
> 6 10776 -1 0
>
>
> In my understanding, it shouldn't be possible to have an edge with cost
> 1000000 in the resulting path (it is the only one in the network to have
> such a cost, and the network is very small) !
>
> Thanks for any hint,
>
> --
> Christophe DAMOUR
>
> Le 03/03/2014 20:20, Christophe Damour a écrit :
>> Hi,
>>
>> Sorry to post twice, I forgot the attached file...
>>
>> I use pgRouting to calculate accessible routes for disabled pedestrians.
>> Network edges have some attributes that are used to filter the
>> accessible network in both ways depending on the user capacities
>> (where clause).
>> Network edges have also attributes that are used to update cost /
>> rev_cost depending on the routing way : If an edge is forbidden in the
>> digitizing way, cost is set to 1 000 000. If it is forbidden in the
>> reverse way, rev_cost is set to 1 000 000. If it is forbidden in both
>> ways, cost and rev_cost are set to 1 000 000.
>>
>> Now, in some cases, despite there is no accessible route according to
>> the where clause, pgr_trsp() returns a route going through edges with
>> cost / rev_cost set to 1 000 000.
>> If I change the where clause so that there is actually an alternative
>> route, same edges with cost / rev_cost set to 1 000 000 are taken into
>> account, and the calculated route is correct.
>>
>> I attached to this message images of both results (forbidden edges in
>> red, returned paths in blue).
>> Routing is calculated from edge n°18295 (vertex n°19314) to edge
>> n°23805 (vertex n°10776).
>> Wrong edge is n°30606 in test 2.
>>
>> Here is the sql code of the first test :
>> SELECT * FROM pgr_trsp(
>> 'SELECT id_tron::integer AS id, source::integer, target::integer,
>> cost::double precision, rev_cost::double precision AS reverse_cost
>> FROM rp_test
>> WHERE type_tron NOT IN(3, 8, 9) AND largeur_c > 90 AND largeur_p > 75
>> AND etat_revet >= 2',
>> 19314::INTEGER, 10776::INTEGER, true, true,
>> 'SELECT to_cost::double precision, target_id::integer, via_path::text
>> FROM reseau_global_rest');
>>
>> And here is the sql code of the second test :
>> SELECT * FROM pgr_trsp(
>> 'SELECT id_tron::integer AS id, source::integer, target::integer,
>> cost::double precision, rev_cost::double precision AS reverse_cost
>> FROM rp_test
>> WHERE type_tron NOT IN(3, 8, 9) AND largeur_c > 90 AND largeur_p > 75',
>> 19314::INTEGER, 10776::INTEGER, true, true,
>> 'SELECT to_cost::double precision, target_id::integer, via_path::text
>> FROM reseau_global_rest');
>>
>> I also attach to this message a shape file of the network.
>>
>> Do I miss something, or is it a bug ?
>>
>> Thanks for any help,
>> --
>> Christophe DAMOUR
>>
>>
>>
>>
>> _______________________________________________
>> 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