Round-trip routing improvements

Published 2026-10-21

I've finally had a bit more time to resume some work on Trail Router. AI has also been a huge accelerant. You can see from the release notes that in the past few months we have:

• Automated a monthly import of OpenStreetMap data, ensuring that our routing data stays fresh
• Improved the 'Avoid Repetition' feature, so that it considers nearby paths as repetition too
• Made some major improvements to the turn-by-turn navigation feature (disabled by default; you can enable it in the settings screen)
• Released updates to the iOS, Android and web apps, fixing so many bugs and small annoyances
• Released some significant improvements to the round-trip routing feature

The focus of this blog post is on the last item: round-trip routing improvements.

Background to round-trip routing

Round-trip routing was the reason that Trail Router was created. I needed a simple way to find a running route that started and finished where I was, and was approximately X kilometers long. This is why round-trip routes are automatically generated for you when you open Trail Router.

The existing approach to generating round-trip routes is documented in How Trail Router works and can be boiled down to the following:

1. Given a user's start location and desired distance, find 'green features' nearby (parks, lakes, hiking trails, etc), and try to generate routes to/around them.
2. If there are no green features nearby, then fall back to the 'guesswork approach'. This involves choosing arbitrary points around the user's location, and then routing to/from these, and hoping for the best.

Both of these are essentially brute-force, and can result in (a) routes that are far too long or far too short and (b) complex routes, with overlapping route lines ('self-intersection') and annoying little out-and-back sections.

Enhancements to the approach

The existing approach remains at the core of the algorithm, so you'll continue to see routes that follow green features when they are available. But there have been a few key changes.

Firstly, if there's a large green feature (e.g. a park), then we take into account the internal layout of paths within that park before constructing our route. Previously, we'd pick points around the perimeter of the park, and then blindly route between those. But this could lead to annoying little out-and-backs and strange loops. By considering the layout of the paths directly in the algorithm, we can better avoid these annoyances and generate less complex routes.

Building on the above, we also now use knowledge of the park's internal layout to generate loops within the park itself, rather than always sticking to the perimeter. This is particularly useful for shorter distance runs (e.g. 5km) in city areas, where one or two parks might be the only green options available to you.

Lastly, we can now get much closer to the user's target distance. This has been achieved by 'repairing' routes that are too short or too long, and again uses knowledge of the path layout to achieve this.

Results

If you ask for a route of 10km, you are now much more likely to get a route close to 10km. 89% of requests are now within 10% of the requested distance, up from 72%.

Distance accuracy	Before	After
Within ±5% of target	52.3%	68.0%
Within ±10% of target	72.5%	89.3%
Within ±15% of target	87.2%	100.0%

Route complexity has also improved massively. The primary measure I use for this is whether the route line crosses over itself ('self-intersection'); I find these difficult to follow, as it's unclear which direction I should go. 94% of routes do not self-intersect now, up from 27%.

Route complexity	Before	After
Routes with no self-intersections	27.5%	94.5%

The above results are based on the top three routes returned for 150 starting locations selected randomly around the UK, spread across target distances ranging from 2km to 30km.

One significant downside of this new approach is that it is a lot more computationally expensive. Request times are roughly 50% higher than before, but I think the results are worth it.

Examples

A picture is worth a thousand words, so here are a few examples:

Feedback

If you have feedback, I'd love to hear from you. Contact me at sam@trailrouter.com.