Resumen. El presente trabajo da a conocer, en primer lugar, una noción de los principales conceptos, la evolución y retos que han conllevado la integración de los sistemas de información geográfica (SIG) y los sistemas gestores de bases de datos (SGBD) para la manipulación y gestión de los datos espaciales. Seguidamente, se desarrolla un caso de estudio para la implementación de las capacidades espaciales en el motor de bases de datos PostgreSQL, utilizando dos estrategias comúnmente utilizadas para el desarrollo de bases de datos espaciales: la extensión nativa de PostGIS y una aplicación tercera, el software ArcSDE (desarrollado por la empresa líder de sistemas de información geográfica ESRI). Finalmente, se analizan y contrastan los resultados de ambas soluciones, de manera que le permita al lector tener una visión general y comparativa de ambas propuestas a través de un caso de estudio sencillo.

Palabras clave: sistema gestor de bases de datos, sistema de información geográfica, PostGIS, ArcSDE, dato espacial, bases de datos espaciales.

Abstract –The present work first reveals a notion

of the main concepts, the evolution and challenges that have entailed the integration of geographic information systems (GIS) and database management systems (DBMS) for the manipulation and management of spatial data. Then, a case study is developed for the implementation of spatial capabilities in PostgreSQL database engine, using two typically strategies used for the development of spatial databases, the native PostGIS extension and a third-party application, ArcSDE software (developed by leading geographic information systems company ESRI). Finally, the results of both solutions are analyzed and contrasted, in a way that allows the reader to have a general and comparative vision of both proposals through a simple case study.

Keywords – database management system, Geographic Information System, PostGIS, ArcSDE, spatial data, spatial database.

I.INTRODUCCIÓN

En el pasado era muy común que los sistemas de información concibieran la representación de un dato espacial como un campo alfanumérico en una tabla en una base de datos relacional, esto debido a que los sistemas gestores de bases de datos (SGBDs) no fueron concebidos inicialmente para representar y manipular datos de una manera espacial [1]. Sin embargo, con el paso del tiempo, se fue comprendiendo que esta técnica de modelamiento limitaba el desarrollo de las aplicaciones y las capacidades de los sistemas, al usar este tipo de datos, tanto así que, en la actualidad, un sistema típico de bases de datos espaciales es un sistema comercial ordinario de bases de datos con capacidades y funciones adicionales para manejar datos espaciales [2].

Los datos espaciales tradicionalmente se han utilizado para representar objetos geográficos localizados en la superficie de la Tierra, tales como ciudades, montañas, y ríos; sin embargo, su uso no se limita exclusivamente a lo anterior. Estos datos se pueden utilizar para representar fenómenos geográficos, tales como inundaciones, huracanes y cambios climáticos; o bien datos no geográficos en otros contextos espaciales, tales como el cuerpo humano o la distribución interna de un edificio [1].

Esto ha dado pie a un aumento en la cantidad y la diversidad de aplicaciones que utilizan datos espaciales. Por ejemplo, existe un caso de estudio acerca de la idoneidad del uso de PostGIS para la consulta espacial de datos relacionados a recursos minerales en Pakistán, recursos preciosos que son considerados claves para el desarrollo de la economía nacional en este país [3]. Otro de los usos en los que se encuentra presente el empleo de PostGIS es en convertir datos a datos espaciales de un almacén de datos del Centro de Datos e Indicadores Ambientales de Caldas (CDIAC) en Colombia, que tiene como propósito fortalecer la gestión ambiental del territorio, en la cual ponen a disposición del público la información de estaciones de monitoreo, diferentes variables meteorológicas, pluviométricas y de calidad del aire [4].

Asimismo, en la provincia de Yunnan en China se han realizado trabajos para la construcción de una base de datos de la calidad ambiental del suelo, mediante la integración del motor de bases de datos Oracle y la tecnología ArcSDE, que han permitido la integración de capacidades espaciales para proporcionar datos básicos comprensivos y exactos para el apoyo a las decisiones científicas sobre la contaminación del suelo, así como su prevención y restauración ecológica [5].

