DISEÑO Y DESARROLLO DE UNA PLATAFORMA DE CÁLCULO Y VISUALIZACIÓN DE INDICADORES ESPACIALES MEDIANTE REJILLAS

MULTIESCALARES (GRID)

J.P. Pérez Alcántara1, J. Ojeda Zújar2, P. Díaz Cuevas3, I. Vallejo Villalta4

1 Departamento de Geografía Física y AGR, Universidad de Sevilla. jpperezalcantara@us.es2 Departamento de Geografía Física y AGR, Universidad de Sevilla. zujar@us.es3 Departamento de Geografía Física y AGR, Universidad de Sevilla. pilard@us.es4 Departamento de Geografía Física y AGR, Universidad de Sevilla. ivallejo@us.es

RESUMEN

En este trabajo se presenta el diseño y prueba de una plataforma para crear, calcular y visualizar indicadores espaciales teselados mediante una rejilla multiescalar (grid). Esta estructura de datos presenta importantes ventajas a la hora de abordar análisis espaciales multivariantes y la concepción de nuevos indicadores compuestos. Además, favorece el manejo y visualización de grandes conjuntos de datos en un contexto de cartografía web aplicando correctamente el uso de la escala significativa en cada nivel de zoom.

La plataforma, llamada Cell, se basa en una arquitectura de microservicios de software libre que cubren todo el flujo de trabajo con la rejilla, desde la teselación y creación de indicadores base a partir de la información vectorial original hasta la visualización de los datos en un front-end web.

Para probar el rendimiento de la plataforma se han teselado dos grandes juegos de datos: el catastro y los Hábitats de Interés Comunitario (HIC) de la Comunidad Autónoma Andaluza. Se han abordado dos mecanismos de visualización de las rejillas: uno más tradicional basado en el dibujado de teselas TMS y otro en el que el cliente web recibe los datos en bruto y realiza en tiempo real el dibujado de las teselas vectoriales.

Palabras clave: grid multiescalar; big data espacial; visualización de vectores en tiempo real; análisis multivariante; indicadores espaciales.

ABSTRACT

This work describes the design and testing of a platform for calculating and visualizing spatial indicators structured in a multiescalar grid. This data structure features significant advantages when used to approach multivariate spatial analysis, as well as the conception of new composite indicators. Besides, it greatly improves the performance for displaying web maps by a correct application of the right representative scale at each zoom level.

The platform, christened as Cell, is based around an Open Source microservices architecture that covers the whole grid dataflow, from the original dataset tesellation process and creation of base indicators to the web front-end data visualization.

To test the platform's performance, two big datasets has been processed: cadastre and Habitats of European Interest for the Andalucía Autonomous Region in Spain. Two visualization techniques has been tested: one, more traditional, based on the prerendering of map tiles, and another where the web front-end receives raw tile data and draws and symbolizes in real time the vector tile.

Keywords: multiescalar grid; big datasets; real time vector visualization; multivariate analysis; spatial indicators.

1

1. INTRODUCCIÓN

El tratamiento de grandes bancos de datos vectoriales siempre ha supuesto un reto para los sistemas de información geográfica. Juegos de datos como los catastrales, tanto por su tamaño como por su complejidad topológica, presentan importantes problemas a la hora de su análisis en continuo. Los vectores, al ocupar una superficie arbitraria de forma irregular, presentan asimismo importantes retos a la hora de aplicar una semiología cartográfica que transmita eficazmente la distribución de un fenómeno territorial (Pérez-Alcántara et al., 2016).

El conjunto de técnicas llamadas "Big Data" son especialmente eficaces cuando se pueden crear paquetes de trabajo bien delimitados los unos de los otros, es decir, que los datos pertenecientes a un paquete de trabajo A, que se realizará en una determinada máquina, no tengan relaciones con los datos pertenecientes al paquete B, a procesar en una máquina distinta. Así como el modelo ráster, debido a su naturaleza continua y regular, se ajusta bien a este tipo de distribución del trabajo, en muchísimas ocasiones los vectores presentan dificultades insalvables, o cuando menos difícilmente estandarizables, debido a la naturaleza irregular de los vectores y a que las relaciones topológicas, lo queramos o no, hacen que se establezcan entre ellos relaciones implícitas.

