* Thankyou for your precious feedbacks,*
Date: Tue, 20 Feb 2018 12:42:33 -0600
From: Vicky Vergara <vicky@georepublic.de>
To: pgRouting developers mailing list <pgrouting-dev@lists.osgeo.org>
Subject: Re: [pgrouting-dev] Greetings!!Hello Sourabh,
This document is very incomplete please review the GSoC rules and the OSGeO
rules about the application*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.*
I must mention that It is not suggesting an algorithm to be implemented on
pgRouting, but looks more on how to use pgRouting for the special case of
"read networks".If you haven't done it, please read the pgRouting wiki
GSoC ideas of graph
algorithms.*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.*
* 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.*
* Please, Let me know if there is any useful resource(content) for the
above ideas.*
Also, to start making the tasks asked so that we consider your application
when we finish refining it.
I made lots of comments on your document.*Done, Please review it and let me know if you requires any information.*
Vicky Vergara
On Fri, Feb 16, 2018 at 12:59 AM, Rohith Reddy <rohithreddy2219@gmail.com>
wrote:> Hello Sourabh,
>
> Sorry for the delayed response. According to my understanding the doc
> explains the practicality of
>
> shortest path problem. It also defines two metrics that can be used for
> computing shortest yet fastest path.
>I agree that is describing the
shortest path problem where you are not using distance as weight. Please
read the pgRouting workshop*>>>Ok I will read that. Here I requires, weights for edges and nodes
seperately, which must apply on transformed Line graph. *
>
> 1. *Road Segments*
> This metric can be used in pgRouting, provided you have the data about
> betweenness and length of edges. If you had a chance to look at the
> documentation of pgRouting, here
> <http://docs.pgrouting.org/2.5/en/pgr_dijkstra.html#descript
ion-of-the-edges-sql-query-for-dijkstra-like-functions> you
> can find that the *cost *column represents the weight of the road. The
> *cost* column can represent length of the road, travel time on the
> road or any such metric which is to be minimised while computing
shortest
> path. In this case the metric you provided can be used as the *cost*
> column for path computation in pgRouting.
>
> 2. *Junctions (intersections)*
> This functionality had a complete rewrite last year as a part of GSoC
> 2017. Firstly the given graph was modelled as line graph
> <https://en.wikipedia.org/wiki/Line_graph> that captures the turn
> costs, and this line graph was further used for computing shortest
path.
> The metric you provided in this case can be used as a *cost* in the
*line
> graph*. You can find further details about the project here
> <https://github.com/pgRouting/pgrouting/wiki/GSoC-2017-Rewrite-TRSP>\.
*>>> Its quite 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. *
> It would be interesting to try and analyse the difference between the
> shortest path(based on length) and shortest path(based on the above
> metrics) on real world road network data like Open Street Maps.
>
> Regards,
> Rohith Reddy.End of pgrouting-dev Digest, Vol 86, Issue 5
********************************************
*Thank you,*
*Sourabh Garg*
*IIT(BHU), India*