I tried calculating a car isochrone from within a pedestrian area. But the car isochrone is getting very small. I think this is due to the pedestrian zone. But when I move the location a little the isochrone is getting much biggger. How can I prevent this?
this is rather hard to reason about without seeing the actual isochrones.
Could you provide the Coordinates you’re using as an input in both cases?
Here are the actual locations:
As you can see here:
the output isochrone is very different.
Your original point on Kalverstraat is not routable by car. Thus, the openrouteservice snaps this to the nearest point that is routable by car, which is somewhere on Rokin, and generates an isochrone from there.
The second point is actually car-routable, being on Singel.
This road, however, is tagged with
motor_vehicle=destination, thus setting a rather low speed of 5 km/h (check the discussion for more details.). In the 5 minutes given, this then yields the rather small isochrone you’re seeing.
You can prevent this by not creating isochrones from non-routable points.
Thanks for you good answer… But how can I prevent creating isochrones from non-routable points? Do I need to check the longitude and latitude on forehand? That is not handy. The best option for me would be if I can skip the non routable points and then start.
By the way… I am running my own ORS server.
What version are you running? If you are runing your own ORS on the master branch or the nightly docker image, you should have access to the /snapping endpoint already.
You could send a request to that before to know which points will be snapped to the graph and which won’t.
And then adjust the your Isochrone requests to skip the relevant points.
I am using the latest docker image I guess. But here is the documentation about the /snapping endpoint? And are there any better solutions. We try to calculate isochrones from 8000 stores in the Netherlands. We just want to have a best average isochrone. Do you have any tips?
which should be the default for the built in swagger-ui. If /v2/snap is not there. try the nightly image or you need to build it from sources.
We are currently using Here and there you can specify a point radius where to go. I assume it take the best available road within that radius. A solution like this will be perfect.
thanks… do you know if it is possible to just start from a best available road? so the 2 points will give a more similar result?
No, currently not.
How would you decide the best available road, for all points? How far can a better alternative be away to be preferred over the nearest point?
That would be a whole desicion tree that differs for every profile.
You could implement this, but i would be surprised if it works properly for all use cases.
So currently it just uses the closest point on the graph, that it can find.
For isochrones there isn’t a radius parameter which defines the distance that it looks in.
That’ might be something to be implemented a lot easier and would give you the option to have an unlimited search radius so it will always snap to the graph.
In either case, please open an issue if you want to see that feature.
I tried the snapping service but It won’t fix anything. I use the new locations [[4.892407,52.368437],[4.889834,52.367286]] which I got from the snapping service. But isochrone is still the same.
DO you think of any other option or solution so the isochrone is not so different for both cases?
The snapping would only solve the case, for points where you don’t get an isochrone at all.
For your “preferred” center point, there is currently no solution.
Only the proposed implementation of a desicion tree (i described above) for the start point, that doesn’t exist yet.
This problem is a big problem for us in big cities (Like Amsterdam). WE cannot relocate all those location manually. Do you have any idea how to relocate these locations to a better location?
ANother option… can we remove motor_vehicle=destination or something?
Can I hire you to help is?