En paralelo a lo anteriormente expuesto para los análisis Big Data se están desarrollando interesantes técnicas de aprendizaje automático, lo que se conoce como Machine Learning (ML). Estas técnicas de ML, por lo general, se basan en el procesamiento de vectores multivariantes que describen los objetos a estudiar, y sobre los que se aplican técnicas de clasificación avanzada, que van desde relativamente sencillos algoritmos como la clusterización K hasta complejos sistemas de clasificación basados en redes neuronales profundas (Deep Learning).

En esta comunición se discute una metodología y plataforma de software orientada a intentar aprovechar lo mejor de ambos modelos (ráster y vectorial) y proponer un modelo para la información geográfica que permita la sistematización de grandes volúmenes de datos, especialmente vectoriales, para propiciar una correcta visualización, almacenamiento y crear una estructura de datos compatible con los procesos de Machine Learning.

1.1. La rejilla multiescalar

El modelo de datos espaciales propuesto en esta plataforma es una rejilla multiescalar. Una rejilla multiescalar discretiza el espacio geográfico en áreas homogéneas que se organizan en distintos niveles de escala, definiendo rejillas de mayor resolución a medida que la escala aumenta.

A estas celdas a distintas escalas se le añade información temática en forma de diccionarios clave-valor. Las características tanto geométricas como temáticas de esta estructura de datos derivan en una estructura asimétrica en las dos componentes de la información geográfica, ya que no es necesario grabar las celdas de las que no hay datos, ni introducir datos nulos en una determinada característica temática en aquellas celdas que no la posean.

1.2. Iniciativas en definición de rejillas espaciales

La inquietud por la homogeneización de la información espacial, especialmente en el campo de la información ambiental, ha sido una constante (Comisión Europea, 2007). Por ello, el Open Geospatial Consortium (OGC) ha establecido una nueva propuesta de estándar, que a fecha de la escritura de este trabajo se encuentra en fase de comentario de la Abstract Specification Topic, para establecer un marco global de adscripción de información ambiental, generalmente generada por redes de sensores o salida de modelos matemáticos, concebido

2

como mecanismo de comparación homogénea entre ellas. Es la iniciativa Discrete Global Grid System (DGGS) (OGC, 2017).

La Directiva INSPIRE también aboga, entre sus múltiples iniciativas, por el uso de las rejillas multiescalares (Comisión Europea, 2010), sobre todo como vehículo de homogeneización y difusión de información sensible sujeta a secreto estadístico a nivel europeo. Basado en lo publicado por INSPIRE, la European Environmental Agency publica una rejillas diseñadas a niveles de 100, 50, 10 y 1 km para toda Europa (EEA, 2011).

A nivel regional andaluz, el Instituto de Estadística y Cartografía de Andalucía (IECA) publica información demográfica en una rejilla compatible con la rejilla multiescalar europea, a nivel de 250 metros.

Figura 1. Hábitats de Interés Comunitario adscritos a la rejilla a diferentes niveles escalares (100, 50, 10, 5, 1 km y 500 y 250 m). Los colores corresponden al reparto en bloques de trabajo del proceso de adscripción.

2. OBJETIVOS

El objetivo de este trabajo, esencialmente metodológico, es presentar un avance de la tesis doctoral del primer autor en la que se describe la arquitectura, la metodología y la implementación de una plataforma destinada a la gestión de estructuras de datos en forma de rejillas multiescalares (nested grid) para el análisis y visualización de grandes bancos de datos espaciales. Metodología y plataforma serán probadas con dos juegos de datos espaciales: los Hábitat de Interés Comunitario y el Catastro de la Comunidad Autónoma de Andalucía.

3. METODOLOGÍA Y RESULTADOS

La metodología seguida para la consecución de los objetivos planteados se basa en el desarrollo del software de la plataforma, que se compone de múltiples componentes que describimos a continuación.

3

3.1. Arquitectura de la plataforma

La plataforma Cell ha sido diseñada en base a una arquitectura de microservicios, es decir, pequeñas unidades de proceso de datos que realizan tareas muy concretas. Esta forma de diseñar plataformas de software web posee varias ventajas, entre ellas, facilitar el despliegue de la aplicación y aumentar drásticamente su escalabilidad. Para implementar esta arquitectura se ha utilizado la tecnología de contenerización Docker, que es la encargada de controlar y crear los microservicios.

En la Figura 2 se puede observar la arquitectura de la plataforma. Sus componentes son, en la parte del servidor (back-end), situada en la parte inferior a Internet:

