<div dir="ltr"><img width="0" height="0" class="mailtrack-img" alt="" style="display:flex" src="https://mailtrack.io/trace/mail/f48926f4b3921db9f7e83f18c2f994d3cbfc35a9.png?u=439451"><div></div><div></div><div></div><div class="gmail_extra"><div class="gmail_quote"><div><b> Thankyou for your precious feedbacks,</b></div><div>   </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Date: Tue, 20 Feb 2018 12:42:33 -0600<br>
From: Vicky Vergara <<a href="mailto:vicky@georepublic.de" target="_blank">vicky@georepublic.de</a>><br>
To: pgRouting developers mailing list <<a href="mailto:pgrouting-dev@lists.osgeo.org" target="_blank">pgrouting-dev@lists.osgeo.org</a><wbr>><br>
Subject: Re: [pgrouting-dev] Greetings!!<br>
<br>
Hello Sourabh,<br>
<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This document is very incomplete please review the GSoC rules and the OSGeO<br>
rules about the application<br></blockquote><div>>><b>Yes Actually It presently seems incomplete as I just mean to present the idea. At Finalizing I will definately follow the Gsoc and OSGeo guidelines.</b></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I must mention that It is not suggesting an algorithm  to be implemented on<br>
pgRouting, but looks more on how to use pgRouting for the special case of<br>
"read networks".If you haven't done it, please read the pgRouting wiki GSoC ideas of graph<br>
algorithms.<br></blockquote><div>>><b>As of me, it must binds as an algorithm which includes transformation to line graph, identifying turns, computing metrics and then minimizing the objective function.</b></div><div><b>    If You don't it as a potential proposal idea, then I am also doing literature work for Multi-modal routing, generic directions and trailer-truck routing problem.</b></div><div><b>    Please, Let me know if there is any useful resource(content) for the above ideas.</b></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, to start making the tasks asked so that we consider your application<br>
when we finish refining it.<br>
I made lots of comments on your document.<br></blockquote><div>>> <b>Done, Please review it and let me know if you requires any information.</b></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Vicky Vergara<br>
<br><br>
On Fri, Feb 16, 2018 at 12:59 AM, Rohith Reddy <<a href="mailto:rohithreddy2219@gmail.com" target="_blank">rohithreddy2219@gmail.com</a>><br>
wrote:<br>
<br>
> Hello Sourabh,<br>
><br>
> Sorry for the delayed response. According to my understanding the doc<br>
> explains the practicality of<br>
> ​​<br>
> shortest path problem. It also defines two metrics that can be used for<br>
>  computing shortest yet fastest path.<br>
><br>
<br>
​I agree that is describing the ​<br><br>
shortest path problem​ where you are not using distance as weight. Please<br>
read the pgRouting workshop<br>
<br></blockquote><div><b>>>>Ok I will read that. Here I requires, weights for edges and nodes seperately, which must apply on transformed Line graph. </b></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
>    1. *Road Segments*<br>
>    This metric can be used in pgRouting, provided you have the data about<br>
>    betweenness and length of edges. If you had a chance to look at the<br>
>    documentation of pgRouting, here<br>
>    <<a href="http://docs.pgrouting.org/2.5/en/pgr_dijkstra.html#description-of-the-edges-sql-query-for-dijkstra-like-functions" rel="noreferrer" target="_blank">http://docs.pgrouting.org/2.5<wbr>/en/pgr_dijkstra.html#descript<wbr>ion-of-the-edges-sql-query-for<wbr>-dijkstra-like-functions</a>> you<br>
>    can find that the *cost *column represents the weight of the road. The<br>
>    *cost* column can represent length of the road, travel time on the<br>
>    road or any such metric which is to be minimised while computing shortest<br>
>    path. In this case the metric you provided can be used as the *cost*<br>
>    column for path computation in pgRouting.<br>
><br>
>    2. *Junctions (intersections)*<br>
>    This functionality had a complete rewrite last year as a part of GSoC<br>
>    2017. Firstly the given graph was modelled as line graph<br>
>    <<a href="https://en.wikipedia.org/wiki/Line_graph" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki<wbr>/Line_graph</a>> that captures the turn<br>
>    costs, and this line graph was further used for computing shortest path.<br>
>    The metric you provided in this case can be used as a *cost* in the *line<br>
>    graph*. You can find further details about the project here<br>
>    <<a href="https://github.com/pgRouting/pgrouting/wiki/GSoC-2017-Rewrite-TRSP" rel="noreferrer" target="_blank">https://github.com/pgRouting/<wbr>pgrouting/wiki/GSoC-2017-Rewri<wbr>te-TRSP</a>>.<br></blockquote><div><b>>>> Its quite <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">relatable to my approach, as I am also thinking of implementing it using "Line graph" of the original road network, and using Dijkstra's algorithm where the nodes and edges both contain weights.<span> </span></span>

</b></div><div><b> </b></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>     It would be interesting to try and analyse the difference between the<br>
>    shortest path(based on length) and shortest path(based on the above<br>
>    metrics) on real world road network data like Open Street Maps.<br>
><br>
> Regards,<br>
> Rohith Reddy.<br><br>
End of pgrouting-dev Digest, Vol 86, Issue 5<br>
******************************<wbr>**************<br></blockquote><div><br></div><div><b>Thank you,</b></div><div><b><br></b></div></div><b>Sourabh Garg</b></div><div class="gmail_extra"><b>IIT(BHU), India</b></div></div>