Methodology

Scope

A venue is in scope if it meets any of three rules: a capacity of 10,000 or more anywhere in the world; the current home venue of a club in one of the 57 competitions tracked in the configuration file, whatever its capacity; or a Formula 1, MotoGP or NASCAR Cup circuit, or a venue that has hosted an Olympic ceremony, a FIFA World Cup match or a Super Bowl.

Competitions are a configuration list, not code. Adding a league adds its venues on the next run.

The capacity rule is being widened below 10,000 in steps. Venues in a new band are collected first and published in batches, no faster than the previous batch has been checked and crawled, so a venue under 10,000 seats may exist in the pipeline before it has a page here. A venue that is a club's home ground, or a circuit, is published at any capacity.

How this site is made

Venue, organization and country pages are generated by code from the sourced records described below. Every sentence on them is a fixed template filled with values from those records, so nothing on those pages is written by a language model and nothing is paraphrased from an article. A page that holds no ownership, naming, sponsorship, tenant or equipment record is marked noindex and kept out of the sitemap, because it adds nothing beyond its Wikipedia or Wikidata entry; it is indexed automatically once the pipeline records something for it. Figures such as counts, shares and the daily fact are computed by scripts from the same records, not typed in.

The blog posts and the technology guides under /technology/ were written with an AI assistant (Claude, from Anthropic). The guides are written from the Wikipedia articles listed at the foot of each one, and the assistant checked each claim against those articles. No subject-matter expert has reviewed them, so treat them as an informed summary, not an authority, and use the cited sources for anything that matters. The site has no named human authors and invents none.

Sources, in order of authority

1. Wikidata (CC0) is the backbone: the item list, capacity, coordinates, country, inception, and the first pass at owner, operator, sponsor and occupant. Rows that come only from here are marked wikidata and treated as a starting point rather than the truth.
2. OpenStreetMap (ODbL) supplies the object ID, address fields and, where available, the building footprint. Lookups go by the wikidata= tag first, then by name within 500 m of the recorded coordinates. An unchanged venue is not re-queried within 30 days.
3. Wikipedia (CC BY-SA 4.0) supplies ownership detail and naming history, parsed from article wikitext through the MediaWiki API, never by scraping rendered HTML. Naming sections yield each name with its start and end year, the sponsor, and, only where the article cites them, the deal value, currency and term. The article revision ID and retrieval date are stored on every row derived from it.

Where no English article exists, the article in the venue's own country language is used with a per-language infobox field map, and the language code is stored alongside the revision ID.

Fields you will see on a venue page

• Roles: owner, operator and tenant, each with a start and end date, a current flag, a source URL and a confidence level. A venue may have several current owners or operators; they are never collapsed into one field.
• Names: every recorded name with its period, the sponsor behind it where there was one, and the published deal value and term where a source states them.
• Sponsorships: naming rights plus founding-partner and pouring-rights deals where a public source exists.
• Competitions: the leagues whose clubs play at the venue, and which club.

Ownership type

The single-word ownership type in the table (public, private, team or mixed) is derived from the organization types of the current owners: a public authority gives public, a club gives team, a company gives private, and more than one kind gives mixed. It is a convenience for filtering; the authoritative detail is the owner rows on the venue page.

Change tracking

Every upsert that alters a value writes a change record with the table, field, old value, new value and timestamp. Those records produce the permanent monthly pages under /changes/ and drive the incremental sync to the search database. Corrections are always made upstream in the master database, never in the published files.

Known limits

• Wikidata ownership statements are often stale or incomplete. Anything marked wikidata should be treated as a lead, not a fact.
• Deal values are only as good as what a publisher chose to print. Most deals have no public figure at all.
• Dates are frequently year-only. Those are stored as the first of January with a year precision flag.
• Tenant lists lag club moves by up to a month, because the pipeline runs monthly.
• Organization matching across sources uses the Wikidata ID first and a normalized name second. Fuzzy matches below a 0.9 score go to a review queue rather than into the published tables.

Conflicts

Where a venue's Wikidata label, its Wikipedia infobox name and a league list disagree about the current name, the venue is flagged rather than silently resolved.