Date: Tue, 20 Feb 2018 12:42:33 -0600
From: Vicky Vergara <[hidden email]>
To: pgRouting developers mailing list <[hidden email]>
Subject: Re: [pgrouting-dev] Greetings!!
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
>>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.
On Fri, Feb 16, 2018 at 12:59 AM, Rohith Reddy <[hidden email]>
> 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#description-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
>>> 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.
> Rohith Reddy.
End of pgrouting-dev Digest, Vol 86, Issue 5