Documentation
How planedata.io tracks aircraft, works out where flights are going, and how you can help or use the data.
Where the data comes fromRoutes and timesEstimated positions CorridorsFlight and airport pagesFeedingFor FBOs and airports PrivacyFAQ
Where the data comes from
Aircraft broadcast their position, altitude and speed by ADS-B. Receivers on the ground pick these up and send them to planedata.io. On top of our own feeders, the map merges other networks: the OpenSky Network worldwide, and adsb.lol for selected regions. For each aircraft the freshest position wins. Where several receivers hear the same aircraft without position data, multilateration (MLAT) works out its position from the differences in arrival time.
Every aircraft’s position is recorded about once a minute and kept, which is what the history, routes and corridors are built from. Aircraft details (registration, type, operator), airlines and airports come from open reference data: tar1090-db, OurAirports and Virtual Radar Server’s standing data. All of it is free and open; nothing is bought from commercial data providers.
Routes and times
Each flight’s origin and destination is worked out in this order:
- Seen at the airport: on the ground there (a transponder switched on to depart or off after landing), or heard climbing out or on approach with the airport behind or ahead of it.
- Route set manually by planedata.io for that flight number.
- Flown before: where this flight number went on earlier flights we watched end to end, once two of them agree.
- Published route: the callsign’s route from the open route list, used only when the aircraft’s position fits it.
Takeoff and landing times are the moments the aircraft left or reached the ground, or estimated from how high and how fast it was climbing or descending when it was first or last heard. There are no commercial timetables behind this: the “usual departure time” and “usual duration” come from the flights we observed, so they get better the longer a route is watched. While a flight is in the air its expected landing blends two estimates: the distance left at its current speed (best when it’s close) and how long the flight usually takes (best when it’s far out), plus about 10 minutes for descent and approach.
Estimated positions
When a cruising aircraft leaves receiver coverage, for example over an ocean, the map keeps showing it at an estimated position. With a known destination it follows the great circle there at its last speed until it should have landed; without one it continues straight for up to two hours. Aircraft that were low or descending when last heard probably landed, so they aren’t estimated. When the aircraft is heard again, the same flight continues and the gap is drawn as a dashed line.
Corridors
Corridors show where flights actually fly, from the last 24 hours: a line along the median flight, shading over the middle 80% of flights and a dashed outline at the furthest flight on each side. Only flights that follow a corridor count, routes flown both ways are drawn once with arrows both ways, and where flights split or merge the corridors join in a Y at the point where they part. Near large airports at low altitude, where arrivals and departures fan out, no corridors are drawn.
Flight and airport pages
Flights: /flight/ASA673 (or the airline flight number, /flight/AS673) shows the
current flight with its progress and expected landing, its path on a map, its usual pattern and its previous flights.
Airports: /airport/KLAX lists arrivals with expected times, departures, recent landings and aircraft
on the ground. Everything is also available from the API.
Feeding
Anyone with an ADS-B receiver can feed planedata.io alongside the networks they already feed, with adsb.im, Ultrafeeder, readsb or mlat-client: see the feeding page, or build one from scratch with the Raspberry Pi receiver guide. Feeders get ten times the API allowance, automatically. Receivers near airports and in areas few others cover help most, because they let us see departures and arrivals, not just aircraft at cruise. Where we need feeders most.
For FBOs and airports
A receiver on an FBO’s roof covers your airport down to the ground, which is exactly where community coverage is thinnest. What you get in return, free:
- An arrivals board for your airport with expected landing times for inbound aircraft, ready to put on a
screen in the lobby or on your website (
/airport/YOURCODE?embed=1). - Expected arrivals through the API for your own tools: line service and fuel planning, crew pickup, hangar space.
- Movement history: which aircraft came and went, when, and how often, from your own airport’s data.
- Your own receiver’s map and statistics, plus a higher API allowance.
The setup is a Raspberry Pi, an SDR dongle and an antenna with a clear view of the sky (around US$100 to $150 in parts), running the free adsb.im image. If you’d like help getting one running, contact planedata.io.
Privacy
Feeders: the contributors page shows your MLAT name and your area rounded to about 10 km, or nothing at all if you choose privacy. Your IP address, exact location and receiver ID are never shown to anyone else.
FAQ
Why is an aircraft missing?
No receiver near it heard it recently. Coverage is best around feeders and thin over oceans and remote areas.
Why does a flight show “?” for its origin or destination?
It was first or last heard too far from any airport to tell, and its flight number has no history or published route yet.
How accurate is the expected landing time?
Usually within 10 to 20 minutes far out, better in the last half hour. Holding, delays and diversions aren’t known in advance.