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
 ÍNDICE DE FIGURAS

Figura 2.4.1 Unión de ambas partes del proyecto 6

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 9

Figura 3.2.1 Diferencia entre contenedor y máquina virtual 9

Figura 3.2.1.1 Repositorios Docker 10

Figura 3.2.2.1 Ejemplo de Dockerfile 11

Figura 3.2.3.1 Proceso de creación de un contenedor 11

Figura 3.3.1.1 Dockerfile de la parte web 12

Figura 3.3.2.1.1 Dockerfile del modelo I 15

Figura 3.3.2.1.2 Dockerfile del modelo II 15

Figura 3.3.2.1.3 Dockerfile del modelo III 16

Figura 4.1 Antigua interfaz gráfica 18

Figura 4.2 Nueva interfaz gráfica 19

Figura 4.1.2 Logo de Leaflet 19

Figura 4.3.1 Diagrama del árbol estructural del proyecto web 20

Figura 4.4.1 Entorno de desarrollo Visual Studio Code 21

Figura 4.4.2 Control de código fuente I 21

Figura 4.4.3 Terminal Powershell integrado 21

Figura 4.5.1 Zonas diferenciadas de la interfaz de usuario 22

Figura 4.5.1.1 Selección de comarca ganadera 23

Figura 4.5.1.2 Resultado de zoom in al clicar en una comarca 24

Figura 4.5.2.1 Información alertas 25

Figura 4.5.2.2 Iconos diseñados para la interfaz 25

8
Figura 4.5.2.3 Filtrado de alertas 26

Figura 4.5.3.1 Información brotes 27

Figura 4.5.3.2 Zoom brote 27

Figura 4.5.4.1 Migración e indicación de la especie 28

Figura 4.5.5.1 Rutas de riesgo por alerta 29

Figura 4.5.5.2 Rutas de riesgo por brote 30

Figura 4.5.5.3 Todas las rutas de riesgo 30

Figura 4.5.6.1 Time Slider 31

9
Capítulo 1 - Introducción

La gripe aviar es un virus infeccioso de tipo A, detectada por primera vez en

humanos en Hong Kong en 1997 [1]. Los seres vivos más directamente afectados son las
aves, sin excepción de especie, pero sí con diferencia de vulnerabilidad entre ellas
ante el virus en términos de gravedad. Esta gripe es altamente contagiosa, la
transmisión se puede llevar a cabo por contacto directo a través de cualquier objeto
infectado. Se encuentra bajo estudio la idea de que una de las posibles causas de las
distintas epidemias sea la relación entre aves domésticas y salvajes.

La supervivencia del virus es de larga duración, principalmente a bajas

temperaturas; no obstante, no tolera las temperaturas cálidas. Cabe destacar que las
temperaturas superiores o iguales a 70º C son fulminantes para este, eliminándolo de
forma íntegra. [2]

Aunque el sector avícola sea el más afectado, es necesario recalcar el peligro

existente para las personas. Los tipos de gripe aviar más contagiosos y con síntomas de
mayor gravedad capaces de afectar a los seres humanos son el H5 (N1, N6 y N8) y el
H7 (N3, N7 y N9). [3]

Hasta hace unos meses, esta enfermedad se consideraba estacional debido a

la variedad de temperaturas, a día de hoy se caracteriza como endémica. Durante el
invierno de este año se hallaron varios focos de gripe aviar que hasta el mes de mayo
no han podido ser controlados. Para sorpresa de los investigadores, ya avanzado el
verano, se ha informado de cinco brotes nuevos en España, sumándose a los ya
existentes y registrando un total de 33 focos. En toda Europa, el resultado ha sido
superior a 5.300 brotes con el consecuente de 46 millones de aves sacrificadas. [4] [5] [6]

Tras los datos publicados por la Autoridad Europea de Seguridad Alimentaria

(EFSA), la misma agencia Europea informó de la gravedad de la situación sugiriendo
nuevas medidas a medio y largo plazo, aconsejando reducir el número de aves de
corral en aquellas zonas geográficas con alto riesgo de infección.

1
1.1 Motivación [7]

Los estragos de la gripe aviar son cada vez de mayor importancia, tanto en la
sanidad de animales y de personas como en la economía global.

El sacrificio de las aves por brotes de gripe aviar se lleva a cabo con las
infectadas y con las sanas, con el fin de prevenir un riesgo mayor, llegando a reducir el
número de aves hasta el 50% en la mayoría de los casos.

