GIS Concepts in Sitrec

Sitrec models the Earth as either a sphere or an oblate ellipsoid depending on the useEllipsoid setting. This document explains the reference surfaces and vertical datums involved, and how Sitrec converts between them.

The WGS84 Ellipsoid

The World Geodetic System 1984 (WGS84) defines a reference ellipsoid that approximates the shape of the Earth. It is the coordinate system used by GPS and by most mapping services (Google Earth, Mapbox, Cesium, etc.).

Key parameters used in Sitrec (LLA-ECEF-ENU.js):

The difference between the equatorial and polar radii is about 21.4 km. This is small relative to the total radius but large enough to matter for accurate positioning — using a sphere instead of the ellipsoid introduces altitude errors of several kilometers at mid-latitudes.

When useEllipsoid is false (legacy mode), Sitrec treats both radii as equal to a, degenerating to a sphere. When true, the real WGS84 polar radius is used.

The EGM96 Geoid

The ellipsoid is a smooth mathematical surface. The actual shape of sea level — driven by gravity variations from uneven mass distribution inside the Earth — is an irregular surface called the geoid.

EGM96 (Earth Gravitational Model 1996) is a spherical harmonic model of the geoid. It defines the geoid undulation N at any point on Earth: the signed vertical distance between the geoid and the WGS84 ellipsoid. Typical values range from about -105 m to +85 m.

Sitrec uses the egm96-universal npm package to look up N at any latitude/longitude (EGM96Geoid.js).

Three Kinds of Height

There are three common ways to express the height of a point:

Ellipsoid height (h)   — height above the WGS84 ellipsoid
Orthometric height (H) — height above the geoid (i.e. above mean sea level)
Geoid undulation (N)   — height of the geoid above the ellipsoid

h = H + N

In plain terms:

• Orthometric height (H) is what most people mean by "altitude above sea level" (MSL). It is what you see on a topographic map or an altimeter.
• Ellipsoid height (h) is the height above the WGS84 reference ellipsoid. It is what GPS receivers natively measure.
• Geoid undulation (N) is the difference. It varies smoothly across the Earth's surface and is provided by models like EGM96.

AWS Terrain Tiles (Terrarium Format)

Sitrec loads elevation data from the AWS Open Data Terrain Tiles in Terrarium PNG format:

https://s3.amazonaws.com/elevation-tiles-prod/terrarium/{z}/{x}/{y}.png

The elevation is encoded in the RGB channels of each pixel:

elevation = R * 256 + G + B / 256 - 32768   (meters)

These elevations are orthometric heights — heights above the EGM96 geoid (approximately MSL). They are not heights above the WGS84 ellipsoid.

The Geoid Correction

Sitrec's internal coordinate system (EUS) is based on the WGS84 ellipsoid, so all positions are ultimately ellipsoid-relative. When loading Terrarium elevation tiles, Sitrec must convert orthometric heights to ellipsoid heights by adding the geoid undulation:

h_ellipsoid = h_terrarium + N

This is done per-pixel in QuadTreeTile.js (computeElevationFromRGBA). The geoid undulation is looked up at the four corners of each tile and bilinearly interpolated across the tile's pixels:

const geoidCorners = geoidCorrectionForTile(mapProjection, z, x, y);
// ...
elevation[ij] = R * 256 + G + B / 256 - 32768
              + interpolateGeoidOffset(geoidCorners, xFrac, yFrac);

The same correction is applied to Mapbox terrain tiles (computeElevationFromRGBA_MB), which also provide orthometric heights.

Without this correction, terrain would be displaced vertically by up to ~100 m depending on location, causing visible misalignment with GPS tracks, satellite imagery, and 3D building tiles (which use ellipsoid coordinates).

Coordinate Systems

Sitrec uses several coordinate systems internally:

The conversion chain is: LLA <-> ECEF <-> ENU <-> EUS, implemented in LLA-ECEF-ENU.js. All conversions support both the spherical and ellipsoidal Earth models.

3D Tiles (Cesium / Google)

Cesium Ion and Google Photorealistic 3D Tiles are delivered in ECEF coordinates on the WGS84 ellipsoid. Sitrec transforms them into EUS using a precomputed ECEF-to-EUS matrix (CNodeBuildings3DTiles.js, buildECEFToEUSMatrix4). No geoid correction is needed here because the tile positions are already ellipsoid-relative.

(In Depth) Altitude Naming Conventions & the MSL Confusion Problem

The Three Surfaces

Standard Terms

Ellipsoidal Height (geometric)

• HAE — Height Above Ellipsoid (most common in military/DoD)
• Ellipsoidal height / ellipsoid height
• h (lowercase, formal geodetic literature)
• "GPS altitude" (informal)

