Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When "directed" option is enabled, "No paths found in (U) pgr_..." error is shown #144

Open
sanak opened this issue Sep 30, 2022 · 3 comments
Assignees
Labels

Comments

@sanak
Copy link
Member

sanak commented Sep 30, 2022

Problem
From the following issue's comment:
#133 (comment)

:
However none of the functions work with directed option enabled (pgrouting 3.3.0 , osm2pgrouting 2.3.8.1) Sql querys work

No paths found in (U) ...

Here is the error message when using pgr_dijkstra.
pgrouting-layer-directed-enabled-error

To Reproduce

  1. Check on "directed" option
  2. Execute "Preview" function

Expectation
The error message should not shown, and the directed result should be drawn.

@sanak sanak added the bug label Sep 30, 2022
@sanak sanak self-assigned this Sep 30, 2022
@sanak
Copy link
Member Author

sanak commented Oct 1, 2022

@jonath35 On my environment, turning on Reverse Cost and set appropriate column name solved the above No paths found in (U) pgr_... issue when directed is enabled.
pgrouting-layer-directed-workaround

If you don't set Reverse Cost, could you try above once ?

@cvvergara
Copy link
Member

Ah, interesting ...

no reverse_cost

For this structure edge_table1 without reverse_cost

gid source target cost
1000 1 2 23
1001 2 1 23

Without the tick mark:
SELECT gid AS id, source, target, cost FROM edge_table1
This represents,1<--->2
With the tick mark:
There would be an error because the reverse_cost column does not exist on the edge_table1

with reverse_cost

For this structure edge_table2 with reverse_cost

id source target cost reverse cost
1000 1 2 23 23

Without the tick mark:
These represents,1<--->2
SELECT gid AS id, source, target, cost, reverse_cost FROM edge_table2
This is weird but also works
SELECT gid AS id, source, target, reverse_cost AS cost, cost AS reverse_cost FROM edge_table2

Without the tick mark:
But if the tick is not there then the query of the image above is
SELECT gid AS id, source, target, cost FROM edge_table2
This represents,1--->2
path from 2 to 1 will not be found

If the word reverse_cost is on the Cost field the query would be
SELECT gid AS id, source, target, reverse_cost AS cost FROM edge_table2
This represents,1<---2
path from 1 to 2 will not be found
In these last 2 cases, the graph is not complete as you want 1<-->2 as the graph and no path will be found depending on the query.

conclusion

  • Have a tick mark on the Reverse_cost field as default as the data from osm2pgrouting has the reverse_cost column
  • Send an appropiate message when the reverse_cost column does not exist on the inner query
  • Beautify the message:

    For example
No paths found in pgr_dijkstra:
10605
to 
11481
* Does the query need `reverse_cost` column?
* Are both vertices in the graph?
* Are both vertices in the same graph component?
* Are both vertices in the same graph strong component?

@sanak
Copy link
Member Author

sanak commented Oct 3, 2022

@cvvergara Okay, thanks for the details!

About graph related part, I may not understand correctly, so I will try to check those in the following example data, later.
https://docs.pgrouting.org/3.3/en/sampledata.html

About the conclusion part,

  • Have a tick mark on the Reverse_cost field as default as the data from osm2pgrouting has the reverse_cost column

Okay, sure. Default tick mark=on will have less troubles.

  • Send an appropiate message when the reverse_cost column does not exist on the inner query

Okay, but is it better to show (raise) this message before running pgr_xxx query in pgRoutingLayer side ?
Or is there possibility to show error in each pgr_xxx functions initial validation process ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants