Great-circle distance and the route map

Open a schedule and you can see, on every leg, exactly which two airports it connects. What you cannot see is where those airports are — or how far it is between them. SSIM gives you the city pair as a pair of codes and stops there. If you want to draw the network on a map, or estimate a stage length, you supply the geography yourself and compute the distance. This post is about that missing half, and about the right way to measure the gap: the great-circle distance.

What the file knows and what it doesn’t

An SSIM flight leg carries a board point and an off point — the origin and destination airports — as three-letter codes. SYD. LAX. LHR. That’s the extent of the geography. The file does not carry latitude and longitude, and it does not carry distance. There is no field for either, in any record type.

This is by design, not omission. SSIM is a schedule-exchange format; its job is to say who flies where and when, not to be a gazetteer. Everyone reading the file is assumed to already know that SYD is Sydney and where Sydney is. The codes are keys into a reference you’re expected to hold separately.

SSIM tells you the what — the city pair. It never tells you the where. The coordinates live in your reference data, not the schedule.

Bring your own geography

So the first step to putting a schedule on a map is joining it to a table of airport coordinates: for each code, a latitude and longitude (and usually a name, city, and country). That reference is public and stable — airport locations don’t move — and it’s the same “bring your own reference data” pattern that turns seats and frequency into capacity you can compare. The schedule identifies the places; your geography says where they are.

Once every board and off point resolves to a coordinate, two things become possible: you can plot the airports on a map and draw the routes between them, and you can compute how far apart any two of them are. Both need the same input, and both need you to measure distance the right way.

Why straight-line distance is wrong

Here’s the trap. Give a computer two coordinates and the naïve thing to do is measure the straight-line distance between them — the flat, ruler-on-a-map distance. On a small scale that’s fine. Across a network it’s wrong, and increasingly wrong the longer the route, for one reason: the Earth is a sphere, and a flat map isn’t.

Every map projection distorts something. A straight line drawn on a flat map is not the shortest path between two points on the globe, and its length is not the real distance. The classic example is a long-haul route that, on a Mercator map, looks like it should bow far north — because the actual shortest path curves over the pole while the map flattens it out. Measure that route with a ruler on the flat map and you get a number that doesn’t match what the aircraft actually flies.

The correct measure is the great-circle distance: the length of the shortest path between two points over the surface of the sphere.

The great-circle idea, in words

Picture a globe and two airports on its surface. Slice the globe with a flat plane that passes through both airports and through the centre of the Earth. Where that plane cuts the surface, it traces a circle — and because the plane runs through the centre, it’s the largest circle you can draw on the sphere: a great circle. The shorter arc of that circle, between your two airports, is the shortest possible path along the surface. Its length is the great-circle distance.

You compute it from the two latitude/longitude pairs and the Earth’s radius. The standard formula is the haversine — a bit of spherical trigonometry that takes the differences in latitude and longitude and returns the arc length along the surface. You don’t need to memorise it; you need to know that it exists, that it’s what “distance between two airports” should mean, and that it takes coordinates as input — coordinates the schedule doesn’t have.

Two caveats worth stating plainly. A great-circle distance is the ideal shortest path, not the exact routing an aircraft flies — real tracks bend around airspace, weather, and airways. And it assumes a perfect sphere; the Earth is very slightly flattened, so great-circle figures are excellent estimates rather than survey-grade truth. For network mapping and stage-length estimation, that precision is exactly right.

An offline map

A pleasant consequence of “bring your own geography” is that the whole thing works with no network at all. Airport coordinates are a fixed, modest reference table — small enough to ship with an application. Once the geography is bundled, plotting a schedule on a real map and computing every great-circle distance is pure local computation: no map tiles to fetch, no geocoding service to call, nothing about your commercial schedule leaving the machine. Keeping sensitive schedule data close and having a working map aren’t in tension.

Where SSIM Toolkit fits

SSIM Toolkit’s geographic route map takes exactly this approach. It resolves each board and off point to a latitude and longitude from bundled reference geography, plots the airports where they actually are, and draws the network between them — computing great-circle distances so a stage length or a route arc is measured over the sphere, not across a flat projection. Because the geography is bundled, the map works locally, on your own machine, on your own files.

The schedule names the city pair. The map is what you get when you bring the where — and measure the distance the way the planet actually curves. More on the Toolkit at /product/ssim-toolkit.