Methodology

Every calculation on SimpleMapLab — the radius tools, the drive-time map, the location-detection tools, and the open-data studies — runs on a fixed set of algorithms and public datasets. This page documents all of them. If you're evaluating our results for accuracy, building on our methodology, or pitching a study to your editor, this is the reference.

1. Distance and great-circle math

Tools relying on point-to-point distance — the Distance Between Two Placestool, every radius-based tool, every "find the nearest X" computation in our studies — use the haversine formula, the standard great-circle distance approximation on a sphere of radius R ≈ 3,958.76 statute miles (equivalent to the WGS84 mean radius of 6,371,008.8 m).

The haversine formula is:

a = sin²(Δlat/2) + cos(lat₁)·cos(lat₂)·sin²(Δlng/2)
d = 2·R·arcsin(√a)

For distances under 1,000 mi the error against the WGS84 ellipsoid is < 0.3%; under 10,000 mi the error never exceeds 0.5%. We deliberately do not use Vincenty's formulae or the geodesic on the ellipsoid because the marginal accuracy gain doesn't affect any of our findings beyond the third significant digit, and the haversine version is reproducible from a calculator.

2. Geodesic radius circles

The Map Radius Tool and the empty-zone rings in the Most Remote Places study use d3-geo's geoCircle() generator — a true geodesic disk on the sphere, not a flat-map circle in Mercator pixel space. The output is a 64-vertex polygon (configurable up to 360) computed by stepping at equal angular intervals around the centre using the haversine forward formula.

At any latitude, every vertex sits exactly the specified radius from the centre along the great-circle arc. When the polygon is then projected (Mercator, Albers, etc.), it appears distorted in pixel space — elongated north–south near the poles, near-circular near the equator. The underlying geometry is correct in both cases.

3. Drive-time isochrones (Valhalla)

The Drive Time Map queries the publicly hosted Valhalla routing engine at FOSSGIS e.V. Valhalla expands a Dijkstra-style frontier from the origin along the OpenStreetMap road graph; each road segment carries a cost (in seconds) based on functional class, default speed limit, and length. Turns add a penalty (left turns across traffic are more expensive than right turns). When the cumulative cost on a branch exceeds the requested duration (15 / 30 / 60 / 90 min), expansion stops. The reachable endpoints are then connected into a smoothed polygon.

Speed assumptions by road class

Live traffic is not modelled. Results represent free-flow conditions. For congested urban areas the actual drive time will exceed the isochrone estimate; for rural cross-country drives the estimate is usually within 5–10%.

4. Polygon area

The Map Area Calculator uses Turf.js's geodesic-area function, which integrates over the WGS84 ellipsoid. For radius circles, area is also computed as A = π·r² on the sphere as a cross-check; the two methods agree to within 0.1% for any radius up to ~3,000 mi.

The Population Within Radius tool uses a faster shoelace approximation with a cos(lat) correction. Accuracy is within 1% for areas under 100,000 sq mi at mid-latitudes — enough for population estimates rounded to the nearest thousand.

5. Point-in-polygon location detection

The location-detection tools — What County Am I In?, What State Am I In?, What ZIP Code Am I In?, Coordinates to City — use a ray-casting point-in-polygon algorithm against US Census Bureau TIGER/Line boundary data, loaded as TopoJSON and decoded to GeoJSON features in your browser. A horizontal ray is cast from the test point and the number of polygon edge crossings is counted; an odd number means the point is inside. Runtime is microseconds on a modern device.

6. Geocoding (address ↔ coordinates)

• Forward (address → coordinates): Photon — a typo-tolerant autocomplete service built on the OpenStreetMap address tree.
• Reverse (coordinates → address): Nominatim — the canonical OSM reverse-geocoder, returning structured city / county / state / country / postal code components.

Both services are queried in real time from your browser. We do not proxy or cache the requests on our servers, so your search terms are visible only to Photon / Nominatim, per their respective privacy policies. Neither service requires an API key for the request volumes our tools generate.

7. Elevation

The Elevation Finder calls the Open-Meteo Elevation API, which returns altitude from the Copernicus 30-meter Digital Elevation Model (DEM). The Copernicus DEM is satellite-derived (TanDEM-X interferometry) and is the current global standard for medium-resolution elevation. Atmospheric pressure at altitude is computed using the International Standard Atmosphere barometric formula:

P = P₀ · (1 − L·h / T₀)^(g·M / R·L)

with L = 0.0065 K/m (lapse rate), T₀ = 288.15 K, g = 9.80665 m/s², M = 0.0289644 kg/mol, R = 8.31447 J/(mol·K).

8. Time zones

The Time Zone Finder resolves any lat/lng to its IANA time-zone identifier using the geo-tz library with polygon data from timezone-boundary-builder. Daylight-savings detection compares the January and July UTC offsets via the JavaScript Intl.DateTimeFormat API.

9. Blank map rendering

Printable maps in the blank-maps library are generated from TopoJSON via d3-geo projections:

• US states: per-state geoMercator fitted to each state's bounds; national map uses geoAlbersUsa with AK/HI insets
• Countries: geoMercator with auto-cropped viewBox fitted tightly to each country's bounding box
• Continents and world: geoMercator with fixed continental bboxes; the world map uses geoEqualEarth for accurate global representation

PNG and PDF exports are generated client-side: PNG via HTML Canvas at 2,400 px resolution, PDF via jsPDF. The files are downloaded directly from your browser — nothing is uploaded to a server.

