La calidad de datos meteorológicos no es un lujo: es lo que decide si un gráfico “bonito” cuenta la verdad o si te está metiendo ruido, sesgos y falsas conclusiones. En esta guía rápida verás qué significa “dato fiable”, qué fallos son más comunes (sensores, instalación, reloj, redondeo, transmisión), cómo detectar problemas sin ser laboratorio, y qué hacer para que tus series sean útiles para análisis, climatología y operativa.

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 la calidad de datos y por qué importa

Un dato meteorológico “de calidad” es un dato que (1) representa bien el fenómeno en ese lugar, (2) está medido con un instrumento adecuado, (3) está bien fechado (hora correcta), y (4) ha pasado controles básicos que detectan fallos típicos. Si cualquiera de estas patas falla, puedes sacar conclusiones erróneas: máximas exageradas por radiación, lluvia fantasma por suciedad, viento subestimado por obstáculos, o tendencias falsas por un reloj desajustado.

2. Idea clave en 30 segundos

• En una frase: un dato fiable es “medición correcta + ubicación correcta + hora correcta + controles mínimos”
• Señal típica: saltos raros, valores clavados, horas que no encajan o máximas “imposibles” en días soleados
• Confusión común: pensar que “si el sensor da números” entonces los números ya valen

3. Fuentes de error más frecuentes (mapa mental)

• Instrumento: deriva del sensor, envejecimiento, condensación, suciedad, calibración deficiente.
• Instalación: altura incorrecta, sombra parcial, pared cercana, asfalto, techo, árboles, canalizaciones de viento.
• Electrónica y muestreo: redondeo, promedios mal definidos (p. ej., racha vs media), resolución insuficiente, filtros agresivos.
• Transmisión: paquetes perdidos, duplicados, reintentos, cortes que generan huecos.
• Tiempo: timestamp mal definido, cambio de hora mal gestionado, UTC/local mezclado, deriva del reloj del logger.

4. Qué NO es calidad (para no engañarte)

• No es tener muchos datos: si son malos, solo acumulas error.
• No es “coincidir con otra estación” un día suelto: puede ser casualidad.
• No es “no tener huecos”: a veces un sistema rellena con valores repetidos y parece perfecto… pero está roto.

5. Cómo se mide o se define en la práctica

• Calidad se evalúa con pruebas simples: rangos físicos, consistencia temporal, coherencia entre variables, y coherencia espacial.
• Señales típicas de fallo: valores clavados (sensor congelado), escalones (cambio de escala/unidad), picos aislados (glitches), persistencia extraña (lluvia constante a 0.2 mm), o desfase horario.
• Objetivo real: detectar lo suficiente para no tomar decisiones erróneas (operativa) y para no contaminar estadísticas (clima/extremos).

6. Checklist rápido de calidad (10 minutos)

• 6.1 Rango y unidades: ¿las unidades son correctas (°C, hPa, mm, km/h) y los valores están en rangos razonables para tu zona y estación?
• 6.2 Valores clavados: ¿hay tramos largos idénticos (temperatura, presión, HR, viento)? Si sí, sospecha sensor o transmisión.
• 6.3 Saltos imposibles: ¿aparecen cambios brutales (p. ej., +8 °C en 1 minuto sin causa)?
• 6.4 Coherencia interna: ¿si sube T, baja algo la HR (a menudo) y la presión cambia con continuidad? ¿la lluvia aumenta solo cuando toca?
• 6.5 Coherencia externa: compara con 1–3 referencias cercanas (AEMET u otras) buscando tendencias, no coincidencia exacta.
• 6.6 Huecos y duplicados: ¿faltan periodos? ¿hay registros duplicados con el mismo timestamp?
• 6.7 Metadatos: ¿sabes altura del sensor, exposición, escudo de radiación, tipo de pluviómetro, resolución y promediado?

7. Timestamps: UTC, cambios de hora y deriva del logger (lo que más rompe series)

Los timestamps son la columna vertebral: sin hora correcta, los datos pierden sentido. Tres problemas dominan: (1) mezclar hora local con UTC, (2) el cambio de hora (DST) mal resuelto, y (3) la deriva del reloj del logger (drift).

