Adding the [ES-AEMET] ZAR radar dataset

[jaimecasari]

ES - AEMET

Short description

Single-site AEMET weather radar reflectivity dataset for the Zaragoza radar (ZAR), derived from PPI radar products and converted into a CF/MLCAST-compliant Zarr archive. The dataset contains equivalent radar reflectivity factor fields in dBZ, stored on the original radar grid with 2D latitude/longitude coordinates, a 10-minute temporal resolution, and temporal coverage from 2020 to 2024.

🗂️ Metadata

• 📛 Dataset Name: ES-AEMET-radar_reflectivity-ppi_ZAR
• ⏰ Last Update: 2026-04-29
• 📅 Update Frequency: Every 10 minutes / Periodic
• 📏 Spatial Resolution: 1 km x 1 km
• ⏱️ Temporal Resolution (Timestep): 10 minutes
• 📐 Dimensions: 410 x 562 pixels
• 🗄️ File Format (example filename): Zarr v3 (ES-AEMET-radar_reflectivity-ppi_ZAR_2020-2024.zarr)
• 🗜️ Archive structure (example filename): One Zarr store containing the full temporal archive (ES-AEMET-radar_reflectivity-ppi_ZAR_2020-2024.zarr)
• 🔑 License: [CC-BY-4.0]([https://creativecommons.org/licenses/by/4.0/)](https://creativecommons.org/licenses/by/4.0/)%60)
• 🌍 Country Coverage: Spain
• 🌐 Geographical Coverage:
  • 📍 North Bound Latitude: 43.89
  • 📍 East Bound Longitude: 2.43
  • 📍 South Bound Latitude: 39.54
  • 📍 West Bound Longitude: -3.52
• 📊 Variables (Units):
  • Reflectivity (dBZ)
• 📬 Maintainer: Agencia Estatal de Meteorología (AEMET)
• 🕒 Temporal Coverage:
  • ⏳ Start Time: 2020-01-01
  • ⏳ End Time: 2024-12-31
• 🧭 Reference System Identifier: EPSG:4326>
• 🔗 Identifier: "N/A"
• 📜 Data lineage: Raw AEMET radar PPI files from the Zaragoza radar (ZAR) were retrieved from the AEMET Big Data platform. The original NetCDF files were inspected, harmonised and converted into a single Zarr archive. During processing, the main radar variable was standardised as equivalent_reflectivity_factor, spatial coordinates were preserved as 2D latitude/longitude grids, CF metadata were added, and a spatial_ref coordinate was included. Monthly intermediate Zarr stores were generated and later merged into a final multi-year archive covering 2020–2024.
• ⚠️ Use Limitation: Access to raw data requires authorization from AEMET Big Data platform.

🔗 Resources

• 📥 Download URL: [AEMET Big Data Platform]([http://bigdata.aemet.es/bigdata/inicio)](http://bigdata.aemet.es/bigdata/inicio)%60) (restricted access, registration required)
• 📄 License URL: [CC-BY-4.0]([https://creativecommons.org/licenses/by/4.0/)](https://creativecommons.org/licenses/by/4.0/)%60)
• 📄 Other URL: [AEMET OpenData]([https://opendata.aemet.es/)](https://opendata.aemet.es/)%60) (public API, does not include radar reflectivity products)

📚 Supplemental Information

• 🌐 [AEMET Big Data Portal]([http://bigdata.aemet.es/bigdata/inicio)](http://bigdata.aemet.es/bigdata/inicio)%60) (main access point for radar data, restricted)
• 🌐 [AEMET OpenData]([https://opendata.aemet.es/)](https://opendata.aemet.es/)%60) (public datasets and API)

[jaimecasari]

We’ll ask Leif for the upload credentials, unless you’d like to check something first.

[franchg]

Hi @jaimecasari! Super cool and wonderful contribution!

I am pasting here the questions I anticipated on slack:

• I see that the dimension is 410 x 562 pixels and the proejction is EPSG:4326 (so the unit is in degree). I presume that the original data would have been in projected coordinates (meters) with 1km pixels with 480x480 resolution. Is there a reason why you are using the  410x562 lat,lon version instead of the 480x480 product with square pixels? I am asking this just because when using lat, lon the image then looks stretched (1 pixel is less than 1km on the horizontal and more than 1km on the vertical) so the model may possibly underperform when training on a "stretched grid". Any thoughts on this @leifdenby ?

• If you want I can help re-projecting the data on a regular 480x480 grid. Is the original data in geotiff format? If so, can you post the output of gdalinfo example_tiff_file.tif?

• Can you also post a screenshot or the output of the validator?

Thanks!

[jaimecasari]

Hi @franchg!

You’re absolutely right. The projection wasn’t adequate. We’re switching to EPSG:25830, which gives us square pixels in meters. Here’s the gdalinfo for the new projection (please let us know if you see something wrong):

We’ll need to make a few updates to both the code and the dataset before uploading everything. As soon as the dataset is ready, we’ll send you a screenshot from the validator.

Thanks a lot for your help!

[leifdenby]

Fantastic that you're already working on this @jaimecasari! If you have any issues with running the validator @jaimecasari, or need suggestions around the transformation tooling too.

[franchg]

I would say that using EPSG:25830 is perfect @jaimecasari! That makes the pixels prefectly square :)

[jaimecasari]

Now we're exceeding the resoluton by 0.4m.

[franchg]

@leifdenby I suggest to relax some more the ~1km check on the validator. I would allow anything up to 1.1km (so 10% more than 1km is fine). That should accomodate any possible mistmach due to re-projections. If you agree I can open a PR

[jaimecasari]

This is the validator output (in this case, the Zarr with SRI):

Do you think it is ok to upload?

We still need to upload the repository showing how to transform the raw data into Zarr, but some code cleaning is still pending.

The pixel size still exceeds the limit until the limitations are relaxed.