También hay que tener en cuenta los daños indirectos, como pueden ser
pérdidas de trabajo en el sector avícola, la subida de precios en productos derivados
de aves como el huevo o la carne, la repercusión en zonas de turismo infectadas, etc.

Por ello, con el fin de alertar de posibles futuros brotes, el Instituto Nacional de
Investigación y Tecnología Agraria y Alimentaria (INIA) y la Universidad Complutense
de Madrid, han llevado a cabo un proyecto conocido como DiFlusion. Esta aplicación
está siendo desarrollada por alumnos de la UCM en los distintos Trabajos de Fin de
Grado y Trabajos de Fin de Máster. En este TFG se ha decidido contribuir a este
proyecto debido al impacto socioeconómico que ocasiona la gripe aviar.

1.2 Objetivos

La finalidad de este proyecto es la mejora de la herramienta de predicción de

brotes de gripe aviar desarrollada por Emilio José Valencia Calvopiña y Cheng Jun Liu
Zheng en su TFG titulado Predicción De Brotes De Gripe Aviar. Los puntos acordados
son los siguientes:

● Automatizar la instalación de la aplicación a través de dos contenedores

Docker como servidor propio.
● Crear una nueva interfaz de software libre.

2
1.3 Plan de trabajo

El plan de trabajo a seguir consta de los siguientes apartados:

● Búsqueda de información sobre el funcionamiento de los contenedores.

● Búsqueda de información sobre el funcionamiento de Docker.
● Creación de una máquina virtual Ubuntu 20.04
● Creación de un repositorio en propio en Docker.
● Búsqueda de información sobre Apache.
● Desarrollo de automatización de la instalación de DiFlusion.
● Pruebas de evaluación de la automatización.
● Búsqueda de bibliotecas JavaScript de código abierto o software libre
compatible con la creación de mapas.
● Búsqueda de plugins para la biblioteca citada en el punto anterior.
● Creación de un repositorio con control de versiones en propio en GitHub
para el desarrollo del código.
● Desarrollo de la interfaz.
● Prueba de evaluación del funcionamiento de la interfaz.
● Integración de la interfaz en el contenedor de la parte web.
● Prueba de la unión de ambas partes.

3
Capítulo 2 - Estado de la cuestión

Debido al nivel de gravedad de la gripe aviar cada vez resulta más útil la
información de propagación, el riesgo existente y las consecuencias que pueda
ocasionar. De esta manera, la aplicación DiFlusion supone un avance para aquellas
personas cuyo día a día depende de forma directa o indirecta de la evolución de esta
enfermedad.

2.1 Introducción del modelo

El modelo de la aplicación de Diflusion se encarga de obtener los datos a través

de distintos portales que proveen información de brotes, temperaturas y alertas. Una
vez conseguidos los datos se procede al procesamiento de estos generando como
resultado archivos GeoJSON.

El modelo está compuesto por tres partes principales. En primer lugar se

encuentran las factorías de datos (de temperaturas y brotes), cuya función es obtener
la información de las correspondientes bases de datos y generar un formato con
mayor manejabilidad. En segundo lugar, el controlador envía los datos al modelo per
se, administrando el número de ejecuciones necesarias en función de la fecha de esa
ejecución. Por último, la parte denominada “modelo”, emplea la información para
calcular el nivel de riesgo por comarca (i) en un periodo de tiempo (t) a través de la
siguiente fórmula:

Riesgoi,t = supervivencia del virusi,t * ∑ riesgo_rutai

Los valores obtenidos del modelo y los datos relevantes no procesados quedan
almacenados en ficheros GeoJSON: alertas.geojson, rutas.geojson, brotes.geojson.
También se dispone de otro archivo del mismo tipo nombrado como
comarcas.geojson que contiene las coordenadas y la información de cada comarca
ganadera.

2.2 Decisión de automatización

Con el fin de facilitar la instalación de este modelo predictivo, el Ministerio de

Agricultura, Ganadería y Pesca solicitó el uso de dos contenedores independientes

4
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 , cuya licencia es de código abierto
[8]

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
3.3.2.1 Construcción de la imagen del modelo

La imagen del modelo, al igual que la imagen web, ha sido creada a través de
un Dockerfile. A diferencia de la parte web, este Dockerfile contiene un gran número
de instalaciones de dependencias necesarias para los scripts, bases de datos, etc.

El Dockerfile que caracteriza a esta parte de la automatización es el siguiente:

Figura 3.3.2.1.1 Dockerfile del modelo I

Figura 3.3.2.1.2 Dockerfile del modelo II

