METAR, TAF and SIGMET Sources for OCC Dashboards

Executive Summary

An operations control center (OCC) choosing weather inputs for a local dashboard has three workable procurement paths: consume a public aviation weather application programming interface (API) and its bulk cache, contract for a managed commercial feed, or reuse weather already distributed by a flight planning or dispatch product the operator already uses. The right comparison is report provenance, territory, format, issue and validity times, delivery behavior, permissions, and the operator's existing procedures. A dashboard can make these attributes visible; it does not itself establish an approved source for operational control. In the United States, 14 CFR 121.101 requires domestic and flag carriers to use an approved system for obtaining adverse weather forecasts and reports ^[1]. European Union Aviation Safety Agency (EASA) guidance calls for authoritative sources or certified providers in relevant flight documentation (Source: www.easa.europa.eu).

As of October 2026, the National Oceanic and Atmospheric Administration (NOAA) Aviation Weather Center (AWC) lists worldwide METAR, terminal aerodrome forecast (TAF), and SIGMET coverage in its API, while its graphical AIRMET (G-AIRMET) product is scoped to the contiguous United States ^[2]. The public API states 100 requests per minute, a 400-entry maximum for most endpoints, and HTTP 204 for a valid request with no data, except GeoJSON ^[2]. Its bulk caches are the better documented route for complete datasets, but cache publication frequency is not the age of the observation or forecast. A United States METAR may normally update about hourly while the METAR cache refreshes every minute.

Commercial alternatives change the integration contract, not the underlying need to inspect every report's timestamp and source. CheckWX documents keyed JSON endpoints, decoded TAF segments and station-query constraints ^[3]. The Weather Company packages aviation data as GeoJSON features and cautions that a METAR feature set can include observations with different valid times ^{[4] [5]}. AVWX says NOAA is its default METAR and TAF provider and warns that a cached report can be multiple days old (Source: support.avwx.rest). A commercial contract therefore needs explicit answers on feed provenance, geographic completeness, permitted display and retention, timestamps, support, and failover. Public product pages do not provide an independent latency ranking.

For international traffic, the United Kingdom's Secure Aviation Data Information Service (SADIS) offers operational meteorological data in traditional alphanumeric and IWXXM forms, subject to State Meteorological Authority approval ^[6]. For a narrow local display, first inspect whether a dispatch or briefing platform the operator already uses can supply the needed view and provenance. If it cannot, design a read-only integration with source labels, issue and valid times, ingestion age, and conspicuous missing-data states. LANDING.AERO describes custom flight operations data integration and dashboards; that is a software implementation route, rather than a weather feed or dispatch service.

Introduction and Background

Aviation weather data reaches an OCC as observations, forecasts, advisories, and briefings. A METAR is an aerodrome observation; SPECI is a special observation. A TAF is an aerodrome forecast. A SIGMET is a significant meteorological information advisory. Their time meanings differ: an observation has an observation time, a forecast has an issue time and a valid period, and an advisory can have issue, start, end, amendment, and cancellation states. The Federal Aviation Administration (FAA) advises users to assess both product issue and valid times ^[7]. Treating all products as one generic “updated at” tile loses that distinction.

This report is for airline, charter, and flight department operations and information technology teams specifying an aviation weather source matrix for an OCC system. The design decision concerns how data enters a dashboard and how the display reports provenance and currency. Approved meteorological, dispatch, and flight following procedures remain with the operator and its competent authority. For example, Canadian Standard 725 requires a flight dispatcher to study pertinent weather reports and charts; a display project does not alter that duty ^[8]. The United States rule for Part 121 domestic and flag operations also ties adverse-weather information to an approved system ^[1].

The scope includes a NOAA AWC API or cache implementation, commercial machine-readable data feeds, and weather functions already inside dispatch or briefing products. It also distinguishes national and international services. NOAA's “worldwide” API label describes the product category it receives; it is not a contractual statement that every aerodrome or flight information region is complete at every moment. SADIS is a different distribution arrangement for international operational meteorological data, with State approval and licence conditions ^[6]. In Canada, NAV CANADA points users to Collaborative Flight Planning Services for most weather tools, while the public page does not describe an OCC bulk-feed entitlement ^[9].

The practical starting questions are therefore concrete:

