Skip to content
RadarWorks

Open data

Where the flights come from

The real-world schedules RadarWorks builds for an airport are recorded flights: aircraft that really took off and landed there, picked up by the ADS-B receivers of a volunteer network. This page says where that data comes from, under which licence, and exactly how RadarWorks turns it into a schedule.

The source: adsb.lol

adsb.lol collects the ADS-B and MLAT positions its feeders receive and publishes every day of them as open data in the adsblol/globe_history repositories, under the Open Database License (ODbL) 1.0. Its feeders contribute their data under CC0.

Contains information from adsb.lol, which is made available here under the Open Database License (ODbL). Flight data: adsb.lol contributors.

What RadarWorks derives, and its licence

Each night RadarWorks reads the previous day’s release once and keeps only airport movements: which aircraft (its transponder address, registration and type), under which callsign, took off from or landed at which airport, when, and the airport at the other end where it is known. adsb.lol’s positions are read and discarded; they are not stored or passed on.

That database of movements is a derivative of adsb.lol’s, and the schedules served from it are produced from it. Both are made available under the Open Database License 1.0. Every day the service sends carries the attribution Flight data: adsb.lol contributors (ODbL 1.0) and the licence.

How the movements are derived

  1. Each aircraft’s day of positions is split into flights at gaps of 30 minutes or more, at readsb’s new-leg marker, and wherever it stood on the ground between two flights.
  2. Each end of a flight is matched to an airport. If the aircraft was seen on the ground, that end is the airport it stood at, within a few kilometres depending on the airport’s size. Otherwise it is the first or last airborne position when that position was low and close: below 2,500 ft above the airport and within 8 km, or projected onto it within six minutes by its climb or descent rate, speed and track.
  3. Takeoff and landing times are extrapolated from the first and last airborne positions by the climb or descent rate.
  4. An aircraft first or last seen farther out (up to 12,000 ft above the airport) gives only candidates: airports with airline service it is clearly climbing away from (or descending towards), heading the right way and within the distance its height allows. The flight’s published route must name one of them. Without a route, a departure with a single candidate is taken. Otherwise that end is left unknown.
  5. Two pieces of one flight separated by a gap in coverage, such as an ocean crossing, are joined when the aircraft was still flying on both sides, kept its callsign and covered the distance at a plausible speed.
  6. Only airline-style callsigns are kept: a three-letter ICAO operator code followed by a digit and up to three more characters. Private, military, state and rotorcraft flights are dropped, as are local flights that start and end at the same airport.
  7. Where only one end of a flight was seen, the other end comes from route data when that route passes through the observed airport. A departure late one evening and an arrival early the next morning by the same aircraft and callsign are joined across midnight.

Reference data

  • Airports, their positions, elevations and codes: OurAirports (public domain).
  • Airport time zones: OpenFlights airports (ODbL 1.0). An airport OpenFlights lacks takes its country’s single zone, or that of the nearest OpenFlights airport in the same country within 150 km. Where neither applies, the time is given in UTC.
  • Airline names and IATA codes, and routes: the Virtual Radar Server standing data (CC0 1.0), routes through adsb.lol’s copy; OpenFlights airlines (ODbL 1.0) for operators it does not list.

How a recorded day becomes a schedule

For an airport and a date, the service takes the airport’s most recent fully recorded local day with the same weekday. That is the date itself if it has been recorded, otherwise a week earlier, two weeks earlier and so on. While fewer than seven days are recorded, it uses the latest recorded day. Each movement keeps its local clock time on the new date. A departure is listed 15 minutes before its takeoff (rounded down to five minutes) and an arrival 5 minutes after its landing (rounded up). A flight number is given only when the callsign ends in digits and the operator’s IATA code is known. Gates are not part of the data.

The method as source code

The method is offered as its source, the files that run on this server. They are written for Node.js and read adsb.lol’s releases directly:

  • ingest.mjs — the nightly job: download, unpack, detect, store
  • download.mjs — finding and streaming a day of adsb.lol's releases
  • tar.mjs — the streaming archive reader
  • movements.mjs — from an aircraft's positions to its takeoffs and landings
  • reference.mjs — airports, time zones, airlines and routes
  • geo.mjs — distances and the airport grid
  • store.mjs — the derived database
  • serve.mjs — a recorded day served as a schedule

Coverage

Coverage is only as good as the volunteer receivers. It is dense across North America, Europe, Japan, Korea, South-East Asia and Australia, thinner in South America, the Middle East and Africa, and close to none in mainland China and India. Where few receivers are near an airport, flights first seen high above it may be missed.

Latest recording: 26 October 2026, with airline traffic at 2,061 airports (953 with at least 10 movements). 8 days are kept.

Questions about the data, or a correction? Ask the RadarWorks team. See also Privacy.