[pgrouting-users] Different comportment between 'shortest_path_astar' and 'driving_distance' functions.

Schembri Samuel Samuel.Schembri at mediapost.fr
Mon Jan 16 09:36:37 EST 2012


Hi steve,

Thank you for the response.

Why I would like to used this method. I prefer driving-distance functions because when we must compute a lot of distances with same departure point, this method is more fast than 'shortest_path_astar' method. After, I can get distance with nodes directly.

Example : get distance between shop and 100 customers.

I can create little graphe ,function, and snapshot.

How would you like receive these informations ?

Regards

Samuel

 

 


-----Message d'origine-----
De : pgrouting-users-bounces at lists.osgeo.org [mailto:pgrouting-users-bounces at lists.osgeo.org] De la part de Stephen Woodbridge
Envoyé : lundi 16 janvier 2012 15:14
À : pgrouting-users at lists.osgeo.org
Objet : Re: [pgrouting-users] Different comportment between 'shortest_path_astar' and 'driving_distance' functions.

Hi Samuel,

I'm not sure I can answer your question with doing some additional research of reading through the code, but the driving directions does not get much use and it is possible that it has a bug that noone has reported until now.

Your example seems like a really good test case. I am trying to collect simple and clear test cases so we can develop a test suite that can be run before we release code to validate changes in a release have not broken anything. If you could create a ticket and attach your test cases or just send them to me off list, I can create a ticket for them.

-Thanks,
   -Steve



On 1/16/2012 3:14 AM, Schembri Samuel wrote:
> Hi,
> I am new user of this pgrouting users list. I hope used correctly.
> I used pgrouting 1.02 on postgres 8.2.17. At this time, I can't update 
> Postgresql.
> There is a different comportment between 'shortest_path_astar' and 
> 'driving_distance' functions when I use reverse_cost column.
> Here are graphe conditions :
>
>   * For each edge without one-way : cost=reverse_cost=length
>   * For each edge with one-way similar to digitalisation way :
>     cost=length reverse_cost=-1 (or 100000)
>   * For each edge with one-way inverse of digitalisation way : cost=-1
>     (or 100000) reverse_cost=length
>   * All another edges are not in graphe.
>
> *shortest_path_astar:*
> /has_reverse_cost = false : /
> Edges with 'cost=-1' are forbiden and Pgrouting don't used them.
> 'Reverse_cost' information is not used.
> /has_reverse_cost = true:/
> Edges with 'cost=-1' are used if 'reserve_cost' is more than 0. Cost 
> used by pgrouting is 'reserve_cost' column.
> Edges with 'reverse_cost=-1' are used if 'cost' is more than 0. Cost 
> used by pgrouting is 'cost' column.
> T his computing is correct.
> *Driving_distance:*
> **
> /has_reverse_cost = false : /
> Edges with 'cost=-1' are forbiden and Pgrouting don't used them.
> 'Reverse_cost' information is not used.
> /has_reverse_cost = true:/
> /Case one : Edge with 'cost=-1' and 'reverse_cost=length':/ Edge can 
> be traveled on digitalisation way ( cost =-1!!). Cost used by 
> pgrouting is 'Reverse_cost' column.
> /Case two : Edge with cost=length and reverse_cost=-1:/ Edge can be 
> traveled on inverse digitalisation way. More, Cost used by pgrouting 
> is 'cost' column.
> In this two case, pgrouting don't respect restrictions. This computing 
> is not correct.
> Could you me if this result is normal or not ?
> Sorry for my bad english and best regards Samuel -- Paris //
>
>
> _______________________________________________
> 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