Un post para hablar de muchas cosas que no se tienen en cuenta al convertir de un formato de datos de radar a otro.
En un post anterior recorrimos la Torre de Babel de los formatos de datos de radar y vimos estándares como FM‑301 que prometen un lenguaje común. Pero hoy quiero plantear una pregunta incómoda:
Si dos radares de países distintos, con fabricantes diferentes, parámetros técnicos diferentes (potencia pico del transmisor, ancho del haz, ganancia de la antena…etc.) estrategias de exploración (VCP) distintas y propósitos operativos diferentes, convierten sus datos al mismo formato estándar… ¿son realmente comparables?
La respuesta corta es no. La larga es depende de lo que hayamos documentado en el camino.
Imaginemos dos archivos FM‑301 con reflectividad (DBZH). En apariencia, idénticos. Pero uno proviene de un radar calibrado hace una semana con el método de verificación de la exactitud en el posicionamiento, con corrección por atenuación y filtro de ecos fijos adaptativo para la supresión de ecos no meteorológicos. El otro lleva dos años sin calibrar, sin corrección por atenuación (porque «no era necesaria» según el fabricante) y con un filtro de clutter fijo que elimina ecos fijos en zonas urbanas. La misma variable, en el mismo formato, pero científicamente son dos mundos distintos.
La interoperabilidad real no se logra solo con unificar el contenedor. Exige que cada paso del procesamiento quede registrado en los metadatos y que las herramientas de análisis sepan interpretarlos. Vamos a desgranar qué pasos son esos y cómo se documentan (o no) en los estándares actuales.
El viaje de un dato: de la antena al archivo
Cada valor de reflectividad o velocidad radial que llega a nuestro ordenador ha pasado por una cadena de decisiones humanas y algorítmicas. Estas son, al menos, las principales etapas que debemos documentar:
1. Calibración del sistema
La reflectividad (dBZ) es una magnitud relativa que depende de la ganancia del receptor, la potencia transmitida, las pérdidas en la guía de ondas, etc. Sin una calibración rigurosa, comparar dBZ entre radares es como comparar temperaturas con termómetros sin ajustar.
- ¿Cuándo fue la última calibración? (fecha y hora).
- ¿Qué método se usó? (solar, con blanco estándar, verificación de la exactitud de apuntado, con generador de ruido, etc.).
- ¿Cuál es la incertidumbre estimada? (ej. ±1 dB).
- ¿Se ha aplicado alguna deriva de ganancia conocida?
En FM‑301, la calibración se documenta en el grupo how o en atributos específicos de la variable, pero no hay un estándar único. La convención CF recomienda atributos como calibration_date, calibration_method, calibration_uncertainty, pero su uso no es obligatorio.
2. Corrección por atenuación
La señal de radar se atenúa al atravesar la lluvia, especialmente en bandas de longitud de onda corta (C, X). Si no se corrige, la reflectividad en zonas tras la tormenta se subestima gravemente.
- ¿Se ha aplicado corrección por atenuación? (sí/no).
- ¿Qué algoritmo se usó? (ej. Hitschfeld‑Bordan, método de la atenuación específica, etc.).
- ¿Se usaron datos de otra frecuencia (dual‑wavelength) o de un modelo?
- ¿Cuál era la atenuación específica estimada (dB/km)?
3. Filtrado de ecos fijos (clutter)
Los ecos de terreno, edificios y otras estructuras fijas contaminan la reflectividad y la velocidad. Los filtros (en el dominio del tiempo o en el dominio de las frecuencias) los eliminan, pero un filtro mal ajustado (o incluso bien ajustado, en dependencia de cuan baja sea la velocidad promedio en el objeto meteorológico) puede eliminar también precipitación real (o parte de ella), especialmente en zonas de montaña. El peor de los casos ocurre cuando hay ecos muy potentes de ecos fijos, cuya velocidad romedio no es cero (proveniente de vegetación susceptible al viento) y el objeto meteorológico, proveniente de precipitaciones estratiformes tiene baja velocvidad promedio. En ese caso el filtrado resulta muy agresivo y a su salida la precipitación ha perdido parte de su potencia real.
- ¿Qué filtro se usó? (Gaussian clutter map, filtro adaptativo, etc.).
- ¿Se usó un mapa de clutter fijo o adaptativo?
- ¿Cuál es el umbral de detección?
- ¿Se ha diferenciado entre clutter de terreno y clutter anómalo (por propagación anómala)?
4. Corrección del perfil vertical (VPR)
La reflectividad varía con la altura incluso dentro de la misma precipitación. Si se comparan PPIs a diferentes elevaciones o se construyen mosaicos sin corregir, los sesgos son enormes.
- ¿Se ha aplicado corrección del perfil vertical? (sí/no).
- ¿Qué método se usó? (ej. VPR climatológico, VPR dinámico, etc.).
- ¿Se usaron datos de modelos o de otros radares?
5. Corrección de la velocidad radial (de‑aliasing)
La velocidad radial tiene un intervalo de Nyquist: velocidades por encima de ese límite se «doblan» (fold). El de‑aliasing (yo lo llamé de-aliasamiento en español) intenta deshacer ese doblamiento, pero no es trivial.
- ¿Se ha aplicado de‑aliasing? (sí/no).
- ¿Qué algoritmo se usó? (ej. de‑aliasing por continuidad espacial, por comparación con modelos, etc.).
- ¿Cuál es el intervalo de Nyquist original del sistema? (±V_max).
- ¿Se usaron múltiples PRF para extender el intervalo?
- ¿Se tuvo en cuenta el deterioro de la calidad de la estimación de los momentos por usar dos frecuencias de repetición (5/4, 4/3, 3/2)?
6. Calidad de la estimación
No todas las mediciones son igual de fiables. Dependen de la relación señal/ruido, del número de pulsos promediados, de la atenuación y de muchas correcciones. Hay que tener presentes la exactitud, la precisión y la resolución conque se hicieron.
- ¿Se incluye un índice de calidad? (ej. SNR, codificación de calidad por bits, etc.).
- ¿Se ha umbralizado por algún criterio de los índices calidad que entrega el procesador de señales?
7. Estrategia de exploración (VCP)
El volumen de datos no es solo un conjunto de PPIs a diferentes elevaciones. La secuencia de elevaciones, la velocidad de giro, el número de pulsos por rayo… todo afecta a la representatividad del muestreo.
- ¿Qué VCP se usó? (nombre o descripción).
- ¿Cuál fue la secuencia de elevaciones y tiempos?
¿Qué recoge FM‑301 y qué hace xradar?
FM‑301, basado en CfRadial 2.1 y las convenciones CF, es un estándar de estructura y metadatos mínimos. Contiene atributos estándar como gain, offset, units, coordinates, y grupos como quality_control donde se pueden añadir anotaciones libres. Pero no obliga a documentar todos los pasos anteriores. Depende de la buena voluntad del productor de datos.
CfRadial 2.1 define, por ejemplo, el atributo calibration como un grupo que puede contener campos como calibration_date, calibration_method, calibration_standard. Pero no define qué hacer si no se ha calibrado, o si se usó un método no listado.
Xradar, la biblioteca de openradar, lee todos estos atributos y los expone como metadatos en la estructura de xarray. Pero no valida si la cadena de procesamiento está completa (y habría que definir qué es completa) ni aplica correcciones por sí misma. Es una herramienta de traducción, no de control de calidad. Si el archivo FM‑301 no incluye el método de de‑aliasing, xradar no lo puede adivinar.
El problema de fondo: la interoperabilidad semántica
Convertir dos archivos al formato FM‑301 es como poner dos libros en el mismo idioma, pero si uno es una traducción literal y el otro una adaptación libre, el contenido no es equivalente. La información de procedencia (lineage) es el verdadero pegamento de la interoperabilidad.
Ejemplo real:
El radar A (EE.UU.) opera en modo VCP 212 (14 elevaciones, 5‑6 minutos de ciclo) y aplica corrección por atenuación usando el algoritmo de la atenuación específica con datos de doble polarización. El radar B (Europa) opera en VCP 21 (9 elevaciones, 10 minutos) y no corrige por atenuación porque asume que en banda S no es necesaria (lo cual es falso para tormentas intensas). Ambos generan archivos FM‑301 con DBZH. Si un investigador los junta para hacer un estudio de precipitación, sin metadatos que indiquen estas diferencias, el sesgo será enorme y la conclusión, errónea.
Un cuestionario para el productor de datos
Propongo que, junto al archivo de datos, el productor responda a un cuestionario mínimo como este (que podría ir en los metadatos how y quality_control) o uno más elaborado que se defina:
- Calibración:
- Fecha de última calibración absoluta:
- Método de calibración:
- Incertidumbre estimada (dB):
- ¿Se han aplicado correcciones de deriva en tiempo real?
- Filtrado de clutter:
- Algoritmo usado:
- ¿Se usó mapa de clutter? (sí/no) – Fecha del mapa:
- ¿Se aplicó filtro adicional por textura?
- Atenuación:
- ¿Corregida? (sí/no)
- Algoritmo:
- ¿Se usaron datos de doble polarización? (sí/no)
- Perfil vertical:
- ¿Corregido? (sí/no)
- Método:
- Fuente de los datos del perfil (climatología, modelo, otro radar):
- Velocidad:
- De‑aliasing aplicado: (sí/no)
- Algoritmo:
- Intervalo de Nyquist original (m/s):
- ¿Se usaron múltiples PRF?
- Control de calidad:
- ¿Se incluye SNR o índice de calidad?
- Umbral de SNR mínimo aceptado:
- Otros criterios de rechazo:
Hacia un estándar de procedencia
La comunidad de datos científicos lleva años trabajando en el concepto de procedencia (provenance). Estándares como W3C PROV o el modelo de procedencia de OGC (PML) podrían adaptarse al contexto radar, pero aún no hay una implementación específica.
Mientras tanto, nuestra mejor arma es la documentación meticulosa en los metadatos y la educación de los usuarios para que no den por sentado que dos archivos con el mismo formato y variable son directamente comparables. Herramientas como xradar pueden ayudar a visualizar estos metadatos, pero el juicio final sobre la comparabilidad sigue siendo del científico.
Tener todo muy bien documentado aun no nos garantiza que los datos de dos radares sean comparables. Pongamos un ejemplo: uno de los radares solo adquiere los tres ángulos más bajos, el otro adquiere 14 ángulos (y ninguno de ellos coincide con los tres del otro). Los volúmenes de datos pueden tener muy pocos puntos de comparación.
Reflexión final (y personal)
Cuando diseñamos el formato OBS en Cuba en 1995, no podíamos imaginar la complejidad de los estándares futuros. Pero sí teníamos claro que, si no documentábamos cómo se había obtenido cada dato (calibración, estrategia de exploración, filtros), el dato perdía su valor. Por eso incluimos campos en las cabeceras de los archivos OBS para registrar cosas adicionales. No era perfecto, pero era un comienzo.
Ahora, con FM‑301, tenemos una oportunidad dorada para hacerlo bien. Pero solo si la comunidad se toma en serio la documentación de la cadena de procesamiento. La conversión de formato es el primer paso; el segundo, y más difícil, es la interoperabilidad semántica. Por suerte, el Universo se está contrayendo, me refiero metafóricamente a que hay menos fabricantes de radares, por tanto, hay menos diversidad de formatos y de algoritmos. Ahora el gran consorcio italiano Leonardo es dueño de los dos más grandes fabricantes: EEC que conserva su nombre original y Gematronik, que ha cambiado varias veces de nombre y ahora es Leonardo Germany.
Como siempre, el reto no es solo técnico, sino también cultural. Y, como en la Torre de Babel, el verdadero milagro no sería hablar todos el mismo idioma, sino entendernos a pesar de nuestras diferencias.
Yo creo que estamos necesitando un software que no solo convierta a un formato (FM-301, por ejemplo) sino que inspeccione toda esta miriada de correcciones que pueden o no hacerse sobre unos datos de radar, que evalue la estrategia de exploración utilizada y compare los parámetros técnicos de cada radar y le haga un informe al investigador que va a usar los datos de varios radares para que sepa qué tiene y qué no y qué debe averiguar con el operador para estar seguro antes de traducir el formato. Yo lo llamaría LAMULA™ Inspector, fantaseando un poco a futuro.
Referencias citadas:
- CfRadial 2.1 (Conventions for Radar Data in netCDF). Unidata.
- COST 717 Working Document (2003). HDF5 Information Model for Weather Radar Data.
- Saltikoff, E. et al. (2019). The weather radar data archive. BAMS.
