UN CUADRO DE MANDOS TERRITORIAL EN LA WEB
66
UN CUADRO DE MANDOS TERRITORIAL EN LA WEB TRABAJO FIN DE GRADO Autora: María Lázaro Muñío NIP Autora: 652326 Director: Rubén Béjar Centro: Escuela de Ingeniería y Arquitectura. Universidad de Zaragoza Titulación: Grado en Ingeniería Informática
Transcript of UN CUADRO DE MANDOS TERRITORIAL EN LA WEB
UN CUADRO DE MANDOS TERRITORIAL EN LA WEB
TRABAJO FIN DE GRADO
Autora: María Lázaro Muñío
NIP Autora: 652326
Director: Rubén Béjar
Centro: Escuela de Ingeniería y Arquitectura.
Universidad de Zaragoza
Titulación: Grado en Ingeniería Informática
Resumen El objetivo de este trabajo fin de grado, llamado “Un cuadro de mandos territorial en la web”, ha sido crear un sistema de información web con una interfaz de tipo dashboard (cuadro de mandos), que permita consultar datos de un territorio español elegido por los usuarios.
Para ello, se han localizado algunos datasets de interés que abarcan varios años y se ha diseñado un sistema basado en metadatos con el objetivo de que el sistema de información no esté atado a unos datasets concretos, sino que, si se añaden nuevos, se puedan visualizar sus datos automáticamente. Esto último siempre que sus datos estén enlazados con las entidades territoriales de la manera que se ha establecido.
El dashboard consta de una página inicial, donde se permite elegir la provincia o municipio (entidades territoriales) que se desea visualizar y dos páginas principales, provincias y municipios, que se muestran según la elección realizada en la página inicial. En las páginas principales se muestran los datasets mediante widgets, gráficas, tablas y mapas. Y además de los datasets, se han incorporado datos con actualización en tiempo real, como la localización de aviones que sobrevuelan la entidad territorial seleccionada.
Las tecnologías utilizadas en el proyecto han sido la base de datos PostgreSQL, el servidor de aplicaciones geográficas Geoserver, Node JS como servidor web y Docker para desplegar el sistema. También Vue JS y Bootstrap para las interfaces de usuario.
3
Contenido 1. Introducción .................................................................................................................................... 4
1.1. Contexto ................................................................................................................................... 5
2. Análisis ............................................................................................................................................... 9
2.1 Requisitos ................................................................................................................................. 9
2.2 Interfaz de usuario .............................................................................................................. 10
2.3 Datos y procesamiento ..................................................................................................... 12
3. Diseño .............................................................................................................................................. 13
3.1. Modelo de datos .................................................................................................................. 13
3.2. Arquitectura ........................................................................................................................... 16
3.2.1. Vista de módulos ............................................................................................................. 16
3.2.2. Vista de componentes y conectores ........................................................................ 17
3.2.3. Vista de despliegue ......................................................................................................... 19
3.2.4. Comportamiento del sistema ..................................................................................... 21
3.3. Interfaz de Usuario .............................................................................................................. 24
4. Implementación ........................................................................................................................... 28
4.1. Front-end ................................................................................................................................ 28
4.2. Back-end ................................................................................................................................. 29
4.2.1. Node JS ............................................................................................................................... 29
4.2.2. PostgreSQL ........................................................................................................................ 29
4.2.3. Geoserver ............................................................................................................................ 31
5. Pruebas ............................................................................................................................................ 35
6. Calendario y esfuerzos .............................................................................................................. 36
7. Conclusiones y trabajo futuro ................................................................................................. 37
Referencias ............................................................................................................................................ 38
Anexo 1: Manual de Usuario ............................................................................................................. 39
Anexo 2: Documentación de la API REST ................................................................................... 46
Anexo 3: Pruebas Manuales ............................................................................................................. 58
4
1. Introducción El objetivo de este trabajo fin de grado ha sido crear un sistema de información web con una interfaz de tipo dashboard (cuadro de mandos), que permita consultar datos de un territorio español elegido por los usuarios.
Para ello, se han localizado algunos datasets de interés que abarcan varios años y se ha diseñado un sistema basado en metadatos con el objetivo de que el sistema de información no esté atado a unos datasets concretos, sino que, si se añaden nuevos, se puedan visualizar sus datos automáticamente. Esto último siempre que sus datos estén enlazados con las entidades territoriales de la manera que se ha establecido.
El dashboard constará de una página inicial, donde se permitirá elegir la provincia o municipio (entidades territoriales) que se desea visualizar y dos páginas principales, provincias y municipios, que se mostraran según la elección realizada en la página inicial. En las páginas principales se muestran los datos de los datasets mediante widgets, gráficas, tablas y mapas.
Los widgets mostraran la información más actualizada de los datos que puedan generar más interés para que el usuario pueda verlos en un solo vistazo. Los mapas tienen distintas capas según las variables de interés contenidas en los datasets asociados a la entidad territorial elegida. Las gráficas muestran los valores de las variables de interés del dataset en la entidad territorial elegida a lo largo del tiempo. Algunas de ellas permitirán comparar estos valores con otros valores de otra entidad territorial. Finalmente, las tablas muestran los mismos valores que las gráficas, y además se pueden descargar en formato CSV.
Además de los datasets, se han incorporado datos con actualización en tiempo real, en este caso la localización de aviones que sobrevuelan la entidad territorial seleccionada por los usuarios, para dar un punto adicional de interés al dashboard. Esto, junto con todo lo comentado anteriormente, se puede ver en la Figura 1.
En la sección de mapa, se permitirá elegir capas según las variables de interés de los datasets asociados a la entidad territorial elegida para mostrarlas en el mapa en diferentes colores y con una leyenda de datos. En el caso de la página de provincias, a parte de las capas relacionadas con sus datos, permitirá mostrar las capas referentes a los municipios de dicha provincia.
5
Figura 1. Página Principal para Provincias.
1.1. Contexto Este trabajo fin de grado es una prueba de concepto (o primera versión) para una parte de un sistema de recuperación y acceso a información mayor que se está construyendo dentro del grupo de investigación IAAA, adscrito al Instituto de Investigación de Ingeniería de Aragón de la Universidad de Zaragoza. Aunque este trabajo se ha realizado con una frontera clara, se empieza a trabajar a partir de unos datasets con cierta estructura que vienen datos, estos datasets provendrían, en un futuro, de un sistema automático de búsqueda, gestión y conversión de datos geográficos existentes en Internet.
6
Se puede señalar que hay muchos dashboards de ciudades públicamente accesibles, pero no hay tantos que traten de recoger información de utilidad para territorios rurales. Este trabajo tiene pues el interés añadido de que, al centrarse en territorios mayores, incluyendo los rurales, permite darse cuenta del problema de la España vaciada. Como por ejemplo, resulta muy claro para cualquier usuario de esta aplicación que hay muchos municipios con poca población.
A continuación se describen algunos dashboards que se han localizado para comprobar el tipo de funcionalidades y datos que suelen tener disponibles este tipo de sistemas de información
Empleos y crecimiento en zonas rurales (Unión Europea)1: un dashboard que para cada Estado Miembro de la Unión Europea permite visualizar en un mapa la renta per cápita de las zonas rurales. También muestra gráficas referentes a tasas de empleo, empleos en el sector agroalimentario, índice de pobreza y comparación de los ingresos de los agricultores con otros empleos. Y además permite ver datos importantes en solo un vistazo, como por ejemplo el número total de trabajadores en la agricultura. Todo esto se puede ver en la Figura 2.
Figura 2. Empleos y crecimiento zonas rurales (Unión Europea).
City Dashboard London2: un dashboard que muestra datos de Londres, Reino Unido, en tiempo real. Estos datos son: tiempo, imágenes de cámaras de tráfico, número de buses y trenes en servicio, contaminación en el aire y algunos más. Todo esto se puede ver en la Figura 3.
1 https://agridata.ec.europa.eu/extensions/DashboardIndicators/JobsGrowth.html 2 http://citydashboard.org/london/
7
Figura 3. City Dashboard London.
City of Las Vegas School Tracker3: un dashboard que muestra en un mapa los tipos de escuelas que hay en Las Vegas, Estados Unidos, pudiendo elegir cuál de ellos quieres ver, junto con gráficas y tablas de los datos de las escuelas. Todo esto se puede ver en la Figura 4.
Figura 4. City of Las Vegas School Tracker.
3 http://communitydashboard.vegas/schooltracker
8
Estos ejemplos, han ayudado en este proyecto a la hora de tomar decisiones sobre el diseño de la GUI. Concretamente se ha tomado al último como referencia ya que estéticamente resulta bonito y muestra de una manera muy accesible los datos. Por ello el diseño de la GUI de este proyecto, que se puede ver en la Figura 1, es muy parecido al de “City of Las Vegas School Tracker”.
9
2. Análisis A continuación, se va a mostrar los requisitos, la interfaz de usuario y el tipo de datos que vamos a tener en el sistema de información.
2.1 Requisitos Los requisitos funcionales (Tabla 1) y no funcionales (Tabla 2) de la aplicación son los siguientes:
REQUISITOS FUNCIONALES ID Requisito RF1 Los usuarios podrán seleccionar una entidad territorial para ver sus datos
concretos RF2 La aplicación resaltará datos actuales agregados sobre cada territorio en
forma de widget RF3 La aplicación permite seleccionar de los datasets ofrecidos, cuál de ellos
desea ver en el mapa RF4 Cada conjunto de datos disponibles en el sistema será visible como una
capa en un mapa y se acompañará de una leyenda cartográfica adecuada para facilitar su interpretación
RF5 Las variables numéricas se representan sobre el mapa con una simbología cartográfica de intervalos de datos, cada una con un color distinto para diferenciarlas.
RF6 La aplicación permite visualizar sobre el mapa, correctamente posicionados, datos procedentes de API externas que se actualicen con frecuencia filtrados por la entidad territorial en ese momento. Esta visualización será dinámica si la fuente externa se actualiza con suficiente frecuencia
RF7 La aplicación permite ver las variables de interés que aparecen en los conjuntos de datos en forma de gráfica. Estas gráficas mostrarán los valores de las variables a lo largo del tiempo.
RF8 La aplicación permite consultar los valores de los datasets asociados a una entidad territorial, a lo largo del tiempo, en forma de tabla.
RF9 La aplicación permitirá descargar en formato CSV los datos mostrados en las tablas.
RF10 La aplicación permitirá comparar los conjuntos de datos de la entidad territorial seleccionada con otra entidad territorial del mismo tipo, siendo los tipos provincias y municipios. Estos datos se mostrarán tanto en tablas como en gráficas.
Tabla 1. Requisitos Funcionales
REQUISITOS NO FUNCIONALES ID Requisito RNF1 El sistema debe poder incorporar nuevos conjuntos de datos sin
modificar el código fuente, simplemente leyendo sus metadatos. Tabla 2. Requisitos No Funcionales
10
A continuación, se puede ver las definiciones de algunos términos de interés:
Dataset: conjunto de datos que contienen distintas variables de interés asociadas a distintas entidades territoriales.
Entidades territoriales: partes en las que se divide el territorio nacional para facilitar su administración. En este caso concreto, las partes serán provincias y municipios.
Simbología cartográfica de intervalos: símbolos cartográficos que se usan en un mapa para representar diversos elementos que se encuentran en la superficie terrestre, graduados por las variables de interés de los datasets con intervalos que pueden ser creados mediante varios métodos, como rupturas naturales, entre otros.
2.2 Interfaz de usuario En lo que respecta a la interfaz de usuario, la idea general es que los usuarios entren en la aplicación, seleccionen una entidad territorial de interés, y a continuación se vean los datos correspondientes sobre un mapa, gráficas, tablas y widgets.
Esto se puede ver en la Figura 5, un primer boceto, en el que tanto la selección de la entidad como los datos se ven en la misma pantalla, y en la Figura 6 y Figura 7 un segundo boceto en el que la selección y los datos se vean en pantallas diferentes.
Figura 5. Primero boceto
11
Figura 6. Segundo boceto. Pantalla inicial
Figura 7. Segundo boceto. Pantalla principal
En definitiva, se decidió optar por el segundo boceto, ya que por cuestiones de estética y funcionalidad se vio que era mejor.
12
2.3 Datos y procesamiento Respecto a los datos, típicamente vamos a tener datos asociados a entidades territoriales, que contienen un código único para poder enlazarlos. Generalmente se mostrarán variables numéricas asociadas a periodos de tiempos anuales, a veces con unidades y otras sin unidades.
El instituto nacional de estadística proporciona identificadores únicos para todas las entidades territoriales de España (al que normalmente se le llama “código INE”), que se han usado en los datasets del sistema, pero algunos proveedores de datos no los usan, por lo que, en una fase previa al trabajo alguien los cruzó.
Por último, cabe destacar que los datos de los datasets de municipios cambian cada año debido a que en ese periodo de tiempo algunos municipios son fusionados, haciendo que uno de los municipios ya no exista, o divididos produciendo que haya un municipio más.
Por ello, en este TFG, a la hora de seleccionar una entidad territorial para mostrar sus datos, solo se permite elegir entre las entidades territoriales del último año, subsanado así el problema.
13
3. Diseño En esta sección, se va a explicar el estilo arquitectural del sistema, junto con su modelo de datos y el diseño de la interfaz de usuario.
3.1. Modelo de datos El objetivo del modelo de datos, que se puede ver en la Figura 8, es tener suficiente independencia de los datos concretos que se muestran en la aplicación. Por ello las entidades de interés no son Población o Vehículos, sino que son Datasets, o capas de mapas. De hecho, el modelo de datos es en parte un modelo de metadatos, porque describe los datos que se incorporan a la aplicación.
Figura 8. Modelo de datos
El uso de una base de datos SQL ha venido impuesto por sus amplias capacidades de consulta espacial y la integración con el servidor Geoserver, pero el modelo relacional no se aprovecha especialmente en un sistema como este, donde no es necesario hacer consultas cruzadas de los datos, y en el que en muchos casos se van a servir tal cual están almacenados. Sin otras consideraciones se habría usado seguramente una base de datos NoSQL, pero en este caso se ha optado por aprovechar la buena capacidad que ofrece PostgreSQL para trabajar con datos en JSON de manera que se tiene lo mejor de ambos mundos: una base de datos con amplio soporte para operaciones espaciales, y la flexibilidad de tener un modelo de datos flexible y adecuado para el tipo de consultas que se van a tener.
La entidad App representa los Dashboards (entidad Dashboard) que tiene el sistema de información, en este caso Provincias y Municipios, y para cada una de ellas contiene los rangos de años y patrones (entidad Dataset_Series) de los Datasets
14
almacenados en el sistema, con el objetivo de que desde esta entidad se puedan obtener todos los Dataset para poder mostrar sus datos de forma automática.
Dicha entidad esta implementada en JSON, como se puede ver a continuación:
Los patrones de cada Dataset son un String que contienen el nombre del tipo de Dataset almacenado, por ejemplo, p_población, en la base de datos junto con “XX”, que serán los dos últimos dígitos del año, permitiendo así hacer consultas a todos los Dataset comprendidos en el rango de años.
Por otro lado, la entidad Dataset representa un conjunto de datos con variables de interés para las gráficas y tablas de datos (id, name, others e ítems) y para mapas (layers y geom), con el objetivo de poder mostrar estos datos en las diferentes secciones de las páginas del sistema de información.
La entidad Dataset, contiene para todos los Datasets del sistema, los datos de tabla ( entidad Table_Data) cuyas columnas son id, name, others (prov o total según el tipo de Dataset y otros datos posibles) y los ítems formados por un conjunto de columnas (entidad Labeled_Column), y los datos del mapa (entidad Map) formados por una geometría (geom) representado con nombre y tipo y por sus layers representados cada uno con nombre y título.
{ “nombre”: String, “dashboards”; {
“provincias”: { “dataset_tipo”: { “años”: String, “patron”: String }, …
}, “municipios”: {
“dataset_tipo”: { “años”: String, “patron”: String }, …
}
} }
15
Esta entidad también esta implementada en JSON de la siguiente manera:
En resumen, el objetivo de estas implementaciones, tanto del Dashboard como de los Datasets es que se puedan consultar mediante el la Entidad Dashboard todos los Datasets existentes, y a su vez cada entidad Dataset ofrezca los datos necesarios para mostrarlos en el mapa y en las gráficas.
{ “nombre”: String, “año”: String “table_data”; {
“id”: { “name”: String, “tipo”: String
}, “name”: {
“name”: String, “tipo”: String
}, “ítems”: {
“nombre_item”: { “name”:String, “tipo”: String
}, …
} “otros”: {
“name”: String, “tipo”: String
}
}, “mapa”; {
“layers”: [ {
“name”: String, “title”: String
}, …
], “geom”: {
“name”: String, “tipo”: String
} }
}
16
3.2. Arquitectura El estilo arquitectural del sistema es un cliente servidor web en 3 niveles (3-Tier). En el nivel de base de datos se usa una BD SQL, en el nivel de servidor web de aplicaciones se usan Node y el servidor especializado en datos geográficos Geoserver, y el nivel cliente se implementa con Vue sobre un navegador de Internet.
A continuación, se describe la arquitectura del sistema en distintas vistas arquitecturales: módulos, componentes y conectores y despliegue, y el comportamiento del sistema.
3.2.1. Vista de módulos En lo que respecta a la vista de módulos del sistema, sigue una arquitectura modelo-vista-controlador [1] como se puede ver en la Figura 9.
Figura 9. Vista de Módulos
17
En la sección de código del cliente, nos encontramos con varios módulos: Main, App, Provincias y Municipios. El módulo Main, contiene instancias a la librería Leaflet 4, una biblioteca de JavaScript que permite visualizar mapas interactivos, y a los módulos App, Provincias y Municipios que dan soporte a las pantallas de la Figura 28 y Figura 29 del Anexo 1.
El módulo App es la pantalla de entrada, y desde ahí se instancian los módulos Provincias y Municipios para que se puedan usar desde dicho módulo.
El código del servidor consta también de varios módulos, agrupados en tres paquees principales: Routes, Controllers y Models.
El módulo de Routes, contiene una clase llamada index que es el que implementa la API REST (Ver Anexo 2) e instancia a los objetos que componen el módulo Controllers (dashboard_controller, dataset_controller) para poder devolver los datos correspondientes a la petición HTTP que se ha generado.
A su vez el módulo Controllers, llama a los objetos del módulo Models (dashboard, dataset, dataset_queries) para obtener los resultados obtenidos mediante consultas a la base de datos. Los objetos del último módulo mencionado usan la librería Sequelize, que es un framework ORM (mapeador objeto-relacional) para bases de datos PostgreSQL entre otras, que permite mapear las tablas de datos con los objetos del modelo.
3.2.2. Vista de componentes y conectores Como se puede observar en la vista de componentes y conectores de la Figura 10, nos encontramos con una arquitectura cliente-servidor de tres niveles donde se separa la base de datos, Geoserver y el servidor web junto con la API que ofrece y el cliente web.
En el primer nivel, cliente web, esta toda la lógica de la aplicación cliente que contiene todo el código necesario para mostrar el resultado al usuario, que se corresponde con los módulos del código del cliente de la vista de módulos (Figura 9).
Para la obtención de los datos necesarios, el cliente utiliza componentes de Leaflet, que empleando el estándar WMS5 (Web Map Service) y el protocolo HTTP (petición – respuesta) se comunica con Geoserver, un servidor que permite servir mapas y datos desde una variedad de formatos. Para los datos que no son mapas, se comunica con el servidor Node mediante la API REST, que es implementada en la clase index del módulo Routes (Figura 9).
A su vez, el servidor Node, nivel dos, se comunica con la base de datos (PostgreSQL) del nivel tres mediante Sequelize y consta de los objetos correspondientes a los módulos Models y Controllers (Figura 9).
4 https://leafletjs.com/ 5 https://www.opengeospatial.org/standards/wms El estándar WMS proporciona una interfaz HTTP simple para solicitar imágenes de mapas geo-registradas desde una o más bases de datos geoespaciales distribuidas.
18
Finalmente, el servidor Geoserver que reside en el nivel dos, se comunica con la base de datos mediante el protocolo JDBC sobre HTTP para obtener los datos espaciales necesarios para servir los mapas.
Además de lo anterior, los componentes del nivel uno, cliente web, se comunican con un servicio externo llamado OpenSky que ofrece una API REST para obtener información de los aviones localizados en unas coordenadas concretas y poder presentar esta información a los usuarios de la aplicación.
Figura 10. Vista de Componentes y Conectores
Las peticiones de la API REST, comentada anteriormente, se explican con detalle en el Anexo 2.
19
3.2.3. Vista de despliegue Como se puede observar en la vista de despliegue de la Figura 11, tanto la base de datos PostgreSQL6 como el servidor Geoserver7 se han desplegado en contenedores Docker [2].
Los contenedores de Docker son procesos que proporcionan un entorno separado del sistema operativo anfitrión y de otros contenedores para ejecutar aplicaciones y que, a diferencia de las máquinas virtuales, usan directamente los recursos del sistema operativo del anfitrión y no virtualmente a través de un hipervisor, lo que los hace mucho más eficientes
La ventaja de introducir Docker en el sistema desde el principio es que se puede encapsular el entorno de trabajo de manera que se puede trabajar en local con la seguridad de que, en el momento de ponerlo en producción, van a ejecutarse con la misma configuración sobre la que se han realizado el trabajo.
Figura 11. Vista de Distribución/Despliegue
6 https://www.postgresql.org/ 7 https://docs.geoserver.org/
20
Respecto al despliegue en Docker, se ha creado un fichero Dockerfile (Figura 12), en el directorio del proyecto que permite a Docker construir automáticamente las imágenes necesarias: Geoserver y PostGIS [3], creando así los dos contenedores (Figura 11).
Figura 12. Dockerfile
En dicho fichero, se describen dos servicios a ejecutar, por un lado, la configuración del contenedor Geoserver donde se describe la imagen de éste, el puerto externo para comunicarse con el cliente web y el puerto interno, 8081 y 8080 respectivamente, su volumen montado en /geoserver_data /data, donde mantiene sus datos de configuración y por último la dependencia de Geoserver para Postgis.
Por otro lado, la configuración del contenedor de PostGIS con su puerto externo 25432, que será usado por el servidor y su puerto interno 5432 para la conexión con el Geoserver y sus volúmenes montados, uno en /var/lib/postgresql/data, donde se mantiene sus datos de configuración y otro para los backup de los datos.
Finalmente, al final del fichero se configuran los volúmenes para el backup de los datos tanto de Geosever como de PostGIS, con el fin de que, si Docker termina incorrectamente o se resetea, no se borren los datos contenidos en él. Lo que no ha sido posible guardar en el backup del Geoserver es la URL base del proxy, para que las capas se previsualicen correctamente, por lo que en este caso se tendría que cambiar a mano.
Una vez se tiene el Dockerfile, se ejecuta dicho fichero en el directorio donde se encuentra, lo que permite hacer uso tanto de la base de datos PostgreSQL como del servidor Geoserver, mediante el protocolo TCP/IP junto con los puertos anteriormente explicados.
Cabe destacar que el Cliente web se comunica con el servidor Web a través del protocolo TCP/IP, y éste mediante el ORM de Sequelize configurado en el puerto 25432 con la base de datos del contenedor Docker.
21
Además, tanto los dos contenedores entre sí, como el cliente web con el contenedor de Geoserver se comunican mediante la red por defecto de Docker Compose.
3.2.4. Comportamiento del sistema Para ilustrar algunos aspectos interesantes del comportamiento del sistema, se han realizado dos diagramas de secuencia: uno para el escenario de cargar una capa en el mapa y otro para la carga de datos en una gráfica (se ha ejemplificado con la de datos de población).
En el primer escenario, como se puede ver en la Figura 13, se detalla como los distintos componentes del sistema interaccionan cuando el usuario selecciona la capa de la sección del mapa que quiere visualizar.
En este escenario, el cliente hace una petición a la API REST para cargar los datos referentes al mapa, que a su vez ésta llama al controlador de Datasets que se encarga de devolver la respuesta en JSON al cliente, haciendo una llamada a Dataset que le devolverá el resultado de la consulta que realiza contra la base de datos.
Una vez tiene los datos necesarios, el cliente hace una petición mediante la librería de Leaflet a Geoserver, obteniendo así la capa para mostrarla en el mapa.
En el segundo escenario, como se puede ver en la Figura 14, se detalla como los distintos componentes del sistema interactúan cuando el usuario selecciona un Dataset concreto, en este caso se ejemplifica con “Población” para visualizar la gráfica correspondiente.
En este escenario, la aplicación cliente hace una petición a la API REST para obtener los datos del Dashboard llamado TFG, que a su vez ésta llama al controlador de Datasets que se encarga de devolver la respuesta en JSON al cliente, haciendo una llamada a Dataset_queries que le devolverá el resultado de la consulta que realiza contra la base de datos.
Una vez tiene los datos necesarios, se realizan varias peticiones a la API REST para obtener los datos de varios Datasets (p_poblacion_15, p_poblacion16, p_poblacion_ 17 y p_poblacion_18), y todas tendrán la misma secuencia en la que la API llama al controlador de Datasets que se encarga de devolver la respuesta en JSON al cliente, realizando una llamada a Dataset_queries que devolverá los datos en formato JSON resultado de la consulta contra la base de datos.
22
Figura 13. Diagrama de Secuencia. Insertar Capa en el Mapa
23
Figura 14. Diagrama de Secuencia. Ver grafica de población
24
3.3. Interfaz de Usuario En lo que respecta a la interfaz de usuario, inicialmente se barajó la idea de mostrar los widgets, mapa, gráficas y tablas en una misma página que permitiese elegir provincias o municipios.
Sin embargo, había alguna diferencia al mostrar los datos de provincias o los datos de municipios, como, por ejemplo, al elegir una provincia se debían poder mostrar los municipios de ésta, pero al elegir un municipio las provincias no se deberían mostrar.
Por ello, para modularizar mejor el código, se decidió mostrar los datos de provincias en una página diferente a la de municipios y por tanto a la hora de elegir que datos se quieren mostrar (provincias o municipios) se añadió a la GUI un formulario en la página principal que lo permite (Véase en la Figura 15).
Figura 15. Formulario de selección. Página principal.
Cada una de estas páginas mencionadas, son componentes de Vue, que usan Bootstrap [8] para mostrar los componentes de éstas (widget, contenedor del mapa junto con la información de selección y el contenedor de las gráficas) y CSS para darles estilo a estos componentes (esto se explica con más detalle en la sección 4.1).
Con respecto al mapa, en el caso de la página de provincias, se decidió diseñar una sección para elegir las capas disponibles. Esta sección tiene una lista para los años y otra para las variables de interés, y un checkbox para poder visualizar o no la capa de municipios en el caso de la página de provincias. Esto último siempre y cuando estén seleccionadas las características año y variable de interés (Véase en la Figura 16)
25
Figura 16. Selección de capas en el mapa. Página Provincias
Por el contrario, en la página de municipios, solo se mostrarían las capas disponibles de municipios (Véase en la Figura 17).
Figura 17. Selección de capas en el mapa. Página Municipios
El diseño de las capas tanto de provincias como de municipios se ha realizado con QGIS8 (se explica con detalle en la sección 4.2.2), de manera que cargando los datos almacenados en la base de datos para cada una de las capas que queremos diseñar, se han creado estilos en formato SLD9 (Styled Layer Descriptor).
8 https://www.qgis.org/es/site/ 9 Styled Layer Descriptor (SLD) es un estándar que permite la aplicar estilos a las características geográficas de un mapa web y su leyenda.
26
Estos estilos se han diseñado editando la simbología de cada una de las capas con el editor de QGIS como se ve en la Figura 18.
Figura 18. Configuración de estilos QGIS
La idea es clasificar las variables de interés, que son campos numéricos en la base de datos, para cada uno de los años con simbología graduada, por lo que, se ha creado una leyenda gradual para cada variable de interés y año mostrados en la sección de selección del mapa. Se ha utilizado el modo “Rupturas naturales” porque la aplicación es automática, no hay que elegir los intervalos a mano, y aun así el resultado cartográfico suele ser bueno. Este modo se basa en la naturaleza de los datos y los agrupa atendiendo a los saltos inherentes a estos buscando los puntos donde se maximizan esas diferencias y los usa como límites de cada intervalo. Una vez hecha la clasificación, basta asignar una “Rampa de color” diferente para cada una de las variables.
Con respecto a las gráficas y tablas, se ha decidido diseñar contenedores con pestañas dinámicas de Bootstrap, creando dos pestañas por cada “Dataset_ Series” (población, parque, o los que haya en ese momento), una para los datos de la provincia/municipio seleccionada y otra para comparar los datos de ésta con otra provincia/municipio. Esta segunda provincia o municipio se selecciona mediante un desplegable con todas las provincias o todos los municipios según la pantalla que nos encontremos (Véase en la Figura 19 y Figura 20).
En los contenedores de cada pestaña se ha decidido mostrar la gráfica con los datos de la provincia/municipio seleccionado o la comparación entre dos de ellos y un desplegable de Bootstrap para mostrar una tabla con todos los datos que se reflejan en la gráfica y alguno más de interés, junto con el botón que permite la descarga de los datos en formato CSV.
27
Figura 19. Pestañas y Gráfica de la pestaña Población
Figura 20. Sección de gráficas y tablas. Comparación entre provincias.
28
4. Implementación En esta sección, se va a explicar las tecnologías utilizadas para llevar a cabo la implementación del sistema de información diseñado en este trabajo.
4.1. Front-end En lo que respecta al Front-end de la aplicación, la parte de la aplicación que se despliega en el computador de los usuarios, se ha utilizado la tecnología Vue Js para implementar el lado del cliente.
Vue JS10 es un Framework Open Source de JavaScript, que permite construir interfaces de usuario de forma sencilla y por ese motivo se ha decidido usar esta tecnología en el proyecto.
Una de sus principales características es que trabaja con componentes Vue, un elemento en el cual se encapsula el código reutilizable. Estos componentes constan de etiquetas HTML, estilos de CSS y código JavaScript.
Para llevar a cabo el código HTML, en este TFG, se hace uso de Bootstrap, un Framework CSS que permite crear interfaces de usuario limpias y adaptables a todo tipo de pantallas y dispositivos.
Además, este Vue JS ofrece muchas librerías, de las cuales, en este proyecto, se han utilizado:
Axios para enviar peticiones a Endpoints REST y realizar operaciones CRUD, siendo éste un cliente HTTP basado en promesas para JavaScript, el cual puede ser utilizado tanto en el Front-end como el en Back-end con Node JS.
Leaflet Vue211 para crear mapas interactivos, con distintas capas y marcadores. Permite crear un mapa, mediante la clase nativa LMap, y añadir a éste la capa Open Street Map mediante la clase nativa LTitleLayer y marcadores con la clase LMarker.
Además, la clase nativa LTitleLayer.wms permite usar un servicio WMS de Leaflet, al que se le debe proporcionar una URL con el WMS que deseamos visualizar y opcionalmente parámetros como Layers (nombre de la capa a visualizar), Format (formato de la capa), etc.
FontAwesomeIcon12 para introducir iconos de FontAwesome en los marcadores del mapa y en los widgets.
HighchartsVue13 para incluir gráficos interactivos y Vue-select, una pequeña extensión de Vue JS, para incluir selectores.
10 https://vuejs.org/v2/guide/ 11 https://vuejsexamples.com/vue-2-components-for-leaflet-maps/ 12 https://fontawesome.com/icons?d=gallery 13 https://www.highcharts.com/blog/tutorials/highcharts-vue-wrapper/
29
Para comenzar a usar esta tecnología, se ha creado un proyecto con Vue JS mediante la herramienta VUE-CLI14 que permite iniciar proyectos Vue JS desde terminal de la siguiente manera: vue init webpack-simple mi-proyecto.
Una vez creado se instalan las dependencias mediante NPM de Node JS (Véase en la sección 4.2.1) y ya se puede iniciar el servidor mediante: npm run dev. De esta manera, se tiene un proyecto Vue listo para trabajar en él.
4.2. Back-end En lo que respecta al Back-end de la aplicación, se ha utilizado las tecnologías Node JS, servidor web y de aplicaciones, PostgreSQL, base de datos relacional, y Geoserver, servidor de datos geográficos. Estas tecnologías se explican en las siguientes secciones.
4.2.1. Node JS Node JS15 es un entorno de ejecución para JavaScript de lado de servidor que utiliza un modelo asíncrono y dirigido por eventos y que soporta protocolos TCP, DNS y HTTP.
Este entorno de ejecución realiza la compilación en tiempo de ejecución lo que permite una mayor optimización a las funciones más usadas, permite tener una escalabilidad alta mediante clusters, expandir el código añadiendo módulos de forma sencilla mediante Node Package Manager (NPM) y tener un alto rendimiento cuando se necesita ejecución en tiempo real.
Por todo ello, en este proyecto, se ha configurado con Node JS, además de que, dado que se ha decidido realizar el Front-end con Vue JS, éste permite mediante línea de comandos crear un proyecto Vue configurado a gusto de cada uno de manera fácil y sencilla.
4.2.2. PostgreSQL PostgreSQL16 es un sistema de código abierto de administración de bases de datos del tipo relacional, pero permite también ejecutar consultas que no sean relacionales.
Dado que, para el proyecto se necesitan consultas que no sean relacionales por cómo está construido el modelo de datos (Véase en la sección 3.1) y además se quieren manipular datos espaciales, se ha decidido optar por esta tecnología.
Y también por sus ventajas, PostgreSQL es multiplataforma (permite usarlo en distintos entornos, sistemas operativos y es compatible con muchos servidores web), es fácil de usar ya que su administración se vuelve sencilla usando PgAdmin, permite
14 https://cli.vuejs.org/ 15 https://nodejs.org/es/docs/ 16 https://www.postgresql.org/
30
manejar gran volumen de datos y soporta las propiedades ACID (Atomicidad, Consistencia, Integridad y Durabilidad).
Además, PostgreSQL tiene un módulo llamado PostGIS, un lenguaje similar a SQL que permite realizar análisis espaciales y consultas típicas sobre datos espaciales con facilidad, lo que le permite tener mucha potencia a la hora de para trabajar con datos espaciales.
Los datos espaciales asociados a entidades territoriales se han cargado en PostgreSQL utilizando QGIS. Estos datos venían en diversos formatos no soportados directamente por las herramientas de carga de datos de PostgreSQL, pero QGIS sí que ofrece el soporte necesario. Se puede ver en la Figura 21.
Los formatos no soportados por PostgreSQL son: Shapefile (SHP), un formato de archivo informático propietario de datos vectoriales, y Geopackage, un formato de archivo universal para compartir y transferir datos vectoriales y ráster.
Figura 21. Insertar datos a PostgreSQL mediante QGIS.
QGIS17 es una aplicación de escritorio para el trabajo con Sistemas de Información Geográfica (SIG) de código abierto que corre sobre Linux, Unix, Windows y Android, y soporta numerosos formatos de datos vectoriales, datos ráster y bases de datos.
17 https://www.qgis.org/es/site/
31
4.2.3. Geoserver Geoserver18 es un servidor que permite servir mapas y datos a través de HTTP desde una variedad de formatos a clientes estándar tales como navegadores web y programas GIS de escritorio. Los datos se publican a través de interfaces basadas en estándares, como WMS, WFS, y algunos otros de los definidos por OGC (Open Geospatial Consortium)19.
Geoserver tiene una interfaz de administración basada en navegador mediante la cual se ha configurado un almacén de datos PostgreSQL (Véase en la Figura 22) para poder crear las capas que se quieren mostrar en los mapas.
Figura 22. Configuración Almacén de Datos Geoserver
18 http://geoserver.org/ 19 https://www.opengeospatial.org/standards
32
Para crear cada capa, se agrega un recurso del almacén de datos y se configura mediante nombre, título y calculando los encuadres nativos y de latitud/longitud. Esto se puede ver en la Figura 23.
Figura 23. Configuración Capa Geoserver
33
Además, también para cada capa se puede agregar el estilo de publicación que desees, como se puede ver en la Figura 24.
Figura 24. Añadir un estilo a la capa.
Para añadir estilos nuevos, Geoserver permite crear estilos mediante la carga de un archivo en formado SLD creado mediante QGIS, de la misma forma explicada en la sección 3.3, y así poder asignarlos a la capa que se desee. Se puede ver en la Figura 25.
Figura 25. Crear un nuevo estilo
34
Una vez configurada la capa, esta se puede previsualizar en el navegador mediante una solicitud al servicio WMS (Web Map Service) que define las capas geográficas y el área de interés que les proporcionara y cuya respuesta es una o más imágenes de mapa en formato JPG, PNG, etc. Esto se puede ver en la Figura 26.
Figura 26. Visualización de la capa.
35
5. Pruebas En lo que respecta a las pruebas del sistema, las pruebas de la GUI se han realizado a mano, comprobando que en el mapa cada variable de interés mostrase la capa que le corresponde, junto con los valores de la leyenda adecuados, y que tanto en las gráficas como en las tablas se mostrasen los datos correctos de la entidad territorial seleccionada. Los casos de prueba concretos se detallan en el Anexo 3.
Las pruebas del servidor, concretamente las peticiones a la API REST, se han probado mediante Moncha, un marco de prueba de JavaScript que se ejecuta en Node JS y en el navegador lo que hace que las pruebas asíncronas sean simples y diversas, y Chai, una biblioteca de aserción BDD (Behavior-Driven-Developmet) / TDD (Test-Driven-Development) para Node JS que se puede combinar con cualquier marco de prueba de JavaScript (en este caso Moncha).
Para ello se ha instalado en Node JS, mediante NPM, las dependencias de mocha, chai y chai-http y se ha creado una carpeta en el proyecto llamada “Test” que contiene un archivo donde se programan las pruebas.
Se han realizado pruebas para cada una de las llamadas de la API obteniendo el resultado que se puede ver en la Figura 27 .
Figura 27. Test peticiones API REST
36
6. Calendario y esfuerzos El trabajo del proyecto se ha organizado en cinco iteraciones cortas con resultados incrementales:
Iteración 0: El objetivo fue tener una aplicación web básica que integrase las tecnologías elegidas (servidor web, cliente Vue JS, PostgreSQL, Geoserver, …) y desplegando la base de datos PostgreSQL y Geoserver en contenedores Docker.
Iteración 1: En esta iteración se creó la visualización de datos del parque de vehículos de los últimos años en un Dashboard, con datos tabulares, widgets, gráficos y un mapa centrado en la entidad territorial seleccionada.
Iteración 2: Esta iteración permitió ampliar la selección de entidades territoriales para cubrir provincias y municipios para parque de vehículos (Trafico) y datos de población obtenidos del INE. También se generalizó el modelo de metadatos, la API REST y el código cliente, para que la aplicación pudiera integrar distintas fuentes de datos para mostrar los datos en el mapa, widgets, gráficas y tablas de datos.
Iteración 3: Durante esta iteración se incluyeron datos obtenidos en tiempo real de una API externa, concretamente Opensky Network API, que se actualizan periódicamente. También se incluyó una nueva fuente de datos, masa forestal, lo que permitió verificar y mejorar el modelo de metadatos y el código cliente, al ponerlo a prueba incluyendo datos nuevos.
Iteración 4: Finalmente se hicieron las pruebas finales de la GUI y la API REST y se completó la mayor parte de la documentación técnica y memoria del proyecto.
La distribución en el tiempo de estas cinco iteraciones, y el esfuerzo dedicado a cada una de ellas se muestra a continuación. Véase en la Gráfica 1 y Tabla 3.
Iteraciones Duración (días) Inicio Fin Horas dedicadas
Iteración 0 6 16/10/2019 22/10/2019 30
Iteración 1 14 23/10/2019 06/11/2019 60
Iteración 2 60 07/11/2019 07/01/2020 180
Iteración 3 4 08/01/2020 12/01/2020 24
Iteración 4 10 13/01/2020 23/01/2020 60
Total (horas dedicadas) 354 Tabla 3. Distribución en el tiempo de las iteraciones.
Gráfica 1. Cronograma de las cinco iteraciones
37
7. Conclusiones y trabajo futuro En este trabajo se ha diseñado e implementado un sistema de información web con dos interfaces de tipo dashboard (cuadro de mandos) que permite ver los datos de un territorio español elegido por los usuarios.
Este sistema permite integrar fácilmente distintas fuentes de datos para provincias y municipios mediante metadatos, pero se ha probado concretamente con datos de población (INE), parque de vehículos (DGT) y pérdida de masa forestal de los municipios y provincias españoles entre los años 2015 y 2018.
Las tecnologías utilizadas en el proyecto han sido la base de datos PostgreSQL, el servidor de aplicaciones geográficas Geoserver, Node JS como servidor web y Docker para desplegar el sistema.
Vue JS y Bootstrap para las interfaces de usuario. Estas interfaces se adaptan a distintos tamaños de ventana de los navegadores web, y se pueden usar también en tabletas, aunque habría algunos aspectos que mejorar, como por ejemplo la sección de capas en el mapa, y la posición de las pestañas de selección para ver las gráficas y tablas. La aplicación no se adapta muy bien a dispositivos móviles con pantallas más pequeñas, por lo que parte del trabajo futuro consistiría en realizar la adaptación a móvil.
Otra de las limitaciones del sistema en su versión actual es que al introducir nuevas fuentes de datos y crear sus metadatos, se visualizarán todas las secciones de la interfaz correctamente, excepto los widgets. En estos aparecerán datos correctos pero los iconos no estarán demasiado relacionados dado que no hay un campo en los metadatos para tener esto. La sección de selección de capas en el mapa verá afectada su usabilidad, en el caso de que haya muchas variables de interés al mismo tiempo.
Por ello, habría que plantearse en el futuro guardar en algún sitio los iconos para que se mostrasen acorde con los datos y mostrar las variables de interés en un desplegable cuando fuesen más de un número estipulado.
Finalmente, a modo de conclusiones personales, puedo señalar que al realizar este proyecto he aprendido a configurar Docker y a mostrar mapas y capas en él diseñadas por mí misma en un sitio web, dato que me parece muy interesante dado que es muy entretenido y que en un mapa puedes mostrar casi todo lo que se te ocurra.
También ha sido nuevo para mí, crear un sistema flexible según las fuentes de datos disponibles en la base de datos, por lo que he aprendido a diseñar metadatos y hacer uso de ellos mediante una API REST, y a mostrarlos en la interfaz de usuario de manera que añadiendo más datos se mostrasen de igual forma.
Estoy segura de que todo lo aprendido con este proyecto, tanto las tecnologías que no había usado, como las que sí, haciendo que sea más hábil con ellas, me servirá en el futuro profesional, lo que hace que este satisfecha con mi proyecto fin de carrera.
38
Referencias 1- Buschmann, Frank (1996). Pattern-Oriented Software Architecture. 2- Docker: https://docs.docker.com/compose/ 3- Docker-Geoserver-PostGIS: https://github.com/orlade/docker-geoserver-
postgis 4- Docker-Geoserver: https://github.com/GeoNode/geoserver-docker 5- Docker-PostGIS: https://github.com/appropriate/docker-postgis 6- Docker-Geoserver: https://github.com/kartoza/docker-geoserver 7- Kartoza: https://hub.docker.com/r/kartoza/postgis/ 8- Bootstrap: https://www.w3schools.com/bootstrap/default.asp
39
Anexo 1: Manual de Usuario A continuación, se va a explicar para cada una de las pantallas de la aplicación cuál es su funcionalidad. Este manual corresponde a la implementación actual de la aplicación, con los Datasets que se han cargado a este trabajo. Dada la naturaleza flexible del sistema diseñado, distintas aplicaciones finales podrían ser configuradas con distintos datos, y posiblemente estas requerirían manuales de usuario ajustados a eso.
La pantalla de inicio del sistema de información (Figura 28), consta de dos desplegables, uno para todas las provincias de España y otro para todos los municipios de la provincia seleccionada, esto quiere decir que, solo se mostraran los municipios si has seleccionado una provincia.
Por tanto, si solo seleccionas la provincia, al hacer click en “Aceptar” te mostrará el Dashoboad correspondiente a la provincia elegida. En cambio, si seleccionas tanto provincia como municipio, te mostrara el Dashboard correspondiente al municipio elegido.
Cabe destacar que se permite la posibilidad de eliminar el municipio seleccionado, en el caso de que quieras mostrar solo la provincia y no el municipio.
Figura 28. Elegir Provincias y Municipios.
La pantalla principal del sistema de información (Figura 29) muestra los datos correspondientes a la provincia o municipio según lo que se haya elegido en la pantalla de inicio. Tanto en el Dashboard de provincias como el de municipios siempre se muestran unos widget con la información más interesante con el objetivo de que en solo un vistazo puedas ver los datos más importantes de la entidad territorial, un mapa con el zoom centrado en la provincia o municipio seleccionada junto una legenda en la que se pueden seleccionar las capas que desea mostrar en el mapa y por último, una sección de gráficas en las que se pueden ver los datos de la entidad territorial separadas por población, tráfico y pérdida forestal, además de gráficas comparativas entre provincias o municipios.
Cabe destacar, que desde la pantalla principal se puede volver a seleccionar otra provincia o municipio si se desea, pulsando en “Elegir provincia o municipio”.
40
Figura 29. Pantalla Principal.
A continuación, se va a explicar cada una de las secciones que componen la página principal, cuando en la página inicial se ha seleccionado solo la provincia.
En primer lugar, los widgets (Figura 30) muestran información del número de habitantes, los kilómetros de pérdida forestal, el número de turismos de la entidad territorial y los aviones que están pasando por ésta.
41
Figura 30. Widgets
En segundo lugar, se muestra el mapa centrado en la provincia seleccionada, en este caso Zaragoza y los iconos de aviones que reflejan que en ese momento hay un avión pasando por esa localización (Figura 31).
Figura 31. Mapa centrado en la provincia seleccionada.
Junto a dicho mapa se encuentra la leyenda que permite seleccionar el año y la variable de interés que quieras mostrar para que se pueda ver la capa correspondiente en el mapa. Para ello, se deben seleccionar tanto año como la variable de interés, da igual en que orden.
El resultado de seleccionar, por ejemplo, el año 2018 y la variable de interés “Turismos” es el siguiente (Ver Figura 32):
42
Figura 32. Resultado elección variable turismos.
En lo que respecta a los municipios, permite seleccionar “ver municipios” para que se muestren en el mapa los municipios de la provincia con respecto a los datos seleccionados en la leyenda, en este caso Zaragoza con año 2018 y con variable de interés “Turismos”, encima de la capa de las provincias. El resultado se puede ver en la Figura 33.
Figura 33. Resultado elección "Ver Municipios"
43
Como se puede observar en la anterior figura, el mapa muestra dos leyendas, que permiten saber los rangos de valores de la variable de interés seleccionada, en este caso turismos, respecto a los colores pintados en el mapa.
En tercer lugar, se muestra la sección de gráficas (Figura 34) compuesta por un panel con varias pestañas que contienen gráficas y tablas de datos.
Al principio se muestra directamente la primera pestaña, en este caso la de población, en la que se muestra una gráfica comparativa de hombres y mujeres en el rango de años 2015-2018, correspondiente con los datos que están almacenados en el sistema, y un desplegable en el que se puede ver la tabla de todos los datos de población, junto con un botón que permite descargar dichos datos en formato CSV.
Figura 34. Sección de gráficas.
En el caso de la pestaña de tráfico y de desforestación (pérdida forestal) siguen el mismo patrón que la de población, pero con los datos correspondientes a ellas.
En cambio, las pestañas de comparación de población (Figura 35), tráfico y pérdida cambian respecto a las anteriores, dado que para realizar la comparación se necesita poder seleccionar otra provincia de España. Esto se realiza con un desplegable que permite elegir la provincia que desees y se muestran los datos tanto de la provincia a la que está orientada el Dashboard como los de la que acabas de seleccionar en la gráfica y en la tabla de datos.
44
Cada vez que selecciones una provincia en el desplegable, se borrarán los datos de la selección anterior tanto en la gráfica como en la tabla de datos y aparecerán los datos nuevos.
Figura 35. Pestaña de comparación de población.
Finalmente, el Dashboard de municipios contiene las mismas secciones que el Dashboard de provincias explicadas anteriormente, pero con los datos almacenados correspondientes a los municipios. El único cambio a simple vista es que, en la sección del mapa, todas las variables a elegir son respecto a los municipios, es decir, las capas a mostrar están diseñadas con los datos de municipios (Véase en la Figura 36).
45
Figura 36. Mapa de Municipios
46
Anexo 2: Documentación de la API REST En este anexo se explica toda la información ligada a las peticiones que contiene la API REST.
Información de la operación Método HTTP GET URI /dashboard Descripción Devuelve el id y los datos de todos los Dashboards, siendo id un identificador único. Los datos se corresponden con la entidad Dashboard del modelo de datos documentado en la sección 3.1. Parámetros de entrada (Path) -- Ejemplo de cuerpo de respuesta [ { "id": 16, "datos": { "nombre": "TFG", "dashboards": { "provincias": { "datasets_poblacion": { "años": "2015-2018", "patron": "p_poblacionXX" }, "datasets_trafico": { "años": "2016-2018", "patron": "p_parqueXX" }, "datasets_deforestacion": { "años": "2015-2018", "patron": "p_deforestacionXX" } }, "municipios": { "datasets_poblacion": { "años": "2015-2018", "patron": "m_poblacionXX" }, "datasets_trafico": { "años": "2015-2018", "patron": "m_parqueXX" } } } } } … ]
Tabla 4. Petición /dashboard
47
Información de la operación Método HTTP GET URI /dashboard/id/:id Descripción Devuelve el id y los datos del Dashboard cuyo identificador único es igual a :id. Los datos se corresponden con la entidad Dashboard del modelo de datos documentado en la sección 3.1. Parámetros de entrada (Path) id Integer Obligatorio Ejemplo de petición - respuesta /dashboard/id/16 { "id": 16, "datos": { "nombre": "TFG", "dashboards": { "provincias": { "datasets_poblacion": { "años": "2015-2018", "patron": "p_poblacionXX" }, "datasets_trafico": { "años": "2016-2018", "patron": "p_parqueXX" }, "datasets_deforestacion": { "años": "2015-2018", "patron": "p_deforestacionXX" } }, "municipios": { "datasets_poblacion": { "años": "2015-2018", "patron": "m_poblacionXX" }, "datasets_trafico": { "años": "2015-2018", "patron": "m_parqueXX" } } } } }
Tabla 5. Petición /dashboard/id/:id
48
Información de la operación Método HTTP GET URI /dashboard/name/:name Descripción Devuelve el id y los datos del Dashboard cuyo nombre es igual a :name. Los datos se corresponden con la entidad Dashboard del modelo de datos documentado en la sección 3.1. Parámetros de entrada (Path) name String Obligatorio Ejemplo de petición - respuesta /dashboard/name/TFG { "id": 16, "datos": { "nombre": "TFG", "dashboards": { "provincias": { "datasets_poblacion": { "años": "2015-2018", "patron": "p_poblacionXX" }, "datasets_trafico": { "años": "2016-2018", "patron": "p_parqueXX" }, "datasets_deforestacion": { "años": "2015-2018", "patron": "p_deforestacionXX" } }, "municipios": { "datasets_poblacion": { "años": "2015-2018", "patron": "m_poblacionXX" }, "datasets_trafico": { "años": "2015-2018", "patron": "m_parqueXX" } } } } }
Tabla 6. Petición /dashboard/name/:name
49
Información de la operación Método HTTP GET URI /dashboard/:id/data/:name_data Descripción Devuelve todos los valores del campo :name_data del Dashboard identificado por id. Esto se corresponde con la entidad Dashboard del modelo de datos documentado en la sección 3.1. Parámetros de entrada (Path) id Integer Obligatorio name_data String Obligatorio Ejemplo de petición - respuesta /dashboard/TFG/data/dashboards { "provincias": { "datasets_poblacion": { "años": "2015-2018", "patron": "p_poblacionXX" }, "datasets_trafico": { "años": "2016-2018", "patron": "p_parqueXX" }, "datasets_deforestacion": { "años": "2015-2018", "patron": "p_deforestacionXX" } }, "municipios": { "datasets_poblacion": { "años": "2015-2018", "patron": "m_poblacionXX" }, "datasets_trafico": { "años": "2015-2018", "patron": "m_parqueXX" } }
Tabla 7. Petición /dashboard/:id/data/:name_data
Información de la operación Método HTTP GET URI /datasets Descripción Devuelve todos los Datasets del sistema con el identificador único y los datos. Los datos se corresponden con la entidad Dataset del modelo de datos documentado en la sección 3.1. Parámetros de entrada (Path) -- Ejemplo de cuerpo de respuesta
50
[{ "id": 2, "datos": { "nombre": "p_poblacion17", "año": "2017", "table_data": { "id": { "name": "cod", "tipo": "character" }, "name": { "name": "nom", "tipo": "character" }, "items": { "Hombres": { "name": "hombres", "tipo": "numeric" }, "Mujeres": { "name": "mujeres", "tipo": "numeric" } }, "total": { "name": "total", "tipo": "numeric" } }, "mapa": { "layers": [ { "name": "Mujeres", "title": "Comarcas:p_poblacion17_m" }, { "name": "Hombres", "title": "Comarcas:p_poblacion17_h" } ], "geom": { "name": "geom", "tipo": "Multipolygon" } } } } … ]
Tabla 8. Petición /datasets
51
Información de la operación Método HTTP GET URI /datasets/id/:id Descripción Devuelve el Dataset cuyo identificador es igual a :id, junto con los datos asociados a él. Los datos se corresponden con la entidad Dataset del modelo de datos documentado en la sección 3.1. Parámetros de entrada (Path) id Integer Obligatorio Ejemplo de petición - respuesta /datasets/id/2 { "id": 2, "datos": { "nombre": "p_poblacion17", "año": "2017", "table_data": { "id": { "name": "cod", "tipo": "character" }, "name": { "name": "nom", "tipo": "character" }, "items": { "Hombres": { "name": "hombres", "tipo": "numeric" }, "Mujeres": { "name": "mujeres", "tipo": "numeric" } }, "total": { "name": "total", "tipo": "numeric" } }, "mapa": { "layers": [ { "name": "Mujeres", "title": "Comarcas:p_poblacion17_m" }, { "name": "Hombres", "title": "Comarcas:p_poblacion17_h" }
52
], "geom": { "name": "geom", "tipo": "Multipolygon" } } } }
Tabla 9. Petición /datasets/id/:id
Información de la operación Método HTTP GET URI /datasets/name/;name Descripción Devuelve el identificador único y los datos del Dataset cuyo nombre es igual a :name. Los datos se corresponden con la entidad Dataset del modelo de datos documentado en la sección 3.1. Parámetros de entrada (Path) name string Obligatorio Ejemplo de petición - respuesta /datasets/name/p_poblacion16 { "id": 1, "datos": { "nombre": "p_poblacion16", "año": "2016", "table_data": { "id": { "name": "cod", "tipo": "character" }, "name": { "name": "nom", "tipo": "character" }, "items": { "Hombres": { "name": "hombres", "tipo": "numeric" }, "Mujeres": { "name": "mujeres", "tipo": "numeric" } }, "total": { "name": "total", "tipo": "numeric" } }, "mapa": {
53
"layers": [ { "name": "Mujeres", "title": "Comarcas:p_poblacion16_m" }, { "name": "Hombres", "title": "Comarcas:p_poblacion16_h" } ], "geom": { "name": "geom", "tipo": "Multipolygon" } } } }
Tabla 10. Petición /datasets/name/;name
Información de la operación Método HTTP GET URI /datasets/year/:year Descripción Devuelve el identificador único y los datos de todos los Dataset cuyo año sea igual a :year. Los datos se corresponden con la entidad Dataset del modelo de datos documentado en la sección 3.1. Parámetros de entrada (Path) year string Obligatorio Ejemplo de petición - respuesta /datasets/year/2017 [ { "id": 5, "datos": { "nombre": "m_poblacion17", "año": "2017", "table_data": { "id": { "name": "fid", "tipo": "character" }, "name": { "name": "name", "tipo": "character" }, "prov": { "name": "prov", "tipo": "character" }, "items": { "Hombres": {
54
"name": "hombres", "tipo": "bigint" }, "Mujeres": { "name": "mujeres", "tipo": "bigint" } } }, "mapa": { "layers": [ { "name": "Mujeres", "title": "Comarcas:m_poblacion17_m" }, { "name": "Hombres", "title": "Comarcas:m_poblacion17_h" } ], "geom": { "name": "geom", "tipo": "Multipolygon" } } } }, … ]
Tabla 11. Petición /datasets/year/:year
Información de la operación Método HTTP GET URI /datasets/:id/ítem/:name_item Descripción Devuelve todos los valores del campo :name_item, asociados cada uno al identificador único y el nombre de la entidad territorial a la que correspondan, del Dataset identificado por :id. Esto se corresponde con la entidad Labeled_Column del modelo de datos documentado en la sección 3.1. Parámetros de entrada (Path) id String Obligatorio name_item String Obligatorio Ejemplo de petición - respuesta /datasets/m_poblacion18/ítem/Hombres [ { “fid”: ”2607”, “name”: “ZARAGOZA” “hombres”: “319177” },
55
… ]
Tabla 12. Petición /datasets/:id/ítem/:name_item
Información de la operación Método HTTP GET URI /datasets/:id/data/:name_data Descripción Devuelve todos los valores del campo :name_data, asociados cada uno al identificador único de la entidad territorial a la que correspondan, del Dataset identificado por :id. Esto se corresponde con la entidad Column del modelo de datos documentado en la sección 3.1. Parámetros de entrada (Path) id String Obligatorio name_item String Obligatorio Ejemplo de petición - respuesta /datasets/p_poblacion18/data/total [ { “cod”: ”51”, “total”:”84519” }, … ]
Tabla 13. Petición /datasets/:id/data/:name_data
Información de la operación Método HTTP GET URI /datasets/:id/total_item/:name_item Descripción Devuelve la suma de todos los valores del campo :name_item del Dataset identificado por :id. Parámetros de entrada (Path) id String Obligatorio name_item String Obligatorio Ejemplo de petición - respuesta /datasets/m_parque18/total_item/turismos [ { “sum”:”23947518”}]
Tabla 14. Petición /datasets/:id/total_item/:name_item
Información de la operación Método HTTP GET URI /datasets/:id/data/:name_data/:id_data Descripción Devuelve todos los valores de los datos de la tabla cuyo :name_data tiene el valor de :id_data, del Dataset identificado por :id. Esto se corresponde con la entidad Column del modelo de datos documentado en la sección 3.1. Parámetros de entrada (Path) id String Obligatorio name_item String Obligatorio
56
Ejemplo de petición - respuesta /datasets/m_poblacion17/data/id/1234 [ { "fid": "1234", "name": "SAN MARTÍN DEL RÍO", "prov": "44", "hombres": "82", "mujeres": "73", "año": "2017" } ]
Tabla 15. Petición /datasets/:id/data/:name_data/:id_data
Información de la operación Método HTTP GET URI /datasets/:id/coordinates/:id_data Descripción Devuelve las coordenadas (xmin, xmax, ymin, ymax) de la entidad territorial cuyo identificador es :id_data, del Dataset identificado por :id. Parámetros de entrada (Path) id String Obligatorio name_item String Obligatorio Ejemplo de petición - respuesta /datasets/m_poblacion18/coordinates/1234 [ { "ymin":"41.02362297", "xmin":"-1.42230776", "ymax":"41.08852773", "xmax":"-1.35234615" } ]
Tabla 16. Petición /datasets/:id/coordinates/:id_data
Información de la operación Método HTTP GET URI /datasets/:id/:name_data Descripción Devuelve los valores de :name_data, del Dataset identificado por :id. Esto se corresponde con la entidad Columna y Labeled_Column del modelo de datos documentado en la sección 3.1. Parámetros de entrada (Path) id String Obligatorio name_item String Obligatorio Ejemplo de petición - respuesta /datasets/m_poblacion18/table_data {
57
"id": { "name": "fid", "tipo": "character" }, "name": { "name": "name", "tipo": "character" }, "prov": { "name": "prov", "tipo": "character" }, "items": { "Hombres": { "name": "hombres", "tipo": "bigint" }, "Mujeres": { "name": "mujeres", "tipo": "bigint" } } }
Tabla 17. Petición /datasets/:id/:name_data
Información de la operación Método HTTP GET URI /datasets/:id/ítems/:id_data Descripción Devuelve los valores de los ítems de la entidad territorial cuyo identificador es :id_data, del Dataset identificado por :id. Esto se corresponde con la entidad Labeled_Column del modelo de datos documentado en la sección 3.1. Parámetros de entrada (Path) id String Obligatorio name_item String Obligatorio Ejemplo de petición - respuesta /datasets/p_poblacion18/ítems/08 [ { "hombres": “2733466”, "mujeres": “2875884” } ]
Tabla 18. Petición /datasets/:id/ítems/:id_data
58
Anexo 3: Pruebas Manuales En lo que respecta a las pruebas manuales, para probar el mapa se ha elegido la provincia Madrid para mostrar la comprobación de que tanto la capa como la leyenda fuesen correctas para cada variable de interés (Véase en la Tabla 19).
Provincia Madrid Variable de interés 2018-Mujeres Mapa y leyenda
Datos BBDD
Observación En el mapa, Madrid esta pintado de color azul oscuro, por tanto el número de hombres debería estar entre el rango 1299059 y 3430207, y efectivamente lo está (3430207)
Variable de interés 2018 - Hombres Mapa y leyenda
59
Datos BBDD
Observación En el mapa, Madrid esta pintado de color negro oscuro, por tanto el número de hombres debería estar entre el rango 1248927 y 3147872, y efectivamente lo está (3147872)
Variable de interés 2018 – Otras (camiones y furgonetas, autobuses, motocicletas,..) Mapas y leyenda
60
61
62
Datos BBDD
Observación En los mapas, Madrid siempre esta pintado pintado del color mas
oscuro de la leyenda, por tanto los valores de las variables de interés deberían estar entre esos, y efectivamente si miramos los datos de la base de datos de la fila anterior, nos damos cuenta que son correctos.
Variable de interés 2018 – Pérdida forestal Mapa y leyenda
Datos BBDD
Observación En el mapa, Madrid esta pintado verde clarito, el primero color de la leyenda, por tanto el número de pérdida forestal en km2 debería estar entre el rango 0 y 30, y efectivamente lo está (3.99)
Tabla 19. Pruebas para el mapa
Este procedimiento llevado a cabo para las variables de interés del año 2018 se repite también para todas las variables de los demás años (2015-2017) y se realiza también para algunas provincias para asegurar que los datos están bien.
Para las gráficas, se ha hecho el mismo procedimiento que en el mapa, comparando los datos de la base de datos, con los datos mostrados tanto en la gráfica como en las tablas (Véase en la Tabla 20).
63
Provincia Madrid Pestaña Población Gráfica y tabla de datos
Datos BBDD año 2018
Datos BBDD año 2017
Datos BBDD año 2016
Datos BBDD año 2015
Observación
Si se comparan los datos mostrados en la gráfica y la tabla con los datos de la base de datos correspondientes con los años, se ve que lo datos mostrados son correctos
Pestaña Tráfico
64
Gráfica y tabla de datos
Datos BBDD año 2018
Datos BBDD año 2017
Datos BBDD año 2016
Datos BBDD año 2015
Observación
Si se comparan los datos mostrados en la gráfica y la tabla con los datos de la base de datos correspondientes con los años, se ve que lo datos mostrados son correctos.
Pestaña Tráfico
65
Gráfica y tabla de datos
Datos BBDD año 2018
Datos BBDD año 2017
Datos BBDD año 2016
Datos BBDD año 2015
Observación
Si se comparan los datos mostrados en la gráfica y la tabla con los datos de la base de datos correspondientes con los años, se ve que lo datos mostrados son correctos.
Tabla 20. Pruebas sección gráficas y tablas
Cabe destacar, que las pestañas de comparación de población, tráfico y deforestación muestran los mismos datos junto con los datos de otras provincias que han sido comprobadas de la misma forma que la provincia de Madrid.
Para la comprobación de las entidades territoriales de municipio se ha seguido el mismo procedimiento seguido para las de provincias.
66
