OSM Tools Isochrones (distance based) appear incorrect


#1

Im using the Isochrone tool in ORS tools and am selecting a location on a road to report a distance based boundary using walking namely 400m, 1000m and 2000m distances. However in one direction the 400m stops at a manual measured 286m, yet in the other direction the measurement could be 800m plus.


#2

Hi,

which exact isochrone does produce these results (400, 1000, 2000)? If it’s the 400 m one that’d be weird, but could still happen.

Generally it’s not impossible, it depends on the road network surrounding that point. If in one direction it’s a lot sparser, it makes sense that the isochrone returns less distance to be covered on that side.

As always, example request is the best thing. Just copy the URL from the text box in the ORS Tools’ main window (or find the request in the QGIS logs, there’s a ORS Tools logger logging all request URLs).


#3

Hi Nils, i checked the 400m manually - whilst there may be some nuances in the routing this looks fairly straightforward yet there seems such a difference. You will see the point is my origin the distance to the north is much less than the distance to the east.

processing.run(“ORS Tools:isochrones”, {‘INPUT_PROVIDER’:0,‘INPUT_POINT’:None,‘INPUT_POINT_LAYER’:‘XXXXXXXX\Calculations\gis\Site access location.gpkg|layername=Site access location’,‘INPUT_FIELD’:None,‘INPUT_PROFILE’:7,‘INPUT_METRIC’:1,‘INPUT_RANGES’:‘400’,‘OUTPUT’:‘XXXXXXXXXX/Calculations/gis/400m walking.shp’})


#4

There’ll be a fix for very short isochrones shortly (in 1-2 weeks live on our servers). The only thing that might not be entirely proper here is the lower left dent, where most of an alleged street is not covered.

However, even here, you should check if that’s not private property down left (looks like a logistics company or car park). Then you can’t access that whole part and the isochrone would atually be fairly correct.


#5

Thanks Nils, what caused me concern was the route immediately north which measured about 280m, and then the long finger to the east which was around 800 m from the point. I dont believe there are any rights of way that could shorten this. Excuse the freehand lines, butthis seemed the easiest way to indicate what I meant


#6

Yeah sorry, now I see what you mean.

@adam any idea? If distance is used as range_type, it should look like this I think.

Can you please paste the request URL? The easiest is if you do it From Map Point on that particular point in the Processing dialog and copy the last log line in the ORS Tools Log (View > Panels > Log Messages).


#7

Hopefully this is correct :slight_smile:

2019-05-09T08:37:39 INFO url: https://api.openrouteservice.org/isochrones?attributes=total_pop&id=1&locations=-1.178764%2C53.582161&profile=foot-walking&range=400&range_type=distance
Parameters: None


#8

Yes, it its:) Thx!

We’ll look into it, pinging @adam.


#9

OK, so it seems this is actually a very complicated issue with how the underlying routing handles the start points of calculations that are in the middle of a length of road. Simply put, it has to snap the starting point to the the closest “junction” that it finds, in this particular case it is the the junction to the south of the starting point. Measuring from that point up to the northernmost boundary is then the 400m.

For the part that is too far away (the 800m part), that is due to both the issue above and another inaccuracy in the calculation. I am in the process of doing a fix for that inaccuracy which should then make them a bit more accurate, but for the first problem I will need a bit to look into if there is a way around it.