Awesome
Forecast Extension Specification
- Title: Forecast
- Identifier: https://stac-extensions.github.io/forecast/v0.1.0/schema.json
- Field Name Prefix: forecast
- Scope: Item, Collection
- Extension Maturity Classification: Proposal
- Owner: @m-mohr
This document explains the Forecast Extension to the SpatioTemporal Asset Catalog (STAC) specification. It defines some high-level fields to get a basic understanding of weather forecast data. Some fields may also be applicable for climate forecast data, but it hasn't been written specifically for that domain.
- Examples:
- Item example for an specific time: An example STAC Item for a forecast covering a specific instance in time
- JSON Schema
- Changelog
Fields
The fields in the table below can be used in these parts of STAC documents:
- Catalogs
- Collections
- Item Properties (incl. Summaries in Collections)
- Assets (for both Collections and Items, incl. Item Asset Definitions in Collections)
- Links
| Field Name | Type | Description |
|---|---|---|
| forecast:reference_datetime | string | REQUIRED. The reference datetime: i.e. predictions for times after this point occur in the future. Predictions prior to this time represent 'hindcasts', predicting states that have already occurred. This must be in UTC. It is formatted according to RFC 3339, section 5.6. |
| forecast:horizon | string | The time between the reference datetime and the forecast datetime. Formatted as ISO 8601 duration, e.g. PT6H for a 6-hour forecast. |
| forecast:duration | string | If the forecast is not only for a specific instance in time but instead is for a certain period, you can specify the length here. Formatted as ISO 8601 duration, e.g. PT3H for a 3-hour accumulation. If not given, assumes that the forecast is for an instance in time as if this was set to PT0S (0 seconds). |
Additional Fields from other extensions
| Field Name | Type | Description |
|---|---|---|
| datetime | string | REQUIRED. The forecast datetime. It follows the definition in the STAC Common Metdata. If the forecast is not only for a specific instance in time but instead is for a certain period, you should use start_datetime and end_datetime and set datetime either to reflect the start_datetime (recommended) or to null. |
| start_datetime / end_datetime | string | The forecast start and end datetime. It follows the definition in the STAC Common Metdata. Only use these fields if the forecast is for a period (and as such forecast:duration is not PT0S). |
| expires | string | The datetime until the forecast is valid or gets superseded by a new forecast. It follows the definition in the Timestamps Extension. |
| deprecated | string | Set this to true if a newer version of the forecast is available. It follows the definition in the Version Extension. |
Note: The fields mentioned above don't use the forecast: prefix!
It is also recommended to implement the Version Extension and use it to "deprecate" old forecasts and link between forecasts with the same forecast datetime using the given relation types.
Media Types
You can use any file format, but here is a list of common media types for forecast assets that have not been listed yet in the list of common media types in STAC:
| Type | Description |
|---|---|
application/wmo-GRIB2 | GRIB2 file (usually with the file extension .grb2 or .grib2) |
application/x-netcdf | NetCDF file (usually with the file extension .nc) |
Contributing
All contributions are subject to the STAC Specification Code of Conduct. For contributions, please follow the STAC specification contributing guide Instructions for running tests are copied here for convenience.
Running tests
The same checks that run as checks on PR's are part of the repository and can be run locally to verify that changes are valid.
To run tests locally, you'll need npm, which is a standard part of any node.js installation.
First you'll need to install everything with npm once. Just navigate to the root of this repository and on your command line run:
npm install
Then to check markdown formatting and test the examples against the JSON schema, you can run:
npm test
This will spit out the same texts that you see online, and you can then go and fix your markdown or examples.
If the tests reveal formatting problems with the examples, you can fix them with:
npm run format-examples