<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 30, 2013 at 10:23 PM, Stephen Woodbridge <span dir="ltr"><<a href="mailto:woodbri@swoodbridge.com" target="_blank">woodbri@swoodbridge.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mukul and Razequl,<br>
<br>
Congratulations on your successful completion of GSoC!<br></blockquote><div><br></div><div>Yes, congratulations!</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

For next steps, I see Daniel has merged the the develop branch into the vrp branch. This will make it easier to eventually merge your code back into the develop branch for our 2.1 release in the future. I think we need to add some methods to generate the distance matrix based on a list of locations. We can write a simple Euclidean distance generator for fast demos and write a separate function that uses one-to-many Dijkstra function to generate the distance matrix.<br>


<br>
Daniel, any thoughts on this? Did you have any specific plans with this?<br></blockquote><div><br></div><div>It would be nice to have some "Distance Matrix Generator", but I don't think all distances need to be newly calculated with every request, so it would be probably more useful to have a function that can transform a "row based" list of distances (stored in a table) into a matrix as needed by TSP or VRP.</div>

<div><br></div><div>I think users might calculate distances like this:</div><div><ul><li>Use Euclidean distance</li><li>When adding a new "stop point" k-Dijkstra can be run and the result can be stored in a table</li>

<li>Use a different route generator like OSRM and store the distances in PostgreSQL</li></ul><div>... or something else.</div></div><div>This would be faster than re-creating the distance matrix with every VRP query.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I want to do some testing on the partition projects, and look at performance and memory usage on large graphs. Mukul is going to look at creating a trsp-partition branch to see if he can integrate the partition model into TRSP.<br>

<br></blockquote><div><br></div><div>Do you think it makes sense to have a "develop-2.0" branch to collect bug fixes and a "develop-2.1" branch to merge new functions such as the partitioning and VRP function?</div>

<div><br></div><div>I think for Razequl and Mukul it's also neice to have their work merged into a branch that is going to become a release in a few months. It's better to do this now when both of you remember what you actually wrote and not one year later ;)</div>

<div><br></div><div>Daniel</div></div><br><br clear="all"><div><br></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>
</div></div>