Los errores de unidades y conversiones rara vez son “un número mal puesto”. Casi siempre son un fallo de cadena: algo cambia en el sensor, en el logger, en el software o en los metadatos… y el dato llega con otra unidad (o se convierte dos veces). Lo peor: muchas veces el valor sigue pareciendo creíble. Aquí vas a entender qué se rompe, por qué se rompe y cómo detectarlo sin volverte loco.

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é se rompe (y por qué importa)

Se rompe la coherencia: el mismo número deja de significar lo mismo. Eso altera extremos, comparaciones entre estaciones, umbrales de alertas y cualquier análisis. Un error de unidades es peligroso porque puede dar una historia meteorológica falsa.

2. Idea clave en 30 segundos

• En una frase: cuando el dato cambia de escala u offset sin motivo meteorológico, casi siempre es un problema de conversión o definición del producto.
• Señal típica: “a partir de tal día” todo el viento es 3,6 veces menor o la presión aparece como ~101000.
• Confusión común: pensar que es un episodio real cuando en realidad es un cambio técnico (logger/API/panel).

3. Cómo se cuela el fallo (la cadena típica)

Sensor → logger → fichero/API → base de datos → panel. Un fallo en cualquier punto puede cambiar unidad, duplicar conversiones o mezclar tipos de dato (instantáneo vs agregado). Si la unidad no viaja como metadato, alguien “asume” y ahí nacen los líos.

4. Los 6 mecanismos más típicos (explicados fácil)

• Doble conversión: el logger ya convierte (por ejemplo a km/h) y el panel vuelve a convertir (m/s→km/h) por rutina.
• Cambio de fuente: cambias de API o proveedor y la unidad por defecto cambia (Pa vs hPa, m/s vs kt, mm vs in).
• Metadatos ausentes o incorrectos: el dato llega sin “unit” y el sistema lo etiqueta mal; o el metadato se queda viejo tras una actualización.
• Mezcla de productos: confundir acumulado con intensidad (mm vs mm/h) o racha con media (definición operativa).
• Tiempo y UTC: el día “corta” mal y los acumulados diarios quedan desplazados (parece que llueve en el día equivocado).
• Redondeo/resolución: al convertir o re-muestrear cambian los escalones (muy típico en lluvia por vuelco).

5. Tiempo, UTC y acumulados (por qué parece una unidad pero no lo es)

En lluvia, radiación y algunos extremos, el tiempo es parte de la definición. Si pasas de hora local a UTC sin control, el acumulado diario puede “moverse” de día. No es que la unidad sea incorrecta: es que el intervalo que estás sumando ya no es el mismo.

6. El papel del QC (control de calidad) y los flags

El QC no “arregla” la realidad: avisa. Lo ideal es tener flags simples que se encienden cuando algo huele a conversión/unidad. No necesitas IA: con reglas claras ya se detecta lo gordo.

7. Tabla de síntomas y causa probable (resolver en 5 minutos)

• Todo el viento cae a ~1/3,6 del histórico: m/s interpretado como km/h o conversión doble.
• Presión alrededor de 101000–102000: Pa interpretados como hPa (o etiqueta mal).
• Temperaturas “300” en pantalla: Kelvin mostrado como °C.
• Lluvia diaria rarísima pero la intensidad “cuadra”: corte diario/UTC mal aplicado.
• Saltos de lluvia con escalones raros: resolución de vuelco o conversión altera cuantización.
• Radiación nocturna alta sostenida: unidad/producto mezclado o sensor/offset mal (a veces también sombreado/emplazamiento, pero primero descarta unidad).

8. Ejemplos cotidianos (para fijarlo)

• m/s vs km/h: un “5” puede ser 5 m/s (18 km/h) o 5 km/h (1,4 m/s). Si no sabes la unidad, estás vendiendo otro viento.
• Pa vs hPa: 1013 hPa es lo normal; 101300 parece “normal” si no miras la etiqueta… pero está en Pa.
• mm vs mm/h: “12” puede ser una lluvia diaria normal o un chaparrón fuerte de una hora. Sin ventana temporal, no significa nada.

9. Errores comunes

• Asumir unidades por costumbre (“esto siempre venía en km/h”)
• Convertir “para que se vea bonito” y luego volver a convertir en otra capa
• No anotar cuándo se tocó logger/API/pipeline

10. Buenas prácticas (las que más evitan líos)

• Que la unidad viaje como metadato siempre
• Definir un único punto oficial de conversión
• Separar “dato crudo” de “dato mostrado”
• Registrar cambios técnicos (aunque sea en una nota simple)

11. Resumen y claves finales

• La mayoría de fallos vienen de doble conversión, cambio de fuente o metadatos rotos
• UTC y acumulados son una trampa frecuente: puede parecer “unidad” pero es definición temporal
• Una tabla de síntomas + flags simples te saca del 80% de casos

12. Mini-glosario

• QC: control de calidad, reglas para detectar valores sospechosos
• Flag: etiqueta de aviso (OK/WARN/FAIL) asociada a un dato o tramo
• Definición operativa: cómo se calcula realmente un producto (racha, acumulado, media)
• UTC: referencia temporal estándar; si cambias de zona horaria sin control, cambias los intervalos

13. Referencias y lecturas recomendadas

• WMO: guías y estándares de observación e instrumentación
• Met Office: recursos de calidad de datos y buenas prácticas
• NOAA: materiales de observación, QC y manejo de series