Mes 1 · Datos y pipeline inicial

• Estaciones piloto: Santa Rosa (inia-17, Ñuble) y Santa Sofía (inia-7, Maule), las de más historia y más heladas de su región entre las estaciones INIA.

• Base histórica consolidada: datos horarios y diarios de las dos estaciones desde 2009–2010 hasta octubre de 2026, congelados en copias con huella para que cualquier resultado se pueda repetir.

• Reporte de calidad: se genera desde la web para cualquier conjunto de estaciones y es reproducible. En las pilotos la cobertura es buena (94 a 99,9 % en casi todas las variables), pero encontró horas corridas cerca de una hora en Santa Rosa entre abril de 2010 y agosto de 2012, y un sensor de humedad que está fallando en Santa Rosa desde 2025.

• Rutinas de carga, limpieza y detección de heladas: funcionando y con pruebas automáticas. Falta acordar los criterios de los eventos ambiguos (la propuesta de revisión manual ya está escrita).

• Repositorio: código, documentación y 270 pruebas automáticas en Git, con reglas de trabajo definidas.

• Decisiones para jefatura: qué hacer con las horas corridas, criterios de eventos ambiguos, acceso a la carga histórica de la fuente y fechas de la Etapa 1 en el plan.

El documento técnico pide validar primero las rutinas en una estación de Ñuble y una de Maule. Jefatura pidió una estación INIA de cada región para los primeros modelos (mes 3). Se eligieron las de más historia y más heladas; si jefatura prefiere otras, todo lo de este informe se rehace con las nuevas desde la web.

Origen. La red de agrometeorologia.cl (INIA, DMC y otras instituciones):

• historia desde 2009 con el formulario de consulta del sitio (ingest/backfill.py);

• datos nuevos cada 4 horas desde el mapa del sitio (ingest/ingest.py, worker).

Se guardan en Postgres:

• obs_horaria: 10 variables por hora;

• obs_diaria: mínima, máxima y promedio diarios;

• tmin_qc: mínima diaria con su control de calidad.

Estandarización.

Datos originales y procesados.

• Originales: los CSV crudos del formulario quedan en data/raw/ y no se borran.

• Procesados: las tablas de Postgres.

• Para modelar y reportar: se trabaja sobre copias congeladas con huella, porque la base sigue creciendo y la carga histórica rellena huecos viejos. Con las copias, el mismo análisis da lo mismo un mes después. Son dos:

Cada copia guarda su huella: si alguien cambia un archivo, se niega a cargarla.

Riesgo: la carga histórica de la fuente está detenida desde el 23-10-2026. El formulario del sitio empezó a pedir una verificación anti-bot.

• No afecta a las pilotos: su historia ya está cargada completa.

• Sí afecta a agregar la historia de estaciones nuevas.

• Propuesta: pedir acceso formal a la fuente.

Cómo se genera. En la web (/panel/calidad, o con «Estaciones del informe» en esta página, con contraseña):

1. Se eligen las estaciones (de cualquier región) y el período.

2. El servicio calcula el reporte sobre una copia congelada de los datos y lo guarda. Se puede ver en la página o descargarlo en markdown y CSV.

El mismo pedido sobre los mismos datos da el mismo reporte (id reporte-3506c58fd668 para las pilotos). Los umbrales van al final de cada reporte.

Qué revisa, por estación y variable:

• cobertura y huecos;

• valores fuera de rango físico;

• sensor pegado (sin contar niebla, calma ni la noche);

• saltos imposibles entre horas;

• días copiados;

• meses anómalos (discontinuidades);

• problemas de horario (horas corridas, hora del máximo diario, calce con la mínima diaria);

• control de calidad de la mínima diaria.