- CellAPI: este componente es el punto de comunicación de la plataforma en servidor con el exterior. Define una API REST en Node.js mediante la cual los clientes web solicitan trabajos al servidor y reciben información del progreso de los mismos, así como de información de catálogo. También es el punto por el que se sirven finalmente los datos;

- RabbitMQ: RabbitMQ es un servidor gestor de colas de mensajes que implementa el estándar Advanced Message Queuing Protocol (AMQP). Es un componente al que se le pueden enviar mensajes, que son puestos en cola y cuyo envío a otros posibles componentes interesados en su contenido es controlado minuciosamente;

- CellDS: este componente aloja el almacén central de datos de la plataforma. Su función es almacenar las rejillas con toda su información temática, así como información de gestión de la plataforma, como por ejemplo metadatos de catálogo y diversa información sobre procesos que realizan otros componentes del sistema;

- CellMapnik: este componente, que puede ser replicado para asumir mayores cargas de trabajo, se conecta al controlador de tareas RabbitMQ y desde él recibe peticiones de dibujado de mapas;

- CellGridder: estos componentes, también susceptibles de ser replicados, son los que se ocupan del trabajo de cartografiar los datos de rejilla a partir de información vectorial;

- CellML: este componente, escrito fundamentalmente en Python, tiene instalado la infraestructura de Python científico formada por las librerías Numpy, Pandas y scikit.learn;

- Redis: este es un componente no vital pero que está diseñado para acelerar en gran medida el sistema y, por tanto, proporcionar una experiencia de usuario más satisfactoria. Redis es un sistema de caché en memoria del tipo clave / valor muy eficiente.

En cuanto a la parte del cliente, el front-end, que es la parte que ven los usuarios en sus ordenadores, las posibilidades son las siguientes:

- clientes pesados: un cliente pesado es una aplicación que se instala nativamente sobre el sistema operativo de un ordenador. Los clientes pesados cartográficos, como pueden ser los SIG QGIS o ArcGIS, podrían por defecto conectarse al sistema mediante los estándares WMS o WFS;

- clientes ligeros web: en el contexto de un programa JavaScript corriendo en un navegador, que es lo que se denomina cliente ligero, la plataforma incluye un desarrollo basado en Leaflet y D3.js capaz de aprovechar las capacidades de visualización e interacción avanzada que ofrece el consumo directo de la información nativa almacenada en la plataforma.

4

Figura 2. Componentes y microservicios de software de la plataforma Cell.

3.2. Preparación del dato original

La preparación del juego de datos original es mínima. Lo que precisa la plataforma es tan sólo que la información original se encuentre en una tabla de la misma base de datos PostGIS en la que se encuentra el almacén central de teselas, CellDS.

3.3. Definición de la rejilla

Uno de los primeros pasos a la hora de inicializar el almacén de celdas o teselas es definir la rejilla multiescalar que se utilizará. La rejilla se compone de los siguientes elementos:

- sistema de proyección en el que se define la rejilla;

- punto de origen de coordenadas de la rejilla;

- definición de niveles escalares: tamaño, en unidades del sistema de proyección de la rejilla, de cada nivel escalar.

3.4. Selección del método de adscripción

Una vez la información a teselar está en la base de datos del teselador hay que definir el método de teselado. Básicamente, el método de teselado depende de dos factores principales: la geometría original (punto, línea o polígono) y la naturaleza estadística del dato temático (continuo o discreto).

La plataforma Cell viene de serie con un conjunto de funciones de adscripción de información directamente aplicables si se cumplen las condiciones apropiadas descritas en el método. Sin embargo, y dado que el motor analítico es una base de datos PostGIS, el usuario avanzado puede programar en SQL o PL/PgSQL un algoritmo de adscripción personalizado con una lógica arbitraria.

3.5. Paralelización del proceso de adscripción

El proceso de adscripción puede llegar a ser realmente costoso en tiempo de procesamiento, especialmente a niveles de escala altos. Por ello, es fundamental implementar una estrategia

5

de paralelización del proceso, es decir, permitir que varias máquinas trabajen simultáneamente en el proceso.

En la Figura 3 se puede apreciar el proceso de reparto en bloques de trabajo de la capa de los Hábitats de Interés Comunitario en Andalucía. Como puede observarse, el recubrimiento no es total, quedando grandes áreas, sobre todo en el Valle del Guadalquivir, sin datos, mientras que los hábitats se concentran densamente en las sierras que lo delimitan.