Geoid / Orthometric Height (physical)

• MSL — Mean Sea Level (aviation, colloquial — ambiguous, see below)
• AMSL — Above Mean Sea Level (aviation — same ambiguity)
• Orthometric height (formal geodetic term)
• H (uppercase, formal geodetic literature)

Geoid Undulation (the separation between the two)

• N — geoid undulation (formal geodetic literature)
• Geoid separation (NMEA $GPGGA sentence field name)
• Geoid height (less precise — easily confused with "height above geoid")

The Fundamental Relationship

h (HAE) = H (orthometric/MSL) + N (geoid undulation)

The geoid undulation N ranges globally from approximately −107 m (Indian Ocean) to +85 m (North Atlantic). Over the continental US it is typically +20 to +30 m.

Geoid Models

The MSL Confusion Problem

"MSL" is used to mean three different things in practice:

1. Geodetic / GPS MSL (orthometric height)

Height above the geoid (EGM96 or EGM2008). Derived by GPS receiver applying a geoid model to the raw ellipsoidal height. This is the geodetically correct meaning.

2. Barometric / Aviation MSL

Height derived from atmospheric pressure, calibrated to the ISA (International Standard Atmosphere) model. Reported by altimeters and used in ATC. Not the same as geodetic MSL — deviates by tens of meters under non-standard temperature/pressure conditions.

3. "GPS altitude" mislabeled as MSL

Many GPS devices, NMEA sentences, and flight logs report the raw ellipsoidal height (HAE) but label it "altitude" or "MSL" — especially when the onboard geoid model is absent or low quality.

NMEA $GPGGA Sentence

The NMEA standard correctly separates these:

$GPGGA,...,<MSL altitude>,M,<geoid separation>,M,...

• MSL altitude = orthometric height (H) above geoid
• Geoid separation = N (geoid height above ellipsoid)
• Ellipsoidal height = MSL altitude + geoid separation (h = H + N)

However, the geoid separation field is often populated from a coarse onboard table (sometimes just a single global constant), making it unreliable on many consumer devices.

MISB ST 0601 (Military UAV Metadata)

The standard defines Tag 15 as "MSL" but does not explicitly specify EGM96. In practice, DoD platforms of the Predator/Reaper era use EGM96 as the geoid model. Tag 75 was added later specifically because Tag 15's ambiguity was a known problem.

Altitude in KML, ADS-B, and Flight Tracking Services

KML Altitude Modes (OGC Standard)

KML defines altitude through the <altitudeMode> element. The standard (non-extended) values are:

Google's gx: extension namespace adds two sea-floor variants (clampToSeaFloor, relativeToSeaFloor) not relevant to aviation.

Key point: KML absolute mode = EGM96 orthometric height. Google Earth's terrain rendering uses EGM96 for its vertical datum, so absolute altitudes render correctly relative to terrain only when the altitude source is also EGM96-based. If the data is HAE (WGS84 ellipsoidal), the KML will appear offset by the local geoid undulation N (typically 20–50 m in mid-latitudes).

ADS-B Altitude: What Gets Transmitted

ADS-B Extended Squitter (1090ES) mandates two altitude fields per FAR 91.227(d):

Barometric (pressure) altitude — always required, always referenced to 1013.25 hPa (QNE). This is the raw transponder Mode C output. It is never QNH-corrected in the transmitted data stream — QNH correction only happens onboard the aircraft and in ATC systems on the ground.

Geometric (GNSS) altitude — also required, transmitted as HAE (height above WGS84 ellipsoid). This is GPS-derived. Not used for ATC separation — only as a cross-check and for EGPWS/terrain systems.

These two values are almost never the same. The difference at cruising altitude can easily be hundreds of feet.

ADSBexchange: Three KML Export Options

When exporting a KML track from globe.adsbexchange.com, three altitude options are offered:

1. Geometric altitude (EGM96)

• Takes the raw alt_geom field (HAE, WGS84 ellipsoid) and adds the EGM96 geoid undulation for the aircraft's position
• Result: orthometric height (MSL, EGM96)
• This is the correct option for Google Earth since KML absolute mode uses EGM96
• The aircraft will appear at the right height above the terrain model

2. Baro + avg.(EGM96 − baro)

• Takes the alt_baro field (QNE pressure altitude) and adds a regional average offset between EGM96 and barometric altitude
• Compensates for the aggregate effect of geoid undulation and local atmospheric pressure deviation from standard
• A reasonable approximation when geometric altitude is unavailable or noisy, but not precise

3. Uncorrected pressure altitude