1. Horas corridas en Santa Rosa, abril de 2010 a agosto de 2012.

   • Qué se ve: el centro diario de la radiación, que cae siempre al mediodía solar, está 0,9 h más tarde que en los mismos meses de los demás años. Lo más probable es horario de verano sin convertir en esos años, aunque la fuente declara hora fija.

   • A qué afecta: a las ventanas horarias de los modelos en esas temporadas (2010, 2011 y 2012). La mínima diaria no cambia.

   • Propuesta: corregir esos meses corriendo las horas una hora en la limpieza, antes de los primeros modelos (mes 3), y dejar documentado el criterio. La alternativa es dejar fuera esos meses.

   • Santa Sofía tiene lo mismo de noviembre de 2009 a enero de 2010. Sus 3 meses sueltos de 2023–2026 están en el límite (+0,5 h) y conviene mirarlos, no corregirlos.

2. Sensor de humedad de Santa Rosa fallando desde 2025:

   • cobertura de 80 % en 2025 y 58 % en 2026;

   • valores de 0,5 % en mayo de 2026.

   Para la temporada 2026 la humedad de esa estación es poco confiable. Conviene avisar a INIA.

3. Caída de presión en las dos estaciones a la misma hora.

   • Qué se ve: el 14-07-2026, a las 07–08 h, la presión baja de golpe a 860 hPa en Santa Rosa y a 841 hPa en Santa Sofía, unos 130 a 150 hPa en una hora, y vuelve.

   • Qué parece: que el mismo día y hora pase en dos estaciones a 60 km apunta a un error de la red, no del sensor.

   • Por qué importa: esos valores caen dentro del rango físico (700 a 1.100 hPa), así que hoy la limpieza no los deja vacíos.

   • Propuesta: que la limpieza descarte los saltos aislados de presión que van y vuelven.

4. Saltos de temperatura (Santa Sofía, 61): ocurren casi todos entre las 8 y las 9 h (22) y entre las 18 y las 19 h (35). Son el calentamiento de la mañana y el enfriamiento del atardecer, probablemente reales en días despejados. Quedan para revisar, no para borrar.

5. Suelo a 10 cm en Santa Sofía: menor cobertura (87,5 %), 17 valores fuera de rango y dos meses anómalos. Es una variable secundaria para heladas; se puede dejar fuera de los modelos de esta estación si no aporta.

Carga

Limpieza

• Mínima diaria (tmin_qc): la mínima de cada día queda ok, parcial, sospechosa o inválida, con su motivo:

  • inválida si cae fuera de rango (≤ -30 °C o ≥ 40 °C);

  • inválida si el sensor está pegado (mín = prom = máx);

  • inválida si es inconsistente (mín > prom);

  • sospechosa si es un salto aislado de 10 °C bajo los días vecinos;

  • sospechosa si es una helada intensa en verano.

  Los estudios usan solo ok y parcial.

• Datos horarios: lo que cae fuera de rango físico se deja vacío al armar las variables de los modelos. Los saltos aislados dentro del rango (como la presión del 14-07-2026) todavía no se limpian.

• Reporte de calidad (entregable 2): detecta lo que queda por revisar (horas corridas, sensores pegados, saltos, meses anómalos) y lo deja con fecha en el detalle. Falta la rutina que aplique las correcciones que se acuerden (por ejemplo, correr las horas de Santa Rosa 2010–2012).

Detección de heladas

• Helada = temperatura ≤ 0 °C, como dice el documento técnico.

• Por día: mínima diaria ≤ 0 °C, con control de calidad ok o parcial.

• Por noche: el evento principal se arma con la temperatura horaria de 12:00 a 12:00 (problemas.evento_noche).

  • Los tramos bajo 0 °C separados por pocas horas se unen.

  • Se queda el tramo que contiene la temperatura más baja.

  • Da la hora de inicio, la duración y cuántos tramos tenía.

Las clases son las de referencia de Maule. Hay dos cosas que mirar:

• La clase «< 1 h» de duración son casi todas noches sin ninguna hora ≤ 0 °C. Los datos horarios son promedios, así que una mínima instantánea de -0,3 °C puede no bajar de 0 °C en el promedio horario.

• La clase «< -3 °C» tiene pocos casos por temporada.

