Historical meteorology supports environmental assessment, air dispersion, climate studies and renewable energy work. Finding a file is only the beginning. We need to know whether it contains station observations or gridded estimates, which variables it holds and how it can become a suitable model input. My original posts examined two different routes: the transition to GHCNh for surface stations, and access through NASA POWER when a gridded historical record is useful.
Why the ISD transition mattered
The Integrated Surface Database, or ISD, was familiar to many dispersion modellers. It brought together weather station records from around the world, and users developed established workflows for preparing those observations in AERMET and producing the SFC and PFL files used by AERMOD.
Moving to a new NOAA product was therefore more than a change of name. Users needed to establish how newer years would be supplied, understand a different file structure and check whether their processor release could read it. That matters particularly when projects rely on open data rather than a budget for purchasing preprocessed records.
What GHCNh provides
NOAA describes Global Historical Climatology Network hourly as the next-generation replacement for ISD. It contains hourly and synoptic observations from fixed land stations and brings multiple sources into common formats and organised station records. Variables can include wind, temperature, dew point, humidity, pressure, cloud, visibility and precipitation, according to station availability. [1]
The development concerns organisation and quality information as well as volume. Station metadata and quality flags should therefore be retained and understood, not discarded after extracting the numerical columns. A variable may be available for only part of the record or have substantially different completeness between years.
Modern formats and workflow compatibility
Bulk downloads are available in PSV and Parquet formats. These support large datasets and automated or cloud processing, but formats are not interchangeable in every tool. The relevant question is which format the next processing step actually accepts.
In my post, I highlighted how a source transition can interrupt an apparently stable workflow. New observations become available while an older processor cannot recognise their structure. Intermediate conversions may then be necessary. Each additional transformation needs a documented method so its effect can be reviewed.
What changed in AERMET v26135
I discussed AERMET v26135, part of EPA’s 2026 updates, including support for GHCNh within the surface-data workflow. The change bulletin records the addition of READ_GHCN in mod_surface.f90 and changes to accommodate the new data type. Consult that documentation for exact formats and limitations rather than assuming that every similarly named file is equivalent. [2]
Reading a file is different from downloading it. GHCNh support does not mean AERMET automatically visits NOAA and obtains observations. The user still selects a station and period, downloads suitable records, prepares control files, runs processing and checks messages. Support in commercial interfaces should likewise be checked against the actual installed product version, rather than an old announcement about planned updates.
Station selection is not a distance-only decision
Wind, temperature, cloud, pressure and humidity are not simply boxes to fill before software will run. They influence the representation of pollutant transport and dispersion. I therefore review completeness, timing, units and missing values alongside location, elevation, surface conditions and coastal or obstruction influences.
A nearby station can represent a different environment. Stations or instruments may also change during a historical period. The nearest site is not automatically best; the study needs an explanation of suitability and an account of remaining gaps or limitations.
When a suitable station is unavailable
In another post I introduced NASA Prediction of Worldwide Energy Resources, or POWER, as a way to access open meteorological and energy-related data by coordinates. The absence of a nearby station does not mean there is no historical information to investigate. Its Data Access Viewer allows a user to select a location, variables and period and obtain outputs without a traditional bespoke data request. [5]
The source is different, however. Selecting a point does not create a weather station there. POWER distributes scientific products based on modelling, data assimilation and observations. The source, grid and coverage of each requested variable need to be understood; meteorological and solar products do not necessarily share the same specifications.
What MERRA-2 and GEOS mean
Part of POWER’s meteorology relies on MERRA-2, a reanalysis record beginning in 1980 within the Goddard Earth Observing System, or GEOS, family. Reanalysis reconstructs atmospheric conditions through time using physical modelling and available observations. It is not a process in which one satellite image directly supplies every required weather variable. [3]
Product specifications are clearer than describing every grid cell as a fixed-size square. NASA documents a 0.5° latitude by 0.625° longitude meteorological source grid for the relevant products, with different resolutions for some solar data. [4] GEOS-IT supplies a near-real-time extension whose values are replaced as MERRA-2 becomes available in the archive. [3] A single source name or resolution should therefore not be assigned to every output.
From coordinates to a defensible use
In POWER I select location, variables and period, then preserve the file definitions, units and time conventions. Such records can support exploratory analysis, historical patterns and energy or climate applications. Extracting a grid cell does not make it a local observation or an automatically suitable input for every dispersion model.
Regulatory modelling involves further questions about representativeness, acceptance, processing and variable compatibility. A station record, WRF-derived dataset or another product may be appropriate, but the choice must follow the study requirements rather than download convenience alone.
The record I retain with the study
I keep source and version, station or coordinates, period, metadata, quality flags, processor release, conversion steps and execution messages. Outputs are reviewed before moving to AERMOD. Creating an SFC and PFL file successfully is not, by itself, evidence that the underlying selection was sound.
That makes meteorology an understandable part of the study’s technical argument instead of a dependency obtained only to make the software run. Official product and processor documentation remain important as these workflows evolve.
References & original writing
Adapted and expanded from the author’s LinkedIn writing. Technical references are listed below.