En las dos primeras figuras priman la instalación de dependencias, como Client

URL (curl) destinada a la veracidad de la conectividad y transferencia de datos; Gnu
Privacy Guard (gnupg) para el cifrado de datos; MongoDB (mondo-db) y Neo4j para
bases de datos; Python (python3) para la ejecución de los scripts, etc.

15
 Figura 3.3.2.1.3 Dockerfile del modelo III

La tercera figura muestra la parte de conectividad con el servidor web.

Necesita la dependencia de OpenSSH Client con el fin de permitir al usuario logarse,
ejecutar comandos y redirigir puertos en una máquina remota. En resumen, facilita la
comunicación de cliente (contenedor modelo) con servidor (contenedor web). Esta
tercera parte también incluye la creación de un usuario, el clonado del repositorio y la
creación de la clave público-privada para la comunicación con otros contenedores.

Esta imagen se construye a través del Dockerfile mostrado en las anteriores

figuras empleando el comando:

$ docker build . -t elenafj18/gripe_aviar

3.3.2.2 Instanciación del contenedor del modelo

Para conseguir la instancia pertinente es necesario el uso del comando:

$ docker run --name gripe_aviar -dt elenafj18/gripe_aviar

Una vez el contenedor esté operativo se requiere del uso de crontab para generar el
envío de archivos desarrollados por el modelo al contenedor web. Esta parte se
desarrollará más en profundidad en el subapartado “3.3.3 Conexión entre
contenedores”.

3.3.3 Conexión entre contenedores

Ambos contenedores se conectarán a través de una clave público-privada.

Este proceso ha de ser manual ya que su automatización no es viable. Para ello, se
necesita la clave creada mediante keygen (dependencia instalada y clave creada

16
gracias a los comandos en Dockerfile) y conocer la ip de ambos contenedores. La
clave privada se crea en la carpeta .sh, también creada previamente en la plantilla
Docker.

A continuación, en el contenedor del modelo, se requiere la ejecución del comando

$cssh-copy-id -i id_rsa.pub <IP_influenza>. Este comando copia de forma
remota la clave privada directamente en el fichero authorized_keys del contenedor
del modelo, permitiendo el intercambio de archivos.

Por último, se reiniciará el servicio SSH con el comando $ /etc/init.d/ssh restart.

Es posible que otros comandos que tienen el mismo objetivo no funcionen debido a
dependencias no instaladas a partir del Dockerfile.

3.3.3.1 Red Docker

Si se decide administrar ambos contenedores en el mismo terminal y se

encuentran en una red docker, es más sencillo acceder a ellos. Para ello es necesario
crear la red con $ docker network create diflusion_network. Y para incluir los
contenedores en dicha red es suficiente con añadir una opción más a la hora de
ejecutar los contenedores, añadiendo --network diflusion_network al poner en
marcha el contenedor con docker run.

Para conocer qué contenedores forman parte de esa red docker existe el
comando $ docker network inspect diflusion_network. Este comando lista un
conjunto de características de la red, como el nombre, la fecha de creación, etc;
pero lo más interesante reside en la información de cada contenedor, pues se muestra
su dirección física y su ip, facilitando los valores de los campos de los comandos que se
han mencionado anteriormente.

17
Capítulo 4 - Desarrollo de la nueva interfaz

Una nueva interfaz de usuario para DiFlusion supone una renovación visual
importante. Y no es esta la única ventaja, sino que contando con la librería de Leaflet,
tratándose esta de una librería de software libre permite su desarrollo y su uso con total
libertad.

Durante la creación de la interfaz se ha tenido en cuenta la ya existente,

replicando en lo máximo posible las funcionalidades que la caracterizaban. Los
mayores cambios a simple vista son el paso de 3D a dos únicas dimensiones, lo que
facilita el tiempo de carga y la eficiencia del programa, y el uso de colores más vivos
con el fin de mostrar de manera más clara los brotes, las alertas y las rutas. A
continuación se muestra una captura de ambas interfaces.

Figura 4.1 Antigua interfaz gráfica

18
 Figura 4.2 Nueva interfaz gráfica

4.1 Leaflet

Como se ha explicado en el Capítulo dos - Estado de la cuestión, apartado 2.2,

la librería elegida para el desarrollo ha sido Leaflet. Leaflet es una librería JavaScript
para la creación de mapas interactivos para navegadores, compatible con HTML5 y
CSS3, lo que facilita el diseño y la funcionalidad. Se caracteriza por su ligereza y sus
innumerables posibilidades. [11] [12]

