Predicción de brotes de gripe aviar

PREDICCIÓN DE BROTES DE GRIPE AVIAR AVIAN INFLUENZA OUTBREAKS PREDICTION TRABAJO FIN DE GRADO CURSO 2020-2021 AUTOR CHENG JUN LIU ZHENG EMILIO JOSÉ VALENCIA CALVOPIÑA DIRECTORES JOSÉ IGNACIO GÓMEZ PÉREZ CHRISTIAN TOMÁS TENLLADO VAN DER REIJDEN GRADO INGENIERÍA INFORMÁTICA FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID PREDICCIÓN DE BROTES DE GRIPE AVIAR AVIAN INFLUENZA OUTBREAKS PREDICTION TRABAJO DE FIN DE GRADO EN INGENIERÍA INFORMÁTICA DEPARTAMENTO DE ARQUITECTURA DE COMPUTADORES Y AUTOMÁTICA AUTOR CHENG JUN LIU ZHENG EMILIO JOSÉ VALENCIA CALVOPIÑA DIRECTORES JOSÉ IGNACIO GÓMEZ PÉREZ CHRISTIAN TOMÁS TENLLADO VAN DER REIJDEN CONVOCATORIA: JUNIO 2021 CALIFICACIÓN: NOTA GRADO EN INGENIERÍA INFORMÁTICA FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID DÍA DE MES DE AÑO V DEDICATORIA A mi familia, que me ha soportado durante todo este proceso y más tiempo aún. – Cheng Jun Liu Zheng A mi familia por haberme brindado la oportunidad de estudiar gracias a su gran esfuerzo. A mis vecinos por su constante apoyo y a mi pareja por alentarme a ser mejor, por su cariño y apoyo en todo momento. -Emilio José Valencia Calvopiña VII AGRADECIMIENTOS A Nacho y a Christian por guiarnos y ayudarnos tanto hacia el buen camino por el que seguir el proyecto. A Irene Iglesias por apoyarnos tanto y hacer posible el desarrollo del modelo y a Carlos Eduardo por la interfaz web y por tener tanta paciencia con nuestros ficheros GeoJSON. IX RESUMEN Predicción de brotes de Gripe Aviar Los brotes por Gripe Aviar, concretamente las variaciones de alta patogenicidad de este virus son un problema que afecta frecuentemente a toda Europa, especialmente en países ubicados al norte donde las temperaturas son más bajas lo que les convierte en entornos ideales para la supervivencia del virus. Durante este trabajo se ha desarrollado una herramienta para poder predecir en qué comarcas ganaderas de España hay un mayor riesgo de que ocurra un brote, teniendo en cuenta brotes de Europa, tomados de la plataforma de Empres-i y proporcionados por la organización de WAHIS, rutas migratorias de diferentes especies de aves que suelen realizar trayectos entre partes de Europa y España, proporcionadas por la Sociedad Española de Ornitología (SEO) y previsiones de la temperatura para cada comarca ganadera. La herramienta además generará reportes con información pertinente a las posibles alertas de cada comarca ganadera en formato PDF y CSV, que se enviarán a una unidad en Google Drive para su almacenamiento. Todas estas tareas se realizarán con una frecuencia semanal y además se actualizarán los brotes que vayan reportándose en Empres-i, con la misma frecuencia. Palabras clave Gripe Aviar, Python, Neo4j, MongoDB, Markdown, SEO Birdlife, Geohash, Webscraping, Empres-I, Brotes XVII ÍNDICE DE FIGURAS Figura 2.1 Mapa con los brotes de gripe aviar en Europa en el año 2021 .......................... 5 Figura 2.2 Lenguajes más usados según Stack Overflow en 2020 ..................................... 10 Figura 3.1 Mapa mundial con cuadrículas de geohash ...................................................... 12 Figura 3.2 Reporte con información de un brote en el antiguo WAHIS-OIE ...................... 14 Figura 3.3 Página con la información de un brote en Empres-i .......................................... 15 Figura 3.4 Primera versión de estructura en Neo4j ................................................................ 19 Figura 3.5 Solapamiento entre cuadrículas de comarca y geohash ................................ 20 Figura 3.6 Segunda versión de estructura en Neo4j ............................................................. 21 Figura 3.7 Tercera versión de estructura en Neo4j ................................................................ 22 Figura 3.8 Operaciones de valores-climatológicos ............................................................... 23 Figura 3.9 Ejemplo de consulta ................................................................................................ 24 Figura 3.10 URL datos ................................................................................................................. 24 Figura 3.11 URL de metadatos .................................................................................................. 25 Figura 3.12 Consulta con latitud y longitud ............................................................................ 26 Figura 3.13 Ejemplo salida JSON (TuTiempo.net) ................................................................... 26 Figura 4.1 Estudio con curva ROC del modelo ...................................................................... 34 Figura 4.2 Mapa con los niveles de alerta de enero 2021 y comarcas donde hubo brotes ............................................................................................................................................... 35 Figura 4.3 Cabecera y sumario PDF ........................................................................................ 36 Figura 4.4 Tabla de alertas PDF ................................................................................................ 37 Figura 4.5 Tabla de brotes PDF ................................................................................................. 37 Figura 4.6 Alertas CSV ................................................................................................................ 37 Figura 4.7 Brotes (1) CSV ............................................................................................................ 37 XVIII Figura 4.8 Brotes (2) CSV ............................................................................................................ 37 Figura 4.9 Aplicación web para la visualización de alertas, rutas y brotes ....................... 39 Figura 4.10 Aplicación web mostrando varias rutas migratorias asociadas a brotes...... 41 XIX ÍNDICE DE TABLAS Tabla 3.1 Dimensiones de una cuadrícula geohash según la longitud ............................. 13 XXI ÍNDICE DE CÓDIGOS Código 1 Documento de un brote en MongoDB ................................................................. 16 Código 2 Documento de una ruta en MongoDB ................................................................. 18 Código 3 Documento de una estación en mongo .............................................................. 28 Código 4 Documento del histórico de una estación en mongo ....................................... 29 Código 5 Documento del histórico final y la predicción de una comarca en Mongo .. 30 Código 6 Ejemplo de una alerta en GeoJSON ..................................................................... 40 Código 7 Ejemplo de una ruta en GeoJSON ......................................................................... 40 Código 8 Ejemplo de brote en GeoJSON .............................................................................. 41 Capítulo 1 - Introducción 1 Capítulo 1 - Introducción La Gripe Aviar es una enfermedad que afecta a las aves silvestres y domésticas, normalmente de forma asintomática debido a que en la mayoría de los casos se trata de gripe aviar de baja patogenicidad. Las aves silvestres acuáticas (gaviotas, cigüeñas, patos, etc.) son los principales huéspedes de este virus y también son las que más pueden transmitir el virus en términos de distancia. Por otro lado, la variante altamente patógena puede provocar graves síntomas, pudiendo provocar la muerte del ave con facilidad y además es altamente contagiosa. Un contagio con este tipo de virus por parte de un ave en una granja puede extenderse muy fácilmente a todas las demás aves del recinto, al no haber mucho espacio entre unas y otras por lo general. Es esta la variante con más posibilidad de contagiar a un ser humano, en concreto los subtipos H5N1 Y H7N9, de nuevo pudiendo provocar graves síntomas en humanos. Las epidemias generadas por este virus aparecen en la mayoría de los casos en el continente asiático y europeo. Dentro de Europa ocurren con mayor frecuencia en países localizados al norte, debido a que el virus es capaz de sobrevivir más tiempo en el medio ambiente con temperaturas bajas. Sin embargo y por desgracia, España no está exenta de este virus con ejemplos de brotes en 2017, y en 2020 y 2021 dentro de una nueva ola de este virus. 1.1 Motivación La avicultura tiene una gran importancia para la economía española. De hecho, España se consolidó en 2019 como el cuarto país de Europa que más cantidad de carne produce en las más de 18.000 explotaciones que existen en el país 1 . Con el comienzo de la pandemia del COVID-19 todos los sectores se vieron perjudicados. A pesar de esta crisis provocada por la pandemia, los sectores agrícolas, ganaderas y pesqueras 1 lamoncloa.gob.es Capítulo 1 - Introducción 2 tuvieron un repunte del PIB de un 4,7% en 2020 2 . Y con respecto a la industria avícola española, esta genera alrededor de 2.300 millones de euros al PIB nacional y aproximadamente genera alrededor de unos 40.000 puestos de empleo 3 . Además, España es una gran exportadora de carne de ave. En estos años, se produjo un aumento del 2,5% del número de ventas en comparación a la década anterior. Los principales países a los que se les vende esta carne de ave son los países de la Unión Europea, de estos destacan los países vecinos (Francia y Portugal) 4 . Hay que destacar que a lo largo de todo el año se producen migraciones de diferentes especies de aves provenientes de países de Europa elevando la probabilidad de contagio en España y poniendo en peligro el sector avícola. Las consecuencias de un brote de gripe aviar en España no son solo sanitarias sino también económicas pudiendo ser peligrosamente catastróficas. Los primeros afectados serían los avicultores y agricultores, puesto que esta enfermedad es altamente contagiosa entre las aves, obligando a sacrificar gran parte de las aves del recinto por razones de salud, suponiendo una gran pérdida económica para ellos. Además, de lo mencionado anteriormente, podría tener grandes repercusiones en la economía del país e incluso en Europa. En cuanto a las consecuencias sanitarias, la variante de alta patogenicidad es muy letal en las aves, por otro lado, las infecciones en humanos son poco probables, pero siguen pudiendo causar graves síntomas. Por estos motivos, es necesario tener un mecanismo para predecir y tener el tiempo suficiente para tomar las medidas necesarias y evitar pérdidas económicas sobre todo en la situación actual donde todo el país está mermado tras la crisis provocada por el COVID-19. 2 efeagro.com 3 avicultura.com 4 https://avicultura.com/espana-las-exportaciones-de-carne-de-ave-cuadriplican-a-lasimportaciones-en-cinco-anos/ Capítulo 1 - Introducción 3 1.2 Objetivos El objetivo de este proyecto consiste en la elaboración de una herramienta capaz de predecir posibles brotes de gripe aviar en las comarcas ganaderas de España a partir de datos de brotes recientes en Europa, rutas migratorias de distintas especies y temperaturas para cada comarca dentro de un período semanal. Para esto se necesita: • Una base de datos con brotes de Europa capaz de actualizarse periódicamente, así como una fuente de datos para extraer dicha información. • Una base de datos con rutas migratorias de especies de aves importantes con respecto a la transmisión del virus en España. • Una fuente de datos de donde recabar previsiones de temperaturas en las diferentes comarcas ganaderas y de donde tomar las temperaturas reales para fechas pasadas con el fin de almacenarlas en la base de datos, todo de forma periódica. • Un modelo capaz de dar un nivel de alerta a cada comarca con los datos anteriores, además de poder generar un reporte con los datos tenidos en cuenta para calcular este nivel en cada alerta. El código resultante se almacenará en este repositorio público de Github. 1.3 Plan de trabajo Este es el plan de trabajo a seguir para el cumplimiento de los objetivos anteriormente detallados: • Búsqueda y elección de las fuentes de datos: se analizarán posibles fuentes de datos para extraer cada tipo de dato necesario para el modelo. Una vez encontrados se procederá a elegir uno para cada tipo de dato. • Diseño de los módulos software: se detallarán los módulos necesarios para la realización de los objetivos de este proyecto. • Desarrollo de la herramienta: se analizarán tecnologías adecuadas para implementar los distintos módulos. Capítulo 2 - Estado de la cuestión 10 de Stack Overflow ofrece en una web 13 resultados de sus encuestas durante diferentes años. Una gran parte de los encuestados en 2020 usa el lenguaje de programación Python, cuya popularidad ha aumentado sin parar a lo largo de los últimos años. Se trata de un lenguaje con una sintaxis sencilla, muy habitualmente usado en el campo del estudio de datos y que ofrece una amplia gama de librerías hechas por la comunidad, las cuales lo convierten en un lenguaje muy versátil y relativamente fácil de aprender, lo cual nos impulsó para usarlo como nuestro lenguaje de programación. Figura 2.2 Lenguajes más usados según Stack Overflow en 2020 13 Stack Overflow Developer Survey 2020 Capítulo 3 - Extracción y almacenamiento de los datos 11 Capítulo 3 - Extracción y almacenamiento de los datos En este capítulo se explicará con más detalle y profundidad el procedimiento de extracción de datos sobre brotes, rutas migratorias y temperaturas para las comarcas para su posterior almacenamiento. Antes de esto se explicará la técnica de geohashing, la cual ha simplificado las operaciones para asociar zonas geográficas y rutas en el desarrollo del proyecto. 3.1 Geohash Para poder realizar las asociaciones entre brote, ruta y comarca se necesitaba primero encontrar rutas en una zona alrededor de un brote y posteriormente verificar si el otro extremo de la ruta está en España. La técnica del geohash consiste en dividir el mapa mundial en rectángulos, cada uno con un código para identificarlos, como se ve en la Figura 3.1, este proceso sigue de forma recursiva dentro de cada uno de los recuadros añadiendo un carácter al código geohash correspondiente cada vez que se baja un nivel. De esta forma podemos enmarcar varias coordenadas dentro de una zona geohash, es decir, podemos asociar brotes y rutas comparando los códigos de geohash que se calculan a partir de sus coordenadas. Además, existen varias librerías de Python destinadas al uso de estos geohashes. Las dos librerías usadas en el proyecto fueron Geolib 14 y Geopy 15 , las cuales permiten calcular el geohash asociado a un punto geográfico representado por los valores de latitud y longitud entre otras funciones. 14 geolib · PyPI 15 geopy · PyPI Capítulo 3 - Extracción y almacenamiento de los datos 12 Figura 3.1 Mapa mundial con cuadrículas de geohash Al inicio del proyecto, se especificó que un brote se asociaría con las rutas en las que alguno de sus extremos estuviera localizado dentro de un radio de 25 km alrededor de dicho brote, para emular este radio se optó por usar geohash con longitud de 4 caracteres cuya cuadrícula tiene unas dimensiones de 39 km x 19.5 km. Capítulo 3 - Extracción y almacenamiento de los datos 13 Longitud en caracteres Dimensiones de la cuadrícula 1 5004km x 5004km 2 1251km x 625km 3 156km x 156km 4 39km x 19.5km 5 4.9km x 4.9km Tabla 3.1 Dimensiones de una cuadrícula geohash según la longitud 3.2 Extracción y almacenamiento de brotes Como se explicó anteriormente, la página de WAHIS-OIE fue la fuente de datos de brotes al principio del proyecto. Su portal para la búsqueda de brotes contiene la información más completa, pues es la fuente de datos de la otra opción que estudiamos, el portal de Empres-i. 3.2.1 WAHIS-OIE y Empres-i Hoy en día, una práctica muy habitual en este tipo de portales web es la de ofrecer una API para el acceso a sus datos, pero este no fue el caso. El buscador sobre brotes tampoco ofrecía ninguna forma de descargar los datos, por lo que se optó por aplicar la técnica del Web scraping. Esta técnica consiste en emular las peticiones que haría una personal real a una web y recoger los datos de la página que devolviese esta petición, todo de forma automática. El lenguaje de Python permite trabajar con la librería requests para realizar estas peticiones y la información se puede extraer mediante expresiones regulares, las cuales nos permiten buscar por patrones en la página del brote. Como ya se mencionó en el anterior capítulo, WAHIS-OIE sería la fuente de datos inicial del proyecto. Se estudió el proceso con el que se notificaban casos, con el fin de entender dónde se encontraba la información que se necesitaba extraer. Cuando un brote es detectado, el servicio veterinario que lo haya descubierto notifica a WAHIS-OIE generando un reporte, el cual contiene información sobre dicho brote o brotes. A cada brote se le asigna un identificador único y se añaden a la base de datos de la Capítulo 3 - Extracción y almacenamiento de los datos 14 organización, ofreciendo acceso a esta información mediante su portal web. Esta información incluye campos como el país y localidad donde se produjo el brote, la fecha en la que se hizo el reporte, el serotipo del virus o el número de casos avistados. Figura 3.2 Reporte con información de un brote en el antiguo WAHIS-OIE Sin embargo, en diciembre de 2020 el portal de WAHIS-OIE cerró temporalmente para mejorar la interfaz de la web y usar tecnologías más modernas en ella, tras lo cual se publicó el nuevo portal 16 2 meses después. La técnica Web scraping requiere del estudio previo de la estructura de una página para poder extraer la información de ella. Estimando el tiempo que se necesitaría para volver a realizar el proceso con la nueva estructura, se decidió usar el portal de Empres-i el cual permite descargar los datos desde 2017 en un fichero CSV. En este fichero aparecen muchos de los datos que ofrecía WAHIS-OIE como el país, el 16 OIE-WAHIS Capítulo 3 - Extracción y almacenamiento de los datos 15 serotipo del virus o el número de casos, pero carecían de la unidad epidemiológica asociada al brote la cual indicaba si este se había producido en un entorno doméstico o más bien entre aves silvestres. Empres-i también ofrece acceso a la información sobre brotes en su web de forma similar a como lo hacía WAHIS-OIE y con una página sencilla de comprender, lo cual no era de extrañar pues WAHIS-OIE es su fuente de información en materia de brotes de gripe aviar. Por lo que se volvió a usar Web scraping para recolectar esta información, apoyándonos en el campo Disease Event ID, el identificador único para cada brote, que aparecía en el fichero CSV para realizar las peticiones a su web. Figura 3.3 Página con la información de un brote en Empres-i 3.2.2 Almacenamiento de los brotes en MongoDB Los brotes se almacenan en una colección llamada outbreaks dentro de MongoDB, donde cada documento sigue la estructura del Código 1. Los campos más importantes en cada documento son: • Latitud y Longitud: las coordenadas donde se produjo el brote. Es necesario saber esta información para poder asociar un brote con una posible ruta migratoria con destino en España. • Geohash: calculado a partir de las coordenadas del brote, necesario para simplificar la asociación entre rutas y brotes. • Fecha de observación y reporte: necesario para delimitar en el tiempo los brotes que se tienen en cuenta para la aplicación del modelo. Capítulo 3 - Extracción y almacenamiento de los datos 16 • Epiunit: también llamado Animal Type en Empres-i, se trata del tipo de unidad epidemiológica que permite saber si el brote sucedió en un entorno salvaje, por ejemplo. Este puede ser Wild, Backyard o Domestic. Necesario en la aplicación del modelo. Código 1 Documento de un brote en MongoDB 3.3 Extracción y almacenamiento de rutas migratorias Las aves acuáticas silvestres son los principales propagadores de la gripe aviar, transmitiendo el virus a través del agua de los lagos o humedales donde suelen habitar. Estas, según la época del año, migran hacia otras regiones del planeta siguiendo lo que se conocen como rutas migratorias. Las rutas migratorias son los desplazamientos que en el momento de la migración las aves realizan. Normalmente suelen seguir un patrón según la zona y las características geográficas de dicha zona. Las aves que contraen la variante de alta patogenicidad del virus y posteriormente siguen estas rutas hasta España son la principal causa de brotes en España y esto es lo que la herramienta del proyecto busca predecir. Capítulo 3 - Extracción y almacenamiento de los datos 17 3.3.1 SEO Birdlife Gracias a la Sociedad Española de Ornitología 17 , a sus esfuerzos y a la investigadora Irene Iglesias, disponemos de un archivo CSV con datos sobre las rutas de más de 40 especies y más de 28 mil rutas conseguidas mediante la técnica de anillamiento, explicada anteriormente en la sección Obtención de datos sobre rutas migratorias del Capítulo 2 - . 3.3.2 Almacenamiento de rutas en MongoDB Las rutas se almacenan en la colección migrations dentro de MongoDB, cada ruta se sigue la estructura del Código 2. Los campos más importantes en la estructura son: • Latitud y Longitud: las coordenadas del extremo de la ruta que está fuera de España, necesario para la asociación entre rutas y brotes. • Geohash: calculado a partir de las coordenadas anteriores, necesario para simplificar la asociación entre rutas y brotes. • Especie: código de la especie de la ruta migratoria. • Comarca_SG: tomado directamente del CSV, gracias a este campo se puede asociar una ruta con una comarca ganadera en España de forma directa. 17 SEO Birdlife - Sociedad Española de Ornitología Capítulo 3 - Extracción y almacenamiento de los datos 18 Código 2 Documento de una ruta en MongoDB 3.3.3 Almacenamiento de rutas en Neo4j Neo4j se trata de otra base de datos NoSQL como MongoDB. Sin embargo, Neo4j tiene la particularidad de almacenar datos, no en documentos, sino en grafos. Para este proyecto, Neo4j se ha utilizado para almacenar una ruta como una relación entre dos nodos, ambos representando zonas geográficas. Esta base de datos se ha reestructurado varias veces para intentar mejorar el rendimiento y precisión al consultar rutas asociadas a un brote. 3.3.3.1 Zonas de geohash como nodos Esta primera versión constaba de un solo tipo de nodo, los nodos geohash. Estos contenían solamente el geohash calculado a partir de las coordenadas de cada extremo de la ruta. Las relaciones entre estos nodos representaban las rutas que asocian una cuadrícula geohash con otra. Capítulo 3 - Extracción y almacenamiento de los datos 19 Figura 3.4 Primera versión de estructura en Neo4j Esta estructura presentaba dos problemas principales: • Precisión de la asociación entre brotes y rutas: pueden existir casos en los que un brote esté situado muy cerca del límite que separa su zona geohash de otra. En estos casos puede haber rutas cuyo punto esté situado justamente en la zona geohash vecina, provocando que no se asocien brotes y rutas aun estando muy cerca entre sí. • Complejidad en la asociación ruta-comarca: la asociación también se debe hacer entre rutas y comarcas. En este caso no hay un destino fijo para cada ruta sino una zona geohash en España. Debido a esto se decidió formar una cuadrícula alrededor de cada comarca y calcular para cada cuadrícula geohash de una ruta, el porcentaje del área que solapaba con una cuadricula de una comarca ganadera. En la Figura 3.5, se puede apreciar de forma visual el proceso, la cuadrícula eyy0 correspondiente al punto de la ruta está completamente solapada por la cuadrícula de la comarca (porcentaje de solapamiento del 100%), por lo que se aceptaría la asociación rutacomarca. Capítulo 3 - Extracción y almacenamiento de los datos 26 Figura 3.12 Consulta con latitud y longitud Las predicciones son de los próximos 7 días (Figura 3.13). Por lo que, para conseguir la temperatura semanal es suficiente con hacer la media de las temperaturas de esos 7 días. Figura 3.13 Ejemplo salida JSON (TuTiempo.net) Para asignar una predicción a una comarca ganadera se usa el centroide de dicha comarca para la consulta de la API y se almacena en la base de datos. Una limitación de la API es que la búsqueda se realiza en un radio de 30 km según la latitud y longitudes especificadas y, si no hay datos en ese rango, la salida será nula. Utilizando únicamente el centroide como punto de referencia, muchas de las comarcas no disponen de predicción. Para solucionar este problema, se han creado cuatro niveles Capítulo 3 - Extracción y almacenamiento de los datos 27 de búsqueda donde acceden aquellas comarcas que no han tenido predicción en el anterior nivel: • Primer nivel: búsqueda en la API según el centroide de las comarcas ganaderas. • Segundo nivel: búsqueda en la API según las coordenadas de la comarca que aparece en la colección estaciones. La diferencia de estas coordenadas con las coordenadas que aparecen en la colección comarcas es que estas tienen menor precisión, es decir, menos decimales. Se usan puesto que, en algunos casos, la búsqueda con menos decimales si arrojan resultados, en cambio con las coordenadas de las comarcas de la colección estaciones, no. • Tercer nivel: búsqueda en la API según las coordenadas de las estaciones más cercanas. Se recorre la lista de todas las estaciones cercanas correspondientes con la API de AEMET, se extraen dichas coordenadas y se realiza la consulta. • Cuarto nivel: como último recurso se busca todas las comarcas de la provincia de la comarca que no tiene predicción y se le asigna la predicción de las comarcas de esa provincia que si tienen. En caso de tampoco obtener predicción se realiza el mismo procedimiento según la Comunidad Autónoma en la que se encuentre. 3.4.3 Almacenamiento de temperaturas en MongoDB Se hace uso de tres colecciones distintas: estaciones, histórico y temperatura. 3.4.3.1 Estaciones En esta colección se guarda la relación entre una comarca ganadera y las estaciones meteorológicas más cercanas. Por ello presenta 496 documentos, mismo número de documentos que la colección comarcas. Cada relación sigue la estructura del Código 3. Los campos más relevantes son: • comarca_sg: es el identificador único de cada comarca. Capítulo 3 - Extracción y almacenamiento de los datos 28 • indicativo: es el identificador único de la estación principal asociada a dicha comarca. • estacionesAdd: un array que contiene por orden de cercanía los indicativos de las estaciones más cercanas. Usada en caso de que la estación principal no pueda proveer datos. Código 3 Documento de una estación en mongo 3.4.3.2 Histórico Esta colección se usa para albergar las temperaturas recogidas por AEMET OpenData, según cada estación. Por este motivo, hay un total de 210 documentos. Todos los documentos se organizan siguiendo la estructura del Código 4, cuyos campos son: • idEstacion: identificador único de la estación. • histórico(semanal): un diccionario cuya clave es el año y el valor es un array con la temperatura mínima de todas las semanas de ese mismo año. Capítulo 3 - Extracción y almacenamiento de los datos 29 • boolCompleto: un diccionario cuya clave es el año y el valor es un array con el número de semana que no tiene temperatura mínima. Es decir, es un diccionario auxiliar, que se utiliza para saber por cada año las semanas que no tienen temperatura mínima. Haciendo que completar esa información con información de las estaciones más cercanas sea más fácil. Código 4 Documento del histórico de una estación en mongo 3.4.3.3 Temperatura Colección que contiene, para cada comarca ganadera, la temperatura por semanas desde el 2017 hasta la fecha actual, así como la predicción para la siguiente semana. La colección sigue la estructura del Código 5. Los campos que lo conforman son: • comarca_sg: identificador de la comarca ganadera. • históricoFinal: un diccionario cuya clave es el año y el valor es un array con la temperatura mínima de todas las semanas de ese mismo año. No hay valores nulos. • predicción: es la predicción proporcionada por la API de TuTiempo.net Capítulo 3 - Extracción y almacenamiento de los datos 30 Código 5 Documento del histórico final y la predicción de una comarca en Mongo Capítulo 4 - Aplicación del modelo y generación de alertas 31 Capítulo 4 - Aplicación del modelo y generación de alertas Tras haber asentado la obtención de los datos y su almacenamiento, se pasó a la fase de diseño de la herramienta. Revisando de nuevo los objetivos, aún son necesarios ciertos módulos en nuestra herramienta para poder aplicar el modelo usando los datos adquiridos. En las próximas secciones se va a detallar el proceso de implementación para cada módulo. 4.1 Actualización de datos sobre brotes y temperaturas Los datos sobre brotes y temperaturas en cada comarca deben estar actualizados para la correcta aplicación del modelo y funcionamiento de la herramienta. Para ambas colecciones se han utilizado scripts para actualizar los datos, lo cual se hace de forma semanal mediante el uso del servicio cron, añadiendo una regla en el fichero de crontab para que cada lunes a las 1:00 se ejecuten los scripts. El script de actualización de brotes manda una petición a la web de Empres-i que devuelve un archivo en formato CSV con los brotes de 1 año actualizados. Se almacena en la carpeta data, se abre dicho fichero y se buscan los brotes de la última semana. Si el brote ya existe se actualiza en la base de datos, si no se añade. El script de actualización de temperaturas realiza una consulta a AEMET OpenData obteniendo las temperaturas mínimas de la semana pasada y se guardan en la base de datos. Una vez actualizado el histórico se procede a realizar otra consulta, pero a la API de TuTiempo para guardar en la base de datos la predicción de la semana actual para la que se va a ejecutar el modelo. 4.2 Implementación del modelo La implementación del modelo consta de tres partes principales: • Factorías de datos: las factorías principales son la de los brotes y temperaturas, que hacen consultas a las bases de datos y transforman la información obtenida a un formato más conveniente para el modelo. Básicamente crean Capítulo 4 - Aplicación del modelo y generación de alertas 32 diccionarios con las comarcas como clave y datos asociados a cada comarca como valor. Con esto asociamos cada comarca con los brotes en Europa mediante las rutas almacenadas en Neo4j y también con su temperatura mínima. • Controlador: le encarga de pasar los datos al modelo y de controlar el número de ejecuciones se han de realizar. Según una fecha y un número de semanas, reitera el proceso de ejecución del modelo empezando por la semana de la fecha especificada y para las semanas anteriores. • Modelo: es la parte que usa los datos proporcionados por el controlador para calcular un nivel de riesgo para cada comarca. Para calcular el riesgo de una comarca i, para una semana t se tienen en cuenta los brotes surgidos en una ventana temporal de 3 meses (12 semanas) en el pasado. Para ello se sigue esta fórmula, proporcionada por la investigadora Irene Iglesias: Riesgo i, t = supervivencia del virus i, t * ∑ (riesgo_ruta i) o Riesgo_ruta i: Es el riesgo que genera una ruta migratoria que asocia una comarca i con un brote. El sumatorio se hace con todas las rutas provenientes de brotes que se produjeron dentro de la ventana temporal de 3 meses mencionada anteriormente. Este riesgo a su vez se calcula con la fórmula: Riesgo_ruta = ProbMigración * Epiunit ▪ ProbMigración: con un valor entre 0 y 1, es la probabilidad de que la especie asociada a la ruta se desplace hacia la comarca ganadera durante la semana actual. ▪ Epiunit: la constante asociada a la unidad epidemiológica del brote de la ruta. Un brote de aves domésticas apenas presenta un peligro pues normalmente se encuentran en cautiverio, mientras que las silvestres son las más peligrosas. Los valores son los siguientes: • Domésticas: 0.1 Capítulo 4 - Aplicación del modelo y generación de alertas 33 • Cautivas: 0.3 • Silvestres: 1 o Supervivencia del virus i, t: número de días que el virus de la gripe puede sobrevivir según el pronóstico de la temperatura mínima de la comarca i durante la semana actual t. Esta a su vez se calcula con la fórmula: Supervivencia = -7.82 * ln(temperatura en grados Celsius (Cº) ) + 29.94 Este valor se saturará en 66. También, en caso de que la temperatura sea igual o esté por debajo de los 0º. Una vez calculado el riesgo este debe traducirse a un nivel de alerta del 1 al 5 para poder ser visualizado en la aplicación web. Por ello se sigue el siguiente esquema: o Alerta nivel 1: 50-100 o Alerta nivel 2: 100-150 o Alerta nivel 3: 150-300 o Alerta nivel 4: 300-2000 o Alerta nivel 5: >2000 Para ajustar el riesgo a los niveles de alerta necesarios y probar la precisión de las distintas versiones del tratamiento de los datos, la investigadora Irene Iglesias hizo varios estudios con la ejecución del modelo durante el periodo de un año (52 semanas) entre los años 2020 y 2021, pues en estos dos años se produjo una ola de gripe aviar por toda Europa, provocando también casos en España. Estos estudios consistían, principalmente, en la generación de una gráfica mostrando una curva ROC. Esta gráfica consta de dos ejes, el vertical representando sensibilidad, probabilidad de que un caso positivo (hubo verdaderamente un brote en una comarca) sea predicho como positivo, y 1 - especificidad en el eje horizontal, donde la especificidad es probabilidad de que un caso negativo (no hubo brote) sea predicho como negativo. En la Figura 4.1 se muestra la gráfica resultante junto con una tabla que muestra diferentes umbrales de riesgo y la cantidad de Falsos Positivos y Capítulo 4 - Aplicación del modelo y generación de alertas 34 Negativos (alertas mal predichas), la cantidad los verdaderos positivos y negativos (número de comarcas en los hubo brote y en los que no hubo), además de la sensibilidad y especificidad correspondientes a cada umbral. Figura 4.1 Estudio con curva ROC del modelo Con el estudio se intentó averiguar qué umbral ofrecía mayor especificidad, con el objetivo de levantar el menor número de falsas alarmas posible. Así se optó por fijar el umbral con un valor de 2000, adquiriendo así una especificidad del 95%. Si bien este umbral es el más adecuado para el modelo, también conllevaba una sensibilidad de solamente el 33%, lo que significaba 2 de cada 3 brotes no serían correctamente predichos. Los pocos casos que ha habido en España hacen que sea muy difícil mejorar la precisión con la que se predicen posibles brotes. En la Figura 4.2 se muestran los niveles generados por el modelo en enero de 2021, con las dos comarcas donde se produjeron brotes rodeados en azul. Este mes junto con diciembre de 2020 fueron los meses con mayor número de brotes en Europa durante esta ola de gripe aviar. Como bien muestra la imagen gran parte de las comarcas mostraban un nivel de alerta elevado, pero solo hubo brotes en dos comarcas con niveles de alerta 3 y 5. Capítulo 4 - Aplicación del modelo y generación de alertas 35 Figura 4.2 Mapa con los niveles de alerta de enero 2021 y comarcas donde hubo brotes 4.3 Archivos generados por la herramienta Una vez aplicado el modelo para el número de semanas especificado, se debe guardar esta información de forma persistente. Para cubrir las distintas necesidades del proyecto, se generan los siguientes archivos: 4.3.1 Reportes La herramienta genera reportes de las alertas con información importante en formato PDF y CSV. Todos los reportes irán destinados a una carpeta Drive. 4.3.1.1 Reportes PDF Se genera un fichero PDF, por cada semana donde se haya ejecutado la herramienta. Haciendo uso del lenguaje de marcado ligero Markdown. Capítulo 5 - Conclusiones y trabajo futuro 43 Capítulo 5 - Conclusiones y trabajo futuro En este capítulo aparecerán las conclusiones obtenidas de este proyecto, además de posibles líneas de trabajo futuro para mejorar la herramienta. 5.1 Conclusiones Durante este proyecto, se ha querido desarrollar una herramienta capaz de calcular un nivel de riesgo de brote de Gripe Aviar para cada comarca ganadera española. Para esto se han usado datos sobre brotes en Europa, rutas migratorias de varias especies de aves acuáticas y las temperaturas mínimas de las comarcas ganaderas. Los datos sobre brotes fueron adquiridos inicialmente del portal de WAHIS-OIE y finalmente de la web de Empres-i. Esto se hizo mediante descarga directa y la técnica de Web scraping para mandar peticiones y extraer estos datos de su web. Los datos sobre temperaturas se obtuvieron de AEMET y tutiempo.net, ambas mediante el uso de sus APIs y finalmente las rutas migratorias fueron proporcionadas por la organización SEO-Birdlife. Tras esto, se pudo aplicar el modelo para la obtención de niveles de riesgo y mejorar la precisión de estos. La herramienta también es capaz de generar archivos con información sobre los niveles en cada comarca y los datos usados para calcularlos, además de poder subir estos ficheros a su respectiva plataforma de almacenamiento en la nube. 5.2 Trabajo futuro Al inicio del proyecto, se especificaron las variables que se iban a usar en el modelo para el cálculo del riesgo de posibles brotes. Aparte de las que actualmente se están utilizando, se debatió sobre el posible uso de dos variables más: • La estacionalidad de las aves: datos sobre el movimiento de las aves según la estación del año podrían ayudar a mejorar el uso de rutas migratorias en el cálculo de riesgo. Capítulo 5 - Conclusiones y trabajo futuro 44 • La cercanía entre puntos de llegada de aves migratorias y humedales del país: estos lugares son ideales para la transmisión del virus entre aves silvestres. Por ello, uno de los trabajos a futuro sería el empleo de estas variables en el modelo, con el fin de obtener una mayor precisión al calcular el riesgo de un posible brote. Otro de los trabajos a futuro, consiste en el desarrollo de una herramienta “offline”. Esta permitiría explorar distintos parámetros usados en el modelo como las constantes asociadas al tipo de ave de una ruta migratoria o la ventana de tiempo usada en la búsqueda de brotes, y además aplicar este nuevo modelo en semanas anteriores a la actual. Esta herramienta tendría el objetivo principal de comparar los niveles de riesgo resultantes con brotes reales que ocurrieron en comarcas de España para así establecer un umbral de riesgo que se podría usar para predecir si una comarca está en riesgo o no. La herramienta generaría una matriz de confusión mostrando los números de verdaderos positivos, falsos positivos, verdaderos negativos y falsos negativos, además de una gráfica con una curva ROC utilizando diferentes umbrales. Las colecciones en MongoDB pueden crecer de forma indefinida si no se piensa en un mecanismo para limitar su tamaño. Una forma de conseguir esto sería la de borrar las entradas más antiguas intentando que las colecciones solo almacenaran la información dentro de una ventana de tiempo. Esto se haría de forma periódica y para no perder estas entradas antiguas, se podrían comprimir en un fichero y ser guardadas en otro lugar. Aunque esto solo mitigaría el problema, podría ser suficiente para evitar tamaños de datos excesivos. Chapter 6 -Introduction 45 Chapter 6 - Introduction Avian Influenza is a disease that affects wild and domestic birds, usually asymptomatically because most of the cases are caused by low pathogenic avian influenza. Wild aquatic birds (seagulls, storks, ducks…) are the main hosts of this virus and the ones that can transmit the virus the most in terms of distance. On the other hand, the highly pathogenic variant can cause dangerous symptoms, which can easily kill a bird and is also highly contagious. An infection of this type of virus in a poultry farm can easily spread to all the other birds as generally there isn´t much space between them. This is the variant that is also the most probable to infect a human being, specifically the H5N1 and H7N9 subtypes, which can also cause serious symptoms in humans. The epidemics generated by this virus appear in most cases on the Asian and European continents. Within Europe, they occur more frequently in countries located to the north, because the virus can survive longer out in the environment with low temperatures. However, and unfortunately, Spain is not exempt from this virus with examples of outbreaks in 2017, and in 2020 and 2021 within a new wave of this virus. 6.1 Motivation Poultry farming is of great importance to the Spanish economy. In fact, Spain was consolidated in 2019 as the fourth country in Europe that produces the most meat in the more than 18,000 farms that exist within the 23 country. With the beginning of the COVID19 pandemic, all sectors were harmed. Despite this crisis caused by the pandemic, the agricultural, livestock and fishing sectors had a GDP rebound of 4.7% in 2020. 24 And 23 lamoncloa.gob.es 24 feagro.com Chapter 6 -Introduction 46 regarding the Spanish poultry industry, it generates around 2,300 million euros to the national GDP and approximately generates 40,000 jobs. 25 In addition, Spain is a major exporter of poultry meat. In these years, there was an increase of 2.5% in the number of sales compared to the previous decade. The main countries to which this poultry meat is sold are in the European Union, of which the neighboring countries (France and Portugal) stand out. 26 It should be noted that throughout the year there are migrations of different species of birds from European countries raising the probability of infection in Spain and endangering the poultry sector. The consequences of an outbreak of avian influenza in Spain are not only sanitary but also economic and can be dangerously catastrophic. The first to be affected would be poultry farmers, since this disease is highly contagious among birds, forcing the slaughter of a large part of the birds in the farm for health reasons, assuming a great economic loss for them. In addition, the above could have a major impact on the country's economy and even on Europe. As for the health consequences, the high pathogenic variant is very lethal in birds, on the other hand, infections in humans are less probable, but can still cause serious symptoms. For these reasons, it´s necessary to have a mechanism to predict and buy enough time to take the necessary measures and avoid economic losses especially in the current situation where the whole country is weakened after the crisis caused by COVID-19. 6.2 Objectives The objective of this project is the development of a tool capable of predicting possible outbreaks of avian influenza in the livestock regions of Spain using data from 25 avicultura.com 26 https://avicultura.com/espana-las-exportaciones-de-carne-de-ave-cuadriplican-a-lasimportaciones-en-cinco-anos/ Chapter 6 -Introduction 47 recent outbreaks in Europe, migratory routes of different species and temperatures for each region within a weekly period. For this the following would be needed: • A database with outbreaks in Europe capable of being updated periodically, as well as a data source to extract such information. • A database with migratory routes of important bird species that are related to the transmission of the virus in Spain. • A data source to collect temperature forecasts in the different livestock regions and from where to take the real temperatures for past dates to store them in the database, all on a regular basis. • A model capable of giving an alert level to each region with the previous data, in addition to being able to generate a report with the data considered to calculate this level in each alert. The resulting code will be stored in this public Github repository. 6.3 Workplan This is the work plan which will be followed to meet the objectives detailed above: • Search and choice of data sources: possible data sources will be analyzed to extract each type of data necessary for the model. Once found, we will proceed to choose one for each type of data. • Design of the software modules: the modules necessary to complete the objectives of this project will be detailed. • Development of the tool: appropriate technologies will be analyzed to implement the different modules. • Evaluation of the model: once the development is finished, it will be evaluated, comparing alerts of the model with outbreaks that occurred in Spain. • Preparation of the project report: finally, the procedures and results obtained during the development process of this project will be drafted. Capítulo 5 - Conclusiones y trabajo futuro 49 Chapter 7 - Conclusions and Future Work In this chapter the conclusions obtained from this project will appear, as well as possible future lines of work to improve the tool. 7.1 Conclusions During this project, an attempt has been made to develop a tool capable of calculating a risk level of an outbreak of Avian Flu for each Spanish livestock region. For this, data of outbreaks in Europe, migratory routes of several species of aquatic birds and minimum temperatures for livestock regions have been used. Data on outbreaks were initially acquired from the WAHIS-OIE portal and finally from the Empres-i website. This was done through direct download and the Web scraping technique to send requests and extract this data from the website. The data on temperatures were obtained from AEMET and tutiempo.net, both by using their APIs and finally the migratory routes were provided by the SEO-Birdlife organization. After this, the model could be applied to obtain risk levels and improve their precision. The tool is also capable of generating files with information on the levels in each region and the data used to calculate them, as well as being able to upload these files to their respective cloud storage platform. 7.2 Future work At the beginning of the project, the variables to be used in the model to calculate the risk of possible outbreaks were specified. Apart from those currently being used, the possible use of two more variables was discussed: • The seasonality of birds: data on the movement of birds according to the season could help to improve the use of migratory routes in the calculation of risk. • The proximity between arrival points of migratory birds and the country's wetlands: these places are ideal for the transmission of the virus between wild birds. For these reasons, one of the future tasks would be the use of these variables in the model to obtain greater precision when calculating the risk of a possible outbreak. Capítulo 5 - Conclusiones y trabajo futuro 50 Another future work consists in the development of an "offline" tool. This would allow modifying different parameters used in the model such as the constants associated with the type of bird on a migratory route, or the time window used in the search for outbreaks and apply this new model for weeks prior to the current one. This tool would have the main objective of comparing the resulting risk levels with real outbreaks that occurred in regions of Spain to establish a risk threshold that could be used to predict whether a region is at risk or not. The tool would generate a confusion matrix showing the numbers of true positives, false positives, true negatives, and false negatives, as well as a graph with a ROC curve using different thresholds. Collections in MongoDB can grow indefinitely if a mechanism to limit their size is not thought of. One way to achieve this would be to delete older entries by trying to get collections to only store the information within a time window. This would be done periodically and in order not to lose these old entries, they could be compressed into a file and saved elsewhere. Although this would only mitigate the problem, it could be enough to avoid excessive data sizes. Capítulo 8 - Contribuciones 51 Capítulo 8 - Contribuciones 8.1 Emilio José Valencia Calvopiña Participación en la actualización del script de Web scraping del portal de WAHISOIE. Tras realizar la búsqueda de posibles fuentes de datos, se optó por seguir usando el portal de WAHIS-OIE como fuente de datos sobre brotes, pues este fue usado durante el proyecto en el que se basa este TFG. Dicho proyecto contaba con un script de Web scraping para este fin, sin embargo, este código ya era obsoleto en relación con la actual web de WAHIS-OIE debido a que el portal había cambiado la estructura de su interfaz, por lo que el script era inutilizable y necesitaba ser modificado para que la extracción fuese correcta. Implementación del modeloV1, usado actualmente. Donde se implementa la función con la que se calcula el riesgo de alerta de una comarca en concreto. Teniendo en cuenta todos los brotes relacionados con dicha comarca, la probabilidad de migración de la especie de la semana pasada de cada brote y la temperatura mínima de la semana con la que se está ejecutando el modelo en la zona de la comarca. Corrigiendo el problema de las semanas de la probabilidad de migración en el modeloV1. La ejecución del código en general se hace de lunes a lunes, el fichero con los datos de la probabilidad de migración se distribuía por semanas, pero empezando del 1 de cada mes y por mes, suponiendo cuatro semanas (del 1 al 7, del 8 al 14, del 15 al 22 y del 22 a fin de mes). Puesto que el fichero que albergaba las probabilidades no seguía la misma distribución del proyecto en general, se debía de adaptar. Encargado de la búsqueda de fuentes de datos que proporcionasen información meteorológica, en concreto de las temperaturas mínimas de las fechas pasadas como de la predicción de la semana siguiente. Pieza fundamental en el cálculo del modelo. La búsqueda de una fuente de datos que pudiese ofrecer datos de predicciones fue la más complicada ya que las fuentes halladas no presentaban una forma de acceso sencilla. En su mayoría, para tener acceso a esos datos se debía de hacer uso de la técnica de Web scraping pero el nivel de complejidad era alto y con el fin de evitar el problema que hubo con WAHIS-OIE, que tras el cambio de la interfaz, el script 59 APÉNDICES Apéndice A - Dependencias software del proyecto A continuación, se enumeran las herramientas software y librerías de código que utiliza el proyecto. El código requiere de un servidor con un Sistema Operativo compatible con todas las herramientas principales, así como de una conexión a internet capaz de conectar con las APIs de AEMET y TuTiempo.net y con la web de Empres-i. Principales dependencias El siguiente listado recoge todo el software necesario para la ejecución del código: • Python3: lenguaje de programación usado para hacer el código. Es también recomendable el uso de versiones >= 3.9, pues este fue el usado en el proyecto. • Pip3: necesario para usar las librerías de Python. Usar la versión acorde con la versión de Python que se esté usando. • MongoDB: para el manejo de la base de datos principal, la cual almacena datos sobre brotes, rutas y temperaturas entre otros. • Neo4j: destinado al almacenamiento de rutas migratorias entre zonas de brote y comarcas mediante una estructura de grafos. • Pandoc: usado para convertir los reportes de ficheros Markdown a PDF. Librerías de Python usadas Se puede obtener información de todas estas librerías en la web de Pypi.org • Geolib, geopy y pygeohash: ofrecen operaciones relacionadas con el manejo de geohashes. 60 • GitPython: librería usada para interactuar con repositorios git. Usado para la subida de ficheros geoJSON al repositorio de la interfaz web. • Pydrive2: ofrece clases pensadas para facilitar el uso de la API de Google Drive. Usado para la subida de ficheros CSV Y PDF a una unidad, entre otras funciones. • Numpy: una popular librería especializada en operaciones sobre valores numéricos, aunque solo se usa su función de logaritmo neperiano en la fórmula del modelo. • Pandas: otra famosa librería que se usa para manejar datos estructurados. En el proyecto se utiliza para realizar operaciones sobre matrices, principalmente con datos extraídos de ficheros CSV. • Unicodecsv: permite el tratamiento de ficheros CSV con caracteres Unicode. • Requests: usado para realizar peticiones a las APIs y a la web de Empres-i, extrayendo los datos que devolvían. • Pymongo: librería oficial de MongoDB para interactuar con su base de datos. • Neo4j: librearía oficial de Neo4j para interactuar con su base de datos.