Este artículo se encuentra estructurado en las siguientes secciones: la sección dos tiene la justificación del estudio; la sección tres describe el problema por resolver; la sección cuatro se refiere a los objetivos que se busca alcanzar con este trabajo; la sección cinco tiene la fundamentación teórica del estudio; la sección seis describe los materiales y métodos; la sección siete describe los resultados obtenidos y su discusión; la sección ocho tiene las conclusiones del trabajo realizado y, por último, la sección nueve contiene el trabajo a futuro.

II.JUSTIFICACIÓN

En la actualidad, existen diversas opciones en el mercado para el almacenamiento, manipulación y análisis de datos espaciales. Por ejemplo, la compañía Oracle fue la primera empresa en la industria de bases de datos en incorporar capacidades espaciales en sus productos. En 1995, Oracle realizó un acuerdo con la empresa ESRI para llevar a cabo la integración de Oracle 7 Spatial con dos productos de esta otra empresa: el Spatial Database Engine (SDE) y ArcView GIS. Desde entonces, Oracle ha desarrollado otras alianzas con otras compañías dedicadas al desarrollo de software de sistemas de información geográfica (SIG), incluyendo Intergraph, MapInfo y GE Smallworld, para desarrollar productos en esta misma línea. Al mismo tiempo, Oracle también ha implementado sus propias estrategias de desarrollo interno, que resultaron en la creación de una estructura de datos espaciales y en la implementación de operadores espaciales mediante la extensión de SQL [2]. Una situación similar se ha presentado con otras organizaciones clave de la industria de bases de datos, tales como IBM, PostgreSQL, Sybase y Microsoft, que se han asociado con otros proveedores de software SIG para desarrollar funcionalidad espacial o han desarrollado sus propias capacidades mediante extensiones a sus productos de bases de datos.

Esta situación ha complicado el panorama de las instituciones gubernamentales, organizaciones sin fines de lucro y empresas privadas, que requieren de una infraestructura de datos espaciales (IDE) para soportar sus actividades operativas y apoyar la toma de decisiones. Llevar a cabo la selección de una plataforma tecnológica se vuelve una tarea compleja, puesto que no existe una evaluación sistemática que permita comparar estos SGBD o una guía que facilite la decisión para seleccionar algún sistema de acuerdo con las necesidades específicas, como pueden ser el tipo de licenciamiento, cumplimiento de estándares, características de almacenamiento y rendimiento, entre otras [6].

A través de este artículo, se busca realizar una comparativa que no ha sido realizada con anterioridad entre la extensión PostGIS y el software ArcSDE, dos de las soluciones más populares para la gestión de datos espaciales a la fecha, donde se analizan y comparan ambos desde una perspectiva de los modelos resultantes para el almacenamiento y gestión de los datos.

III.PROBLEMA

Existe una práctica general de desarrollar repositorios de bases de datos espaciales basándose en una arquitectura híbrida donde los datos espaciales y convencionales se almacenan por separado [7], tal como se presenta en la Fig.1.

Fig.1. Arquitectura de un repositorio de bases de datos débilmente acoplado.

Sin embargo, este acercamiento sufre de varios inconvenientes. Por una parte, la coexistencia de modelos de datos heterogéneos implica dificultades de modelaje, así como en el uso e integración de los datos. Asimismo, existe una pérdida parcial de funcionalidades básicas de un SGBD, tales como las técnicas de recuperación, consultas y optimización [8].

Dichosamente, la situación ha cambiado con la adición de extensiones espaciales a los SGBD, las cuales permiten que, en un mismo repositorio, se pueda almacenar datos convencionales, como cadenas de caracteres, valores numéricos y fechas, con datos no convencionales, como geometrías e imágenes, preservando todos los mecanismos de integridad referencial ampliamente conocidos de las bases de datos e incorporando nuevas características para la gestión de datos espaciales, tales como almacenamiento de datos espaciales de forma nativa, funciones espaciales, índices espaciales, entre otros. No obstante, es una tecnología que puede ser considerada relativamente nueva y poco conocida en ámbitos tradicionales de la computación e informática, que suelen requerir de la intervención de profesionales de otras especialidades, tales como geógrafos, cartógrafos, topógrafos, planificadores, entre otros.