Figura 4.1.2 Logo de Leaflet

19
4.1.1 Plugins

La comunidad del software libre participa, crea y mantiene nuevas

características para añadir a los mapas. Estas características reciben el nombre de
plugin. Son fácilmente accesibles y no muy complejas de utilizar. Cada uno de los
plugins utilizados se especificarán en los puntos correspondientes de cada
funcionalidad del mapa. Los plugins disponibles se encuentran recogidos en la web
oficial de Leaflet.[13]

4.2 Repositorio Github

A día de hoy todo desarrollo necesita de un control de versiones para facilitar el

trabajo al desarrollador en cuestión y evitar así pérdidas graves que puedan afectar al
proyecto y recuperar cambios hechos con anterioridad. Por ello se ha llevado a cabo
la creación de un repositorio en Github: https://github.com/Elenafj18/applicacionWeb.

4.3 Árbol estructural

El árbol estructural del proyecto web se ha respetado tal cual estaba en el

proyecto antiguo.

Figura 4.3.1 Diagrama del árbol estructural del proyecto web

20
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
4.5.6 Time Slider

El modo en el que evolucionan los brotes de gripe aviar es importante para

todos los afectados por este virus, además, es útil poder revisar fechas anteriores por si
hay similitud entre la fecha actual y un año atrás. Por estos motivos, se decidió, ya en la
interfaz anterior, añadir un Time Slider para controlar el tiempo y poder ver
exactamente qué brotes y qué alertas existen en cada momento exacto. Para llevar a
cabo esta función se ha utilizado Time Dimension, uno de los múltiples plugins de
Leaflet.

La antigua interfaz contaba con dos barras de tiempo, una para alertas y otra
para brotes, lo que podía llevar a inconsistencias temporales ya que no había relación
entre brotes de hace un año y alertas de hace unas semanas. Por ello se ha decidido
unificar todo en un solo time slider. De esta manera, podemos ver en una semana
determinada el nivel de alerta de cada comarca y el estado de los brotes.

La duración de cada alerta en el mapa es de una semana, ya que pasados 7

días se renuevan los archivos que predicen el nivel de riesgo. En cambio, los brotes
aparecen en el mapa durante un periodo de tres meses, ya que es el tiempo estimado
en el que sigue habiendo riesgo de contagio.

Figura 4.5.6.1 Time Slider

En la barra temporal se pueden observar varios botones; los tres primeros son los
botones universales de control, permiten retroceder, poner en marcha o avanzar en el
tiempo. También encontramos la fecha y la hora que caracteriza la situación del
mapa en ese instante, seguidas de la propia barra, desplazable por el usuario para
facilitar su uso. Por último encontramos los fotogramas por segundo, este regula la
velocidad del paso del tiempo en la aplicación cuando el play es clicado por el
usuario.

31
Capítulo 5 - Conclusiones y posibles extensiones

Debido a que este trabajo forma parte del proyecto DiFlusion, y que puede ser
una herramienta muy útil para varios sectores, a continuación se exponen las
conclusiones a las que se ha llegado y los posibles trabajos que se pueden desarrollar
gracias a estas mejoras.

5.1 Conclusiones

Como se ha mencionado anteriormente, este proyecto puede suponer un antes

y un después en los sectores relacionados directa o indirectamente con la gripe aviar.
Por lo que se espera que el desarrollo que se ha realizado aporte valor a la
herramienta con el fin de ayudar a más seres vivos.

Estas mejoras están desarrolladas con el fin de mejorar la calidad de la

aplicación, así como promover su independencia todo lo posible de otras plataformas,
ya sea por limitación o por licencia. A su vez, supone un ahorro de tiempo al usuario,
elimina complicaciones innecesarias y realiza una instalación más limpia.

5.2 Posibles extensiones

Al tratarse de un proyecto tan amplio las posibilidades de mejora son

prácticamente infinitas. Una de estas potenciales extensiones es la refactorización de
código, respaldada por la diversidad de autores que han llevado a cabo el desarrollo
de cada una de las partes; se busca homogeneidad y, por supuesto, consistencia.

Durante este TFG se ha tratado la automatización de la instalación de la parte

del modelo y la parte de la interfaz gráfica, por lo que sería útil extrapolar la
automatización a la inicialización de las distintas bases de datos.

Por último hay que dar cabida al valor que pueden añadir nuevas
funcionalidades basadas en otras fuentes de datos.

32
Chapter 6 - Introduction

