Hi all,
I was looking at an isochrone for a particular park and I noticed it excludes a large part of “Roebourne Crescent” which is definitely within the 1km. First thought was to check the underlying OSM data but it looks correct there. Any ideas as to why it would skip this section of the road? See link below for isochrone in question, you will notice Roebourne Crescent just to the east of the park is missed by the isochrone.
This is a graphical issue due to the detailing of the outline.
If you have an API key and query it via the api, you can use the smoothing factor and try again, e.g.
...,"smoothing":0.1
Hi Hendrik,
Thanks for your reply - I tried it via the api with smoothing as 0.1 but still get the same result using the below
{“locations”:[[144.961050,-37.687427]],“range”:[500,1000],“range_type”:“distance”,“smoothing”:0.1,“area_units”:“m”,“units”:“m”}
Interestingly for the result from the api call with smoothing as 0.1, the starting point is not within either the 500m or 1000m isochrone.
From what I have seen in the past, I think this is because of how the algorithm works in looping over the roads. In the case of Roebourne Crescent, as it loops around onto the other road it is always seen as being reachable in the distance/time frame and so no “edge” vertices are created on it for the isochrones. But then because the isochrone distance is so small (generally I would not recommend such small distances for isochrones) when the polygon is created using points that are marked as the boundary in time/distance or as a dead end, the polygon would cut across the area (notice that two of the points are at dead ends) that would be reachable. Normally (with bigger distances) there would be a point on Bolinda Road or similar which would in effect “fix” the problem as that would extend the polygon out more. The method of using the smoothing factor is the correct approach I believe, but because of how small the isochrones are, I think it simply doesn’t have enough points to be able to smooth properly.
Ultimately I think that the problem is a combination of the small isochrones and the loop of the road, so it’s two sub-optimal things coming together and then producing the result which is partially incorrect as the internal algorithms for generating the boundary points of the isochrones and for smoothing the resulting polygon were not designed to take into account these particular cases at this scale.
Hi Adam,
Thanks for the detailed explanation about why this is happening and using larger distances for the isochrones, I will certainly keep that in mind for actual analysis.
I continued to play around with this example before getting your reply and I’m wondering if this shows something is wrong in the data. In the example below with the starting point on Roebourne Crescent, it looks like it is snapping my starting point to near the yellow dot I drew at the intersection of Cheviot and Roebourne. Shouldn’t the 50m isochrone be near my starting point and not roughly 220 metres away? (I only used such a small distance to see if it would draw an area on Roebourne or not). If say I was doing a 2000m isochrone, the result would be 10% further south west than it really should be.
Thanks again for your replies, they are really helpful for me as I’m just starting to use the service so I’m learning things like not using small isochrones as I go.
That’s really strange, as the node is definitely a part of both ways…
There is also no restriction tag on them…
@HendrikLeuschner @andrzej, any idea why it wouldn’t snap to the closest road but to the next?
The road (Roebourne Crescent) still seems to be used for the generation of the isochrones…
no idea
The snapping to the yellow point is because (I believe from what I have seen before) the isochrones algorithm needs to attach to an existing node (normally a junction in the road) on the network. In this case, the closest node on the edge closest to the point specified is the one represented by the yellow point. When routing, the algorithms can create a virtual node, whereas with the isochrones the algorithm can’t.