Figura 3. Distribución los datos originales en paquetes de trabajo de igual densidad de información para distribuir la carga del proceso de adscripción.

3.6. Grabación del formato teselar

El componente CellDS es el almacén final de toda la información teselada. Dicho almacén es una base de datos PostGIS, ya que se aprovecha en el sistema las capacidades de dicha base de datos geográfica para acelerar, gracias a su alta capacidad de indexación tanto de información alfanumérica como espacial, el acceso a la información.

La estructura de datos en la que se guarda la información teselar es asimétrica en dos sentidos. Por un lado, sólo se guarda la información de aquellas celdas en la que la información original tiene presencia, y, por otro, en cuanto a la información alfanumérica, sólo se guarda aquella que afecta a cada celda considerada. Es decir, en ningún lugar de la base de datos hay lugar para incorporar valores nulos. Sólo se consignan aquellos datos que realmente son fruto de la actividad teseladora.

3.7. Estructura de los datos alfanuméricos

Como es propio de la estructura de datos JSON, los datos alfanuméricos de cada celda se graban según una estructura clave / valor, es decir, un identificador alfanumérico que se correlaciona con un dato. Aparte de permitir la asimetría de datos entre celdas comentada anteriormente, la otra gran ventaja del formato JSON es que permite una libertad total para diseñar estructuras de datos personalizadas para cada indicador o algoritmo de agregación sobre celda.

Aunque pueda parecer difícil de procesar, el uso de JSON es eficiente por dos razones. Una, que PostgreSQL cuenta con un índice, el GIN, que indexa eficientemente este tipo de estructura de datos. La otra, que JSON es el formato de datos nativo de JavaScript, el lenguaje en el que se programa la interactividad de las páginas web, por lo que es uno de los estándares de la web para la transmisión de datos.

3.8. Metadatos

A la par que se lleva a cabo el proceso de teselación se van recogiendo estadísticas de los datos para cada nivel de escala. Puesto que la cantidad de datos puede llegar a ser muy grande, la realización en tiempo real de estas estadísticas puede ralentizar el sistema, y dado que las

6

rejillas tienden a ser datos que reflejan un estado temporal concreto de una variable, son poco dados al cambio, por lo que la generación de las mismas redunda en un sistema más ágil.3.9. El cliente web

Para la visualización de los datos de rejilla se ha creado un cliente cartográfico web llamado CellFrontend. Este visor dispone de las funcionalidades usuales de los visores cartográficos web (zooms, desplazamientos, carga de capas de fondo a partir de servicios externos WMS y similares), pero está especialmente diseñado para tratar con la información nativa de rejilla. Como ya se ha comentado, existe la posibilidad, gracias al componente CellMapnik, de obtener información de la rejilla en formato cartográfico predibujado en el servidor, al modo que lo hacen los servicios WMS o TMS. Más interesante que esta opción, sin embargo, es la de acceder a la información de la rejilla en su formato nativo, es decir, en lugar de recibir un mapa predibujado o geometrías en formato vectorial, lo que el cliente recibe es la definición de las celdas en la rejilla. Al poseer el cliente también la definición de la rejilla, es capaz, en tiempo real, de dibujarla directamente sobre el mapa.

Esta opción, gracias a la librería de visualización D3.js, abre amplias posibilidades de crear técnicas y herramientas de visualización y navegación de los datos muy potentes. Además, al estar recibiendo el cliente datos en bruto, puede utilizar éstos no sólo para recrear un mapa de teselas, sino también para generar otro tipo de visualizaciones de datos, como gráficos estadísticos, histogramas, recuento por clases, etc.

Figura 4. Las imágenes superiores corresponden al dibujado vectorial de las teselas, mientras que las inferiores corresponden con el dibujado de las teselas en el servidor.

7

En la Figura 4 se pueden apreciar las dos modalidades de representación. En la parte superior, con fondo blanco, se puede observar un ejemplo de representación vectorial. Las teselas son dibujadas en tiempo real por el cliente, en función de los datos de definición de rejilla que recibe desde el servidor, y gracias a poseer la definición matemática de la rejilla. En la parte inferior, con fondo negro, las teselas están generadas en el servidor.

3.10. La teselación de datos de ejemplo

Para probar la plataforma se ha teselado un conjunto de datos de ejemplo. Los datos teselados han sido:

- indicadores de catastro;

- Hábitats de Interés Comunitario;

- sintaxones presentes en los anteriores hábitats.