• Territory: Which stations, routes, flight information regions, and advisory types must appear?
• Authority: Which source is approved in each operating jurisdiction and manual?
• Representation: Does the integration need coded text, parsed fields, polygons, or IWXXM?
• Time: Which observation, issue, valid, receipt, and display timestamps are available?
• Rights: May the operator store, transform, redistribute, and show the data internally?
• Failure: What should an OCC user see when a source returns no report or stops updating?

NOAA AWC API and Cache

Capabilities

The AWC Data API is a useful public baseline because its product table and restrictions are documented together. It lists METAR in raw text, JSON, GeoJSON, CSV, XML, and IWXXM; TAF in the same set except CSV; and SIGMET in raw text, JSON, GeoJSON, and XML ^[2]. WMO describes IWXXM as an aviation meteorological information exchange model designed for software consumption, including products such as METAR/SPECI, TAF and SIGMET (Source: wmo.int). A parser should preserve coded source text alongside decoded fields so users can trace the rendering to the report that supplied it.

The AWC table treats G-AIRMET as a contiguous United States product, Alaska AIRMET separately, and pilot and aircraft reports as primarily United States and North Atlantic coverage ^[2]. NOAA's 2024 service notice said traditional alphanumeric AIRMETs for the contiguous United States would retire in January 2025, while Alaska and Hawaii AIRMETs were outside that change ^[10]. This is a United States distribution change, not a statement about AIRMET availability worldwide. A cross-border matrix should not silently apply the CONUS G-AIRMET model to Canada, Europe, or oceanic operations.

AWC recommends compressed cache files when a client needs routinely updated complete datasets. The listed METAR caches refresh once a minute, the TAF XML cache every 10 minutes, and the CONUS SIGMET and G-AIRMET caches once a minute ^[2]. “Refresh” here means publication of the cache file, not reissuance of every report within it. AWC itself notes that most METARs update about once an hour ^[2]. An OCC should record both the cache fetch time and the report's own observation or issue time.

Adoption and Integration

A narrowly scoped request works for a few stations or a filtered route query. A bulk cache makes more sense when many users or screens need the same population. AWC's published restrictions are 100 requests per minute and 400 entries for most endpoints, with larger queries directed toward cache files ^[2]. The operator should set a recognizable client identity, budget shared polling centrally, and avoid each wallboard tab creating its own API load.

The ingestion state machine must distinguish an empty result from an error. AWC documents 204 No Content for a valid request with no data, except GeoJSON; Internet Engineering Task Force RFC 9110 likewise defines 204 as successful with no response content ^{[2] [11]}. A 204 for one station should not erase an older report without a visible “no current report” state.

Strengths and Limitations

The strength of AWC is transparent product, format, cache and restriction documentation. The limitation for procurement is that a public endpoint is not a substitute for a contract specifying operational availability, redistribution rights, support response or complete territory coverage. A flight operations team should test specific station and advisory populations against its approved source, record discrepancies, and keep the dashboard's purpose separate from dispatch release or briefing obligations.

Commercial Feed Providers

Capabilities

Commercial feeds can reduce parsing work and offer support arrangements, although the published pages reviewed here do not establish comparable end-to-end latency. CheckWX documents raw, short and decoded METAR models and a decoded TAF model with structured time segments ^{[12] [3]}. Its documentation requires an API key, returns timestamps in UTC, limits multi-station requests to 25 International Civil Aviation Organization (ICAO) identifiers, and recommends caching METAR and TAF responses for at least 15 minutes ^[13]. Those are implementation constraints to test against the operator's desired screen interval and station count, not measures of weather quality.

The Weather Company describes an Aviation Core package of GeoJSON feature data with global airspace scope ^[4]. Its METAR documentation warns that one feature set can hold observations from multiple valid times; its TAF service includes raw report text and parsed station metadata; and its SIGMET features expose active and expiration timestamps ^{[5] [14] [15]}. A map layer's feature-set timestamp therefore cannot stand in for each METAR observation time. Its SIGMET documentation says the last transmission obsoletes a previous issuance, a state transition that the local store should model explicitly ^[15].