El problema que se plantea abarcar, a través del caso de estudio propuesto para este artículo, es dar a conocer a la comunidad de profesionales e investigadores de computación e informática, las consideraciones que conlleva el diseño e implementación de bases de datos espaciales utilizando la extensión espacial PostGIS y el software ArcSDE, así como sus implicaciones en los modelos de datos resultantes y la calidad de los datos.

IV.OBJETIVOS DE ESTUDIO

Para este trabajo se establecieron cuatro objetivos, los cuales se listan a continuación:

· Explicar los conceptos principales y la evolución que han tenido las bases de datos espaciales a través de la historia.

· Contrastar el proceso de modelamiento e implementación de bases de datos espaciales utilizando la extensión de PostGIS y el software ArcSDE.

· Analizar las ventajas y desventajas que tienen los modelos físicos de bases de datos espaciales que utilizan la extensión de PostGIS y el software ArcSDE para el almacenamiento de los datos espaciales.

· Dar a conocer a los ingenieros en el área de computación e informática, recursos que tienen los sistemas gestores de bases de datos para la implementación de capacidades espaciales.

V.FUNDAMENTACIÓN TEÓRICA

Un SIG es un sistema de información compuesto por hardware, software y procedimientos para capturar, manejar, manipular, analizar, modelizar y representar datos georreferenciados, con el objetivo de resolver problemas de gestión y planificación [9].

Dentro del software que compone un SIG se encuentran las bases de datos espaciales. Estas representan una de las áreas dentro del manejo de datos donde se ha desarrollado últimamente una mayor evolución. Se parte de un punto donde inicialmente no se usaban SGBD, sin embargo, debido a la gran importancia que los SIG han cobrado, se han ido integrando de diversas formas. En la actualidad, se emplean bases de datos relacionales que son adaptadas para poder integrar plenamente la información geográfica de forma óptima [10].

Una de estas integraciones es la extensión PostGIS. PostGIS es un proyecto encabezado por la empresa canadiense Refractions Research, que se publica bajo la Licencia Pública General de GNU y brinda capacidades espaciales al motor de bases de datos PostgreSQL, al incorporar más de 300 operadores, funciones, tipos de datos e índices de tipo espacial [11].

Por su parte, la empresa Environmental Systems Research Institute (ESRI), líder en el desarrollo y comercialización de software especializado en sistemas de información geográfica, de igual forma, ha desarrollado su propia estructura nativa y propietaria para la gestión de datos geográficos llamada geodatabase.

Una geodatabase es la estructura de datos nativa del software SIG ArcGIS, que almacena elementos geográficos de distintos tipos y permite acceder y trabajar con todos los datos geográficos en una variedad de archivos y formatos [12] que, a través del software ArcSDE (Spatial Database Engine), permite que la estructura de una geodatabase de ArcGIS sea almacenada en una base de datos relacional [13].

Este esquema de trabajo utiliza una arquitectura de varios niveles que implementa la lógica avanzada y comportamiento en el nivel de aplicación (ArcGIS) sobre la capa de almacenamiento (motor de base de datos), donde la responsabilidad de la administración de los datos espaciales es compartida entre ambas partes [14].

Su propósito es servir como puerta de enlace entre los clientes SIG y los sistemas gestores de bases de datos, para un fácil almacenamiento, acceso y gestión de datos espaciales en los motores de bases de datos DB2, Informix, Oracle, PostgreSQL y SQL Server [12], como se puede apreciar en la Fig. 2.

Fig. 2. Comunicación entre un cliente SIG y un SGBD usando el software ArcSDE.

En la siguiente sección, se desarrolla un caso de estudio particular para la implementación de una base datos espacial utilizando la extensión espacial PostGIS y el software ArcSDE, modelos de datos que se procederán a analizar y contrastar el uno con el otro.

VI.MATERIALES Y MÉTODOS

El caso de estudio consiste en el desarrollo de una base de datos catastral que permita vincular la información de las parcelas del país (elemento geográfico) con la de su respectivo propietario (elemento convencional).

