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?
Hey,
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?
Best regards
1 Like
Here are the actual locations:
{“locations”:[[4.891271797584913,52.36807818974749],[4.889748302909088,52.367337933858714]],“range”:[300]}
As you can see here:
the output isochrone is very different.
Hey,
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.
Best regards
hi,
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.
Best regards,
Evert
Hi @Evert1976,
What version are you running? If you are runing your own ORS on the main 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.
Best regards
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?
Try http://localhost:8080/ors/swagger-ui/index.html
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?
Hi !
I have also the same problem in Bordeaux. I try to generate an isochrone with these attributes:
{"locations":[[-0.5780053138732911,44.841279624418355]],"area_units":"km","attributes":["total_pop"],"range_type":"time","range":[900]}
The starting point is in a “living_street”, so I don’t know what the speed limit is, but even with a low speed limit the isochrone is way too small. It is smaller than with the same time but a pedestrian profile.
Is this a problem in the API, or with the source openstreetmap data ?
Thanks !
Hi @thewildman,
this is because e.g. on the west side of the isochrone, the car profile won’t take
due to the highway=pedestrian tag.
For which roads are considered by car see:
So the car-profile starting there is running into dead ends everywhere, due to the many one ways.
This might be also an issue with the access=destination tag handling in isochrones.
If you think the API is handling the data incorrectly please open an issue with a thorough description and examples
Best regards
1 Like
Hi @amandus, thanks for the answer.
The strange thing is that ORS will have no problem to route you from this point to outside of town, and the times will be lower than the isochrone limit.
So is the isochrone algorithm much different than the routing one?
One ways and pedestrians should be handled in the same way I believe, but I don’t know about “destination” .
Hi @amandus
So to make this point clearer, here is a route starting from the same point and leaving this zone by car in less than 15 minutes.
ORS Maps (openrouteservice.org)
So there are routes leaving this zone, it is not isolated from the rest of the network.
Should I open an issue ?
Hi everyone,
some of the described issues related to ways tagged with access: destination are probably resolved via #1682. This fix is scheduled to be rolled out in a couple of weeks with the upcoming ORS v8 release.
Cheers,
Andrzej
1 Like