AVWX documents parsed report output as JSON, XML, or YAML, and presents global inflight advisory coverage (Source: info.avwx.rest). Its source documentation names NOAA as the default METAR and TAF provider while indicating use of regional sources (Source: support.avwx.rest). Its API documentation cautions that a cached response may contain a report multiple days old (Source: support.avwx.rest). This disclosure makes report-time validation essential even when a provider returns a successful response. AVWX also documents a no-report HTTP 204 case (Source: support.avwx.rest). Tomorrow.io describes aviation fields blended into a synthetic timeline; teams seeking the original coded bulletin should verify separately that their contract exposes that bulletin ^[16].

Adoption

A proof of concept should use a representative sample of domestic, international, diversion and remote stations. It should compare coded reports, parsed values, cancellations and coverage against the approved source at recorded UTC times. Vendor demonstrations should include the exact licence tier, query shape, data lineage and local persistence terms. A GIS display also needs the geometry semantics: an advisory polygon may be useful for situational awareness, but the team must know whether the feature is an issued boundary, a provider transformation or a derived intersection. CheckWX documents a decoded G-AIRMET format with GeoJSON polygon points; that is specific to its documented G-AIRMET endpoint ^[17].

Strengths and Limitations

A managed feed is preferable when the operator needs contractual support, a negotiated redistribution right, harmonized global coverage, or provider-maintained parsing. The apparent convenience must be checked against actual terms. Public pages reviewed for the named providers do not provide one common price, quota, licence, support, and latency basis; a numeric cost ranking would be invented. The evaluation should request written answers for:

• Provenance: Original issuing office, upstream distributor, and fallback source per product.
• Completeness: Station, flight information region and advisory-type coverage by territory.
• Time fields: Observation, issuance, valid period, provider receipt and delivery times.
• Corrections: Supersession, cancellation and duplicate handling.
• Delivery: Polling, subscription, bulk export, pagination and rate limits.
• Rights: Internal display, retention, derived alerts and redistribution permissions.
• Service: Measured delivery objectives, support path and outage notices.

Existing Dispatch and Briefing Platforms

Capabilities

An operator may already pay for a weather view within an approved flight planning, dispatch or briefing workflow. Jeppesen FliteLink says it can distribute an electronic flight folder from Jeppesen Dispatch or third-party planning systems and advertises Weather and NOTAM enrichment in one tier ^[18]. ForeFlight says its Graphical Briefing content derives from approved government sources ^[19]. DTN AviationSentry Airline Edition describes a customizable display with METAR, pilot report, NOTAM and TAF information ^[20]. These are examples of existing product capabilities, not evidence that any particular operator's installation exposes a licensed machine-readable export.

The preferred question is whether the current product already has the necessary display, configured source and audit trail. If it does, a duplicate local weather ingestion stack may add another timestamp, another failure mode, and another interpretation of which report is current. A local dashboard can sometimes deep-link to the approved workflow or receive permitted status data from it. The platform owner and the operator's designated meteorological and dispatch authorities should specify what can be shown and whether it is merely supplemental.

Adoption

Jurisdiction changes the answer. Under US Part 121, the approved adverse-weather information system is a regulatory matter ^[1]. EASA guidance identifies source selection, import, validity checks and distribution as elements of data assurance, and says supplemental sources should be evaluated by the operator (Source: www.easa.europa.eu). In Canada, Standard 725 describes dispatcher weather study duties, while Transport Canada guidance for in-flight weather displays recommends showing currency or age and validity time and clearly indicating missing data ^{[8] [21]}. That guidance addresses in-flight information; the same display attributes are sensible OCC design questions, not a claim that the advisory circular directly mandates a ground dashboard.

International distribution has its own access model. SADIS provides operational meteorological information under ICAO Annex 3 and regional plans, including traditional alphanumeric code and IWXXM XML ^[6]. Users need State Meteorological Authority approval. The SADIS API uses the Open Geospatial Consortium Environmental Data Retrieval pattern, and its licence permits integration and display in the licensee's systems ^{[6] [22] [23]}. The licence also makes backup switchover testing a user responsibility ^[23]. NAV CANADA provides most public weather tools through Collaborative Flight Planning Services; a public viewer should not be assumed to grant a bulk data or redistribution right ^[9].

Strengths and Limitations

