Esta checklist es nuestra “cinta aislante premium” contra los líos silenciosos: cosas que no rompen nada, pero te contaminan diarios, extremos, gráficas y decisiones. La idea es simple: punto único de conversión + unidades visibles + QC mínimo + tiempo en UTC. Lo demás es reforzar.

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. Antes de empezar: regla de oro

Un dato “bonito” no es un dato correcto. Si no sabemos unidad, semántica temporal y origen, no se usa para extremos, diarios ni verificación.

2. Checklist exprés (10 minutos)

1. ¿Qué unidad guardo y cuál muestro? Escríbelo (aunque sea en un README).
2. Punto único de conversión: decide dónde conviertes (ideal: en el pipeline antes de DB, o en API, pero solo en uno).
3. Unidades visibles en el panel: que cada variable tenga su etiqueta (°C, hPa, mm, km/h, W/m²).
4. Missing ≠ 0: revisa que ausencia de dato no se vuelva “0”.
5. UTC en almacenamiento: guarda timestamps en UTC y conviertes a local solo al mostrar.
6. Chequeo rápido de factores típicos: viento (×3,6), presión (×100), temperatura (±273,15), lluvia (×1000).

3. Checklist completa (1 hora, bien hecha)

3.1 Inventario de variables (lo que tienes)

• Lista variables: temperatura, humedad, presión, viento medio, racha, lluvia, radiación, UV…
• Para cada una anota: unidad del sensor/logger, unidad almacenada, unidad mostrada, resolución (decimales/pasos).

3.2 Contrato de unidades (lo que esperas)

Crea un “contrato” sencillo por variable: qué unidad esperamos en cada punto. Ejemplo:

• Presión: almacenar hPa (no Pa)
• Viento: almacenar m/s o km/h, pero uno fijo y documentado
• Lluvia: almacenar como mm por intervalo o como acumulado, pero deja claro cuál

3.3 Validación de esquema (schema validation)

• Tipos correctos (numérico vs string)
• Campos obligatorios (timestamp, variable, valor)
• Orden y nombre estable (evita “TEMP” hoy y “temp” mañana)

3.4 Flags de calidad (QC flags) mínimos

Marca el dato, no lo “maquilles”. Recomendación simple:

• OK: pasa checks
• SUSPECT: raro pero posible (no bloquea, avisa)
• BAD: físicamente imposible o inconsistente
• MISSING: ausencia real

3.5 Checks físicos y de coherencia interna

• Rangos físicos: lluvia < 0 no; radiación nocturna ~0; HR 0–100
• Coherencia viento: racha ≥ media (si no, hay problema de semántica o unidades)
• Presión: si ves 101325 y esperabas hPa → está en Pa

3.6 Checks “detecta-factor” (los 4 demonios clásicos)

• ×3,6 (m/s↔km/h): si la serie se multiplica de golpe por ~3,6 y se queda así, canta
• ×100 (Pa↔hPa): 101325 vs 1013,25
• ±273,15 (K↔°C): 293 K “parece” 293 °C si alguien olvida restar
• ×1000 (m↔mm): lluvia diaria de 0,012 m = 12 mm (ojo a escalas)

3.7 Semántica temporal (instantáneo / promedio / acumulado)

Para cada variable, fija:

• Instantáneo (valor en ese minuto)
• Promedio (media de 10 min)
• Acumulado (mm en 10 min / 1h / día)

Si no lo fijas, los derivados (diarios, extremos, intensidades) salen “bien” pero mal.

4. Pruebas rápidas (para pillar errores sin forzar)

• Comparación con estación cercana (misma masa de aire): si el viento es siempre 3–4×, sospecha factor 3,6
• Comparación con radar (para lluvia): si tienes “30 mm en 10 min” y el radar está seco, sospecha (pero ojo con convectiva localizada)
• Comparación cruzada: lluvia fuerte suele venir con señal en HR, presión y/o cambios de viento (no siempre, pero ayuda)

5. Trampas típicas (y cómo las evitamos)

• Doble conversión: DB convierte + API convierte → decide un único punto, y bloquea el resto
• Missing a cero: destruye acumulados → missing debe ser NULL/NaN y con flag
• Redondeo agresivo: oculta señales → conserva raw y muestra redondeado si quieres, pero no destruyas el original

6. Lluvia convectiva: picos reales vs errores (muy importante)

La convectiva puede dar picos auténticos que parecen “error”. Checklist para no confundirnos:

1. Duración: un error suele ser un pico aislado de 1 lectura; una tormenta deja varios puntos coherentes (aunque sea breve).
2. Coherencia con intensidad máxima del pluvio: si el pluvio tiene un límite físico/elec (tipping bucket), revisa si el pico supera lo posible.
3. Eco radar cercano (si disponible): no es prueba absoluta, pero si hay eco convectivo encima, el pico gana credibilidad.
4. Contexto: cambios bruscos de HR, rachas o temperatura pueden acompañar; si todo está plano y solo llueve “a lo loco”, sospecha.
5. Persistencia de acumulado: si el acumulado diario queda raro (ej. suma negativa o saltos atrás), puede ser error de reseteo/contador.

7. Timestamps: UTC, cambio de hora y drift del logger

• Guardar en UTC: siempre que podamos. Mostrar en local, sí, pero procesar en UTC.
• DST (cambio de hora): días de 23h/25h → los acumulados diarios y promedios deben contemplarlo.
• Drift: si el logger se adelanta/atrasa, los picos se desplazan y “parece” que algo falla en unidades. Revisa sincronización (NTP) y anota correcciones.

8. Checklist final antes de publicar extremos/diarios

1. Unidades visibles y correctas
2. Semántica temporal definida
3. QC flags funcionando
4. UTC end-to-end (o conversión controlada)
5. No hay doble conversión

9. Mini-glosario

• QC flag: etiqueta de calidad (OK/SUSPECT/BAD/MISSING)
• Semántica temporal: instantáneo/promedio/acumulado
• Drift: deriva del reloj del logger

10. Referencias y lecturas recomendadas

• Met Office
• WMO
• NOAA