<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think there will be both cases. DARP/TSP might only need the matrix at<br>
first. But when you got your optimized tour result you had to run again<br>
the shortest path search to retrieve a path, which causes two problems:<br>
<br>
* The network (conditions) might have changed if you run those path<br>
queries later.<br>
</blockquote>
<br></div>
I guess this assumes the you are getting live feed data for traffic or something like that. What are you think here? Also be aware that the algorithms can select any of equal distance alternatives and the later if you single shortest path it might pick a different path, which may or may not be problematic.<br>
<br></blockquote><div><br></div><div>I actually don't assume live feed data but the fact that pgRouting keeps the network in a database and it's possible to change attributes for example, that are part of your cost parameter, at any time. Or maybe road links become unavailable during a long APSP query.</div>
<div><br></div><div>I think the library should ensure that when you make a query it reads the network data available at that time. If the query for processing a huge distance matrix takes one hour for example, but makes steadily new requests to the database, it could happen that some attributes change over time.</div>
<div>Whether this is problematic for an application or not depends on the application. In most cases it probably isn't, that's true. But pgRouting isn't limited to road networks, so who knows what kind of applications will make use of it.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* It might be slower to later run single shortest path queries again<br>
independently<br>
</blockquote>
<br>
It would be interesting to enhance our single shortest path to be able to extract multiple single shortest paths based on a single graph build. So input might be something like<br></blockquote><div><br></div><div>This would be the same as k-Shortest Path, right?</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><a href="http://www.pgrouting.org/rfc/rfc-04.html">http://www.pgrouting.org/rfc/rfc-04.html</a></div><div><a href="http://www.pgrouting.org/rfc/rfc-04.html"></a> </div>
<div><br></div><div>Daniel </div><div><br></div><div><br></div><div><br></div></div>-- <br><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">Georepublic UG & Georepublic Japan<br>eMail: <a href="mailto:daniel.kastl@georepublic.de" style="color:rgb(66, 99, 171)" target="_blank">daniel.kastl@georepublic.de</a><br>
Web: <a href="http://georepublic.de/" style="color:rgb(66, 99, 171)" target="_blank">http://georepublic.de</a></span><br>