10. Study methodology — Most Remote Places

The Loneliest Towns in America study aggregates the SimpleMaps uszipsdataset (Census 2020 ACS, ~41,000 ZCTAs) by postal city + state. Any (postal city, state) pair with summed population ≥ 50 is a candidate "town." Any place with summed population ≥ 10,000 is an "anchor city." For every candidate, we compute the haversine distance to every anchor (a brute-force ~117 million calls, ~2.5 minutes on a modern laptop) and keep the top-5 nearest. Rankings are descending by the distance to the nearest anchor.

Two parallel rankings are published: a lower-48-only ranking (which produces the press-friendly headline — "the loneliest town in the contiguous US is X") and an all-50 ranking (where Alaska's bush villages dominate). Per-state breakdowns are computed independently within each state. Limitations: haversine straight-line distance is used, not driving distance; the 50-resident population floor excludes fire-watch posts and seasonal camps but may also exclude a handful of legitimate very-small towns.

11. Study methodology — State Capital Radius

The 100-Mile Radius Around Every US State Capital study takes the lat/lng of each state capitol building (USGS GNIS records), draws a 100-mile geodesic circle around it, and tests every state ZIP code centroid against that circle. ZIPs inside the circle contribute their population to the "captured" total; ZIPs outside don't. The captured share is reported against the state's Census-estimated population. Largest-city-outside-the-radius is computed by aggregating ZIPs by postal city and ranking the cities whose centroid is outside the circle.

The state's population-weighted centroid is also computed (sum of zip.lat × zip.pop / sum of zip.pop) so the capital-to-pop-centroid distance can be reported. This is the cleanest single measure of how "misplaced" a capital is.

12. What we don't do

• We don't scrape protected sites. Every data source is either explicitly licensed (CC-BY, ODbL, MIT, public domain) or a published official dataset.
• We don't fabricate numbers. If a value isn't reproducible from a source we cite, it doesn't go on the site.
• We don't use AI to invent data. Long-form prose is drafted with AI assistance (see Editorial Policy) but every number, place name, and dataset row comes from a published source via a deterministic script. AI is not in the data path.
• We don't round secretly. If a number is shown to one decimal place, the underlying calculation is at full precision and the rounding is for display only. The JSON / CSV downloads carry the full precision.
• We don't mix study scopes. Each study clearly states whether it covers the 50 states only, the 50 states + DC, the lower 48, or includes territories. Boundaries are not silently extended.

13. Data sources, licences, refresh cadence

14. Study output licensing

SimpleMapLab's original study datasets — the per-state JSON and CSV files attached to each study — are published under a Creative Commons Attribution 4.0 International (CC-BY 4.0) licence. You may reproduce, remix, adapt, and build upon them for any purpose, including commercial, as long as you give appropriate credit. Standard attribution:

SimpleMapLab (2026). [Study Title]. Retrieved from [Study URL].

The blank maps in the blank-maps library are public domain — no attribution required, free for commercial and non-commercial use.

15. Accuracy bounds and known limitations

We try to be specific about where each calculation is accurate and where it isn't. The key bounds:

• Distance: haversine error vs. true geodesic < 0.5% at any distance. Within bounded.
• Drive time: 5–10% under-estimate in free-flow rural conditions; can be 30–60% under-estimate in congested urban areas (no live traffic modelling).
• Population in a radius: ZIP-centroid aggregation — accurate to within 1–3% for radii ≥ 10 mi. For very small radii (< 5 mi) the granularity of ZIP centroids creates substantial noise; the tool warns users in that regime.
• Elevation: Copernicus 30 m DEM is ±2 m vertical accuracy in flat terrain, ±5–10 m in steep terrain.
• Reverse geocoding: Nominatim correctness is high in well-mapped regions (urban US, EU); spotty in rural areas of less-mapped countries.
• Postal-city aggregation in studies: Some Census incorporated places share postal city names with neighbouring unincorporated areas, leading to occasionally surprising aggregations (e.g., a single postal city name may span two adjacent counties). We've chosen postal-city aggregation because it matches how Americans refer to where they live.

16. Reproducing our results

For each study, the analytical pipeline is a single TypeScript script in our repository. You can run these scripts locally — they read the public source CSVs (Census uszips, USGS GNIS coordinates) and write a JSON output identical to the one we publish:

• scripts/compute-state-capital-radius.ts — the State Capital Radius study
• scripts/compute-most-remote-places.ts — the Most Remote Places study

If you reproduce a study and get different numbers, please let us know — either we have a bug worth fixing or your replication uncovered a methodology question worth explaining better.

17. Corrections

Errors are inevitable in any project that processes 41,000+ ZIPs against multiple datasets. When we find one — or you report one — we fix the underlying data or formula, rebuild the affected pages, and note the correction inline on the page itself (an "Updated: corrected X on Y" line is added to the page footer). Significant corrections (e.g., a ranking change of more than two positions, a headline number changing by > 10%) are also noted in a public changelog and emailed to anyone who has cited the affected number to a publication.

To report a possible error: email hello@simplemaplab.comwith "Correction:" in the subject line, the page URL, the value you believe is wrong, and your source if you have one. We respond within 1–3 business days and publish fixes within 48 hours of confirmation.

Questions

Anything that should be in this methodology but isn't — a calculation you can't reproduce, a source you think we should disclose, a limitation you think we're hiding — tell us.

Methodology page last reviewed: 14 May 2026. Maintained by the SimpleMapLab team.