Una parcela es: “una porción pequeña de terreno, de ordinario sobrante de otra mayor que se ha comprado, expropiado o adjudicado” [15]. Es representada como un polígono que contiene un número de finca que la identifica de forma única, un número de derecho (documento legal), su dirección en prosa, el uso de la tierra (comercial, residencial, industrial o desconocido) y el cálculo del valor fiscal de la propiedad que puede ser mayor o igual a cero y puede ser opcional.

Un propietario es una persona física que posee número de cédula, un nombre completo, estado civil (soltero, casado, divorciado, unión libre, viudo o desconocido) y sexo (femenino, masculino o indefinido). El sexo y el estado civil son opcionales y el nombre del propietario se compone de tres partes: nombre, primer apellido y segundo apellido, siendo este último opcional en el caso de personas extranjeras.

Por simplicidad del modelo, se establece una restricción para que una parcela pueda tener a lo sumo un propietario, a la vez que un propietario pueda tener varias parcelas.

Por su parte, el proceso de la construcción de la base de datos se llevó a cabo en tres fases: diseño del modelo lógico, definición de la arquitectura e implementación del modelo de datos.

Para el diseño del modelo lógico, el primer paso fue identificar las entidades necesarias del ámbito del problema que, en este caso, son Parcela y Propietario. Una vez identificadas las entidades, se procedió a definir los atributos relacionados para cada entidad, su tipo de dato y restricciones de campos nulos, valores por defecto o valores específicos para el campo, lo cual dio como resultado la identificación de los siguientes atributos por cada entidad:

Parcela:

· Num_finca: identifica de manera única una parcela.

· Derecho: documento legal.

· Dirección: ubicación geográfica en prosa.

· Uso_tierra: representa el uso de la tierra para la parcela.

· Valor_fiscal: valor fiscal declarado de la parcela.

· Dueño: identificador único del propietario.

Propietario:

· Cédula: identificador único de una persona.

· Nombre: describe el nombre del propietario.

· Primer_apellido: describe el primer apellido del propietario.

· Segundo_apellido: describe el segundo apellido del propietario.

· Estadocivil: describe el estado civil de la persona.

· Sexo: describe el sexo de una persona.

Las restricciones identificadas se listan a continuación:

· Restric_uso: valida el uso correcto de la tierra (Parcela).

· Restric_valorfiscal: valida que el valor fiscal se encuentre en un rango considerable (Parcela).

· Rest_estadocivil: valida el estado civil de una persona (Propietario).

· Rest_sexo: validar el sexo de una persona (Propietario).

Para cada una de las anteriores, se define el tipo de restricción, sea de valores codificados (solamente acepta ciertos valores) o un rango de valores (establecido por un límite mínimo y máximo). Finalmente, se identifican las relaciones entre la entidad Parcela y Propietario, sus campos de relación y la cardinalidad.

La Fig. 3 muestra las entidades resultantes, con sus respectivos campos y restricciones, mientras que la Fig. 4 presenta las restricciones del modelo y la Fig. 5 las relaciones entre las entidades.

Fig. 3. Entidades del modelo lógico.

Fig 4. Restricciones del modelo lógico.

Fig. 5 Relaciones entre entidades.

● Componentes de software

El SGBD seleccionado para el desarrollo del caso de estudio es PostgreSQL 11, en el cual se desarrollará una versión de la base de datos utilizando la extensión espacial de PostGIS 3.0 y otra versión utilizando el software ArcSDE 10.8.

● Implementación del modelo

Se utilizaron dos herramientas CASE para llevar a cabo la implementación del modelo de la base de datos: el Enterprise Architect, para la construcción del modelo en el caso de ArcSDE, y el pgModeler, para la implementación usando la extensión PostGIS.

Estas herramientas permiten de una forma sencilla realizar el diseño físico de una base de datos espacial, que puede ser exportado a través de un archivo XML o SQL, para que luego sea importado e implementado en el SGBD.

A continuación, en la Fig. 6 se visualizan los modelos resultantes para cada caso:

Fig. 6. Modelo físico de la base de datos en Enterprise Architect.

