Airport or field elevation describes a location

Airport elevation is a geographic and operational reference value. It describes the airport according to the applicable airport-elevation definition, not the current state of the atmosphere. It is normally represented as a number of feet above MSL and does not change from one routine weather observation to the next.

Station elevation is also a location-related value, but it is not the altimeter setting. It identifies the height above sea level to which the station’s pressure measurement pertains. [1] Systems that store both an airport elevation and a station elevation should keep them as separate fields rather than assuming that one is a duplicate of the other.

The altimeter setting describes pressure for an instrument

The altimeter setting is a pressure value reported in the METAR’s pressure group. In the U.S. format, the letter A followed by four digits represents inches of mercury, with the decimal point omitted. Thus, A2992 represents 29.92 inches of mercury. [2]

The setting is used by an aircraft altimeter. It is not a measurement of how high the airport is. The standard pressure of 29.92 inches of mercury is the setting that yields pressure altitude for a standard flight level; that figure is still a pressure setting, not the airport’s elevation. [1][3]

A simple example shows why the fields must not be mixed. Suppose an airport record gives a field elevation of 1,200 feet MSL, while a METAR reports A2992. The first value describes the airport’s elevation. The second reports a pressure setting in inches of mercury. Neither value can be substituted for the other, and the METAR value does not mean that the airport is at 2,992 feet or at any other elevation.

Assign each value to its proper record

A reliable data model separates relatively stable location attributes from time-specific observations. An airport or station record can hold the identifier and applicable elevation metadata. A weather-observation record can hold the METAR text, observation time, and parsed altimeter setting.

For example, a conceptual schema might use distinct fields such as:

• airport_identifier
• field_elevation_ft_msl
• station_elevation_ft_msl, if available and needed
• observation_time
• metar_altimeter_inhg
• raw_metar

The field names should make the meaning and units explicit. A generic field called elevation_or_pressure or altitude_value obscures the distinction and invites conversion errors. If a source provides station elevation separately from airport elevation, retain that source value as station metadata rather than silently replacing the airport elevation. Station elevation and the METAR altimeter setting are not the same quantity. [1][2]

Parse the altimeter group as an observation value

When software parses a U.S. METAR, it should recognize A plus four digits as an altimeter-setting group and interpret the digits in the specified units. For example, A2992 becomes 29.92 inHg, not 2,992 feet, 299.2 feet, or a value to be added to airport elevation. The Aviation Weather Center describes this encoding and the altimeter group’s use by aircraft altimeters. [2]

The parsed value should remain attached to the observation from which it came. It is time-dependent: a later METAR may report a different setting. Airport elevation, by contrast, belongs to the airport or station record and should not be overwritten whenever a new observation arrives. This separation also helps preserve provenance: users and downstream systems can identify which report supplied the pressure setting and when it was observed.

Validate meaning, not just number format

A validation rule should check more than whether a value is numeric. It should check that each value is in the expected field, has a declared unit, and comes from an appropriate source. An elevation field expressed in feet MSL should not accept a METAR pressure token. An altimeter field expressed in inches of mercury should not accept a runway elevation.

Likewise, do not calculate airport elevation from the altimeter setting. The METAR setting is a pressure value used for altimetry, while airport elevation and station elevation describe locations. [1][2] Keep those categories in separate fields rather than compressing them into a single “altitude” concept.

Separate fields are safer than inferred values

A minimal implementation might store a single airport elevation and parse the altimeter group directly from each METAR. A more detailed implementation may also store station elevation, where the data source supplies it. Both approaches can be sound if they maintain clear definitions and do not treat station elevation as interchangeable with field elevation.

An unsafe approach is to use the reported altimeter setting as a proxy for airport elevation, or to derive a pressure setting from the airport’s published elevation. These shortcuts confuse two different measurement roles. They also discard the observation’s timestamp and the distinction between a location height and the station’s pressure reference height. [1][2]

Example of a practical research context

VectorWX is one place a student can read a METAR next to airport information. The useful question is whether each value keeps its meaning, units, and time. A map marker can show elevation as location metadata, while the observation panel shows the altimeter setting as part of that report.

Keep presentation clear without merging the concepts

A user interface may place both values within the same airport view because both are relevant to that location. Physical proximity on a screen, however, should not become semantic merger in the data model. Labels such as “Airport elevation (ft MSL)” and “Altimeter setting (inHg)” make the difference explicit. If station elevation is included, label it separately and explain what the value represents.

The same principle applies to exports and APIs. Field names, units, and timestamps should travel with values so that another system does not mistake an altimeter setting for elevation or assume that an observation’s pressure value is a permanent airport attribute.

Stable metadata and changing observations need different lifecycles

Airport elevation is relatively stable metadata. A METAR altimeter setting is part of a specific observation and can change over time. Treating them as separate entities makes updates more reliable: a new report updates the weather observation without altering airport metadata, while a correction to an airport record does not rewrite historical pressure observations.

This separation improves traceability in archives, analytics, and software integrations. Historical weather reports remain interpretable in their original observational context, while location records can be maintained according to their own sources. Where both an airport elevation and a station elevation are available, storing both with clear definitions avoids a false assumption that one value must be used for every purpose. [1]

Semantic precision supports safer automation

As aviation-weather systems combine airport databases with live or archived observations, more calculations and displays depend on machine-readable fields. A system that stores an altimeter group as a generic numeric “altitude” risks propagating errors into summaries, filters, or downstream applications. Explicit field names and units reduce that risk and make automated validation possible.

The governing distinction is straightforward: airport elevation is metadata about an airport; station elevation describes the height to which station pressure pertains; and the METAR altimeter setting is a pressure setting in the observation. [1][2] Pressure altitude, produced from the standard pressure setting, is still not a survey of the airport. [3]