• Raw alt_baro field: pressure altitude at 1013.25 hPa standard, no correction
• This is what ATC Mode C radar sees before QNH correction
• Looks wrong in Google Earth because it doesn't account for geoid undulation or non-standard pressure
• Lowest quality for 3D reconstruction; use only when the others are unavailable

ADSBexchange API fields (for reference):

• alt_baro — barometric pressure altitude, feet, QNE (1013.25 hPa), or "ground"
• alt_geom — geometric/GNSS altitude, feet, referenced to WGS84 ellipsoid (HAE)

FlightRadar24

FR24 displays barometric altitude only — specifically the raw QNE (1013.25 hPa standard pressure) altitude from the ADS-B transponder. It is not corrected for local QNH.

Consequences:

• At high-altitude airports (e.g., Denver KDEN, elevation 5,433 ft), aircraft on the ground will show ~5,400 ft, then jump to 0 ft when the "on ground" bit is set, creating a discontinuous step.
• FR24 does show GPS altitude separately where available (aircraft transmitting geometric altitude), displayed as a secondary field.
• The primary altitude shown is always the raw QNE pressure altitude — not true MSL, not HAE, not EGM96.

FR24 statement: "ADS-B only reports altitude values based on the standard pressure of 1013 hectopascals."

FlightAware

FlightAware similarly displays barometric pressure altitude at 29.92 inHg (QNE). It is uncorrected for local altimeter setting.

This means the altitude shown is the same datum as FR24 — raw QNE pressure altitude. Not true MSL in the geodetic sense; not HAE; not EGM96-corrected.

FlightAware can show geometric altitude when available from ADS-B, but it is not the primary displayed value.

Practical implication: A flight at 5,500 ft indicated (with a local altimeter setting of, say, 30.15 inHg) may appear on FlightAware at ~5,125 ft because FlightAware uses QNE, not QNH.

Barometric Altimetry and the 18,000 ft Rule

Below the transition altitude (US: 18,000 ft / FL180)

Pilots set their altimeter to QNH — the local sea-level pressure at the nearest reporting station. The altimeter reads altitude AMSL. This is a reasonable approximation of geodetic MSL but is meteorologically influenced (varies with weather). Each reporting station issues a new QNH ~hourly.

At and above 18,000 ft MSL (FL180 and above)

All aircraft set altimeters to the standard pressure setting: 29.92 inHg / 1013.25 hPa (QNE). The altitude indicated becomes a Flight Level — a pressure surface, not a true altitude.

This means:

• FL350 (35,000 ft) is the pressure level corresponding to 35,000 ft in the International Standard Atmosphere (ISA), not necessarily 35,000 ft above the geoid.
• On a cold day, the atmosphere is denser and FL350 is geometrically lower than 35,000 ft.
• On a hot day, FL350 is geometrically higher than 35,000 ft.
• The divergence between pressure altitude and geometric altitude at cruise altitudes can easily exceed 1,000 ft in extreme temperature conditions.

Why the transition exists

The purpose of QNE above FL180 is not accuracy — it's uniformity. Every aircraft uses the same datum above the transition, so vertical separation is consistent even if the absolute altitude is off. ATC radar works with Mode C (QNE) codes and applies its own QNH correction to convert to displayed altitude for controllers.

Temperature error — the key non-obvious effect

A barometric altimeter is calibrated to ISA (15°C at sea level, lapse rate of 2°C/1000 ft). It has no temperature compensation for real-world conditions. On a cold day:

• Air is denser; a given pressure is reached at a lower geometric altitude
• The aircraft is physically lower than the altimeter indicates
• Cold temperature correction is required for obstacle clearance; it is safety-critical and commonly neglected

At cruise altitude, ISA deviations of ±20–30°C are routine, producing geometric altitude errors of several hundred to over 1,000 feet.

Summary: What Each Source's Altitude Actually Means

Relevance to UAP/ADS-B Analysis

When reconstructing aircraft geometry (e.g., in Sitrec) from ADS-B data:

1. Use alt_geom (HAE) if available — it's geometrically clean and can be used directly with WGS84 lat/lon.
2. If only alt_baro (QNE) is available, you need to apply two corrections to get HAE:
   • QNH correction: convert from QNE to orthometric height using local pressure (requires meteorological data for that time/place)
   • Geoid correction: add EGM96 undulation N to convert from orthometric to HAE
3. ADSBx's "geometric (EGM96)" KML export already does this correctly and is suitable for Google Earth rendering and 3D reconstruction.
4. The uncorrected QNE baro altitude can be off by hundreds to over a thousand feet from true geometric altitude at cruise — never use it for precision geometry without correction.

Summary of What to Assume