<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Calibri, sans-serif" size="2">
<div>Hello PG-Routing – users,</div>
<div> </div>
<div>I hope, this is the right address for my mail...</div>
<div> </div>
<div>We are using pg-routing since some years and we are very impressed by the functionality and the speed.</div>
<div> </div>
<div>Today we tried first time pg_routing Version 2.0 (2.0.0,pgrouting-2.0.0,0,d6ed2cb,master,1.46.1) on PostgreSQL 9.2.4, compiled by Visual C++ build 1600, 64-bit with POSTGIS="2.1.1 r12113" GEOS="3.4.2-CAPI-1.8.2 r0" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL
1.10.0, released 2013/04/24" LIBXML="2.7.8" LIBJSON="UNKNOWN" TOPOLOGY (topology procs from "2.0.3 r11132" need upgrade) RASTER.</div>
<div> </div>
<div>When updating our code we replaced shortest_path through pgr_bdDijkstra.</div>
<div>And then we saw that the result of this algorithm seems to be false. But only when not using reverse costs.</div>
<div> </div>
<div>Here a simple test case, where we can reproduce the behaviour:</div>
<div>There are three Points. Costs from 1 to 2 and 2 to 3 are 1. Costs from 3 to 1 are 1.5. Reverse costs are equal.</div>
<div>When we search the shortest path from 3 to 1, the algorithm should use the direct connection. But it does not:</div>
<div> </div>
<div>select sp.id1::int4 as vertex_id, sp.id2::int4 as edge_id, sp.cost::float8 </div>
<div> from pgr_bdDijkstra('</div>
<div style="padding-left: 70pt; ">select 1::int4 as id, 1::int4 as source, 2::int4 as target, 1::float8 as cost, 1::float8 as reverse_cost</div>
<div style="padding-left: 70pt; ">union all </div>
<div style="padding-left: 70pt; ">select 2::int4 as id, 2::int4 as source, 3::int4 as target, 1::float8 as cost, 1::float8 as reverse_cost</div>
<div style="padding-left: 70pt; ">union all </div>
<div style="padding-left: 70pt; ">select 3::int4 as id, 3::int4 as source, 1::int4 as target, 1.5::float8 as cost, 1.5::float8 as reverse_cost', </div>
<div style="text-indent: 35pt; ">3, 1, false, false) sp</div>
<div> </div>
<div>result (vertex_id, edge_id, cost): </div>
<div>3;2;0</div>
<div>2;1;0</div>
<div>1;-1;0</div>
<div>-> wrong edges and even wrong costs</div>
<div> </div>
<div>when we use as last option "true" (has_rcost) the result is ok:</div>
<div>3;3;1.5</div>
<div>1;-1;0</div>
<div>-> correct result</div>
<div> </div>
<div>when we walk from 1 to 3 without reverse costs:</div>
<div>1;3;0</div>
<div>3;-1;0</div>
<div>-> right edges but still wrong costs</div>
<div> </div>
<div>After trying a while we saw, that there is also a pgr_dijkstra - routine in pg-routing 2.0, which seems to make the same as earlier the shortest_path.</div>
<div>We take this function now and that seems to work perfect (same sql as above but with pgr_dijkstra):</div>
<div>3;3;1.5</div>
<div>1;-1;0</div>
<div>-> correct result</div>
<div> </div>
<div>We are not sure, whether we used the pgr_bdDijkstra correct. But we think we did and we think the result of this function is not correct.</div>
<div>We did not find this problem described somewhere, that's why we wanted to inform you.</div>
<div> </div>
<div>It would be nice, if you let us know, whether this is really a bug or if we are doing something wrong.</div>
<div> </div>
<div>Thanks and Regards</div>
<div> </div>
<div>Thomas Höhne</div>
<div> </div>
<div><font size="2" color="#000080">IDU Ingenieurgesellschaft für Datenverarbeitung und Umweltschutz mbH<br>
Thomas Höhne<br>
<br>
Goethestraße 31<br>
02763 Zittau<br>
Germany<br>
<br>
Tel 03583 5409 499 / 5409 497<br>
Fax 03583 5409 / 498<br>
Internet <a href="http://www.idu.de"><font color="#0000FF"><u>www.idu.de</u></font></a></font></div>
<div> </div>
<div> </div>
<div> </div>
</font>
</body>
</html>