"See bottom for general descriptive information.

---

# Releases

## [1.9.0] 2025-12-17

### Add parameterization to auth requests
* authorization URL now defined by variable set for environment

## [1.7.3] 2025-06-05

### Make wmoCode provide \"letter\" code
* make wmoCode value a code in format of WMO 4678 code-table
* previously value was given as numerical SYNOP code
* the numerical value is inverted as best as possible, but some edge cases may not convert back precisely to what the raw text indicates because multiple things can have same numeric code
    * dust when may have been from sand
    * fog when may have been from mist
    * ice grains when may have been from snow pellets

### Add constraints to temporal parameter values
* make request fail if parameter is set to something that would obviously not correspond to available data
* are sanity checks, as still possible to specify time values for which data cannot be provided

## [1.3.0] 2025-02-03

### Add new parameter handling to select by insert time...
* inserted after datetime
* inserted through datetime

### Documentation updates

## [1.1.0] 2024-11-06

### Add TAF API with new endpoints
* spatial filters
* temporal filters
* data filters, including by stationId and flightCategory

---

# TAF API information

_last updated for v1.7.3_

For a given station only the objects associated with the latest raw TAF report will be returned in responses.

The objects in a TAF API response are only a portion of a given raw TAF report.  Each object in the API response defines a single combination of values for station, forecast, layer, and weather.

Consider a single raw TAF report such as this, where each forecast has been set on a separate line:
```
    PAPG 301726Z 3018/3118 10009G20KT P6SM -RA SCT025 OVC050 WS020/12030KT
    FM310000 12006KT 6SM -RA BR BKN015 OVC030 WS020/12025KT
    FM311000 VRB04KT 4SM -RA BR OVC007
    FM311500 12007KT P6SM -RA BKN025 OVC050
```
That raw TAF would produce 10 response objects that could be returned for a request if the parameters allowed it.
* The first forecast (line) - 2 objects, two layers (`SCT025`, `OVC050`) and one weather code (`-RA`)
* Second forecast - 4 objects, two layers (`BKN015`, `OVC030`) and two weather codes (`-RA`, `BR`)
* Third forecast - 2 objects, one layers (`OVC007`) and two weather codes (`-RA`, `BR`)
* Fourth forecast - 2 objects, two layers (`BKN025`, `OVC050`) and one weather code (`-RA`)
A response object will have one `wmoCode` value under each `layerNumber` value under each `forecastNumber` value under each `stationId`.  Compile across those fields for the complete (as allowed by request parameters) data.

See documentation for complete request parameter definitions.

Response data is in GeoJSON format.  See Postman collection for description of properties in response feature objects.

Values with units are provided in either \"default\" (mostly, but not all, imperial) or \"metric\" system.  See documentation or Postman collection for details.

## Spatial filters

These allows to select data within a specific area.  Only one may be used per request.
* Bounding box - Defines rectangular area set by furthest southwest location and furthest northeast location.
* Polygon - Defines area enclosed by series of points.  Response behavior is unpredictable if created shape is self-interesting other than last point matching first point.
* Circle - Defines area from center point and radius.  The larger the defined area, the more its shape on projected map will differ from true circle on spherical coordinates.  Constraint is set to limit radius and thus circle size.  Request will fail or have unpredictable response behavior if circle area crosses the antimeridian (180W/180E longitude).
* Corridor - Defines area from series of points defining a (not necessarily straight) line and halfwidth that tells distance from line to encompass.  Constraint is set to limit halfwidth, though line length not limited.  However response behavior is unpredictable for long distances between points.  Request will fail or have unpredictable response behavior if corridor area crosses the antimeridian (180W/180E longitude).

## Temporal filters

These allow to select based on time-related characteristics on data.  Parameters can limit responses to data valid at a particular time or within a timeframe, ingested/saved within a timeframe, and for data from forecast models corresponding to specific model run times.
* valid at - Allows to specify an exact time to limit to data valid then.
* from/until - Allows to set a timeframe to limit to data whose valid periods overlap at all with that timeframe.
* inserted after/through - Allows to set a timeframe to limit to data ingested/saved at some time within that period.  This is useful for chaining requests to continually acquire newly available data, like by setting the \"after\" time as the latest insert time seen from a previous request and the \"through\" time as the current time.
"