How We Calculate Everything

Every page on halfway.travel is generated by one build from one dataset, and this page is the contract between the two. Nothing on the site is hand-typed twice: when the drive model changes, every pair page changes with it; when a rule cell is re-verified, every page that cites it updates the same day. The machine reads 150 cities (GeoNames-derived, with coordinates and population), 663 candidate towns, a curated venue registry for the hotels-near family, and the rules seed matrix described below.

The halfway answer is a three-step computation. First, distance: the great-circle distance between the two cities, computed with the haversine formula, multiplied by a road-factor band that rises with distance — 1.22 under 80 miles, 1.10 under 250, 1.08 under 500, and 1.06 beyond — because short hops detour more in relative terms. Second, time: road miles divided by an effective speed band (40 mph under 80 road miles, 52 under 200, 60 under 450, 64 beyond), which folds in urban congestion at both ends. Third, the meeting point: the half-time point sits at the 50% fraction along the geodesic (40/60 and 60/40 alternates are computed too), and candidate towns within 40 miles of it are scored for fairness:

score = 40·(1 − detour/30) + 30·(1 − |t_a − t_b|/20) + 20·(popTier/3) + 10·(min(3, hotels)/3)

In words: low detour (up to 40 points), balanced drive times from both cities (up to 30), town size (up to 20), and lodging depth (up to 10). The top three towns are chosen with at least 15 miles between them, and the band widens to 60 miles where candidates are thin. The formula is the same on every pair page — fairness is not editorial judgment here, it is arithmetic you can check.

Honesty beats polish, so here is exactly where v1 stands. Estimated: all drive times and distances (the road-factor model above — straight-line geometry, not a routed path); all lodging counts (population-derived tiers, not a mapped inventory); the drive-or-fly and one-tank comparisons inherit those estimates. Curated seed: the hotels-near venue registry and the rules matrix (five topics, 36 — see the next section). Upgrade path: the OSRM/OSM/GeoNames batch replaces the road-factor model with routed distances and real drive-time matrices, swaps lodging counts for mapped inventory, and grows the town pool — all without changing a single page template. Until then, every page that shows a drive time labels it as an estimate, and none of these pages claims route-snapshot provenance.

The rule checkers run on data/rules/rules.json — a seed matrix with 10 car-seat states, 15 speed-limit states, 6 chain-law states, 5 pet-rule states and 9 toll systems, 168 cited cells in total. The contract for every cell: rule text of forty words or fewer, a citation with title, URL and retrieved date, an as-of stamp, and a confidence level. Medium confidence — which is every cell in this seed — renders a visible line telling you to confirm current requirements with the state authority. Where we were not confident of a rule's shape, the cell or the state was omitted, not guessed. The same JSON is exported to /data/rules/rules.json so machines and people read identical values. Full 51-jurisdiction capture with statute-level citations ships with the rules data build.

The rules matrix is on a yearly review cycle: every cell re-opened, every citation re-fetched, retrieved dates refreshed, diffs logged. This seed was reviewed 2026-08-21; the next review falls due 2027-08. The city and town registries refresh as the underlying GeoNames-derived data does, and the OSRM batch lands as its own milestone. Between cycles nothing on the site silently changes — a page is either rebuilt from data or it is not rebuilt at all.

Found a number that cannot be right? Write to hello@halfway.travel with the page URL and what you observed. Corrections that change a value ship with the next build. See also the affiliate disclosure for how this site is funded, and about for who runs it.