Las fuentes de los datos de catastro son el catastro en continuo de toda Andalucía, obtenido en un proyecto anterior, junto a todos sus datos asociados en formato CAT. Con dichos datos se han calculado varios indicadores sobre las parcelas, asociados algunos geométricamente a esas mismas parcelas (en el ámbito urbano) y otros a construcciones presentes en las mismas (en el ámbito rural).

En cuanto a los Hábitats de Interés Comunitario (HIC), la estructura de datos de la fuente original consistía en un ingente conjunto de polígonos a los que se les asignaba la información de los hábitats que se encontraban en cada uno de ellos (pueden ser varios) en el porcentaje estimado de dominancia sobre el polígono.

Los HIC van acompañados de un catálogo de sintaxones que los definen. Dado que los polígonos de implantación de estos sintaxones son los mismos que los de los HIC, se ha recurrido a la misma técnica de agregación, es decir, agregando por sintaxon y porcentaje de presencia en cada celda y después creando una aproximación de la superficie ocupada en función de dicho porcentaje.

4. CONCLUSIONES

La codificación de información geográfica con rejilla multiescalar proporciona diversas ventajas frente a los modelos vectorial y ráster clásicos:

- eficiencia en el almacenamiento de varios juegos de datos grandes;

- mejoras en la semiología cartográfica y en la identificación de patrones de distribución del fenómeno geográfico a varias escalas;

- facilidad de implementación de medidas de secreto estadístico;

- facilidad de creación de nuevos indicadores a partir de información de base.

Cada elemento funcional de la arquitectura rinde a niveles variables y tienen rango de mejora.

Las pruebas de rendimiento se han llevado a cabo en dos servidores Linux de CPU de 8 núcleos con 64GB de RAM. Uno de ellos tiene instalado todos los componentes de la plataforma, mientras que el otro replica los componentes de teselado CellGridder para aumentar la velocidad de la construcción de los datos de rejilla.

8

La tarea más pesada, la creación de la información teselada, requiere una gran cantidad de tiempo para teselar algunos de los juegos de datos. Los datos de indicadores catastrales, al tratarse de agregaciones de puntos, son teselados a una velocidad muy alta, obteniéndose, para unas teselas de 100 km a 30 metros de resolución, unos tiempos de proceso de un par de horas. Sin embargo, los datos de los hábitats y los sintaxones, al tratarse de polígonos que hay que cortar con las teselas, si han necesitado una gran cantidad de tiempo para ser procesados, en torno a las 75 horas.

En cuanto a tamaño de datos, los dos conjuntos de datos alcanzan los 40GB, habiéndose procesado 53.3 millones de teselas para la Comunidad Autónoma Andaluza. Si bien el teselado de los hábitats puso el tamaño total de la base de datos en 38GB, la adición de los datos catastrales sólo supuso un peso adicional de 2GB, con lo que cual se cumple la previsión de diseño del sistema de que lo pesado es la definición de la tesela para la primera capa del sistema, reaprovechándose posteriormente dicha definición para otras capas, que tan sólo aportan nuevo material temático sobre ellas. La base de datos, convenientemente indexada, responde muy bien a peticiones de datos, procesando peticiones de datos temáticas sobre una zona delimitada en cuestión de milisegundos, ya que se filtra por la citada zona y por el nivel de zoom más conveniente a la extensión de la misma. Los filtros sobre información temática, almacenada en formato JSON y sobre la que se ha construido un índice GIN, son también muy eficaces. En total, la indexación completa de los datos finales lleva 37 minutos.

La API del componente CellAPI es muy sencilla, limitándose a recoger información sobre el área y el nivel de zoom seleccionado por el cliente y devolviendo la información en el formato que éste entiende, descrito en la sección de metodología. Dado que casi toda la lógica de negocio la hace la propia base de datos en SQL, los tiempos de respuesta, aún en el caso de solicitar una decena de miles de celdas, son de unos pocos milisegundos.

El rendimiento del componente de predibujado cartográfico CellMapnik también es óptimo, llegando a dibujar decenas de miles de teselas en menos de un segundo. Esto se debe a la buena indexación de la base de datos descrita anteriormente y a la eficiencia del software de dibujado, Mapnik, cuyo principio de diseño fundamental es la rapidez.

En cuanto a las tareas de Machine Learning, este es el sistema más lento, ya que los procesos que realiza son muy intensos. Por ejemplo, la realización de un análisis de clusterización de una variable unidimensional para extraer intervalos de representación Jenks puede llegar a tardar 30 minutos para una decena de miles de valores.

