Discrepancy between isochrone and matrix results

openrouteservice
1

I tried to calculate the isochrone and matrix from 222 Jackson St, Hoboken, NJ 07030.

First I generated a 5-mintue car driving isochrone and this is what I got.

image
image975×558 92.6 KB

I then found the driving time from my location to some pois within the isochrone is more than 5 minutes. For example it takes over 7 minutes to get to 414 Grand St, Jersey City, NJ 07302,

image
image975×548 89.1 KB

Wondered why there is such discrepancy. Thanks

2

Got two maps uploaded.

3

As I’ve said before, Isochrones use shortest distance, where the default used by Directions is recommended. Change your route-preference to shortest, and you’ll see less of a discrepancy. There will still be some difference, due to the creation of the polygon, rounding, slightly different algorythms etc, but the results will be much closer.

Note that shortest distance is not always the best/fastest way to go.

4

Thanks Stefan!
I am calculating the time isochrone which I am assuming based on the shortest driving time. Then I use the matrix to calculate the duration from the center to the POIs within the isochrone. For example, I calculate the 10-min time isochrone from a location. Then I calculate the driving time from the location to some POIs within the 10-min time isochrone. I found the distance may be 12 even 14 minutes. I am wondering how can I reduce the difference between these two outputs. I didn’t find parameters that I can tune the time isochrone and the matrix/duration.

5

Which is the wrong assumption. The isochrone polygon is created using the endpoints of routes that are created using shortest distance. So in order to get similar (not equal!) results from your directions, use shortest distance in your directions. If I do a quick test, I get results that are 10 minutes drive away for destinations on the edge of a 10-minute isochrone.

6

Thanks Stefan!

I see we can use shortest distance in the direction method.

Do we have the same option if I want to use the matrix method?

Thanks again.

7

RTM: https://openrouteservice.org/dev/#/api-docs/v2/directions/{profile}/post

preference (string) df.: recommended Specifies the route preference.

Options:
fastest (deprecated!)
shortest
recommended

8

For the direction method, we do have those options.

How about the matrix?
https://openrouteservice.org/dev/#/api-docs/v2/matrix/{profile}/post

Are the distance and duration outputs from the matrix based on the recommended routes by default?

Thanks

9

Please also note, that isochrones are always an approximation and are simplified by default.
You can use the smoothing parameter and set a low value to get more detailed but also more complex polygons.

10

Hey,

to expand on @amandus answer a bit:

Isochrones seem “simple” on the surface but are indeed rather tricky once you get into the nitty-gritty details.

The underlying problem is that you’re trying to generalize a route network (i.e. the network of all streets within 5 minute drive time from your starting point) to an area - the isochrone we’re looking for.
This generalization is necessary, since we can’t transfer the whole reachable network. While this might work for these small (5 minute) isochrones, this would just be huge amounts of data for larger isochrones.

As it turns out, transformation from “this is a huge number of points I’d like included” to “this is the (concave) outline best defining this number of points” is rather complicated.

A few instances of these complications can be seen above:

  • The rather shallow “bay” area east of the starting point is included in the isochrone - even though it’s water and you can’t drive on that with a car.
  • The tip of the island to the north of said “bay” area is excluded, although it is easily reachable.
  • The lake to the west is included as well, as are the railways near hoboken terminal. Neither are driveable by car. Should the isochrone contain a hole there?
  • The isochrone endpoint on the highway to the south will be reached by car within 5 minutes easily, but surrounding buildings near it won’t. Should the isochrone be a line here?

These issues can be solved by fine-tuning the isochrone, as can be done with the mentioned smoothing parameter: Setting it to 0 will result in the following isochrone:

Screenshot 2023-02-03 at 15-57-34 V2 Isochrones {Profile} Post ORS API
Screenshot 2023-02-03 at 15-57-34 V2 Isochrones {Profile} Post ORS API561×845 105 KB

As you can see, this more specific isochrone will exclude the parts in Jersey City taht can’t be reached within 5 minutes - but it will also exclude the streets near the bay area west of the starting point.

Isochrone generation can be controlled by a few parameters, but the “optimal” set of parameters is different for each location and every isochrone range - what might work for 222 Jackson Street, Hoboken, 5 min car isochrones might generate horrible results for a 1h hiking isochrone in the rockies or a 30 minute bike isochrone somewhere in the netherlands.

I hope this gives a bit of an insight,
best regards

1 Like