Hello,
when I try computing directions in R with the coordinates 18.9364946 7.3059808 I get the error message that the point is could not be found within radius.
Even if I increase the radius up to 50km, where there is definitely a valid point (see attached picture), I get the same error message
Can someone help?
You sure that’s lon/lat, not lat/long?
Please provide a valid curl request.
yes I double checked that. It’s lon/lat.
Here’s my code:
v <- rbind(c(18.55496, 4.36122), c(18.936495, 7.305981))
radius <- c(350, 50000)
try(openroute_results <- ors_directions(v, radiuses = radius))
and the error message:
Error : Openrouteservice API request failed
[2010] Could not find point 1: 18.9364950 7.3059810 within a radius of 50000.0 meters.geterrmessage()
[1] “Indizierung außerhalb der Grenzen”
@MFax can you please post all information regarding the request if it is not possible for you to provide a curl or POST request? especially the profile, as the engine uses an entirely different graph depending on the profile.
It is hard to help if you only show us fractions of the request
Best regards
Hi @amandus,
I don’t know how to give you a curl or POST request from my R code.
ors_directions defaults to “driving-car” in R. The code above is the whole request
Best regards
thank you for the information.
this seems to be a problem with the backend. Even setting -1 as radius will not find a point:
curl -X POST \
'https://api.openrouteservice.org/v2/directions/driving-car' \
-H 'Content-Type: application/json; charset=utf-8' \
-H 'Accept: application/json, application/geo+json, application/gpx+xml, img/png; charset=utf-8' \
-H 'Authorization: xxx' \
-d '{"coordinates":[[18.55496,4.36122],[18.936495,7.305981]],"radiuses":[350,-1]}'
it finds a route with a point that is about 20 km away:
curl -X POST \
'https://api.openrouteservice.org/v2/directions/driving-car' \
-H 'Content-Type: application/json; charset=utf-8' \
-H 'Accept: application/json, application/geo+json, application/gpx+xml, img/png; charset=utf-8' \
-H 'Authorization: xxx' \
-d '{"coordinates":[[18.55496,4.36122],[18.925323,7.192188]],"radiuses":[350,-1]}'
so it should be working with a radius parameter.
Or do we have an internal limit to the search radius that i don’t know about?
I’ve followed up on this a bit and it seems that actually there is an internal limit on the GraphHopper side. Basically, what ORS does is to use GH’s default location lookup settings regardless of the radius and to return an error if the distance to the point found exceeds the limit set by the radius. However, the search on the GH side is bound as well by index.high_resolution and index.max_region_search configuration parameters which are currently set to 500 meters and 4 tile iterations, respectively.
Unfortunately, the technical details in LocationIndexTree seem quite obscure such that it is not entirely clear to me how these internal parameters could be easily translated to the actual distance.
Thank you all for your quick answers.
So is there any way to get this working? I also tried this manually with a nearby point like you.
But this happens with dozens of points I need to look up and I can not manually look for a nearby point every time
Best regards
Dear @MFax,
I’m not sure how much can be done about this on our side in short term. Internal search radius limit could be increased by a higher value of index.max_region_search. I don’t think this would require rebuilding the routing graphs, however, we would need to investigate all possible consequences first, including any potential performance penalty. @adam, what do you think?
I tried looking for the first snapped point between your original coordinates and the road and found that the snapping limit seems to be around 7 km for the considered region, which seems reasonable to me.
curl -X POST \
'https://api.openrouteservice.org/v2/directions/driving-car' \
-H 'Content-Type: application/json; charset=utf-8' \
-H 'Accept: application/json, application/geo+json, application/gpx+xml, img/png; charset=utf-8' \
-H 'Authorization: xxx' \
-d '{"coordinates":[[18.55496,4.36122],[18.913304,7.282273]],"radiuses":[350,-1]}'
I’ve just investigated for a while, and passing -1 as the search radius does normally work in overriding the default distance.
The problem here lies with the first point which is so far away from any road (the nearest I can see is over 170km away) that as @andrzej said, the defaults of GH are not wide enough. In their code they note that increasing the value can have an impact on performance so it is not something that we would change without properly looking into the impact.
Thanks y’all for your answers
@adam I don’t really get what you mean with the first point. It’s the coordinates of the capital city of Central Africa. So how do you get 170km?
Also @andrzej. Is there any way I could change this when I would be hosting it locally? Or anything else I could do to get this working?
ah, ok sorry, i was getting latitude longitude mixed up (the last coordinate looks very similar on the map in terms of relation to the road if you reverse it, so i was looking in Niger)
ah ok
Sorry for the possibly dumb question, but would it be possible to change this on a local build so I could at least get the distances hosting it locally?
King regards
I would suggest increasing the default value of index.max_region_search from 4 to 6 or 8. I’m not sure, though, whether it is currently possible to specify this at the level of ORS app.config file, it might be necessary to adjust the ORS source code to pass this parameter to the GraphHopper instance.
Hi! Similar sort of problem here. No matter which two points I pick in Chamonix, France and Zermatt, Switzerland, I get the same result (even when I pick points that are directly on a road). I was working in R using the API, but it also doesn’t work on the website.
It seems like the point in Zermatt might be the problem, as the same Chamonix point works for routing to other points.
Any idea what might be causing this?
Also, because I don’t just want to comment ‘negative’ feedback: I absolutely love the product. Thanks so much for creating this, and writing such clear instructions for R, as well.
Thanks a lot for your feedback!
The problem in this case is that apparently the road leading to Zermatt is closed to motor vehicles, as evident from OSM tags. Once you switch from car to bike the route can be found.
Got it, that makes a lot of sense. Thanks for the quick help!
Any updates on this one? I seem to be having the same issue. I’m not too fussed about the knocks in performance that changing maxRegionSearch etc. will cause … I just can’t figure out where to change them!
I’m very unfamiliar with Java, but locally (in the Docker container) I’ve managed to dig myself down to /ors-core/.m2/repository/com/github/GIScience/graphhopper/graphhopper-core/v0.13.2 and this is where I found the graphhopper-core-v0.13.2.jar file. Unpacking this .jar left me with the GraphHopper.class file (along with other files) which is sort of what I wanted, except this is an intermediate representation of the Java code, and as a result I don’t think I can easily edit it.
Before this .jre is created, and before this GraphHopper.class file is built, it must all be source (.java files) at one point right?
Can anyone point me to this “correct file” before it’s built on the Docker container please? All I want to change is those two parameters, have it build properly, and then not have to worry about not finding a road close enough. I’m (as you might be able to tell) happy to poke around in the files, just unsure of really what I’m doing when it comes to Java. 
I feel like I’m close, but if I’ve run down a rabbit hole and there’s a much easier way to do all of this - then I would greatly appreciate some help!
Cheers,
Troy
Thanks for reaching out @troy!
Typically it shouldn’t be necessary to increase the internal GraphHopper limit defined by max_region_search. Maybe try adjusting the search radius in ORS first. You can do it either on a per-query basis by specifying the radiuses API parameter, or set it globally through maximum_snapping_radius in the app.config file . The value -1 will use the maximum available search radius and unless this fails there is no need of increasing max_region_search in the GH instance.
Hi @andrzej, thanks for the quick reply!
I am having an issue when setting the radiuses=-1|-1 in my query. It still comes up with a “cannot find point within radius of -1 meters.”
As an example, a point in question is … “Could not find point 0: 115.4614830 -29.6923130 within a radius of -1.0 meters.” … However, I’ll be dealing with points like this often, points quite far away from roads I mean, so it really is in my best interest to take a bit of a performance hit (locally) but always make sure my request finds a road. I can then just calculate an error by taking the difference between the first point found in the route and the point given in the query.
Before I got stuck into any of the GraphHopper code I looked through all of the .config files and seemed to still come up empty! The only mention of “snapping” I found in any of the configuration files was within RouteProfileConfiguration.java. In that file I changed int maximumSnappingRadius=350 to int maximumSnappingRadius=15000, and even rebuilt my whole graph etc. in a fresh docker-compose. Then when running the same API request it still by default hit the 350m limit, and then when parsing through the -1|-1 parameter I recieved the same “Could not find point … within -1 meter radius…”.
This is what lead me to the same conclusion you guys got to within this thread: that the limit must be imposed further downstream (by GH as you revealed).
And, because my knowledge of Java is scrappy at best, I figured it’d be easiest for me to just find the GraphHopper.java file which holds the original class, and then just switch int maxRegionSearch=4 to 10 (or anything a bit larger). Then, after a day of searching for the class I realized that ORSGraphHopper.java extends the original GraphHopper.java class, which is not contained within the repo as source because it’s taken from the ‘Maven Central Repository.’ Which left me with my plan of action for today to fork the GIScience>graphhopper repo, make the small change, and then try point maven at that instead and see if it works.
If I’m completely wasting my time, and there’s some way easier way to change these parameters (i.e. increase search radius to something like 10km) then please, please, please let me know because I’m flying blind here haha!
Cheers,
Troy