En cuanto al cliente, a día de hoy se utiliza para renderizar la tecnología SVG descrita en la sección de metodología. Aunque no es la que permite una mayor densidad de información, facilita mucho el diseño de interacción con la misma, una ventaja a tener muy en cuenta y que hace difícil prescindir de dicha tecnología. En las pruebas realizadas, en un ordenador cliente MacBook Pro con 4 núcleos de CPU y 16GB de RAM, el navegador Chrome soporta una cantidad de celdas rondando las 5000, pero esta cantidad de información en un navegador Firefox, por ejemplo, vuelve al sistema demasiado lento como para proporcionar una experiencia de usuario adecuada, por lo que hay que reducir la densidad de información a no más de 3000 celdas.

BIBLIOGRAFÍA

Álvarez Francoso, J. I., Camarillo Naranjo, J. M., Limones Rodríguez, N. y Pita López, M. F. (2014): Globalclimatemonitor.org: una herramienta de acceso a datos climáticos globales, GeoFocus, 14, 1-6.

9

Enrique, I., Molina, J., Escudero, M., Ojeda, S. y Pérez, G. (2013): La distribución espacial de la población en Andalucía, IV Jornadas Ibéricas de Infraestructuras de Datos Espaciales.

European Commission (2007): Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE). http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32007L0002, Comisión Europea, INSPIRE.

European Forum for GeoStatistics (2012): ESSnet project GEOSTAT 1A-Representing Census data in a European population grid-Final Report. Eurostat-Luxembourg.

INSPIRE Thematic Working Group Coordinate Reference Systems & Geographical Grid Systems (2010): D2.8.I.2 Data Specification on Geographical Grid Systems – Technical Guidelines. http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_Specification_GGS_v3.0.1.pdf, Comisión Europea, INSPIRE.

Instituto de Estadística y Cartografía de Andalucía (2017): Memoria técnica de la actividad "Distribución espacial de la población en Andalucía". http://www.juntadeandalucia.es/institutodeestadisticaycartografia/distribucionpob/metodologia/MT010112.pdf, Instituto de Estadística y Cartografía de Andalucía.

Mora-García, R. y Marti-Ciriquian, P. (2015): "Desagregación poblacional a partir de datos catastrales", en de la Riva, J., Ibarra, P., Montorio, R., Rodrigues, M. (Eds.) 2015: Análisis espacial y representación geográfica: innovación y aplicación. XIV Congreso de la Asociación de Geógrafos Españoles, Zaragoza. Universidad de Zaragoza y AGE. Pp. 305-314

Noguero-Hernández, M.D., Vallejo-Villalta, I., Ramírez-Moreno, E., Ramírez-Torres, A. (2016): Identificación del espacio residencial en Andalucía a partir de datos catastrales. Aplicaciones de las Tecnologías de la Información Geográfica para el desarrollo económico sostenible. XVII Congreso Nacional de Tecnologías de la Información Geográfica. Málaga. AGE. Pp. 421-431.

Open Geospatial Consortium (2017): Topic 21: Discrete Global Grid Systems Abstract Specification. http://docs.opengeospatial.org/as/15-104r5/15-104r5.html, Open Geospatial Consortium standard abstracts.

Pérez-Alcántara, J.P., Díaz-Cuevas, M.P., Álvarez-Francoso, J.I. y Ojeda-Zújar, J. (2016): Métodos de adscripción y tratamiento espacial para la generación y visualización de indicadores de vivienda (GRID) a través de Catastro. Aplicaciones de las Tecnologías de la Información Geográfica para el desarrollo económico sostenible. XVII Congreso Nacional de Tecnologías de la Información Geográfica. Málaga. AGE, Pp. 224-235.

Pérez-Alcántara, J.P., Ojeda-Zújar, J., Díaz-Cuevas, M.P. y Álvarez-Francoso, J.I. (2017): Integración de datos poblacionales y catastrales en estructuras GRID: primeros resultados para el espacio residencial en el litoral andaluz. XXV Congreso de la Asociación de Geógrafos Españoles, Madrid, 25-27 Octubre 2017, Madrid.

Santos J.M. (2015): La cartografía catastral y su utilización en la desagregación de la población. Aplicación al análisis de la distribución espacial de la población en el municipio de Leganés (Madrid). Estudios Geográficos, LXXV, I 278, pp. 309-333.

10