Avian influenza is an infectious virus type A, first detected in humans in Hong

Kong in 1997 . The living beings most directly affected are birds, without exception of
[1]

species, but with a difference in their vulnerability to the virus in terms of severity. This flu
is highly contagious, transmission can be carried out by direct contact through any
infected object. The idea that one of the possible causes of the various epidemics is the
relationship between domestic and wild birds is under consideration.

Survival of the virus is long lasting, mainly at low temperatures; however, it does
not tolerate warm temperatures. It should be noted that temperatures above or equal
to 70o C are fulminant for this, eliminating it completely. [2]

Although the poultry sector is the most affected, the danger to humans needs to
be emphasised. The most contagious and symptomatic types of avian influenza
capable of affecting humans are H5 (N1, N6 and N8) and H7 (N3, N7 and N9). [3]

Until a few months ago, this disease was considered seasonal due to the variety
of temperatures, nowadays it is characterized as endemic. During the winter of this year
several outbreaks of avian influenza were found which could not be controlled until
May. To the surprise of the researchers, by late summer, five new outbreaks have been
reported in Spain, adding to the existing ones and recording a total of 33 outbreaks.
Across Europe, the result has been more than 5,300 outbreaks, resulting in 46 million birds
being slaughtered. [4] [5] [6]

Following the data published by the European Food Safety Authority (EFSA), the
same European agency reported on the seriousness of the situation suggesting new
medium- and long-term measures, advising to reduce the number of poultry in
geographical areas at high risk of infection.

33
6.1 Motivation

The ravages of avian influenza are becoming increasingly important, both for
animal and human health and for the global economy.

The slaughter of birds for outbreaks of avian influenza is carried out with infected and
healthy birds in order to prevent an increased risk, reducing the number of birds by up
to 50% in most cases.

Indirect damage, such as job losses in the poultry sector, higher prices for poultry
products such as eggs or meat, the impact on infected tourist areas, etc. , must also be
taken into account.

Therefore, in order to warn of possible future outbreaks, the Ministry of Agriculture,

Fisheries and Food and the Complutense University of Madrid (UCM) have carried out a
project known as DiFlusion. This application is being developed by students of the UCM
in the different End of Degree Theses (TFG) and End of Master Theses(TFM). In this TFG it
has been decided to contribute to this project due to the socio-economic impact
caused by avian influenza.

6.2 Objectives

The purpose of this project is to improve the tool for predicting avian influenza
outbreaks developed by Emilio José Valencia Calvopiña and Cheng Jun Liu Zheng in
their TFG titled Prediction of Avian Influenza Outbreaks. The points agreed are as
follows:

● Automate the installation of the application via two Docker containers as a

server.
● Create a new free software interface.

34
6.3 Workplan

The work plan to be followed consists of the following sections:

● Search for information on the operation of containers.

● Search for information on how Docker works.
● Creating a Ubuntu virtual machine 20. 04
● Creating your own repository in Docker.
● Search for information about Apache.
● Development of automation of the DiFlusion installation.
● Automation evaluation tests.
● Libraries Search Open source JavaScript or free software compatible with
mapping.
● Search for plugins for the library mentioned in the previous point.
● Creating a repository with its own version control in GitHub for code
development.
● Development of the interface.
● Test to evaluate the functioning of the interface.
● Integration of the interface into the container of the web part.
● Proof of the union of both parties.

35
Chapter 7 - Conclusions and future work

As this work is part of the DiFlusion project and can be a very useful tool for
several sectors, the following are the conclusions reached and the possible work that
can be developed as a result of these improvements.

7.1 Conclusions

As mentioned above, this project may represent a before and after in sectors
directly or indirectly related to avian influenza. So it is hoped that the development that
has been carried out will bring value to the tool in order to help more living beings.

These enhancements are developed in order to improve the quality of the

application, as well as to promote its independence as much as possible from other
platforms, either by limitation or by license. At the same time, it saves the user time,
eliminates unnecessary complications and performs a cleaner installation.

7.2 Possible extensions

With such a wide-ranging project, the scope for improvement is almost endless.
One of these potential extensions is code refactoring, supported by the diversity of
authors who have carried out the development of each of the parts; homogeneity
and, of course, consistency are sought.

During this TFG we discussed the automation of the installation of the part of the
model and the part of the graphical interface, so it would be useful to extrapolate the
automation to the initialization of the different databases.

Finally, the value added by new functionalities based on other data sources
needs to be accommodated.

36
 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-aves-
corral-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