An existing platform is strongest when it is already embedded in the operator's approved procedure and meets the needed user task. Its main limitation for a custom OCC dashboard may be access to an export, event stream or embedding right, which must be confirmed under the actual agreement. Procurement should compare the platform's integration offer with a direct public or commercial feed, not infer the answer from a product screenshot. The local dashboard specification should name the authoritative screen or document for each operational decision.

Feature Comparison

Table 1 is a jurisdiction-labelled source matrix. AWC's API product coverage and cache publication claims apply to its service, while national issue schedules and access rights must be checked in the operating jurisdiction. “Verify” marks a contract or schema question, not a documented absence.

The table separates issue cadence from distribution cadence. A one-minute cache can repeatedly contain the same hourly observation. A newly published cache can still contain a forecast issued earlier, or an amended forecast that supersedes it. The correct freshness test uses the product's own time semantics and the operator's chosen policy. It also keeps the coded report, provider transformation, and display update as distinct records.

Table 2 compares sourcing options for the same local dashboard. It is a procurement matrix rather than a ranking of forecasting accuracy or safety.

There is no public, comparable end-to-end delivery benchmark among these options in the reviewed primary documents. A procurement exercise should run the same station and advisory sample through candidate feeds and preserve the original report identifiers and UTC timestamps. It should score the resulting evidence against the operator's requirements rather than equating more map features with a better operational source.

Performance and Benchmarks

A weather-data benchmark should measure data delivery and display behavior, not assert relative forecasting skill from an API response. The minimum record for each sample is product, location or flight information region, source identifier, original coded text or source record, issue time, valid period, provider receipt time if supplied, local receipt time, parser version, and dashboard render time. FAA guidance specifically identifies issue and valid times when judging product currency ^[7]. The Weather Company notes that its METAR feature sets may contain reports with different valid times, so a single tile timestamp is an incomplete benchmark field ^[5].

Run the test against the same declared list of stations and advisory regions over a representative operating cycle. Keep the method reproducible:

• Coverage denominator: Count expected station-product or region-product combinations, then report matched, absent and untestable counts.
• Source lag: Calculate local receipt UTC minus the report's observation or issue UTC, with the report type stated.
• Transport lag: If a provider receipt time is available, calculate local receipt minus provider receipt separately.
• Completeness: Preserve coded and parsed versions and compare correction or amendment identifiers.
• Continuity: Log consecutive empty results, errors, retries, failover, and restoration.
• Display lag: Record local receipt to visible render without claiming that this measures meteorological age.
• Method: Publish sample geography, clock synchronization method, request interval and excluded records.

The absence of a public cross-provider benchmark matters because each vendor describes a different product model. CheckWX's 15-minute cache recommendation is a client-use rule ^[13]. AVWX's note that a cached response can be days old concerns a report's age (Source: support.avwx.rest). These numbers cannot be ranked on one “real time” axis. EASA's rules call for half-hourly METAR at aerodromes serving scheduled international commercial air transport operations, showing that issue cadence also varies by jurisdiction and aerodrome class (Source: www.easa.europa.eu).

For a dashboard, alerting should be conditional on source confidence. A missing SIGMET in a valid no-data response can mean no current advisory, while a transport error means the system cannot determine that state. AVWX documents its own 204 no-report case (Source: support.avwx.rest). The interface should expose which case occurred and preserve the last successful fetch time. Derived geofence alerts need a review of polygon source, validity and licence before activation.

Data Analysis and Evidence

The most useful published quantitative limits are delivery constraints and product schedules, not vendor speed claims. AWC documents 100 API requests per minute and a maximum of 400 entries for most endpoints ^[2]. CheckWX documents a maximum of 25 ICAO identifiers in one multi-station request ^[13]. The public SADIS licence says there are no direct API licence charges, while access still requires State approval and compliance with its agreement ^[23]. Those facts affect architecture and procurement, but they do not determine the operator's total cost of ownership.

A hypothetical OCC watches 160 airports. If it queried one airport per request each minute, it would make 160 requests per minute, above AWC's stated 100-request limit ^[2]. Batching or the full METAR cache would change that load. If a provider allows 25 airports per call, 160 airports require at least seven calls for one sweep, before retries or additional products ^[13]. This arithmetic is a capacity illustration only: endpoint query rules, licensing, geographic response size and actual report availability still govern a deployed design.