Las dos cosas son parte de los criterios por acordar.

Revisión manual de eventos ambiguos

El documento técnico pide definir y documentar este procedimiento. La propuesta:

• marcar automáticamente los casos ambiguos (helada en varios tramos, tramos de una sola hora, huecos dentro de la noche);

• revisarlos en una página con el gráfico de la noche y botones para unir, separar, descartar o confirmar;

• registrar quién decidió, cuándo y con qué criterio.

En las pilotos son unos 30 casos fragmentados por estación en 16 años, así que la revisión manual es abordable.

Está pendiente:

• jefatura tiene que acordar los criterios: cuántas horas sobre 0 °C siguen siendo la misma helada, cómo se cuenta la duración, qué hacer con las noches sin hora ≤ 0 °C, y los rangos de cada clase. Las preguntas están en la sección de decisiones;

• construir la página de revisión.

Mientras tanto, la detección automática usa valores provisionales. Cada resultado queda marcado con la versión de los criterios que usó, así que lo hecho con criterios viejos se reconoce.

Validación

Las rutinas tienen pruebas automáticas con datos armados a mano: 270 pruebas en Python y 10 en la web, que se corren antes de integrar cada cambio. Cubren:

• detección de eventos y bordes de las clases;

• reporte de calidad: cada problema puesto a propósito se detecta, y solo ese;

• ventanas horarias sin usar datos del futuro;

• copias congeladas.

Además, se ponen errores a propósito en el código para comprobar que las pruebas los detectan. En el reporte de calidad se detectaron los 16 errores puestos.

Estructura del repositorio (Git):

Reglas de versionamiento:

• Integración: cada cambio va en su propia rama y entra a la rama principal solo con todas las pruebas pasando.

• Mensajes: los commits dicen qué cambió y por qué.

• Datos: no se guardan en Git (data/ queda fuera); su versión es la huella de cada copia congelada.

• Trazabilidad: cada resultado de un modelo y cada reporte de calidad guarda el commit del código con que salió.

• Documentación: el uso y el funcionamiento de cada parte están en el README.

Remoto: el repositorio se comparte en GitHub (Thinkagro/heladas-nhuble, rama main).

1. Horas corridas de Santa Rosa (2010–2012): ¿se corrigen corriendo las horas una hora, o se dejan fuera esos meses? Propuesta: corregir.

2. Criterios de los eventos ambiguos y rangos de las clases (ver «Qué cambia si cambia el criterio»). Hace falta para cerrar el procedimiento de revisión manual.

3. Estaciones piloto: confirmar Santa Rosa y Santa Sofía.

4. Acceso a la fuente: pedir acceso formal a agrometeorologia.cl para retomar la carga histórica de estaciones nuevas.

5. Fechas (resuelta, para conocimiento): las entregas siguen la carta Gantt presentada a jefatura (Etapa 1 en las semanas 1 a 3), no las semanas 1 a 4 del documento técnico.

6. Repositorio compartido: dónde se publica el código para el equipo y el administrador de Alertfrost.

7. Sensor de humedad de Santa Rosa: avisar a INIA.

Trabajo por hacer (equipo pinguino):

1. Rutina de limpieza que aplique las correcciones acordadas y deje registro de cada una:

   • correr las horas de Santa Rosa 2010–2012 (si jefatura lo aprueba);

   • descartar los saltos aislados de presión que van y vuelven.

2. Página de revisión manual de eventos ambiguos, cuando estén los criterios.

3. Caracterización de heladas reproducible: hecho. Sale del reporte de calidad para cualquier conjunto de estaciones, y cada reporte se descarga también como borrador de este informe (tablas armadas, conclusiones «Por completar»): si cambian las pilotos, se pide de nuevo y solo se reescriben las conclusiones.

4. Repositorio compartido (remoto) una vez decidido dónde.

5. Recrear el contenedor de los cuadernos para que vean las copias del reporte de calidad.

Depende de jefatura: las 7 decisiones de la sección anterior.