Methodology

GEM publishes one row per train, phase or unit. A terminal page groups every row that shares GEM's terminal-level identifier. When a release lacks that identifier the fallback key is the terminal name plus country. The terminal's country, region, coordinates and wiki link are taken from the first unit that reports them.

Rolled-up status. The terminal status is the "most alive" unit status: operating beats construction, which beats pre-construction, then proposed. Only if no unit is in one of those states does idle, mothballed, shelved, cancelled or retired apply, in that order. A terminal with one operating train and three under construction is shown as operating, with both capacities reported separately.

Capacity roll-ups. Operating capacity is the sum of operating units; under-construction and proposed (proposed + pre-construction) likewise. Total excludes cancelled, shelved and retired units. Units without a reported capacity contribute nothing and are never estimated.

Terminal capacity is stored in both million tonnes per annum (Mtpa) and billion cubic metres per year (bcm/y) of gas equivalent. When GEM provides both, both are kept. When one is missing it is derived at 1 Mtpa = 1.36 bcm/y, GEM's own convention. Values given in other units (tonnes per day, bcf/d, mmcf/d) are converted through Mtpa; unrecognised units are logged and shown as "Not reported".

Worked example: a 13.3 Mtpa export train is 13.3 × 1.36 = 18.09 bcm/y. An import terminal listed at 12 bcm/y is 12 ÷ 1.36 = 8.82 Mtpa.

GEM's pipeline file has one row per segment. Segments sharing a project identifier become one pipeline page, with the name and country list merged across them.

Length and capacity are not blindly summed. GEM repeats project-level figures on every segment row, so adding them would double-count a two-segment project. When every segment reports the identical figure we count it once and label it "repeated"; when the figures differ they are genuinely per-segment and we sum them. Both the total and the per-segment values are shown, so the rule is always visible. Where GEM reports no length at all, the length is measured from the route geometry and labelled as such.

Routes come from three sources, in order: GEM's route GeoJSON, matched by segment or project identifier; a route column of coordinates in the spreadsheet, accepting either "lat,lon" pairs or WKT; and, failing both, a straight line between the reported start and end points. Each segment row says which source its geometry came from, and a straight endpoint line is never mistaken for a surveyed route. Pipelines with none of the three are listed but not drawn.

Capacity is stored in bcm/y, converted from bcf/d at 1 bcf = 0.0283 bcm where that is the reported unit. Diameters given in inches are converted to millimetres at 25.4 mm per inch.

A terminal is listed as connected to a pipeline when its coordinates fall within 25 km of the pipeline's route, measured to the nearest point on a route segment rather than only to its vertices. Where we hold no route, the same test is applied to the reported start and end points. A third, weaker signal is a name overlap such as Sabine Pass Pipeline and Sabine Pass LNG Terminal.

Every link on the site says which of the three matched it and how far apart the two are. Proximity is not proof of a physical connection: a pipeline may pass a terminal without serving it, and a real feeder may be below GEM's size threshold and so absent entirely.

The map is MapLibre GL JS, served from this site. There is no tile provider and no API token: the basemap is a single Natural Earth 1:110m country-outline file (public domain) reduced to about 170 kB, and the assets come from two GeoJSON layers generated at build time. Nothing on a map page contacts a third party.

Map code loads only when a reader presses the load button, so pages carrying a map cost nothing extra until then. Pipeline routes in the map layers are simplified with Ramer–Douglas–Peucker at about a 2 km tolerance for drawing; the full-precision geometry stays in the build database and drives the measured lengths.

Every vessel's IMO number is checked against its own check digit: multiply the first six digits by 7, 6, 5, 4, 3 and 2, add them up, and the last digit of that total must equal the seventh digit. Numbers that fail are kept and shown, marked "check digit fails", rather than silently dropped or corrected.

Containment systems are normalised from GEM's free text into a canonical name and a family: membrane (GTT Mark III, NO96 and their variants, plus the Korean KC-1), Moss spherical, prismatic Type B (SPB), and Type C pressure tanks. Anything unrecognised keeps its original wording and is filed as "other". The same is done for propulsion, which is grouped into steam turbine, dual-fuel diesel electric, two-stroke dual-fuel (X-DF, ME-GI, ME-GA) and plain diesel. The original text is always shown on the vessel page alongside the normalised name.

Sister ships are vessels sharing a shipyard, a delivery year and a cargo capacity rounded to the nearest 1,000 m³. That combination usually means one design and one order, but it is an inference from three fields, not a shipyard record, and the page says so.

Cargo capacity is stored in cubic metres of liquid LNG. Figures under 1,000 are read as thousands of m³, and European thousands separators are handled; anything unparseable is reported rather than guessed.

We hold no vessel positions, voyages or AIS data, and carriers are deliberately absent from the map.

A country page gathers terminals whose country matches, pipelines whose crossed-country list includes it, and vessels either flagged there or owned by a company headquartered there. Headquarters come only from the hand-maintained company file, so owned-fleet counts are as complete as that file and no more. The import against export balance uses operating capacity only, unadjusted for ownership stakes or utilisation.

Owner, operator and parent fields such as Owner A [50%]; Owner B [50%] are split on semicolons (or commas when every part carries a percentage) into one stake per company, with the percentage kept where given. Each name is normalised (case, punctuation, legal suffixes such as Inc., Ltd, S.A.) and folded into a single company record; a hand-maintained alias file handles renames like Qatar Petroleum → QatarEnergy or DSME → Hanwha Ocean. Headquarters, ticker and website are shown only when set in that file.

On a terminal page stakes are merged across units. If a company holds a stake in only some units the unit count is shown next to it. Company pages count linked assets from the database, so "linked to N terminals" is always exact for the current release.

The opening paragraph on every asset page is filled from a fixed sentence template: name, rolled-up status, facility type, location, unit count, capacities by status, earliest start year and owners. Because it is templated it is always consistent with the table beneath it. Page titles follow the patternName — type, place | LNG Chain; descriptions are the summary truncated to 158 characters.

A terminal's URL is /terminal/<slug>/, where the slug is generated once from name and country and then stored against the GEM identifier. Later GEM renames do not change the URL. If a slug is deliberately changed, the old path is written to a redirects table and emitted as a Cloudflare _redirects rule. Slug collisions are resolved by appending the GEM identifier.

Every ingest keeps the outgoing database before replacing it, and a diff script compares the two on the tracker's own identifiers rather than on names, so a renamed project is recorded as a rename instead of one asset vanishing and another appearing.

Recorded moves are: an asset appearing or disappearing, and changes to status, capacity, ownership, name, key dates, containment, propulsion, and whether a pipeline has route geometry. Capacity moves below a rounding threshold are ignored, so a re-stated decimal does not register as news. Each change is written as a sentence at diff time and committed to the repository, which is why the change log survives even though the source publishes only a current snapshot.

A scheduled worker reads public RSS for a fixed set of searches plus the name of every tracked terminal, and matches headlines to assets by whole-phrase name matching. Names shorter than six characters or of a single word are skipped, so a company called Shell does not capture every headline containing that word.

We store the headline, the publication and the link, and nothing else. No article text is fetched or stored, and outbound links carry no ranking signal. Matching is approximate and labelled as such.

GEM's terminal and pipeline files are re-ingested when GEM publishes a release (roughly annually); carriers quarterly. Each ingest is diffed against the previous database to produce a change log (new assets, status changes, capacity changes, ownership changes). See data sources for the release currently loaded.