Why the same build passes on appveyor and fails on travis-ci.
@rajhim2 I don't have any idea how it passes on appveyor, however, there's an error in your added files.
In the file src/kargersContraction/kargersContraction.c
, the function's name shall be in all lowercase, as PostgreSQL converts all unquoted names to lowercase (_pgr_kargerscontraction
instead of _pgr_kargersContraction
).
You need to change this in all the three lines:
https://github.com/rajhim2/GSoC-pgRouting/blob/him/src/kargersContraction/kargersContraction.c#L43
https://github.com/rajhim2/GSoC-pgRouting/blob/him/src/kargersContraction/kargersContraction.c#L44
https://github.com/rajhim2/GSoC-pgRouting/blob/him/src/kargersContraction/kargersContraction.c#L116
Why the same build passes on appveyor and fails on travis-ci.
@rajhim2 I don't have any idea how it passes on appveyor, however, there's an error in your added files.
In the file
src/kargersContraction/kargersContraction.c
, the function's name shall be in all lowercase, as PostgreSQL converts all unquoted names to lowercase (_pgr_kargerscontraction
instead of_pgr_kargersContraction
).You need to change this in all the three lines:
https://github.com/rajhim2/GSoC-pgRouting/blob/him/src/kargersContraction/kargersContraction.c#L43
https://github.com/rajhim2/GSoC-pgRouting/blob/him/src/kargersContraction/kargersContraction.c#L44
https://github.com/rajhim2/GSoC-pgRouting/blob/him/src/kargersContraction/kargersContraction.c#L116
Thank you @krashish8 ! It worked like a charm.
Once that
From the console terminal:
# make sure that you are in the correct branch
git checkout combinationsSQL
# update to latest main repo contents
git fetch upstream
# Put your work on top of what develop
git rebase upstream/develop
Once you have updated the repo, the following that I forgot to mention on our last meeting must be done:
in doc/src/release_notes.rst
in the corresponding 3.1.0 release notes add
.. rubric:: New functions
* pgr_dijkstra(combinations)
From the github website:
I was adding the boost functionality to the function pgr_depthFirstSearch
(pgRouting/GSoC-pgRouting#38) I was implementing.
For this I was supposed to use boost::depth_first_search - for directed graphs, and boost::undirected_dfs - for undirected graphs.
In the current implementation, I have used pgrouting::UndirectedGraph
(#L117) and called boost::depth_first_search
, yet the function gives the correct result, as expected, for the undirected graph. The documentation for boost::depth_first_search
says the graph Graph& g
should be directed, however in the current implementation, I use undirected graph with it, and it is working alright.
Moreover, in the pgrouting, we have the functions pgr_primDFS and pgr_kruskalDFS, both of which work only for Undirected Graphs, but in the implementation, I see that the function calls the boost::depth_first_search
which is supposed to take only Directed Graphs as input.
As the current implementation works good on calling boost::depth_first_search
for both directed and undirected graphs, I don't consider the need to use boost::undirected_dfs
as everything is working fine.
Anyone has any idea why does the boost::depth_first_search
still works for undirected graphs?
Dear pgrouting-community,
we are big fans of your work! And are especially using the driving-distance feature of the pgrouting library.
There is one known issue with this function though, that is summarized in the issue #584.
With the help of @vjeranc I was exploring possibilities to fix this.
In this attempt we were having some preliminary results that are summarized in the PDF attached.
We wanted to contact you because so far the best fix for us seemed to be a custom dijkstra-function as we were not managing to fix this using Boost.
Therefore, we wanted to hear your opinion on that. Is this something that could be accepted? Looking forward to discuss with you.
Best,
Elias
@EPajares Hi, starting a discussion:
For simplicity suppose there is a graph G(E,V) where E= {(u,v,cost=10)} AND V={u,v} and a driving distance of 4 departing from
u=======+----------------------------v
then between vertex u & v at the "+" its where the driving distance is reached
From the documentation this are the possible columns
RETURNS SET OF (seq, [start_vid,] node, edge, cost, agg_cost)
What would the result be with this graph?
RETURNS SET OF (seq, [start_vid,] node, edge, cost, agg_cost, partial_edge)
We would have in the response all current edges + all edges that can only be "partially traversed" in the reality and are currently not in the response. With the additional parameter 'partial_edge' we could mark all edges that can only be "partially traversed". With post-processing we could use the cost, agg_cost and max_cost to extrapolate along the edge. But this also means that we would probably not have a node at the position "+" but would also create this one with post-processing.
Your result file contains
SELECT * FROM pgr_kargersContraction(
whereas it should be
SELECT * FROM _pgr_kargersContraction(
according to your queries.
kruskalBFS
function (an already-implemented function).kruskalBFS-edge-cases
: https://travis-ci.org/github/krashish8/GSoC-pgRouting/jobs/694577924#L1323
This is the result file. The main queries lie in the *.test.sql file - https://github.com/rajhim2/GSoC-pgRouting/blob/him/docqueries/kargersContraction/doc-pgr_kargersContraction.test.sql
In your case, all the three queries are calling the underscored function, so, I guess, if you change it to the main function, then the test will pass.
@EPajares Hi, starting a discussion:
For simplicity suppose there is a graph G(E,V) where E= {(u,v,cost=10)} AND V={u,v} and a driving distance of 4 departing from
u=======+----------------------------v
then between vertex u & v at the "+" its where the driving distance is reached
From the documentation this are the possible columnsRETURNS SET OF (seq, [start_vid,] node, edge, cost, agg_cost)
What would the result be with this graph?
@cvvergara
The result also does not need to contain additional columns. The partial edges can have agg_cost=drivingDistance
and cost
of the edge can stay the same. User would then check the predecessor agg_cost
of the node
at edge
to figure out the partially traveled part.
The result would be (seq, [start_vid,] node, edge, cost, agg_cost) = (1, u, v, 1, 10, 4)
. Given that predecessor of v
using edge 1
is u
and agg_cost
at u
is 0
then it's simple to figure out the partially traveled part.
I'm understand that implicitly marking the partial edges in this way complicates the function unnecessarily but I have not figured out a simpler way without adding an extra column in the result.