Where the data comes from
Thway relies on geographic and accommodation data to plan multi-day hiking routes. Transparency matters to us: when you trust a tool to shape your itinerary, you deserve to know where the underlying information comes from and how we process it.
Below is an overview of our three core data layers, the methodology behind our routing algorithm, and how we work to keep everything accurate and up to date.
Hiking route geometry is sourced from OpenStreetMap, where long-distance trails are mapped as relations with waymarked route data. Each route is divided into segments with connection points, allowing flexible multi-segment route building.
We extract trail geometries from OSM relations and process them into a graph of segments and vertices. In Denmark, this covers trails like the Hærvejen and other nationally waymarked routes. As we expand to other regions, we follow the same approach: pull the official trail relations from OSM and build our segment graph on top of them.
Every trail is broken into segments at natural junction points: where paths cross, where a village offers services, or where a route branches. This segmentation is what allows you to build custom itineraries. You choose which segments to walk, and the planner handles the rest.
Stay data comes from multiple sources. In Denmark, commercial accommodation (hotels, B&Bs, hostels) is sourced from the Danish Central Business Register (CVR), while shelters, huts, camping sites, tent pitches, and wild camping areas come from Denmark's geographic database (GeoFA). We also incorporate data from OpenStreetMap where available.
Finding a place to sleep is often the hardest part of planning a multi-day hike. Our accommodation database is designed to cover the full spectrum: from commercial hotels and rural guesthouses to primitive shelters and designated wild camping areas. Each listing includes its type, approximate location, and how far it sits from the trail.
We are especially attentive to shelters and free-to-use facilities that don't appear in commercial booking platforms. Many long-distance hikers rely on these, and we believe a planner that ignores them is missing half the picture. We always recommend verifying availability and conditions directly before you set out, as these can change with the season.
Routing between trail points and accommodation uses a road network derived from OpenStreetMap. We apply weighted distance calculations that prefer footpaths and hiking trails over roads.
When you finish a day's walk and head to your accommodation, the route between the trail and your stay matters. We don't just measure straight-line distance. We calculate actual walking routes using the surrounding road and path network. Footpaths and unpaved trails receive lower weights than asphalt roads, so the algorithm naturally prefers the paths a hiker would choose.
This network also underpins our daily distance calculations. The distance shown for each candidate stay is the real walking distance along paths, not a rough approximation. For hikers planning around physical limits or daylight hours, that precision makes a meaningful difference.
methodology
Our routing algorithm uses Dijkstra shortest-path calculations on the road network to find the optimal route between your current position and candidate stays. Each day, we search for accommodation within a configurable radius of your ideal daily walking distance and rank candidates by closeness to your target.
The generation process is interactive and deterministic. When you start a route, the algorithm computes the first day’s candidates based on your starting point and preferred daily distance. You pick the stay that suits you, and the algorithm advances to the next day, using your chosen stay as the new starting point. This cycle repeats until the route is complete.
Because each day depends on your previous choice, the algorithm is inherently sequential, but that is by design. It mirrors the way hikers actually think: one day at a time, each decision shaping the next. If you change your mind about a previous day, you can go back and pick a different stay, and the remaining days recalculate automatically.
Behind the scenes, we maintain session state in temporary database tables that are scoped to your planning session. This means the algorithm can efficiently query for candidates without scanning the entire dataset each time. When you finish or abandon a session, the temporary data is cleaned up automatically.
data updates
Trail networks and accommodation don’t stand still. Paths get rerouted, shelters close for renovation, new guesthouses open along popular corridors. We periodically re-import data from our sources to capture these changes.
For OpenStreetMap-derived data (trails and road network), we re-extract from updated OSM exports. For government data sources like CVR and GeoFA, we re-import when new versions become available. Manual corrections, often prompted by hiker reports, are applied as they come in.
There may be a lag between a real-world change and its appearance in the planner. If you spot something outdated, please let us know via the contact page.
data accuracy & limitations
We work to keep data current and accurate, but trail conditions, accommodation availability, and opening hours can change without notice. Always verify critical details (especially for remote shelters and seasonal accommodation) before your hike.
Some specific limitations to be aware of: distance calculations are based on the road and path network in our database, which may not account for very recent reroutes or temporary closures. Accommodation listings reflect the best information we have, but we cannot guarantee availability or pricing. Primitive shelters in particular may have no formal booking system, and conditions can vary with the season.
We see data quality as an ongoing commitment, not a one-time achievement. Every hiker who reports an issue helps us improve the database for everyone who comes next. If something looks wrong, trust your instincts, and then tell us about it.