# ourairports-data: a daily dump of the world's airports as CSV > The ourairports-data repository publishes OurAirports as a set of CSV files updated daily, covering airports, runways, frequencies, navaids, countries and regions, with a permissive public domain licence and direct download links. It suits anyone building an aviation application who needs airport reference data without scraping a website, and the detail to plan around is that contributions are not accepted here at all. **davidmegginson/ourairports-data** — Open-data downloads for OurAirports.com - Repository: https://github.com/davidmegginson/ourairports-data - Stars: 522 · Forks: 76 - Language: Unknown - License: Unlicense - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/davidmegginson-ourairports-data ## What the repository is The repository publishes open-data downloads for OurAirports, updated daily, and it points to the documentation at ourairports.com/data for what the files mean. That is the whole concept, and it is worth being clear about the division of labour. OurAirports is the live site and the editorial process: people sign up, they add airports, they correct information, and the site grows. This repository is the machine-readable output of that process, republished as CSV files so that other programs can consume the data without scraping HTML. The repository is not a fork of the site and it is not a project anyone contributes to directly. It is a mirror of a generated artefact, and the README is explicit that OurAirports generates the files every day. The licence is the Unlicense, which is the public domain dedication. For a dataset like this, that is the right choice. The data describes physical facts about the world, the facts are collected by a large number of volunteers, and the data is not the product of a single creative effort that someone could claim authorship of. Putting it in the public domain removes any question about what a downstream user has to do to use it, which is what you want from reference data. The primary language is recorded as unknown, which is accurate for a repository whose tracked content is CSV. The default branch is main, the last push was on 2026-10-16, and there are no GitHub releases, which makes sense for a repository whose whole purpose is to have the current state of the data at a stable URL. The repository root is minimal by design. There is the LICENSE file, the README, and seven CSV files: airports.csv, airport-comments.csv, airport-frequencies.csv, runways.csv, navaids.csv, countries.csv and regions.csv. No build scripts, no application code, no configuration. That listing is itself the documentation of the data model. There is a table of airports, a separate table of the comments users have attached to them, a table of radio frequencies, a table of runways, a table of navaids, a table of countries and a table of regions. Six downloadable files plus the comments file, and the shape of that set is the shape of the reference data any aviation application actually needs. ## The download links and what is in each file The README lists direct download links for the files, and they are hosted on GitHub Pages under the repository owner's account: * https://davidmegginson.github.io/ourairports-data/airports.csv * https://davidmegginson.github.io/ourairports-data/airport-frequencies.csv * https://davidmegginson.github.io/ourairports-data/runways.csv * https://davidmegginson.github.io/ourairports-data/navaids.csv * https://davidmegginson.github.io/ourairports-data/countries.csv * https://davidmegginson.github.io/ourairports-data/regions.csv The URLs are stable, so they can be hard-coded into a program or a build script. That is the practical advantage over using the main site, where the same content is available in a format intended for a browser. The airports.csv file is the core one, and it is the one most people want. Every airport in the database, with its identifiers, its name, its position and its associated country and region. The countries.csv and regions.csv files provide the reference data those two columns refer to, which is the usual shape for a normalised dataset: the large table holds foreign keys, and the small tables hold the display values. runways.csv covers the runways at each airport, which is a separate table because an airport has a variable number of them and each has its own attributes. airport-frequencies.csv covers the radio frequencies on offer at each airport, and navaids.csv covers the navigation aids, which are navigational beacons and the like that exist at particular locations and serve particular routes. The seventh file, airport-comments.csv, is not in the download list but is present in the repository, and its role is different from the other six. The other files are the structured reference data, generated from the database. The comments file holds the free-text notes that users have written about particular airports, the kind of thing that includes local operating notes, noise abatement procedures and the informal information that never fits a structured field but is often the most useful thing in the dataset. That distinction matters when you are deciding what to fetch. If you are building an application that needs to display an airport's runways, you need airports.csv and runways.csv. If you want to show the notes that regulars have written about a field, you need the comments file as well. The frequencies and navaids files are the two most likely to be relevant only if your application is radio-oriented, and they are the two most likely to change, since the radio environment at an airport is adjusted more often than the location of its terminal building. ## The date caveat, which is the one thing to know The README carries a note that explains a behaviour that would otherwise look like a bug, and it is worth reading before you build anything on top of these files. OurAirports generates the files every day, but GitHub updates the date only when the contents have changed. As a result, files that change rarely, like countries.csv, may show a date weeks or months in the past. So the modification date of a file is not a reliable indicator of how current its contents are. The dump is regenerated daily, but GitHub only records a new commit when the bytes actually differ, so a file whose content is stable keeps its old date indefinitely. This is a general property of any commit-based publishing system, and it comes up in several forms. A stable file keeps a stale date. A file that changes daily gets a fresh date every day. And the overall picture is a mixture of files with wildly different dates in the same repository, which makes the dates useless for telling a consumer how stale the dataset as a whole is. The practical consequence is that you should not build a freshness check on the file dates. If you need to know whether your copy is current, compare the contents rather than the timestamps, or fetch and diff, or use the dataset's own published documentation for what the update cycle means. There is a related question about how a consumer should consume the data at all. A file that changes daily is awkward to depend on directly, because a build that fetches it will produce a different result each time. The usual answer is to fetch it on a schedule of your own, store it, and treat the stored copy as your input. That gives you reproducible builds and a record of what you shipped. The unpacking of the note is also worth noting. If you fetch countries.csv and see a date from months ago, the correct reading is not that the data is months old. It is that the data has not changed in months, because the source regenerates the file daily and the content is identical each time. For a file listing the world's countries, that is exactly what you would expect. ## Why pull requests are not accepted The README has a section on correcting or adding data that opens with a bold instruction: please do not create pull requests. The reason follows immediately. To add new airports or update information for existing ones, you go to ourairports.com and create a free account, and your updates will appear in the next daily data dump to GitHub. The repository cannot merge pull requests because they would be overwritten by the next data dump. That is the key thing to understand about this repository: it is generated output, and generated output does not accept contributions. Any commit made directly would be overwritten within a day by the automatic publishing process. A pull request would be a valid, mergeable change that the automation would then destroy. So the route for a correction is the site itself, where the data is entered and validated, and the dump is a consequence of that process rather than an input to it. The site is where the community work happens, and the account requirement reflects that there is a human cost to every change. Adding an airport means someone has to supply the details and accept responsibility for them. There are also limits on what can be done even through the site, and these are worth knowing before you spend time trying. You cannot update the internal ident that OurAirports uses. You cannot merge duplicate airports. And you cannot delete non-existent ones. The internal ident is the site's own identifier for a record, which is presumably referenced by other parts of the system and so cannot be changed without breaking those references. Merging duplicates and deleting records are the two operations that would require changing how records relate to each other, which is exactly the kind of thing a nightly regeneration makes awkward. For those cases there is a different route: a problem report, available through the satellite view button on each airport page, and the maintainers will get to it. So the escalation path exists, it is just slower than the self-service path for the common case. For a developer, the practical summary is that this repository is read-only. You consume it, you do not change it, and if you find an error you fix it at the source. ## Choosing how to consume it A few practical decisions follow from the shape of the project, and they are worth laying out because the README leaves them to the reader. The first is whether to fetch the files directly or to mirror them. Fetching the URLs directly is fine for a script that runs occasionally. For anything with a deployment, mirroring on your own schedule gives you a stable copy, a record of what you shipped and builds that do not change underneath you. The second is which files you need. The airports table is the one every consumer wants, and it is also the one that dominates the download. If you only need country and region lookups, fetching countries.csv and regions.csv alone is much lighter. If you are displaying runway information for a specific field, you can fetch the runways file and join it locally rather than taking the whole dataset. The third is how to load it. These are CSV files, and the usual advice for reference data of this kind is to load them into a database rather than parse them at request time. The airports file in particular is large, and a database table with an index on the identifier gives you lookups that a CSV scan cannot match. The fourth is how to keep the data fresh. If you mirror it, you have to decide a cadence. The source regenerates daily, so mirroring daily or weekly is reasonable. And because the content only changes when something actually changes, you can also compare before replacing, so a mirror that only swaps the file when the content differs avoids pointless reloads. The fifth is a question about the licence that has a simple answer. The Unlicense puts the data in the public domain, so you can use it commercially, modify it, redistribute it, and include it in a product without attribution requirements or licensing discussions. That is the reason to prefer this dump over a source that would require a licence negotiation. And the sixth is what to do when you find an error. Fix it at the source, on the site, because the dump will carry your fix within a day and any local patch you apply will be lost at the next refresh. The documentation at ourairports.com/data is the reference for what each column means, and it is the right place to start before writing any parsing code, because the column set is wide and the semantics of some of the fields are not guessable from the names alone. ## Conclusion Adopt ourairports-data if you need airport, runway or navaid reference data and would rather fetch a file than scrape a site, since the dump is refreshed daily and the licence is public domain. Do not try to contribute to it, because pull requests are explicitly not accepted and any change would be overwritten by the next dump, and check first which of the six files you actually need, because the airport table alone is large and the countries file changes rarely enough that its date can look stale. ## FAQ ### What is the ourairports-data repository? It is a set of open-data downloads for OurAirports, published as CSV files and updated daily. The repository root holds the LICENSE, the README and seven CSV files, and the files are also served directly from GitHub Pages for stable URLs. The data is released under the Unlicense, which places it in the public domain. ### Which files does ourairports-data publish? airports.csv with the airports themselves, runways.csv, airport-frequencies.csv for the radio frequencies, navaids.csv for the navigation aids, countries.csv and regions.csv for the reference data the airport table refers to, plus airport-comments.csv holding the free-text notes users have written about particular airports. The first six have direct download links listed in the README. ### How current is the data in ourairports-data? The files are generated every day, but GitHub updates the commit date only when the contents have changed. So a file that changes rarely, such as countries.csv, can show a date weeks or months in the past, and freshness checks based on the file dates are not reliable. Comparing the contents is the way to tell whether a copy is current. ### Can I submit a pull request to ourairports-data to fix an airport? No, the README asks that you do not create pull requests, because the repository is generated output and any merge would be overwritten by the next daily data dump. Corrections go to ourairports.com with a free account and appear in the next dump. Some changes cannot be made there at all, such as changing the internal ident, merging duplicate airports or deleting non-existent ones, and those go through the problem report button on the airport page. ### How should I use the ourairports-data files in an application? Mirror them on your own schedule rather than fetching them at request time, so builds stay reproducible and you keep a record of what you shipped. Load the CSVs into a database for lookups, fetch only the files you need since the airport table dominates the size, and remember that the licence is public domain so commercial use and redistribution carry no conditions. ### Is ourairports-data still being maintained? The repository is not archived and the last push was on 2026-10-16, with no GitHub releases because the current data is always at the same URLs. The files are regenerated every day by OurAirports, and the documentation describing the columns and the data model lives at ourairports.com/data. ## Sources - [davidmegginson/ourairports-data on GitHub](https://github.com/davidmegginson/ourairports-data) - [Issues](https://github.com/davidmegginson/ourairports-data/issues) - [License: Unlicense](https://github.com/davidmegginson/ourairports-data/blob/main/LICENSE) - [README](https://github.com/davidmegginson/ourairports-data/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/davidmegginson-ourairports-data