Leufü Wechun

El problema: el dato llega cuando ya es tarde

La Dirección General de Aguas publica el estado de sus estaciones en un visor público. Pero tiene una limitación que lo inutiliza para prevenir: sólo informa el nivel de las estaciones que ya están en alerta. Las demás aparecen con valor 0.0 aunque estén transmitiendo con normalidad.

La magnitud del problema se ve en los números: a nivel nacional, de las 1.837 estaciones del visor, sólo 9 traen medición. Son exactamente las mismas 9 que están en alerta. Con esa única fuente no se puede anticipar nada, porque para cuando el dato existe, el río ya cruzó el umbral.

Y en sectores rurales ese margen es justamente lo único que hay: viviendas dispersas, sin sistema de aviso local, donde muchas veces la primera señal de una crecida es el ruido del agua.

Recuperar el dato que el visor no entrega

La solución pasa por entender que el visor hace dos llamadas distintas, no una. La primera devuelve el listado completo de estaciones con sus coordenadas y su estado, y es la que trae los ceros. La segunda es la que el visor dispara al pinchar un marcador: un POST de RichFaces que devuelve ultimoCaudalReg, el caudal real en m³/s de cualquier estación, esté o no en alerta.

Esa segunda llamada exige mantener la cookie de sesión y el javax.faces.ViewState, y va una petición por estación: unos 170 segundos para recorrer las 55 de la región. A cambio, 45 de esas 55 pasan a informar caudal donde antes había un cero.

Dos señales, y siempre gana la peor

Cada estación se evalúa por dos caminos independientes, y se toma el más grave de los dos. No se promedian: el nivel se mide en metros y el caudal en m³/s, así que mezclarlos daría un número sin significado físico.

• Por umbral — qué porcentaje del umbral oficial alcanza el nivel medido. Normal bajo el 80 %, atención entre el 80 y el 100 %, alerta al superarlo, crítica desde el 120 %.
• Por tendencia — cuánto ha crecido el caudal en una ventana de seis horas. Atención al 50 % de crecimiento, alerta al 100 %.

La detección por tendencia es lo que hace que la alerta sea temprana, y tiene un detalle que decide si funciona o no: compara contra la lectura más antigua de la ventana, no contra la anterior. Una crecida que sube un 15 % por hora durante seis horas duplica el caudal sin que ninguna comparación consecutiva llegue a delatarla.

Además funciona en estaciones que no publican umbral, que de otro modo quedarían ciegas. Y hay una regla que no se negocia: cuando la DGA declara alerta oficialmente, el sistema nunca rebaja el nivel por debajo de «alerta». Es la fuente oficial y no se la contradice.

Episodios, no lecturas

El sistema no guarda una alerta por cada medición alta: registra episodios. Uno se abre cuando la estación deja de estar normal y se cierra cuando vuelve a estarlo.

La diferencia importa al mirar el historial. Con lecturas sueltas, la pregunta que puede responder es «cuántas mediciones altas hubo»; con episodios, «cuántas crecidas hubo», que es la que le interesa a alguien que vive junto al río.

De ahí sale también el criterio para avisar: sólo se emite un evento cuando el estado cambia — se abre, escala, desciende o se resuelve. Mientras el nivel se mantiene, el episodio se actualiza en silencio, para no ahogar a los vecinos en notificaciones repetidas de algo que ya saben.

Arquitectura

Backend en FastAPI con SQLAlchemy sobre PostgreSQL 16 con PostGIS, en las mismas capas que uso en el resto de mis proyectos: models → schemas → services → routes. La lógica de evaluación vive en alert_service.py, aislada del transporte, y por eso se puede probar sin levantar la API.

El frontend es React 19 con Vite, el mapa va sobre Leaflet con teselas de OpenStreetMap —que no piden clave de API, algo que importa en un proyecto que aspira a ser replicable sin costes— y el historial se dibuja con Recharts. Las alertas viajan por WebSocket con reconexión progresiva, así que el panel cambia solo cuando el estado de un río cambia.

La ingesta corre aparte, como servicio o desde cron, y va acumulando la serie histórica. Es una necesidad, no una elección: el visor de la DGA sólo entrega una fotografía del instante, nunca el pasado. El historial que muestra la ficha de cada estación existe porque este sistema lo construyó sondeando.

Por qué es open source

Porque el destinatario no tiene con qué pagarlo. Una junta de vecinos rural o un municipio pequeño no va a licitar un sistema de alerta temprana, y ese es exactamente el lugar donde más falta hace.

Con el código abierto, otra región puede instalarlo, ajustar los umbrales a sus ríos y mantenerlo sin depender de mí. Un proyecto de seguridad comunitaria que dependa de que su autor siga interesado es un proyecto frágil; abrirlo es lo que le da posibilidad de sobrevivir.

En qué está hoy

Funcionando sobre datos reales de las 55 estaciones de La Araucanía, con el repositorio público. Todavía no hay despliegue abierto al público ni el canal de notificación que cierra el círculo: hoy el sistema detecta y muestra, y el siguiente paso es que el aviso salga hacia el vecino sin que nadie tenga que estar mirando la pantalla.