En la Fig. 7 se muestra el modelo físico de la base de datos pgModeler.

Fig. 7. Modelo físico de la base de datos en pgModeler.

VII.RESULTADOS Y DISCUSIÓN

Utilizando la herramienta pgAdmin, una herramienta de código abierto para la administración de bases de datos PostgresSQL, se puede explorar la implementación de los modelos físicos del caso de estudio utilizando el software ArcSDE y la extensión PostGIS.

En el caso del software ArcSDE, se puede observar una serie de deficiencias en el proceso que se lleva a cabo para transformar el modelo físico propietario de ESRI, a un modelo físico estándar para una base datos relacional.

Por un lado, se puede apreciar en la Fig. 8, que la llave primaria es automáticamente asignada al campo objectid, un valor autoincremental de la tabla, lo que propicia el error de que se coloque dos veces un mismo registro con identificadores distintos, ocasionando una duplicidad de información.

Fig. 8. Llave primaria de la tabla parcela creada en la columna objectid.

La relación que se creó en el modelo no se mapea en la relación entre Parcela y Propietario como una llave foránea, permitiendo que un usuario pueda registrar una parcela a una cédula de un propietario no existente.

En una configuración estándar del software ArcSDE para el motor de bases de datos PostgreSQL, las geometrías de los objetos espaciales se codifican por defecto utilizando un tipo de dato propietario del ArcSDE, lo que complica compartir estos datos con aplicaciones de terceros.

También se puede observar en la Fig.9, que las restricciones de valores codificados y los rangos de valores no son implementados por el motor de base datos. Esto se debe a que el cumplimiento de la integridad es delegado al software ArcSDE, lo que permite que aplicaciones de terceros puedan corromper más fácilmente los datos, al no implementar un mecanismo de integridad referencial propio del motor de bases de datos.

Fig 9. Modelo físico resultante a partir del uso del software ArcSDE.

El modelo construido consta de dos entidades, no obstante, en el modelo resultante de base de datos se puede observar que hay más de dos tablas. Este excedente se debe a que el software ArcSDE requiere de una serie de tablas adicionales para la implementación de capacidades espaciales al motor de bases de datos PostgreSQL, lo que ocasiona una sobrecarga al motor para escribir o recuperar la información.

Por otra parte, el mismo modelo construido utilizando las capacidades espaciales de la extensión espacial PostGIS genera un modelo físico mucho más limpio y consecuente con la teoría del diseño de bases de datos. A diferencia del software ArcSDE, las llaves primarias son establecidas en los campos Cédula y Num_Finca de las tablas Propietario y Parcela respectivamente. Asimismo, se establecen restricciones de integridad para garantizar que los campos Uso_tierra, Valor_fiscal, Estadocivil y Sexo se limiten a un rango de valores que sean considerados como válidos. En el caso de las relaciones entre tablas, se crean las llaves foráneas respectivas, que garantizan que no se pueda crear una parcela asociada a un propietario no registrado.

Por último y no menos importante, los datos espaciales son almacenados en un formato compatible con los estándares de Open Geospatial Consortium (OGC), que a través de una serie de funciones preconstruidas por la extensión PostGIS, facilitan el intercambio de información geográfica entre aplicaciones, tal como se muestra en la Fig. 10.

Fig. 10 Modelo físico resultante a partir del

uso de la extensión PostGIS.

VIII.CONCLUSIONES

A continuación, se enumeran las principales conclusiones que se obtienen de este trabajo:

● Las deficiencias halladas con la implementación del caso de estudio utilizando el software ArcSDE demuestran que, con el uso de este software, es más propenso a inducir problemas en la calidad de los datos de una base de datos espacial, que propiamente el uso de otras alternativas para la gestión de datos espaciales, como es el caso de la extensión PostGIS.

● La implementación de una base de datos espacial integrada con el software ArcSDE requiere de conocimiento especializado por parte de los desarrolladores y administradores de bases de datos, para que, conociendo las limitantes de este software, puedan crear soluciones para mantener la integridad referencial de los datos y crear procesos de control y aseguramiento de calidad más exhaustivos.

