Routes.aero
I built a great-circle route planner on a live 3D globe, solo, so anyone can draw a leg, see true distances, and export maps worth sharing. A native iOS companion is on the way.
Open the planner →What's missing today
I like looking at how the world connects by air: great-circle routes, the reach of a single hub, the shape of an airline's network. But there's no good way to just see it. The options are rough: heavyweight GIS software, antiquated calculators that haven't changed in years, or a map buried in a flight-search funnel whose real job is selling you a ticket, a hotel, and a credit card.
The few purpose-built tools are narrow and unreliable. They work until they don't: units get fuzzy (nautical miles versus frequent-flyer "miles"), polar routes look wrong even when the math is right, and range, ETOPS, and power features live somewhere else and are hard to make sense of. For a passionate enthusiast, there just isn't much built for the job.
That's where Routes.aero starts: one modern, map-first place to draw a route, see true distances, and actually understand the aviation world around it. Type JFK-LHR, see the route. No signup wall, no upsell, just the map.
Building something different
I'm a geographer, and I love data. I also love GCMap: it's an institution, and it's helped millions draw a line between two airports. But it is what it is, a quick answer and a static map that stopped growing years ago, never meant to become a place to explore the data behind a route.
I didn't want a missing feature. I wanted a different product: one built to display flight data, with a rich API underneath that other things could tap into. So I built it at routes.aero, in public, honest about the hard parts like polar routes on a 3D globe, with room to grow into trip stories, airline Networks, and richer data over time.
What I shipped
Routes.aero is a map-first planner. The homepage invites you in with a live globe; the core experience lives in the planner, where the map stays central and the chrome stays out of the way.
Getting routes on the map. A command bar accepts the shorthand the community already uses: EWR-SIN, multi-leg trips, comma-separated airport lists for markers. Hit Draw and the app calls a planning API backed by shared geodesy in a TypeScript core package, the same great-circle logic whether you're on the web or, soon, native iOS. Airport suggestions help you finish a code without leaving the keyboard.
Seeing the world your way. You can work on an interactive Mapbox globe or flat Mercator, both live and pannable, then switch to static projection modes (Equal Earth and other export-friendly layouts) when you want a poster-style map. I spent real time on the unglamorous cases: when a route crosses the pole, the globe can't draw a perfect line through the Arctic, and the product says so, with a clear nudge to a flat or projection view. Distances in the sidebar stay correct even when the display geometry gaps.
Going deeper without dumbing it down. A glass sidebar groups the serious work into five focused tools, so depth is a click away instead of buried in menus.
Around the planner, Stories are long-form trip writeups, and Networks is an early look at browsing airline route libraries on a flat map, the first step toward the data-richer vision.
On iOS, RoutesAero is in development on MapKit: same plan API, native globe and flat maps, adaptive layout for phone and iPad. Web stays the reference; mobile catches up on feel, not on math.
Outcomes
routes.aero is live. Real deploys, real URLs you can send someone, real exports in Slack threads and trip reports. I ship from a monorepo on main; when a polar-route fix lands, it's because I needed it in the product, not because a ticket queue said so.
What's still growing, honestly:
- Networks and live airline schedule data (provider evaluations in progress, no overclaiming yet).
- iOS TestFlight and an App Store path for RoutesAero.
- Analytics in the sense I care about as a geographer: less pageviews, more "what does this network look like?" over time.
I didn't have a team of ten or a six-month enterprise mandate. I had a problem I felt in my own planning, a stack I could ship on, and the bias to put something in front of users early. Routes.aero is the 0→1. The data story is the 1→N.
How it’s built
Routes.aero is a pnpm monorepo: a Vite/React web app, a small Hono API, and a shared core package for itinerary parsing, airport indexing, and great-circle planning. The web client is a single-page app covering the marketing home, the planner, trip stories, and a lazy-loaded Networks viewer.
Planning path. The browser sends an itinerary to the plan API, with a local fallback when you're developing offline. The API returns structured PlanData: legs with distance, initial track, and timing; route summaries; optional range polygons from power-user syntax. That response drives both Mapbox layers (interactive globe and Mercator) and an SVG world map used for projection views and export-friendly geometry.
Map engines. I rent the interactive globe from Mapbox GL for speed and quality I wouldn't match solo. I own the projection and export path: d3-geo layouts, themes, and letterboxed export presets. Globe route lines get extra preprocessing (polar gap splitting, antimeridian handling) so the app doesn't pretend the renderer can draw impossible geometry; the numbers always come from the plan, not the tessellated line.
Data on the client. Thousands of airports ship in a bundled index for fast, offline-friendly autocomplete, with API enrichment when needed. Networks catalogs are static GeoJSON snapshots for now, deliberately simple until the provider story matures.
Ship pipeline. GitHub Actions build the web app and API; production runs on Cloudflare, static assets plus a worker-hosted API. The planner deep-links its state in the URL, so shares are just links. iOS reuses the same plan contract with MapKit handling rendering: same math, native feel, two clients and one core truth.