Table 3 gives a hypothetical example of the UTC fields a dashboard should calculate. The timestamps are invented to explain arithmetic and are not operational thresholds. The rows separate report time, local receipt and validity where applicable.

The METAR row uses 14:20 minus 13:50, or 30 minutes. The same record reached the local system at 14:02, so at 14:20 the time since local receipt is 18 minutes. Neither calculation alone proves that a report is suitable for a dispatch decision. Product-specific issued and valid periods, station reporting practice, correction status and the operator's approved procedures determine that. Transport Canada's weather-display guidance calls for age and validity time, plus clear missing-data indication, which supports exposing these separate states ^[21].

The capacity lesson is equally concrete. A centralized ingest service can poll once and distribute internally, whereas one polling loop per user multiplies calls. CheckWX documents UTC timestamps. A comparison trial should normalize every record to UTC for calculations, retain the source's original timestamp fields, and report nulls rather than manufacture a time that a source did not supply. Log each fetch attempt, response code, record count, checksum and parser result. Those measurements create an auditable local record without claiming a public vendor latency benchmark that does not exist.

Implications and Future Directions

A source decision should be made in two passes. First, operations defines the approved use: products, geography, authoritative source, required briefing or dispatch record, and escalation path. Second, information technology maps that decision to data contracts and display behavior. This order aligns with EASA's source-selection and validity-check considerations and with US Part 121's approved-system requirement (Source: www.easa.europa.eu) ^[1]. The display can improve access to information, but it does not authorize a new source or change who exercises operational control.

For implementation, turn the comparison into acceptance criteria:

• Inventory: List every route, station, alternate and flight information region in scope.
• Trace: Store the original text or source record and its issuing authority.
• Normalize: Preserve observation, issue, valid, receipt and render times as separate UTC fields.
• Clock: Monitor system clock synchronization and record calculation errors.
• Represent: Distinguish missing report, expired report, source error and parser error.
• Supersede: Apply correction, amendment and cancellation rules per product.
• Test: Compare coded and parsed values on a dated sample before enabling alerts.
• Fail over: Define whether the backup is independent or shares the same upstream source.
• Contract: Confirm permitted storage, display, derived notifications and support.
• Review: Recheck the matrix when an authority, upstream source or contract changes.

The SADIS licence explicitly names WIFS API as a backup and places switchover implementation and testing on the user ^[23]. That is a stronger and more specific failover statement than simply saying “two feeds are available.” It also shows why source independence needs to be checked: AVWX says NOAA is its default METAR and TAF provider (Source: support.avwx.rest), so pairing AVWX with direct NOAA access may not provide independent upstream observations. The application should identify the issuing report and the transport provider separately.

Machine-readable exchange is evolving. WMO describes IWXXM as software-oriented aviation meteorological exchange (Source: wmo.int). The SADIS API uses an Environmental Data Retrieval interface and still operates under approval and licence terms ^[22]. These developments favor adapters that preserve source fields and can accept new formats without rewriting the OCC screen. They do not justify a claim that coded text, XML or a particular vendor is universally best. A custom studio such as LANDING.AERO can build the integration and workflow view around an operator's systems, but its own description is of tailored operations software, not a meteorological authority or off-the-shelf dispatch platform.

Conclusion

For an OCC dashboard, choose the weather source by approved use, territory, provenance, timestamp semantics, delivery method and rights. NOAA AWC provides a well-documented public API and bulk caches for a local integration, with explicit request and entry limits. Commercial feeds provide alternative data models and potentially contractable services; their public documentation is too heterogeneous for a defensible speed or price ranking. A dispatch or briefing product already in the operator's workflow may supply the needed operational view, and its export rights should be checked before duplicating ingestion.

A useful procurement artifact is the dated product matrix above, completed for the operator's own stations and flight information regions. Put METAR observation time, TAF issue and valid times, SIGMET issue and expiry, and G-AIRMET snapshot validity into separate fields. Treat a valid no-data response, an expired report and an upstream failure as different interface states. Test every alert against original reports and the operator's approved procedure. The engineering objective is a transparent, maintainable display that shows what the source actually provided and when, so the people responsible for operational decisions can use the information within their established process.