Repository navigation
Radar provider for Spain / western Mediterranean (AEMET) — coverage gap and data-format constraints #1
Description
Context
I sail the Balearic Islands (western Mediterranean) and Storm Intelligence is a great fit — but the bundled radar providers leave a gap over Spain: RainViewer serves display tiles only (no raw acquisition), and Radar-DPC (Italy) / DWD (Germany) don't reach the region. So the inference tier (cells / hazards / approaching-storm) can't run over Spanish waters.
I looked into filling this and wanted to share what I found and check the best path before contributing code.
Findings
EUMETNET OPERA Open Radar Data looked ideal (max-reflectivity DBZH as GeoTIFF/ODIM-HDF5, CC BY 4.0, public S3, pan-European). But it has no radar coverage over Spain / the Balearics — sampling the composite returns nodata across the whole Spanish Med (only the edge of French radars reaches Catalonia). Spain doesn't contribute to OPERA.
AEMET (Spanish national met service) is the only source that covers the Balearics — regional radar pm (Palma), 240 km radius, PPI reflectivity, 10-minute cadence. But:
- The AEMET OpenData REST API (
/red/radar/regional/{code}) servesimage/gifonly — the OpenAPI spec exposes exactly two radar endpoints, both labelled "Imagen", with zero GeoTIFF/tiff references. - AEMET docs mention a georeferenced GeoTIFF (EPSG:4326) carrying an RGBA→dBZ
ESCALA, but it appears to live only in their bulk-download web portal — I couldn't find a programmatic route (no GeoTIFF API endpoint, no discoverable radar WMS).
What I'd like to contribute
A display-tier AEMET provider (products / latest / tile) so Spanish / Iberian / Balearic users get the AEMET regional radar as a chart overlay — a clean, spec-conformant fill for the geographic gap. Happy to PR this.
Where I'd value your guidance (inference tier)
For downloadRaw / cellsFromRaw, the only programmatically-accessible AEMET product is the palette-coded GIF. Per §7 of radar-provider-specification.md ("MUST NOT fabricate raw acquisition by saving rendered PNGs and calling them native data"), decoding the GIF palette back to approximate dBZ for cell detection goes against the letter of the spec. Before investing:
- Do you know a gridded / GeoTIFF AEMET route (or an OPERA-style source with real Spanish coverage) I've missed?
- If the palette GIF is the only option, would you consider a clearly-documented, best-effort palette-decoded
cellsFromRaw(quantized dBZ, limitations stated) — or would you prefer this provider stay display-only?
Thanks for the project — happy to do the work along whichever path fits your standards.
Activity
SFH008 commentedon Sep 13, 2026
Hi
I have been forking your project nad have exended it with AEMAT, IPMA, METEO France and NOA providers.
METEO france has been very tricky.
fakehec commentedon Sep 14, 2026
Hi Steen — nice, that's a lot of coverage.
For what it's worth I came at #1 from the same direction: there's an AEMET regional-radar provider open as #2, and a fix for the own-ship
navigation.positionbeing read as an unwrapped node as #4 — yourfix/normalize-signalk-self-valuesbranch looks like it solves exactly that same thing, so we clearly hit the same wall.A few notes from the AEMET side in case they save you time:
/red/radar/regional/pmis a two-step keyed call (metadata JSON carrying a one-shotdatosURL → then the actual GIF), the image is a 480×530 palette GIF in EPSG:4326 whose palette has to be mapped back to dBZ, and they rate-limit hard if you poll tightly (that bit us). Météo France I haven't touched — curious what made it tricky: auth, the radar-mosaic format, or projection?Are you planning to PR the IPMA / Météo France / NOAA providers up to OpenFairWind? Between your branch and #2/#4 there's a real risk of two parallel AEMET paths. Happy to rebase or fold our standalone provider in behind yours if the maintainer wants to take your architecture as the base — either way it'd be good to land this upstream so it doesn't stay stuck in forks. Is @OpenFairWind still active on merges? Mine have been open a little while.
fakehec commentedon Sep 14, 2026
One clarification, since you said "your project" — it isn't mine! This is @OpenFairWind's plugin; I'm just a contributor like you (I opened #1 and the #2 / #4 PRs, nothing more). So the person who can actually merge IPMA / Météo France / NOAA is the maintainer — which is why I'd open PRs for them rather than let them live only in a fork. Glad to compare notes as fellow contributors, though.
fakehec commentedon Sep 14, 2026
Update, Steen — I've put three of the regions we both looked at up as a PR against OpenFairWind (independent of the AEMET one, #2): #6 — IPMA (Portugal), NOAA NEXRAD CONUS, and NOAA NEXRAD Puerto Rico / USVI (the last via the IEM
nexrad-n0qWMS, since the CONUS XYZ mosaic doesn't reach the Caribbean). All keyless, display-only, with unit tests, on the existing provider contract.I deliberately left Météo France out — you were right that it's the tricky one: its radar sits behind the token-gated API Paquet Radar (15-minute composite packets on a Lambert grid), materially more work than the others. If you've already cracked MF in your fork, a PR from you for it would be very welcome — glad to review or help.
Since we've clearly been building the same thing in parallel, it'd be good to converge on OpenFairWind rather than split it across forks. 🙂
SFH008 commentedon Sep 24, 2026
Hi Hugo,
I had to rool the work bad to start and took a different approach.
I now have radar providers working for AEMET, IPMA and the Greek NOA. I have not yet looket at French radards but should be easy enough. I also added EUMET sat.
So now I have EUMET satellite as base layer and the ground radars as layers. I have now written a new storm cell detector which works independently of the DPC HRD engine. Italy has this middle layer to calculate all the values. Unfortunately that is not publicly available for Spain, Portugal and Greece.
The storm cells are showing nicely now. Next step is to work on severity. For now I have set cutoff at 25 DBZ which would be like a light rain.
fakehec commentedon Sep 24, 2026
That looks great, Steen — the EUMETSAT base + per-country ground-radar layers is a much cleaner architecture than a single-provider bolt-on, and writing a detector that doesn't depend on the Italian DPC HRD middle layer is exactly the right call for ES/PT/GR, which don't expose it.
Happy to help however is useful:
Regarding my open PRs (#2 AEMET, #6 IPMA/NOAA): since you rolled the provider work back and rebuilt it, just close them if they're superseded — no need to rebase onto the new structure unless a piece is still useful to you. Let me know which way you prefer.
Great to see this moving.
SFH008 commentedon Sep 24, 2026
And here you go for IPMA in Portugal