Si los datos meteorológicos fueran una peli, los metadatos son los subtítulos: sin ellos, puedes “entender algo”… pero te pierdes lo importante y acabas sacando conclusiones raras. Aquí comparamos métodos para gestionar metadatos y control de calidad (QC) sin dolor.

Este artículo forma parte del tema Datos de calidad en WikiMeteo.es, donde reunimos conceptos y guías prácticas para entender mejor el tiempo y el clima.

1. Qué es y por qué importa

Gestionar metadatos es decidir qué significa cada dato y bajo qué condiciones se generó: zona horaria, muestreo, agregación, unidades, resolución, firmware/pipeline, ubicación, mantenimiento, etc. Sin eso, comparar periodos o estaciones es como comparar naranjas con tornillos.

2. Idea clave en 30 segundos

• En una frase: el mejor método es el que reduce confusiones y deja rastro de los cambios
• Señal típica: si cambias algo (sensor/pipeline/hora) y no lo registras, la serie “miente” sin querer
• Confusión común: “si se ve bien en la gráfica, está bien” (spoiler: no siempre)

3. Métodos habituales (qué son)

• Bitácora manual: anotas cambios y mantenimiento (simple, muy útil, pero depende de constancia).
• Metadatos embebidos: el dato viaja con campos como timeZone, units, sampling, pipelineVersion.
• Validación por esquema (schema validation): reglas de “forma” del dato (campos obligatorios, tipos, rangos, unidades).
• QC por reglas: checks automáticos de rango, saltos, persistencia, coherencia.
• Comparación externa: con estaciones cercanas, radar/satélite o un baseline/climatología.

4. Cuándo usar cada enfoque (sin liarla)

• Si estás empezando o vas solo: bitácora manual + 5–8 flags simples (te da control real).
• Si publicas datos o los compartes: metadatos embebidos + schema validation (evita que el dataset sea “ambigüo”).
• Si tienes varias estaciones/pipelines: versionado + comparaciones externas (detecta cambios silenciosos).
• Si te importan extremos reales (convectiva/rachas): QC con severidad (sospechoso vs inválido) para no cargarte eventos.

5. Tiempo y timestamps (UTC, cambio de hora y drift)

• Recomendación práctica: guarda en UTC y convierte al mostrar (con TZ explícita).
• Cambio de hora: algunos días tienen 23/25 horas; si no lo contemplas, rompes diarios y acumulados.
• Drift del logger: el reloj se va; si no sincronizas, se desplaza el ciclo diurno.

6. Checks automáticos con flags (paquete mínimo)

• FLAG_MISSING: faltan datos en una ventana esperada.
• FLAG_DUPLICATE_TS: timestamps repetidos (reintentos/parsing).
• FLAG_OUT_OF_RANGE: fuera de rango físico razonable.
• FLAG_STEP: salto brusco no plausible para el intervalo.
• FLAG_STUCK: variable clavada (sensor congelado o comunicación).
• FLAG_TIME_OFFSET: desfase horario detectado (UTC/local/DST/drift).
• FLAG_RESOLUTION_CHANGE: cambia el número de valores únicos (redondeo o firmware).

7. Ejemplos reales rápidos (pluviómetro y proveniencia)

• Pluviómetro: un pico breve puede ser real en convectiva; antes de marcarlo como error, mira coherencia temporal, huecos/duplicados y (si puedes) radar.
• Proveniencia: si un pipeline aplica suavizado o relleno, debes marcarlo; si no, comparar con otro dataset es injusto.
• Cambio de agregación: pasar de “instantáneo” a “media 10 min” cambia máximos/rachas; sin metadato, parece que el clima cambió.

8. Errores comunes

• Mezclar UTC y hora local sin dejarlo claro
• No registrar mantenimiento (luego no sabes por qué cambió la serie)
• QC agresivo que elimina extremos reales
• Confiar en una sola señal (una métrica o una gráfica bonita)

9. Buenas prácticas

• Metadatos mínimos obligatorios + changelog corto pero constante
• Flags automáticos con severidad (sospechoso vs inválido)
• Schema validation para no aceptar “basura bien peinada”
• Comparar siempre “periodos comparables” (mismo muestreo/unidades/pipeline)

10. Resumen y claves finales

• Bitácora + metadatos embebidos = base sólida
• Schema validation evita ambigüedad y errores de forma
• QC por flags detecta fallos sin destruir eventos reales
• El tiempo (UTC/DST/drift) es el gran saboteador silencioso
• Proveniencia y versionado son la diferencia entre “dato” y “producto fiable”

11. Mini-glosario

• Proveniencia: de dónde viene el dato y qué transformaciones sufrió
• Schema validation: validar estructura, tipos y reglas del dataset
• Flag: etiqueta de calidad (p. ej., sospechoso/invalidado)
• Agregación: cómo se resume el dato (media, máximo, total) y en qué ventana

12. Referencias y lecturas recomendadas

• ECMWF (documentación y guías de datos)
• Copernicus (productos y control de calidad)
• WMO (buenas prácticas y guías)