graphhopper / graphhopper/graphhopper
Inaccurate Isochrones/SPT's when intersections are sparse
- Dominant language
- Java
- Stars
- 6.7k
- Forks
- 2k
- Avg merge
- 15h 58m
- Merged PRs (30d)
- 3
Description
**Describe the bug**
One use-case of GH is to create isochrones to show how far one can get, in this case, how far one can get walking from a bus stop. However, these isochrones and SPT's can be fairly imprecise for situations where the time or distance limit is short and the road network is sparse (ie. few intersections like in rural or suburban areas).
**To Reproduce**
- Create an isochrone or SPT on a road where there are no intersections within the time/distance limit.
Figure 1 - distance_limit=1100m, profile=foot
Figure 2 - distance_limit=1150m, profile=foot
- Alternatively, create an isochrone or SPT on a road where there are few intersections within the time/distance limit (Figures 3 and 4).
Figure 3 - distance_limit=400, profile=foot
Figure 4 - distance_limit=400, origin moved very slightly to the west; profile=foot.
Note that the isochrones above are shown exactly as returned by GH, and aren't processed by any other tools.
**Expected behavior**
Tracing through from the origin to the end of each line in the SPT gives you the distance_limit, which would be similar to what you'd get when making a Service Area in ArcMap.
**System Information**
GH 3.2
**Approach to Resolve**
Having looked through the codebase I'm looking for some guidance into what would be required to resolve this issue.
One possible approach I was thinking of is, after having generated the edges in the SPT, extend them along the road away from the origin until the exact distance/time limit is reached. If this ends up degrading performance then making it optional could work for turning it into a PR.
Thanks!
Contributor guide
Assessment
This issue has not been assessed yet.