Sistema de alerta para gripe aviar

SISTEMA DE ALERTA PARA GRIPE AVIAR WARNING SYSTEM FOR AVIAN INFLUENZA TRABAJO FIN DE GRADO CURSO 2021-2022 AUTORA ELENA FERNÁNDEZ JIMÉNEZ DIRECTORES JOSÉ IGNACIO GÓMEZ PÉREZ CHRISTIAN TOMÁS TENLLADO VAN DER REIJDEN GRADO EN INGENIERÍA DEL SOFTWARE FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID SISTEMA DE ALERTA PARA GRIPE AVIAR WARNING SYSTEM FOR AVIAN INFLUENZA TRABAJO DE FIN DE GRADO EN INGENIERÍA DEL SOFTWARE DEPARTAMENTO DE ARQUITECTURA DE COMPUTADORES Y AUTOMÁTICA AUTORA ELENA FERNÁNDEZ JIMÉNEZ DIRECTORES JOSÉ IGNACIO GÓMEZ PÉREZ CHRISTIAN TOMÁS TENLLADO VAN DER REIJDEN CONVOCATORIA: SEPTIEMBRE 2022 CALIFICACIÓN: GRADO EN INGENIERÍA DEL SOFTWARE FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID 16 DE SEPTIEMBRE DE 2022 DEDICATORIA A mis amigos, a mi pareja y a mi familia. En especial a mi madre y a mi padre por darme la oportunidad de estudiar y a mi hermana por ayudarme a alcanzar mis sueños. -Elena Fernández Jiménez 2 AGRADECIMIENTOS A José Ignacio por las pautas facilitadas, por la adaptación a los problemas y por el interés puesto. A todos los compañeros de la Universidad Complutense de Madrid por trabajar en este proyecto y haber hecho posible mi colaboración. 3 RESUMEN Sistema de alerta para gripe aviar La situación de la gripe aviar en España empeora cada vez más. El número de brotes sigue creciendo a pesar de las altas temperaturas. La repercusión en la sociedad castiga de forma económica, sanitaria y social y produce el sacrificio de aves en buen estado de salud. Las mejoras desarrolladas para el proyecto DiFlusion han sido la automatización de instalación de la propia aplicación y el desarrollo de una nueva interfaz. La automatización evita tiempo de preparación y complejidad a la hora de instalar la aplicación. A su vez, facilita el almacenamiento de datos ya que se trata de dos contenedores independientes pero que funcionan como servidor propio; sin necesidad de dependencia de Google Drive o de Github permite el almacenamiento de datos en local. Por otro lado, la interfaz no generará problemas de licencia debido a la librería escogida para el desarrollo; también se trata de una nueva interfaz más ligera y eficiente, pero con funcionalidades muy similares a la anterior. Palabras clave Gripe aviar, automatización, instalación, Docker, Dockerfile, contenedor, Leaflet, interfaz, alertas, brotes. 4 ABSTRACT Warning system for avian influenza The avian flu situation in Spain is getting worse and worse. The number of outbreaks continues to grow despite the high temperatures. The impact on society imposes economic, health and social penalties and leads to the slaughter of healthy birds. Improvements developed for the DiFlusion project have been the automation of the installation of the application and the development of a new interface. Automation avoids preparation time and complexity when installing the application. At the same time, it facilitates data storage due to two separate containers that work as a server; without the need for Google Drive or Github dependencies, it allows data storage locally. On the other hand, the interface will not cause license problems due to the library chosen for development; it is also a new interface that is lighter and more efficient, but with functionalities very similar to the previous one. Keywords Avian influenza, automation, installation, Docker, Dockerfile, container, Leaflet, interface, alerts, outbreaks. 5 ÍNDICE DE CONTENIDOS Introducción 1 Motivación 2 Objetivos 2 Plan de trabajo 3 Estado de la cuestión 4 Introducción del modelo 4 Decisión de automatización 4 Una nueva interfaz gráfica 5 Unión de ambas partes 6 Desarrollo de la automatización 8 Máquina virtual como entorno de desarrollo 8 Docker 9 Repositorio 10 Imágenes y dockerfiles 11 Contenedores 11 Contenedores DiFlusion con Docker 12 Contenedor web 12 Construcción de la imagen web 14 Instanciación del contenedor web 14 Contenedor del modelo 14 Construcción de la imagen del modelo 15 Instanciación del contenedor del modelo 16 Conexión entre contenedores 16 Red Docker 17 Desarrollo de la nueva interfaz 18 Leaflet 19 Plugins 20 Repositorio Github 20 Árbol estructural 20 Entorno de desarrollo 21 Interfaz gráfica 22 Comarcas ganaderas 23 Alertas 24 Brotes 26 6 Migraciones 28 Rutas de riesgo 28 Time Slider 28 Conclusiones y posibles extensiones 30 Conclusiones 30 Posibles extensiones 30 Chapter 6 - Introduction 31 6.1 Motivation 32 6.2 Objectives 32 6.3 Workplan 33 Chapter 7 - Conclusions and possible extensions 34 7.1 Conclusions 34 7.2 Possible extensions 34 7 entre sí pero capaces de comunicarse. Uno de ellos contendría la interfaz del programa; mientras que el modelo lógico estaría en el otro contenedor. Esta última parte se encargaría de extraer y analizar la información, de hacer sus cálculos pertinentes y de enviar los datos a la interfaz gráfica para el usuario final en archivos GeoJSON. Debido a problemas con los tamaños de los ficheros y los repositorios web, se decidió que uno de los contenedores funcionase como servidor propio de la aplicación y que el otro se encargase de la manipulación de datos. Para eliminar de forma completa el problema del tamaño de los archivos se decidió implementar las lecturas desde el propio servidor web, no sin encontrar dificultades de acceso al realizar peticiones HTTP asíncronas a través de Ajax con XMLHttpRequest. Al realizar este tipo de peticiones, esta es bloqueada por la política CORS(Cross-Origin Resource Sharing). La solución residiría en eliminar el bloqueo a través de la herramienta apache a2enmod (ver sección 3.3.1 Contenedor web). De esta manera, gracias a Docker, aplicación de código abierto encargada de facilitar la automatización del despliegue de aplicaciones en contenedores y de la gestión de estos últimos, y gracias a sus famosos archivos Dockerfile, de los que hablaremos más adelante, se ha ahorrado tiempo de instalación. Con unos sencillos pasos se ha conseguido (entre otros) la instalación de dependencias, el clonado del proyecto y la puesta en marcha del programa a través de Apache, creando el servidor mencionado en el apartado anterior. 2.3 Una nueva interfaz gráfica El proyecto ya contaba con una interfaz gráfica por lo que a priori se podría pensar en que es innecesario desarrollar otra nueva. Pues bien, el problema residía en las licencias de las librerías empleadas, ya que no eran de software libre y podría ocasionar problemas en un futuro. Se hizo una búsqueda de librerías libres que supliesen la, entonces empleada, librería ArcGIS. Tras buscar alternativas capaces de trabajar con mapas se tuvieron dos librerías en cuenta. Una de ellas era CesiumJS [8], cuya licencia es de código abierto 5 pero cuenta con varios plugin no libres y/o no gratuitos. Además se trataba de una librería que no solo se centraba en mapas, sino en modelado 3D, lo que complicaría el desarrollo. La segunda librería, y la finalmente elegida, fue Leaflet, con licencia BSD (Berkeley Software Distribution) [9] siendo una de las licencias más permisivas que existen dentro del mundo del Software Libre; además, esta librería incluye plugin desarrollados y mantenidos por usuarios de la comunidad del Software Libre. Una vez elegida la librería, el objetivo tomó la forma de intentar que las funcionalidades de la interfaz creada con Leaflet se aproximara todo lo posible a la existente en ese momento. 2.4 Unión de ambas partes Tras llevar a cabo la automatización y la nueva interfaz, se decidió unificar ambas partes. De esta manera, estos cambios realizarán un lavado de cara al proyecto. Quedando como resultado una instalación sencilla a través de unos sencillos comandos capaz de montar un servidor y que pusiera en marcha la aplicación con la nueva interfaz. Eliminando contras como las trabas ocasionadas por el tamaño de los archivos, los posibles problemas con las licencias no libres y añadiendo ventajas como la comodidad y una nueva interfaz con un funcionamiento más rápido. Figura 2.4.1 Unión de ambas partes del proyecto 6 En la Figura 2.4.1 se observa una máquina virtual ejecutándose en la máquina física. Dentro de la máquina virtual (VM) se ha ejecutado el contenedor con la parte web el cual funciona como servidor. Desde la (VM) se ha accedido al puerto 8080 a través del navegador, destino de la información enviada por el contenedor en ejecución. Esta información es la interfaz que se ha desarrollado para el proyecto, alojada en un repositorio github, cuyo código es clonado en el contenedor. 7 Capítulo 3 - Desarrollo de la automatización El objetivo principal de la automatización de la instalación a nivel técnico es realizar a través de contenedores una separación de la parte web y de la parte del modelo encargada de tratar los datos. También se ha tenido en cuenta la necesidad de un sistema propio no dependiente de repositorios web para el almacenamiento de ficheros tratados por la parte web. El sistema operativo requerido para la instalación según la Guía de Instalación del TFG Predicción De Brotes De Gripe Aviar es GNU/Linux. Las ventajas que supone este sistema operativo son la licencia de Software Libre que posee y los distintos paquetes al alcance de cualquier usuario Linux, entre otros. 3.1 Máquina virtual como entorno de desarrollo La decisión de emplear una máquina virtual como entorno de desarrollo en vez de un Dual Boot (multiarranque) se debe a las ventajas de la virtualización. El proceso de automatización se realizaría de manera limpia y sin influencia de otros servicios capaces de condicionar su integridad. El desarrollo de la parte a tratar en este capítulo se ha llevado a cabo en una máquina virtual en Oracle VM Virtualbox. Esta máquina virtual cuenta con la distribución Ubuntu 20.04 LTS de Linux y las configuraciones mostradas en la siguiente imagen. Figura 3.1.1 Configuración Máquina Virtual Ubuntu 20.04 LTS 8 Figura 3.1.2 Configuración Máquina Virtual Ubuntu 20.04 LTS II Para comenzar el desarrollo era necesaria la instalación de algunos paquetes, como el de Docker, y el clonado del proyecto, bien desde la máquina virtual Taiga (máquina encargada de almacenar el proyecto) o desde el repositorio github. Este clonado contenía dos carpetas generales, la parte web (“applicacion Web”) y la parte del modelo (“TFG”) . 3.2 Docker [10] Docker es una plataforma de software libre con licencia Apache License 2.0 diseñada para desarrollar, compartir, administrar y ejecutar aplicaciones creadas por cualquier usuario. Todas estas ventajas se deben al uso de contenedores, similares a las máquinas virtuales, pero más cómodos para el desarrollo de aplicaciones independientes. Figura 3.2.1 Diferencia entre contenedor y máquina virtual 9 Algunas de las ventajas de los contenedores Docker son las siguientes: [11] ●Portabilidad: descargables y ejecutables desde cualquier terminal que soporte Docker. ●Ligero: comparten el kernel del sistema operativo del equipo, por lo que no emplea el almacenamiento que requeriría otro SO, favoreciendo la eficiencia y los costes en tiempo y espacio. ●Seguridad: caracterizados por el aislamiento frente a otros contenedores y/o programas. El único límite visible respecto a Docker y la instalación del proyecto DiFlusion en cualquier terminal es la obligatoriedad de emplear un sistema Linux, ya sea como Host SO o a través de virtualización. Esto se debe a las dependencias utilizadas en ambas partes del proyecto: la parte visual de la interfaz y la parte lógica del modelo. Es cierto que se adapta a muchas distribuciones de Linux, pero las posibilidades de Windows y Mac acaban aquí si no cuentan con un hipervisor. 3.2.1 Repositorio Una vez instalado Docker en la máquina virtual, se procede a la creación de una cuenta Docker, para almacenar las imágenes en distintos repositorios que posteriormente se ejecutarán para dar lugar a los contenedores funcionales. Es necesaria la creación de un repositorio por imagen, por lo que existe un control de versiones por cada una y facilita el desarrollo y la subida y descarga de cambios producidos. A continuación, se adjunta captura del conjunto de repositorios donde se encuentran las imágenes finales y de prueba utilizadas en el proyecto. Figura 3.2.1.1 Repositorios Docker 10 3.2.2 Imágenes y dockerfiles [10] Las imágenes de Docker se definen como plantillas de solo lectura. Estas plantillas están formadas por una serie de instrucciones que, tras ejecutarlas, dan lugar a un contenedor. Estas recetas se desarrollan en un fichero llamado Dockerfile, donde se especifica la configuración y las diferentes directrices a seguir. A través del comando $docker build [OPTIONS] PATH | URL | - se construye la imagen. Figura 3.2.2.1 Ejemplo de Dockerfile 3.2.3 Contenedores Una vez construidas las imágenes a través de los dockerfiles, está todo listo para ejecutar un contenedor. Un contenedor no es más que una instancia de la propia imagen. Para iniciar dichas instancias se requiere el uso del siguiente comando: $docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]. Las ventajas de la API de Docker es la facilidad para arrancar, parar, eliminar y gestionar contendores. A su vez, permite crear redes e incluir más de un contenedor en ella, permitiendo que se conecten entre sí. Figura 3.2.3.1 Proceso de creación de un contenedor 11 3.3 Contenedores DiFlusion con Docker Tras la justificación del uso de Docker y la introducción de la división de la aplicación, se procede a explicar cada una de las partes. 3.3.1 Contenedor web El contenedor encargado de la parte web está caracterizado por su función de servidor así como por tener los archivos de la interfaz de usuario. Para obtener la imagen web es necesario ejecutar el comando: $ docker pull elenafj18/httpddocker:latest Y para comprobar que se ha descargado con éxito es recomendable ejecutar: $ docker images Este último comando muestra la lista de imágenes disponibles (descargadas o construidas) para instanciar. Su desarrollo se ha llevado a cabo en un Dockerfile, el cual es el mostrado en la figura siguiente. Figura 3.3.1.1 Dockerfile de la parte web A continuación se explica el significado de cada instrucción: 12 ●FROM httpd:2.4. Imagen de la que partirá el contenedor. No todos los Dockerfile necesitan una imagen previa; pero en este caso facilita la creación del servidor. La imagen origen cuenta con Apache HTTP Server Versión 2.4. ●MAINTAINER elenafj18. Como su propio nombre indica, muestra el usuario por el cual está siendo mantenida (y desarrollada) dicha imagen. ●RUN apt-get update. Se encarga de actualizar la lista de aquellos paquetes que están disponibles. ●RUN apt-get -qq -y install openssh-server. Realiza la instalación de herramientas del protocolo Secure Shell (SSH). Su función es acceder a la red y comunicarse con otros contenedores de forma segura. Necesario para la comunicación de ambos contenedores. ●RUN apt-get -q -y install apache2. Instala Apache, que cuenta con herramientas necesarias que se explicarán en el comando siguiente. ●RUN a2enmod headers. a2enmod es una herramienta perteneciente al servicio Apache. Este comando permite realizar lecturas de ficheros desde local, ya que sin habilitar los headers, se produce un intercambio de recursos de origen cruzado (Cross-origin resource sharing, CORS), bloqueando la lectura de los archivos. Se usa para el tratado de los GeoJSON. ●RUN service apache2 restart. Es necesario reiniciar el servicio apache para que los cambios surjan efecto de forma satisfactoria. ●RUN apt-get -qq -y install git. Para descargar Git. Sistema de control de versiones. Necesario para el clonado de repositorios. ●RUN git clone https://github.com/influenzaAviar/applicacionWeb usr/local/apache2/htdocs/appWeb. Clona el código de la interfaz en la carpeta que el servidor emplea para mostrar por el puerto indicado. ●RUN useradd -ms /bin/bash webserver. Crea un nuevo usuario llamado webserver. ●WORKDIR /home/webserver. Equivalente al comando $cd. Especifica el directorio actual en el momento en el que se inicie el contenedor. 13 ●RUN mkdir .ssh. Crea el directorio .ssh en la carpeta del usuario. Este comando facilitará la conexión entre ambos contenedores a la hora de crear una clave público-privada. 3.3.1.1 Construcción de la imagen web Una vez completado el Dockerfile se procede a emplear el comando de construcción de la imagen. $ docker build . -t elenafj18/httpddocker El punto especifica la ruta donde se encuentra el Dockerfile del cual parte la imagen, y la opción “-t” permite al usuario Docker añadir una etiqueta a la imagen para facilitar su puesta en marcha y sus gestiones en Docker, en este caso “elenafj18/httpddocker”. 3.3.1.2 Instanciación del contenedor web La instanciación del contenedor web se realiza por medio del comando: $docker run -dit --name httpddocker -p 8080:80 elenafj18/httpddocker Este comando además de crear el propio contenedor, incluye la opción de “--name” al igual que el tag de las imágenes permite que su manipulación sea más fácil. También cuenta la opción de hacer un puerto público, en este caso emite por el puerto 8080 de la máquina física lo enviado al puerto 80 del contenedor; en este caso la interfaz web gracias al servidor Apache. 3.3.2 Contenedor del modelo El contenedor encargado de la parte del modelo posee todos aquellos archivos cuya función principal es el tratado de datos con el objetivo de conseguir ficheros GeoJSON que más tarde serán interpretados por la interfaz. Para obtener el contenedor es necesario la utilización del comando que se muestra a continuación: $ docker pull elenafj18/httpddocker:latest 14 4.4 Entorno de desarrollo El entorno de desarrollo es una decisión importante para el desarrollador, puesto que el trabajo va a estar condicionado por la experiencia con el entorno y las posibilidades que este ofrezca. En este caso se ha elegido Visual Studio Code. Figura 4.4.1 Entorno de desarrollo Visual Studio Code Visual Studio Code permite administrar el repositorio, en este caso el creado en la plataforma Github, proporcionando mayor comodidad a la hora de realizar clonados, commits, subir o bajar cambios y recuperar versiones anteriores. También cuenta con una terminal PowerShell integrada para facilitar el uso de otros comandos. Figura 4.4.2 Control de código fuente I Figura 4.4.3 Terminal Powershell integrado 21 4.5 Interfaz gráfica La interfaz gráfica registra algunas diferencias notables respecto a la anterior. Se ha tenido en cuenta la importancia de difundir y dar popularidad al proyecto, por lo que se ha decidido incluir el nombre de este en la propia interfaz. Los colores que priman son el negro y el rojo, siguiendo de cierta manera el estilo de la antigua parte web. Sin embargo, para una visión más clara de las zonas geográficas se han respetado los colores del mapa. También se han utilizado distintos colores para las alertas, lo que en su conjunto, produce en el usuario una mayor necesidad de interacción. Figura 4.5.1 Zonas diferenciadas de la interfaz de usuario La interfaz cuenta con varias zonas diferenciadas. En la parte izquierda de la pantalla se observa una serie de botones; en primer lugar aparecen dos símbolos reconocidos por cualquier usuario, el “+” y el “-” cuya función es ajustar el zoom para una visión más específica. A continuación, el icono de “home” sirve para resetear el zoom y las coordenadas. El icono similar a una lupa con un círculo rojo en su interior cumple la función de centrar la vista del mapa en los brotes, es decir, en Europa. El siguiente es similar al anterior, pero con un triángulo en lugar del círculo; su objetivo es mostrar las alertas con mayor claridad, es decir, España. Los dos botones siguientes son para mostrar las rutas, el primero muestra rutas infectadas y el segundo cualquier ruta 22 registrada; aparecerán en rojo y en blanco respectivamente. Por último, se observa la figura de un embudo, se trata de un botón desplegable del cual aparecen botones que filtran los distintos niveles de riesgo de las alertas. En la zona inferior izquierda de la pantalla se observa una escala del mapa. Justo en medio se ha creado un time slider para controlar el tiempo y mostrar los brotes y las alertas en la fecha señalada y adaptar la velocidad con la que transcurre. Finalmente, en la parte inferior derecha se ha incluído la leyenda de las alertas. 4.5.1 Comarcas ganaderas Las comarcas ganaderas se muestran en el mapa gracias al archivo comarcas.geojson incluido en el repositorio. Este archivo posee la lista de comarcas con sus correspondientes coordenadas, además incluye los nombres de la provincia y de la comunidad autónoma a las que pertenece. Con el fin de dar mayor detalle al usuario, se ha desarrollado una modal en la zona noreste de la pantalla, donde indica los campos mencionados de la comarca sobre la que se desliza el ratón. A su vez, se resalta la comarca por la que el usuario desliza el ratón. Figura 4.5.1.1 Selección de comarca ganadera 23 Otra de las funcionalidades que le caracteriza es el “zoom in” realizado cuando el usuario clica sobre una de las comarcas. Permitiendo una visión más amplia de la comarca seleccionada. Figura 4.5.1.2 Resultado de zoom in al clicar en una comarca 4.5.2 Alertas La información de las alertas se encuentra recogida en el archivo alertas.geojson. Este archivo es uno de los que ha requerido mayor tratamiento de datos para su interpretación en la interfaz para alcanzar los objetivos requeridos. Los campos de este fichero incluyen el identificador de la alerta, las coordenadas utilizadas para los marcadores, el nombre de la comarca, la fecha, el riesgo de la alerta y un enlace a más información. Las alertas se mostrarán en el mapa únicamente en su fecha correspondiente. Con el fin de clarificar la información de las alertas y su representación en el mapa se han utilizado distintos colores en función de su nivel de gravedad. 24 Figura 4.5.2.1 Información alertas Los niveles de alerta se clasifican en una escala del 1 al 5. Los colores, tal y como se muestran en la leyenda, son amarillo, naranja, rojo, marrón y negro respectivamente, siendo el nivel 1 el más leve y el 5 el más grave. Para añadir más información, al clicar sobre una alerta aparece un popup con el nivel de riesgo, por aclaración en caso de haber muchas alertas juntas. A su vez, se muestra un botón que redirige al informe completo sobre esa alerta, situado en Google Drive. Los iconos propios de las alertas se han diseñado de esta manera para que haya una relación directa entre el icono de la cabecera de la interfaz y estos, produciendo una sensación de mayor profesionalidad y consistencia en el estilo del desarrollo web. Figura 4.5.2.2 Iconos diseñados para la interfaz 25 Cabe mencionar el botón de filtrado de alertas situado en la parte oeste de la pantalla. Este desplegable permite mostrar las alertas de uno o varios niveles específicos. Para conseguir este filtrado ha sido necesario emplear el plugin de Leaflet conocido como Tag Filter Button. Para facilitar el filtrado y la gestión de estas, se ha leído el archivo alertas.geojson y se ha filtrado en código añadiendo las etiquetas correspondientes a cada alerta e incluyendo cada una en una capa de datos distinta. Figura 4.5.2.3 Filtrado de alertas 4.5.3 Brotes Los brotes de gripe aviar se registran en el fichero brotes.geojson. Este GeoJSON abarca los siguientes campos: identificador del brote, país, ciudad, fecha de observación, la especie encontrada, el número de casos y el serotipo; además de las coordenadas donde se sitúa. Para observar los brotes y su localización se recomienda usar la vista de brotes, conseguida a través del tercer botón de la parque izquierda. Los brotes aparecen como logos en forma de virus y de color rojo. 26 Figura 4.5.3.1 Información brotes Leaflet permite un zoom de gran nivel, de esta manera permite al usuario ver con exactitud de dónde proviene el brote. Figura 4.5.3.2 Zoom brote 27 4.5.4 Migraciones El archivo migrations.geojson incluye todas las rutas registradas con un punto origen y un punto fin, así como la especie característica de cada una. Para conseguir el propósito de mostrar las rutas, se ha incluído el penúltimo botón de la zona izquierda. Este botón carga una capa de datos y pinta en blanco cada ruta registrada. Al deslizar el ratón por encima de cada una, el color de la ruta correspondiente cambiará a gris y mostrará arriba a la derecha la especie migratoria característica. Figura 4.5.4.1 Migración e indicación de la especie 4.5.5 Rutas de riesgo Las rutas de riesgo y sus funciones implementadas aportan un valor añadido a la interfaz. Sin embargo, estas funcionalidades llevan sin estar disponibles un tiempo debido al tamaño del archivo rutas.geojson. Debido a este problema las pruebas realizadas se han llevado a cabo con un fichero más pequeño, por ello se muestran menos datos. Este problema es solventable una vez que el contenedor del modelo genere los nuevos geojson con nuevos datos y los envíe al contenedor de la interfaz, 28 donde en ninguno de los dos casos existirá la limitación de almacenamiento propia de github. Como funcionalidades extras se han desarrollado tres distintas. La primera de ellas se centra en las alertas. Además de mostrar un popup con el nivel de alerta y el enlace a los informes almacenados en Drive, al clicar sobre una alerta esta mostrará las rutas que llegan a esa comarca desde los distintos brotes activos. De esta manera se permitirá el estudio de la procedencia mayoritaria de aves potencialmente infectadas en cada comarca. Figura 4.5.5.1 Rutas de riesgo por alerta Tras reconocer la importancia del origen de cada alerta, se pensó también en las ventajas de saber el destino de aquellas migraciones que venían de focos de gripe aviar. Por ello, se decidió, ya en la antigua interfaz, que al clicar sobre un brote, se mostraría su alcance. De esta manera, siguiendo las antiguas funcionalidades, en la nueva interfaz también aparecen las distintas rutas con origen en un mismo brote, además de la información explicada anteriormente en el apartado 4.5.3 Brotes. 29 Figura 4.5.5.1 Rutas de riesgo por brote La última funcionalidad es prácticamente idéntica a la mostrada en la sección 4.5.4 Migraciones. Su objetivo es mostrar el número total de rutas provenientes de focos de gripe aviar. Su activación se produce a través del botón del ave roja situada en el conjunto de botones de la izquierda. Figura 4.5.5.3 Todas las rutas de riesgo 30 BIBLIOGRAFÍA [1] Evolución y situación actual de la gripe aviar. Ministerio de Sanidad. https://www.sanidad.gob.es/ciudadanos/enfLesiones/enfTransmisibles/gripeAviar/evol ucion.htm [2] Documentación sobre la gripe aviar. Ministerio de sanidad y consumo. PDF online. https://www.sanidad.gob.es/ciudadanos/enfLesiones/enfTransmisibles/docs/gripeAviar .pdf [3] Infecciones notificadas en humanos por virus de la influenza aviar A. CDC. https://espanol.cdc.gov/flu/avianflu/reported-human-infections.htm [4] La incidencia de la gripe aviar en verano plantea cambios de medidas de control. Animal's Health. https://www.animalshealth.es/avicultura/incidencia-gripe-aviar-verano-plantea-cambi os-medidas-control [5] Andalucía notifica otro foco de gripe aviar en aves de corral de Huelva. Animal's Health. https://www.animalshealth.es/avicultura/andalucia-notifica-otro-foco-gripe-aviar-avescorral-huelva [6] La peor temporada de gripe aviar de la historia de Europa: 5.300 brotes y 46 millones de sacrificios. Animal's Health. https://www.animalshealth.es/avicultura/peor-temporada-gripe-aviar-historia-europa-5 300-brotes-46-millones-sacrificios [7] Gripe aviar. Organización Mundial de Sanidad Animal. https://www.woah.org/es/enfermedad/influenza-aviar [8] CesiumJS. Cesium. https://cesium.com/platform/cesiumjs/ [9] Leaflet license. Github. https://github.com/Leaflet/Leaflet/blob/main/LICENSE [10] Docker overview. Docker. https://docs.docker.com/get-started/overview/ [11] What is a container? Docker. https://www.docker.com/resources/what-container/ 37 [12] Docker build.https://docs.docker.com/engine/reference/commandline/build/ [13] Leaflet. OSGeoLife. https://live.osgeo.org/es/overview/leaflet_overview.html [14] Leaflet. Leaflet. https://leafletjs.com/ [15] Plugins. Leaflet. https://leafletjs.com/plugins.html 38