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

Incorrect error message when querying a table service #5845

Closed
murr999888 opened this issue Sep 30, 2020 · 2 comments · Fixed by #5846
Closed

Incorrect error message when querying a table service #5845

murr999888 opened this issue Sep 30, 2020 · 2 comments · Fixed by #5846

Comments

@murr999888
Copy link

murr999888 commented Sep 30, 2020

Before calculating routes, I try to check the reachability (no “disconnected” road segments) of the destinations.
I want to do this through a table query - from depot to each item.

To test it, I took a sample query from the documentation and added an unreachable point to it and added a "radiuses" parameter.
http://router.project-osrm.org/table/v1/driving/13.388860,52.517037;13.397634,52.529407;13.428555,52.523219;44.0086,30.7672?sources=0&radiuses=300;300;300;300

Query result:
{"message":"Could not find a matching segment for coordinate 3","code":"NoSegment"}

OK. I change the source point number to 2
http://router.project-osrm.org/table/v1/driving/13.388860,52.517037;13.397634,52.529407;13.428555,52.523219;44.0086,30.7672?sources=2&radiuses=300;300;300;300

Query result:
{"message":"Could not find a matching segment for coordinate 3","code":"NoSegment"}

OK. I change the order of the points and put the unreachable point first.
http://router.project-osrm.org/table/v1/driving/44.0086,30.7672;13.388860,52.517037;13.397634,52.529407;13.428555,52.523219?sources=0&radiuses=300;300;300;300

Query result:
{"message":"Could not find a matching segment for coordinate 3","code":"NoSegment"}

OK. I change the source point number to 1
http://router.project-osrm.org/table/v1/driving/44.0086,30.7672;13.388860,52.517037;13.397634,52.529407;13.428555,52.523219?sources=1&radiuses=300;300;300;300

Query result:
{"message":"Could not find a matching segment for coordinate 3","code":"NoSegment"}

I would like to get exactly the index of the point (or points) to which the route cannot be laid. But the response from the server is the same every time, and it is impossible to understand what the destination is incorrect.

It would be ideal to have an array of such points in the server's response.

It would be possible to make separate routing requests for each depot-client pair, but I have 400-500 destinations each time.
Is there another way to find unreachable destinations with a single query?

@danpat
Copy link
Member

danpat commented Sep 30, 2020

The error:

{"message":"Could not find a matching segment for coordinate 3","code":"NoSegment"}

is being caused by your use of the radiuses= parameter. There are no edges at all within 300m of coordinate 3, so the table call as a whole fails. No paths are being computed, because input coordinate 3 cannot be snapped to any roads.

@murr999888
Copy link
Author

murr999888 commented Sep 30, 2020

Of course, the radiuses parameter is set just for detecting incorrect destinations.

As I pointed out above - the order of the coordinates doesn't matter.
This point (44.0086,30.7672) - is unreachable. It can be placed anywhere in the query - the result will always be the same.

For example - in first position
http://router.project-osrm.org/table/v1/driving/44.0086,30.7672;13.388860,52.517037;13.397634,52.529407;13.428555,52.523219?sources=0&radiuses=300;300;300;300

If the number of points is 4 - will be returned
"Could not find a matching segment for coordinate 3",

If the number of points is 3 - will be returned
"Could not find a matching segment for coordinate 2",
Etc.

Query without this point and specifying the radius parameter returns the correct result.

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

Successfully merging a pull request may close this issue.

2 participants