[pgrouting-users] TRSP Problem

[Christophe Damour]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-users/attachments/20140307/70579f7f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug_trsp.zip
Type: application/x-zip-compressed
Size: 90330 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/pgrouting-users/attachments/20140307/70579f7f/attachment-0001.bin>