● Una vez que se exporta un modelo de una base de datos espacial utilizando el software ArcSDE a PostgreSQL, no existe una forma rápida para resolver el problema de integridad que se genera por la exportación del archivo. Una solución sería utilizar la integridad referencial nativa del motor de bases de datos y realizar pruebas respectivas utilizando el software SIG ArcGIS para garantizar su correcta implementación.

● A diferencia del software ArcSDE que comparte responsabilidades con el motor de bases de datos para la gestión de datos espaciales, PostGIS está pensado en que la base de datos maneje todo lo relacionado con el almacenamiento y procesamiento de los datos espaciales, lo que garantiza una mayor interoperabilidad con otros software SIG, separando responsabilidades según competa; por un lado, el motor de bases de datos como responsable de todo lo relacionado con el almacenamiento de datos y el software SIG en lo que compete a edición y visualización de datos espaciales.

IX.AGRADECIMIENTOS

Con base en la experiencia en esta investigación, se planea profundizar en el desarrollo y divulgación de nuevos casos de estudio para la aplicación de las bases de datos en otras disciplinas distintas a la computación e informática, tales como la biología, construcción, sociología, geología, geografía, topografía, entre otras, de manera que sea posible dar a conocer las bondades de los SGBD para el uso y explotación de los datos espaciales, así como crear redes de investigación interdisciplinarias que permitan llevar estos avances tecnológicos a campos históricamente más conservadores.

REFERENCIAS

[1] E.Malinowski and E. Zimányi, "Advanced Data Warehouse Design from Conventional to Spatial and Temporal Applications". Berlin Heidelberg: Springer, 2008.

[2] A.Yeung, and G.B,Hall, "Spatial Database Systems: Design, Implementation and Project Management". Springer. 2007.

[3] N.Chaudhry and M. Yousaf. "Spatial querying of mineral resources using PostGIS". 2nd International Conference on Advancements in Computational Sciences (ICACS), Lahore, Pakistan, 2019, pp. 1-6, doi: 10.23919/ICACS.2019.8688999. 2019

[4] R. Melo,and R. Vilman, "Implementación de PostGIS sobre la bodega de datos del CDIAC, que permita la espacialización y análisis de los datos ambientales del departamento de Caldas". Trabajo Final de Graduación. Universidad Nacional de Colombia. [Online]. Available: https://repositorio.unal.edu.co/handle/unal/76061

[5] Y. Zhao, H. Liang, N. Zhou, J. Zhao and Y. Zhang, "Design and Implementation of Yunnan Province Soil Environmental Quality Database Based on ArcSDE for Oracle". International Conference on Manufacturing Technology, Materials and Chemical Engineering 14–16 June 2019, Wuhan, China. 2019 Available: https://doi.org/10.1088/1757-899X/592/1/012194

[6] E. Malinowski, "Evaluación de los sistemas de administración de bases de datos con extensiones espaciales". Revista Ingeniería, vol. 24, no.2 ,2014.

[7] M. Worboys and M. Duckham, "GIS: A Computing Perspective". CRC Press,2004.

[8] P. Rigaux, M. Scholl, A. Voisard, "Spatial Databases. San Francisco": Morgan Kaufmann. 2011.

[9] M. Goodchild, "GIS and basic research: The national center for geographic information and analysis". Government Information Quarterly, 7(3), pp.343-355. 1990.

[10]V. Olaya,"Sistemas de información geográfica Un libro libre de Víctor Olaya", Available:http://volaya.github.io/librosig/index.html, 2014.

[11] R. Obe, L. Hsu, "Postgis In Action", Second Edition. Manning Publications, 2015.

[12] H. Nasser, "Learning ArcGIS Geodatabases". Birmingham, UK.: Packt Publishing, 2014.

[13]D.Peters,"System Design Strategies". Redlands, California: ESRI Press, 2009.

[14]DataManagement.Available:http://www.esri.com/products/arcgis-capabilities/data-management.

[15]Parcela.Available:http://buscon.rae.es/drae/srv/search?id=pN6GGbTdXDXX206hcRbC