• 7.1 UTC vs hora local: decide un estándar. En meteorología y series largas, lo más robusto es almacenar en UTC y convertir a local solo para visualizar. Si guardas en local, documenta siempre la zona horaria y el DST.
• 7.2 Cambio de hora (DST): el día del cambio aparecen horas repetidas (otoño) o horas inexistentes (primavera). Si tu sistema “duplica” o “salta” sin control, tus máximas/mínimas diarias y acumulados pueden quedar mal. Regla práctica: guarda en UTC para evitar ambigüedades; si no puedes, marca explícitamente el offset (por ejemplo, +01:00 / +02:00) y evita recalcular diarios sin considerar el DST.
• 7.3 Deriva del reloj (drift): algunos loggers se adelantan o atrasan minutos con el tiempo. Síntoma típico: tus picos (racha, precipitación, cambios de viento) aparecen desplazados respecto a estaciones cercanas o a radar/satélite. Mitigación: sincronización periódica (NTP si hay red), o reajuste manual registrando el momento. En análisis, detecta drift comparando eventos claros (paso de frente, salto de presión, inicio de lluvia) con referencias y corrige el desfase si es estable.
• 7.4 Reglas de oro: (a) no mezcles fuentes con zonas horarias distintas sin normalizar; (b) conserva el timestamp original y guarda un campo de “hora corregida” si ajustas; (c) documenta cambios de firmware o configuración del reloj.

8. Ejemplos rápidos de fallos típicos (y cómo se ven)

• Temperatura sobreelevada por radiación: máximas demasiado altas en días de sol y poco viento; suele delatar mala ventilación/escudo o entorno urbano (pared, tejado).
• Humedad pegada al 99–100%: sensor mojado o ventilación deficiente; mira si coincide con niebla real o si es constante.
• Presión con escalones: cambio de unidades o recalibración; revisa metadatos y continuidad.
• Lluvia “a goteo” constante: pluviómetro sucio, vibraciones, calibración mala; se ve como incrementos pequeños repetidos sin radar/nubes.
• Viento subestimado: anemómetro bajo/obstáculos; verás rachas raramente altas incluso en temporales regionales.
• Eventos desplazados en el tiempo: timestamp mal (UTC/local) o drift del logger; se detecta al comparar con otras estaciones o con productos de observación.

9. Errores comunes

• Guardar hora local sin documentar DST y luego comparar con series UTC
• Corregir datos “a ojo” sin dejar trazabilidad (qué se cambió y cuándo)
• Usar promedios mal definidos (confundir racha con media)
• No aplicar filtros mínimos de rangos y valores clavados
• Confundir “microclima real” con “sensor mal instalado” sin validar con contexto

10. Buenas prácticas (lo que más mejora con poco esfuerzo)

• Guardar datos en UTC y convertir a local solo en la capa de visualización
• Sincronizar reloj (NTP) o revisar drift regularmente
• Documentar metadatos: altura, exposición, instrumentos, resolución, cambios
• Aplicar QC mínimo: rangos, spikes, stuck values, duplicados
• Comparar con 1–3 referencias (tendencias, no igualdad)

11. Resumen y claves finales

• Calidad = medición + ubicación + hora + controles
• Timestamps mal gestionados destruyen diarios, acumulados y comparaciones
• UTC como estándar simplifica DST y reduce ambigüedad
• Un QC mínimo evita la mayoría de errores graves
• Metadatos y trazabilidad son parte del dato

12. Mini-glosario

• QC (control de calidad): pruebas para detectar datos imposibles o sospechosos
• Timestamp: marca de tiempo asociada a cada registro
• UTC: tiempo universal coordinado, referencia estándar
• DST: cambio de hora estacional
• Drift: deriva progresiva del reloj del dispositivo

13. Referencias y lecturas recomendadas

• AEMET: documentación y criterios de observación y redes
• WMO: guías de instrumentos y métodos de observación
• NOAA: recursos educativos sobre medición y calidad