pgr_drivingdistance vs pgr_dijkstra - delievering contradictionary results

[Styp]

I encountered an issue which is difficile to explain.

Starting with the same starting point both algorithms return different results. It is obvious that the 2 algorithms produce two total different things, but the details have to be similar if not equal. In my opinion the boostlib works with Dijkstras algorithm on both functions.

Lets give the start point an id, in my case: 915231
And the endpoint id, in my case: 1291686

The end point is within the pgr_drivingdistance result and gave me a result of: 1.72xxxx.
This means the point is in reach within 1.73minutes. As I made a selection of all points in reach under 2 minutes. So far I do not see or feel any issues, but...

I use the same 2 points as an input for the pgr_dijkstra routine, my summed up result returns me a value of 1.99. This means the point is in reach within almost 2 minutes.

As this is only the 'introduction' to the problem, we digged deeper...

This is an example of what I described above. The point set and the blue line are the return set of a 2 minutes calculation starting at the same point. In my eyes something is completely off here!

We analysed the 2 graphes and realized, that to a certain point the routing does the same, but than chooses another direction. In my opinion this is wrong. Although, the nodes do not need to have the same 'costs' the end point of the routing has to be equal to the drivingdistance node cost. This is obvious as otherwise there would be a better route!

Reverse_cost is turned off! In both cases!

Hope you understand my theory!

Thank you
Styp

[woodbri]

Thank you for the report. It would be helpful if you can create a small table of edges that reproduces this problem so someone can look into it. You might also want to look at #203 Also I curious what you get for the route cost if you use pgr_trsp().

[Styp]

First of all, sorry that it took so long to come back on this topic - and at the moment there is no spare time to analyze it in detail. Currently it is very busy at work, so the few hints I can assume and give are all I can to at this point in time.

The yellow line is the one with pgr_trsp(). It is obvious that there is a difference in the routing algorithm, but somehow the result doesn't make sense at all.

Unfortunatly, gitHub does not allow me to upload a zip file, so i can not supply the data...

[woodbri]

An OSM file from @Styp can be downloaded from:
http://imaptools.com:8080/dl/Sion.osm.7z or
http://imaptools.com:8080/dl/Sion.zip
both are the same data in different compressed formats.

[woodbri]

@Styp I'm not sure I realized this was OSM data before. How did you load this data and create the topology?

[Styp]

osm2pgrouting was used - I think it is also Daniels project, so I assume it should work correctly.

[cvvergara]

Work in progress:
Upoladed the data with osm2po. instead of osm2pgrouting.
The image shows the edges that form a minimum spanning tree within the distance.
The area is what is generated by the points as polygon.

There is no difference on the costs obtained using driving distance and using dijkstra.

select sum(cost) from pgr_dijkstra('select id, source, target, km as cost  from si_2po_4pgr', 8887, 2188);
     sum     
-------------
 0.886207587
(1 row)

select cost from pgr_drivingdistance('select id, source, target, km as cost  from si_2po_4pgr', 8887, 1) where id1 = 2188;
    cost     
-------------
 0.886207587
(1 row)