-
Notifications
You must be signed in to change notification settings - Fork 1
Forecast Data API Details
The API to retrieve Global Forecast data can be found here: https://ads.atmosphere.copernicus.eu/how-to-api
These are split into Single Level, Multi level and Slow access categories. We’ll need to get clarification that what we are using is correct (i.e. do we require multi level data meaning different pressure/atmosphere height levels). Until then we are assuming that single level is fine and using the following options:
-
Particulate matter d < 2.5 µm (PM2.5)
-
Particulate matter d < 10 µm (PM10)
-
Total column sulphur dioxide
-
Total column nitrogen dioxide
-
Total column ozone
Using only the Single Level category means we are not required to supply a pressure level or a model level.
The date supplied will always be todays date - 1 day as we always want to query 5 days ahead and this is the maximum date value permitted in this field.
We will use 00:00 unless told otherwise.
Each of these refers to a time in hours ahead of the selected Date. To retrieve 5 days worth we will need 5 values in an array:
[ 24, 48, 72, 96, 120]
The response format specified is GRIB. This is a file that will contain the response data.
import cdsapi
c = cdsapi.Client()
c.retrieve(
'cams-global-atmospheric-composition-forecasts',
{
'date': '2024-04-18/2024-04-18',
'type': 'forecast',
'format': 'grib',
'variable': [
'particulate_matter_10um', 'particulate_matter_2.5um', 'total_column_nitrogen_dioxide',
'total_column_ozone', 'total_column_sulphur_dioxide',
],
'time': '00:00',
'leadtime_hour': [
'24', '48', '72',
'96', '120',
],
},
'download.grib')
- Response data is structured as a table with dimensions for latitude and longitude, with the corresponding values for each variable.
- We would need to perform another step to associate these values with cities
- In associating the results with a city, an algorithm needs to be thought of to derive the value for a city from many potentially numerous sources
Getting Started and Overview
- Product Description
- Roles and Responsibilities
- User Roles and Goals
- Architectural Design
- Iterations
- Decision Records
- Summary Page Explanation
- Deployment Guide
- Working Practices
- Q&A
Investigations and Notebooks
- CAMs Schema
- Exploratory Notebooks
- Forecast ETL Process
- In Situ air pollution data sources
- Notebook: OpenAQ data overview
- Notebook: Unit conversion
- Data Archive Considerations
Manual Test Charters
- Charter 1 (Comparing ECMWF forecast to database values)
- Charter 2 (Backend performance)
- Charter 3 (Forecast range implementation)
- Charter 4 (In situ bad data)
- Charter 5 (Filtering ppm units)
- Charter 7 (Forecast API input validation)
- Charter 8 (Forecast API database sizes)
- Charter 9 (Measurements summary API input validation)
- Charter 10 (Seeding bad data)
- Charter 11 ()Measurements API input validation
- Charter 12 (Validating echart plot accuracy)
- Charter 13 (Explore UI after data outage)
- Charter 14 (City page address)
- Charter 15 (BugFix diff 0 calculation)
- Charter 16 (City page chart data mocking)
- Charter 17 (Summary table logic)
- Charter 18 (AQI chart colour banding)
- Charter 19 (City page screen sizes)
- Charter 20 (Date picker)
- Charter 21 (Graph consistency)
- Charter 22 (High measurement values)
- Charter 23 (ppm -> µg m³)
- Charter 24 (Textures API input validation)
- Charter 25 (Graph line colours)
- Charter 26 (Fill in gaps in forecast)
- Charter 27 (Graph behaviour with mock data)
- Charter 28 (Summary table accuracy)
- Re‐execute: Charter 28
- Charter 29 (Fill in gaps in situ)
- Charter 30 (Forecast window)
- Charter 31 (UI screen sizes)