Sobre Este Proyecto
FloodRisk (Floods Argentina) es una plataforma de riesgo hidrológico con enfoque cívico para Tucumán, Argentina. Integra precipitaciones observadas, datos de ríos y estaciones, alertas oficiales y señales de pronóstico en un único mapa interactivo y centro de información—diseñada para claridad en situaciones de estrés, SEO y operatividad diaria.
Destacado en prensa
Este proyecto fue destacado por un medio local de Tucumán por su aporte a la concientización sobre inundaciones y la seguridad pública. Leer la nota.
El proyecto nació de una necesidad concreta: hacer que la información relevante sobre inundaciones sea más fácil de encontrar e interpretar para residentes y organismos, sin ocultar la metodología ni las fuentes. La aplicación pública prioriza vistas centradas en localidades, trazabilidad transparente de los datos y una clara separación entre datos hidrométricos medidos y proyecciones basadas en modelos (por ejemplo, pronósticos de crecida cuando se habilita la API de Google Flood Forecasting), para evitar que los usuarios confundan un pronóstico con una medición real.
Características principales
- Next.js App Router y SEO técnico — Páginas renderizadas en el servidor, helpers de metadata compartidos, sitemap y robots, y URLs canónicas definidas por configuración de entorno para mantener consistencia en descubrimiento y compartición.
- Mapa provincial interactivo — Mapa basado en Leaflet con enfoque por localidad, capas y layouts mobile-first (bottom sheets, pantalla completa, vistas compartibles) optimizados para que la interfaz sea usable en el celular durante eventos climáticos.
- Páginas por localidad y territorio — Detalle por localidad con lluvias recientes, contexto de pronóstico y contenido orientado al riesgo para no especialistas; estructurado para compartir y previews en redes.
- Ríos, estaciones y contexto hidrológico — Integración con fuentes tipo INA de ríos y precipitaciones cuando están configuradas, junto con tarjetas opcionales de pronóstico de Google Flood que presentan señales a escala de cuenca diferenciadas de mediciones directas.
- Centro de pronósticos — Integración con Open-Meteo y otros servicios, con referencias a fuentes oficiales como SMN cuando corresponde, orientado a “qué podría pasar” sin reemplazar alertas institucionales.
- Visualización de alertas oficiales — Banners del SMN y contenido que refuerza la atribución de la fuente para que el usuario entienda quién emitió la alerta.
- Página de fuentes y metodología — Documentación explícita de proveedores, limitaciones y construcción de capas del mapa—clave para generar confianza en un producto relacionado con desastres.
- Flujos para partners — Acceso basado en roles (por ejemplo, administrador u operador) y superficies autenticadas para uso operativo además del sitio público.
- Reportes colaborativos y estructurados (API) — Servicio FastAPI para sesiones, reportes e ingesta de datos; worker en background para procesamiento periódico, cálculo de riesgo y envío de alertas.
- PWA y notificaciones — Manifest y service worker orientados a alertas en tiempo real cuando la configuración lo permite (por ejemplo VAPID), dentro de las limitaciones de permisos del navegador.
- Instrumentación analítica — Google Tag Manager integrado en la app para medición sin scripts dispersos.
- Operación containerizada — Stack basado en Docker Compose (web, API, worker, Postgres) para despliegues reproducibles en VPS.
Arquitectura y responsabilidades
- Frontend (
apps/web) — Next.js, React y CSS global para el dashboard y mapa; foco en UX responsive y patrones accesibles.
- Backend (
services/api) — FastAPI: autenticación, reportes, estado de fuentes, proxy de Google Flood cuando está habilitado y APIs consumidas por el frontend.
- Worker (
services/worker) — Ingesta de datos, cálculos de riesgo y disparo de alertas desacoplados del request/response.
- Almacenamiento de datos — PostgreSQL según la configuración de despliegue.
Stack tecnológico
- Frontend: Next.js (App Router), React, TypeScript, Leaflet (mapa), PWA (manifest / service worker).
- Backend: Python, FastAPI, persistencia tipo SQLAlchemy (según convenciones del proyecto), pytest para testing.
- Datos e integraciones: PostgreSQL; fuentes meteorológicas e hidrológicas institucionales y abiertas (como SMN, INA cuando están disponibles); Open-Meteo; API opcional de Google Flood Forecasting.
- Ops: Docker, Docker Compose, despliegue compatible con nginx (dominio productivo: floodrisk.com.ar).
Desafíos y decisiones de diseño
Integrar múltiples proveedores sin una única “fuente de verdad” requirió especial cuidado en la comunicación visual: diferenciar pronósticos de observaciones, mostrar fallos o ausencias de datos en la interfaz y documentar la metodología de forma explícita. Los layouts mobile centrados en mapas exigieron iteración constante—modos fullscreen, bottom sheets y reducción de comportamientos conflictivos de autopan en pantallas pequeñas. El uso de feature flags por entorno (por ejemplo Google Flood) permite mantener coherencia entre staging y producción usando el mismo código base con distintas integraciones habilitadas.
Objetivo
Ofrecer una herramienta de riesgo hidrológico rápida, confiable y mantenible para Tucumán—transparente con sus fuentes, respetuosa de las instituciones oficiales y diseñada para incorporar nuevas fuentes de datos y alertas sin tener que rehacer todo el sistema.
