The 'Raw' METAR format is one of the most common weather formats used globally for the transmission of observational weather data. The reports are issued with a predictable schedule or when meteorological conditions vacate defined parameters, and since the METAR format is standardised through the International Civil Aviation Organization (ICAO), the language and data presented within the report is easily understood and translated by flight and/or operational aircrew in most parts of the world.

In this article we'll show basic results that might be returned using our own METAR API - the results of which were shown a while back by way of some basic graphs (albeit via an earlier version of the API). While we archive meteorological data from numerous sources that permit feature-rich animations and other graphics, the METAR report is rather bland and boring in comparison. However, if you're in the field of aviation safety investigation (as we are), or you're required to analyse historical airport trends, it'll come in quite useful.

The API can be used to return weather information in a number of ways, and only a small portion of data is presented for this cursory introduction. Requests that return formatted data for Google and other charting services, graphs, and so on, are all excluded for the sake of brevity.

The Result

Requests should be made to https://api.beliefmedia.com/platform/sources/metar/metar.json. A number of parameters determines what information is returned.

Browsing Metars

Unless a station (or station="xxxx") is part of your request URL, the results will return YSSY (Sydney). Additionally, if the type is omitted we'll browse results by default. A request to metar.json?apikey=xxxxx&type=browse unfolds as follows.

Pagination can be altered with pg (the page number) and number (the number of results). In all example provided on this page, the order may be altered with order=desc or order=asc.

Current Date and Full Day Reports

To return reports for today only, or reports issued on the current UTC date, use metar.json?apikey=xxxxx&type=today. Results are not paginated and they're returned in a manner identical to the browsing results. To return reports for the last 24 hours (useful when building trending graphs), use metar.json?apikey=xxxxx&type=day. If no station is provided, Sydney (YSSY) results are returned by default. Results are not paginated.

Searching Metars

METARs may be searched via a date range and/or by METAR text. To search via a date range, a start date and/or end date should be provided. The start and end times may be provided in a 6-figure date format (eg: 20180405), a UNIX timestamp, or a date/time string formatted exactly as follows: 23-december-2018-1035. A request made to metar.json?apikey=xxx&type=search&start=20180404&end=6-april-2018-0100&search=nosig returns (in part) the following:

The value of searching free text comes from returning results that might show a particular weather type, or those that contain INTER periods, etc. Results are paginated.

METAR Data

For each report we provide a result that translates portions of the data into a 'human readable' format... or at least a format that's more easily used in other applications. Parsing METAR data can often be problematic because of the human editing that often takes place, the variances that might apply from country to country, and simply the order or manner in which the report is rendered. That said, we chop the report up into pieces and return it as basic data whenever the information complies with an ICAO format. For example, to return a result for KJFK (New York) we'll use metar.json?apikey=xxx&id=z1ZY. The result:

If the wind is varying we'll return that data in the wind array. Where there's a FM, INTER, or TEMPO period in the forecast, that data is also returned. In fact, just about every METAR variable is returned (there's too many variations to provide examples). An example METAR that shows the data discussed is as follows (metar.json?apikey=xxxxx&id=mZ8A):

Note that we don't break down the changes (INTER, TEMPO, FM etc) into smaller chunks. To do so, add complete=yes to your request URL. The primary purpose of returning the results as above was to extract data for wind, dewpoint, humidity, temperature, wind, and other common weather information... so we generally didn't worry too much about returning information that would rarely be used.

PHP Functions

A super-simple function to return search and browsing data is shown below. In reality, you'll want to create an array of options and just merge them with defaults (a long list of arguments isn't a very clever option). We've written the function for illustrative purposes only.

To return a single report, a function as follows will suffice.

Considerations

• We've provided snippets of code in the past (including a WordPress plugin) that would return various types of aviation weather reports - including METARS.
• Our Social Media & Marketing Platform has supported the generation of 'reports to Twitter' for some time, although it's been one of the less utilised features for obvious reasons. While we migrate many of the features of our platform over to the API-centric system, we've disabled adding new airport stations.
• We archive data dating back to around 2000. However, we regularly archive data leaving around 2 years of reports searchable. To enable a full search, use full=yes in the request URL.
• Each report is sent to Twitter to its own dedicated account. We've only just started recording the tweet ID, and this is now returned in the JSON response when available.
• We record weather data from numerous sources... most of it without a mass-market. If you're interested, please make contact with us.
• To request data from an earlier version of the API, use version=0.2 (where 0.2 is the version you're requesting). To avoid compatibility issues, it's good practice to include the version in all requests.