Este mes el periódico ARA cumplirá 10 años, y creo que es un buen momento para explicar su proyecto de meteorología que he comandado desde el primer día. Me he entretenido a escribir esta especie de chala larguísima porqué creo que se han hecho cosas bastante únicas que quiero poner en valor, y porqué he trabajado muchas ideas con tanta libertad com soledad, y creo que es un ejercicio necesario y quizás interesante poderlo relatar y dar algunos detalles.
Cuando llegué al diario ARA todavía había paletas y plásticos. Todo estaba por hacer, y el encargo de hacer de cero toda la sección de meteorología en poco más de un mes era todo un reto. Mi idea clave cuando aterricé era humanizar las previsiones del tiempo online y hacer entrar la figura del hombre / mujer del tiempo.
Quería una web sencilla pero muy actualizada, donde pudieras entrar informarte del tiempo y la previsión sabiendo que alguien velaba por advertirte no sólo del pronóstico, sino de los cambios que pudiera haber durante el día. Un lugar donde la interacción con los lectores fuera clave. Estamos hablando de 2010, hay que ponerlo en contexto, las redes apenas estaban estallando.
La web salió con un proyecto en el que cada uno podía buscar la previsión para su municipio pero todo se hacía de forma manual. La gente de tecnología construyó un editor de contenidos concreto y especial para el tema, creábamos la previsión para una cuarentena de puntos, y eso extrapolaba según coincidencias geográficas al resto de municipios. Se aplicaban algunos criterios de altitud que ajustaban temperaturas y cosas como la diferencia entre lluvia y nieve según la altitud. Todo era manual, sólo contábamos con una herramienta para duplicar símbolos y temperatura de una día para otro y no empezar de cero.
El hecho más diferencial eran unas pequeñas frases que acompañaban las previsiones, estaban preescritas y aportaban cosas que un símbolo y una temperatura no podían decir. Os adjunto algunos ejemplos: “Sólo lloverá hasta media mañana”, “Necesitarás una capa más que el día anterior”, “el viento aumentará la sensación de frío”. Las había que estaban pensadas para corregir cambios en la previsión y para dar una sensación de actualización inmediata: “Se está acercando un aguacero: si sales, coge el paraguas”, “Aún lloverá dos o tres horas más”. Teníamos casi un centenar en un selector del modo que fuera rápido ponerlas, y con cierta frecuencia metíamos o eliminábamos según el uso y la necesidad.
Como veis el objetivo era dar una sensación de actualización muy grande, de mucha fiabilidad en la actualización. En la página principal del web había una frase corta, de la longitud de un tuit, con la cara del meteorólogo que estuviera actualizando y la hora de la última actualización. Todas las previsiones también tenían la hora de la última actualización. Las horas de actualización me parecían entonces un factor muy importante y que no se encontraba casi en ninguna parte en las previsiones de internet.
Aquella idea para mí sigue siendo buena, pero la ejecución era muy compleja y excesivamente exigente. Además en los primeros años del diario las previsiones a los móviles evolucionaron mucho, Google entró, el iPhone te la daba ya de entrada … pronto me quedó claro que necesitábamos un sistema mejor. Si cuando entré en el diario mi lema era “humanizar las previsiones del tiempo online”, ahora era clave una nueva idea: “ser la segunda opinión necesaria”. Era totalmente imposible ser la primera previsión del tiempo que caía en las manos del usuario, pero sí podíamos ser una segunda opinión fiable y que una vez más, diera las garantías de un predictor con nombre y apellido. Nos hacía falta un contenido mucho más detallado, que entrara en las previsiones por tramos horarios y que diera datos de viento, sensación térmica, cota de nieve … había que hacer entrar en juego los datos de un modelo de predicción, sin aumentar el presupuesto.
Empecé a trabajar con el modelo americano de previsión, el GFS, que si bien tiene la fama (y las métricas) de ser un poco peor que el europeo, tiene la ventaja de ser totalmente libre de acceso. Había que descargar la salida del modelo en el formato meteorológico GRIB y transformarla en algo utilizable por un diario digital. El software GrADS permite extraer la información numérica específica que necesitas, y también aporta la posibilidad de crear mapas de cualquier variable, o hacer cálculos a partir de diversos datos del modelo. Así creé una serie de scripts de GrADS que me dieran toda la información que quería para un número de puntos de previsión que define con más detalle que la comarca, ya partir de aquí haríamos el downscalling a cada municipio, que debía tener en cuenta criterios como la diferencia de altura y la cota de nieve.
Faltaba un último paso, que era escoger el símbolo. El modelo te da directamente datos como la temperatura en superficie y una racha máxima de viento, pero había que traducir toda la información en un símbolo para un día o un tramo horario. Esta parte la abordé con un script de PHP que decide el símbolo a partir de criterios como la nubosidad en diferentes niveles, la precipitación, la cota de nieve, y también uno mucho más complejo como es el riesgo de tormenta. Esto me permitió ajustar detalles a medida que fui conociendo el modelo, por ejemplo, había que menospreciar ligeramente la nubosidad, porque con el mix de nubes a todas las capas que ofrece, el símbolo resultante daba muchos más momentos de cielo tapado de los que realmente había.
La flexibilidad que me ofrecía coger toda la información directamente del modelo me permitió abordar preguntas casi filosóficas como, ¿si el modelo prevé lluvia sólo durante la noche, el símbolo que resume el día debe incorporar la lluvia? Creí que la lógica de los mapas del tiempo que se hacen manualmente tendería a ignorar una lluvia que cayera la noche, a no ser que fuera en un mapa estrictamente de noche, como se han hecho en algunas cadenas de televisión, en el que los soles se sustituyen por lunas.
En esta fase también me plantee ofrecer sólo la información concreta y útil para el usuario, sin dejar de lado detalles como el viento, la cota de nieve y la sensación térmica, pero evitando que demasiada información generara ruido y fuera difícil de mostrar bien en una pantalla de móvil. Así, en el resumen diario de la previsión, el viento sólo aparece si está prevista una racha de más de 30 km/h, y se da cuenta también de rachas más fuertes de +50, +70 o +90. La temperatura de sensación sólo aparece si difiere cuatro grados o más de la real, por debajo o por encima. Y la cota de nieve sólo aparece si se aproxima a menos de 500 m de la altitud del municipio. De este modo creí que evitábamos ruido pero manteníamos un nivel bueno de información a escala local.
También creí que era importante diferenciar entre una lluvia de cuatro gotas o una posible lluvia abundante. Diseñamos hasta tres símbolos de lluvia según la cantidad esperada, y en caso de que la lluvia tuviera que ser muy abundante: más de 20, más de 50 o más de 100 l / m2 previstos, esta información también aparecería destacada en el resumen del día.
Pasamos de un sistema totalmente manual a uno totalmente automático? No exactamente. Aunque el volumen de información que supone una previsión a siete días, a escala subcomarcal, por tramos de tres horas y con múltiples variables hace imposible corregir errores del modelo de forma manual, sí que dejamos la puerta abierta a poder modificar símbolos y temperaturas cuando fuera necesario en el resumen del día. Un ejemplo muy claro es el caso de las nieblas de subsidencia, los modelos de previsión tienen muchos problemas aún por detectar las situaciones de niebla. Si no pudiéramos tocar manualmente nada de la previsión que ofrecemos, en un día de diciembre con niebla persistente en Lleida y una máxima de 1 o 2 grados, mostraríamos un día de sol y temperaturas de 17 o 18. Haya niebla o no, muchos modelos detectan mal las inversiones térmicas, y poder corregir temperaturas mínimas y máximas es importante para poder ofrecer mejor calidad de las previsiones. También es importante corregir temperatura en sitios de montaña, donde el modelo se ve obligado a resumir en un punto de previsión altitudes muy distintas.
También me interesaba mucho poder ofrecer una previsión probabilística de lluvia, un indicador que te dijera como de fiable es un símbolo de lluvia o de no lluvia. Las previsión determinista en la web se completa con un bloque de gráficos de previsión probabilística de precipitación a partir del modelo GEFS, que abarca hasta 14 días y permite tener una visión muy interesante de posibles cambios en el tiempo a medio y largo plazo, y también de como de fiables son. Un ingrediente que creo muy interesante y muy útil para tomar decisiones a medio plazo. Precisamente este otoño de 2020 acabo de implementar la nueva versión del GEFS. Con toda la información y los criterios claros, la gente de los departamentos de tecnología, diseño y sistemas dieron forma a la web y garantizan la estabilidad de las actualizaciones. Estoy muy orgulloso del producto final.
Todo este trabajo con el modelo de previsión y GrADS me permitió también elaborar todos los mapas que están disponibles en la web y que luego con la gente de sistemas y de vídeos hemos pulido y hecho más atractivos para poderlos utilizar en animaciones a los vídeos, los textos y las redes sociales. Todo lo que usamos es producto propio elaborado en el diario, algo que me parece bastante remarcable para un periódico de la envergadura del ARA.
En definitiva el objetivo era dar el salto a una información mucho más completa y útil a nivel municipal, pero teniendo en cuenta el máximo de elementos posibles para no perder la calidad de un producto vigilado por un meteorólogo. La parte más humanizada, relatada y de contexto de la previsión en el diario la ofrecemos con un texto diario de previsión, audio, vídeo, y con unas frases que acompañan a los mapas en la versión desktop. La combinación de los dos aspectos creo que es clave. La obsesión sigue siendo luchar contra la sensación de recibir una previsión al móvil y no tener la más remota idea de cómo se ha hecho, y quizás más importante, no tener ni idea sobre cómo de lejos de mi contexto geográfico están las personas que están ofreciéndome este servicio.