Using the json V2 example with just two coordinates. The second coordinate is within a few meters of a valid road.
{“coordinates”:[[-122.4889283,38.5192598],[-122.32358,38.41810]]}
This is the error I get:
“engine”: {
“version”: “6.0.0”
,
Those are long/lats. These are in North America.
This problem has been occuring more frequently in the last few months.
Has something changed in the underlying model?
Sorry, my bad. didn’t check thoroughly 
try extending the search radius for the second point:
{"coordinates":[[-122.4889283,38.5192598],[-122.32358,38.41810]],"radiuses":[350,500]}
There are still a few of us in NA. 
That worked in the sample. I’ll code it up and have high hopes.
Can you explain a bit more about this, why it suddenly seems to be needed for me after years of successful directions without radia and also why I would not just put -1 in for every coordinate pair?
The help was kind of limited to what verses why.
The default search radius for deriving the closest point on the graph from the input point is/was by default 350m.
When you say it is ‘suddenly’ needed to pass radiuses:
did you previously find routes for the exact points you are having trouble with now?
Or do you just encounter the point not found error more often?
If it’s the first case there might be something wrong during the graph building. We recently developed some additional logic for cleaning up OSM data before building the graphs but as far as i know thats not used yet ( @adam or is it ?).
Maybe you just got unlucky when setting your points, so they have not been within the 350m range.
This may be a valid road, but it is not in included in the graph that is used for routing:
https://maps.openrouteservice.org/directions?n1=38.413568&n2=-122.32815&n3=15&a=38.42273,-122.334008,38.420226,-122.323666,38.415316,-122.326477,38.405968,-122.326155&b=0&c=0&k1=en-US&k2=km
most probably because of the access=private and highway=service tags which are both not suited for general routing:
Regarding setting -1 as radius, depends on your use case:
If you need a route by any means, do it. But in this case you would also get routes for switched lng/lat order when the waypoints would be in some ocean.
But as you are using the api directly there shouldn’t be a problem with setting the radiuses parameter by yourself to overwrite the default of 350?
best regards
Just recently (the last month? )is the first time we have encountered these errors and we have used the directions service for years. And yes, places that used to work no longer work now so I do suspect it might be your new logic.
So problems are now arising when Google comes back with a point such as an airport using the center which is more that 350 meters from a road. Or in other cases it may be a park where they give you the centerpoint but again that may be more than 350 meters away from the road.
You can give Google an address to a location but they often give you back the center point of the object rather than just the location of the address. Not sure if that has changed recently.
I am worried about bumping it to some arbitrary number because it may fall outside of radius. Maybe 500 would work in most cases but then I could find 1% of locations not found.
On the -1 if it finds the lng/lat is that going to be OK? Is it just if it does not resolve it then it could send me to who knows where? I am confident of my locations, just not confident how far away from the nearest navigable road they are.
AFAIK it’s just akin to a Nearest Neighbor calculation, i.e. it will stop looking as soon as it hits the first candidate edge.
Altering the search radius also comes with performance penalties. As you can imagine searching the world for some road is more intense than a few sqkm. So, please, don’t use ‘-1’. Also, I can’t imagine any use case where it would actually make sense to consider roads 100 km away from the asked location. Rather gracefully error out informing the user/analysis that there was no road around.
We don’t offer a Nearest service yet unfortunately, but others do, such as OSRM. Then you could look for the nearest road and even select one if there’s multiple. Mixing data/code-bases from different providers comes with its own caveats though.
OK. I will not use -1. I really don’t have a way to determine a valid distance until after the fact. Nothing in the coordinates I get from Google helps me to determine how close to the street it is.
Would a default of 1000 be acceptable? This would probably work in most cases.
Sure, totally acceptable.
That’s what a Nearest Service does for you, calculate the distance to the closest road(s). Since OSRM is in its last breaths, maybe you wanna check out Valhalla for that:
You’d have to host that yourself though… Even though Mapbox will release their Valhalla instances finally in a few weeks, I doubt they’ll release this endpoint.