2. Introducción

2.1. ¿Qué es una Base de Datos Espacial?

PostGIS es una base de datos espacial. Oracle Spatial y SQL Server (versiones de 2008 o posteriores) son también bases de datos espaciales. Pero, ¿eso qué quiere decir? ¿qué convierte a una base de datos normal en una base de datos espacial?

La respuesta corta es …

Las bases de datos espaciales almacenan y manipulan objetos espaciales como cualquier otro objeto en la base de datos.

A continuación, se repasa brevemente la evolución de las bases de datos espaciales y después se repasan tres aspectos de la asociación de datos espaciales con una base de datos – tipos de dato, índices y funciones.

  1. Tipos de datos espaciales se refiere a formas como punto, línea y polígono;

  2. Indexado espacial multi-dimensional que se usa para procesar operaciones espaciales de forma eficiente;

  3. Funciones espaciales en :term:`SQL`para consultar propiedades y relaciones espaciales.

Combinados, los tipos de dato espaciales, índices y funciones, proporcionan una estructura flexible para un rendimientos y análisis optimizados.

2.1.1. Al Principio

En las antiguas implementaciones de GIS de primera generación, todos los datos espaciales se almacenaban en ficheros simples y eran necesarios programas GIS especiales para interpretar y manipular los datos. Estos sistemas de gestión de primera generación estaban diseñados para responder a las necesidades de usuarios que disponían de todos los datos necesarios dentro del ámbito de su propia organización. Se trataba de sistemas propietarios, auto-contenidos, construidos específicamente para manejar datos espaciales.

Los sistemas espaciales de Segunda Generación almacenan parte de los datos en bases de datos relacionales (normalmente los «atributos» o las partes no-espaciales), pero aún le falta la flexibilidad de una integración directa.

**Las auténticas bases de datos espaciales nacieron cuando se empezó a tratar a las entidades espaciales como objetos de la base de datos de «primera clase» **

Las bases de datos espaciales integran completamente los datos espaciales con una base de datos relacional. La orientación del sistema cambia de ser GIS-céntrico a ser BaseDeDatos-céntrico.

_images/beginning.png

Nota

Un sistema de gestión de bases de datos espacial se puede usar en aplicaciones más allá del mundo geográfico. Las bases de datos espaciales se usan para gestionar datos relacionados con la anatomía del cuerpo humano, circuitos integrados de gran escala, estructuras moleculares y campos electromagnéticos, entre otras aplicaciones.

2.1.2. Tipos de Datos Espaciales

Una base de datos normal tiene cadenas, números y fechas. Una base de datos espacial añade tipos de datos adicionales para representar entidades geográficas. Estos tipos de dato abstraen y encapsulan estructuras espaciales tales como límites y dimesión. En muchos aspectos los tipos de datos espaciales se pueden entender simplemente como formas.

_images/hierarchy.png

Los tipos de dato espacial están organizados en un tipo jerárquico. Cada sub-tipo hereda la estructura (atributos) y comportamiento (métodos o funciones) de su super-tipo.

2.1.3. Índices espaciales y Rectángulos Envolventes

Una base de datos normal proporciona índices para permitir un acceso rápido y aleatorio a subconjuntos de datos. El indexado para tipos estándar (números, cadenas y fechas) se hace normalmente con índices de tipo B-tree.

Un B-tree particiona los datos usando el ordenamiento natural para colocar los datos en un árbol jerárquico. El orden natural de números, cadenas y fechas es fácil de determinar – cada valor es menor que, mayor que o igual a cada uno de los otros valores.

Pero como los polígonos se pueden superponer, estar contenidos dentro de otros y están colocados en un espacio bidimensional (o de más dimensiones), un B-tree no se puede usar para indexarlos de forma eficiente. Las bases de datos espaciales proporcionan un «índice espacial» que responde a la pregunta «¿qué objetos están dentro de esta caja particular?».

Una caja (“bounding box”) es el rectángulo más pequeño – paralelo a los ejes de coordenadas – capaz de contener una entidad dada.

_images/boundingbox.png

Las cajas se usan porque responder a la pregunta «¿está A dentro de B?» es muy costoso computacionalmente para polígonos pero muy rápido en el caso de rectángulos. E incluso los más complejos polígonos o líneas pueden ser representados por una simple caja.

Los índices tienen que responder rápidamente para ser útiles. Por eso, en vez de dar resultados exactos como hacen los B-trees, los índices espaciales dan resultados aproximados. La pregunta «¿qué lineas están dentro de este polígono?» interpretada por un índice espacial se reformularia como «¿qué lineas tienen cajas envolventes que están contenidas dentro de la envolvente de este polígono?».

Los tipos de índices espaciales implementados por distintas bases de datos varían mucho. Las implementaciones más comunes son el Árbol-R (R-Tree) y Quadtree (usados en PostGIS), pero hay también índices basados en grids e indices GeoHash implementados en otras bases de datos espaciales.

2.1.4. Funciones Espaciales

Para manipular datos en una consulta, una base de datos normal proporciona funciones tales como concatenar cadenas, aplicar operaciones de hash sobre cadenas, hacer cálculos matemáticos con números o extraer información de fechas.

Una bases de datos espacial proporciona un conjunto de funciones para analizar componentes geométricos, determinar relaciones espaciales y manipular geometrías. Estas funciones espaciales sirven de «ladrillos»para construir cualquier proyecto espacial.

La mayor parte de las funciones espaciales se pueden agrupar en una de las siguientes cinco categorías:

  1. Conversión: Funciones que convierten entre geometrías y formatos de dato externos.

  2. Gestión: Funciones que gestionan información sobre tablas espaciales y administración de PostGIS.

  3. Recuperación: Funciones que recuperan propiedades y medidas de una Geometría.

  4. Comparación: Funciones que comparan la relación espacial de dos geometrías.

  5. Generación: Funciones que generan nuevas geometrías a partir de otras.

La lista de posibles funciones es muy grande, pero hay un conjunto de funciones común, definido por el OGC SFSQL e implementado (junto con algunas funciones útiles más) por PostGIS.

2.2. ¿Qué es PostGIS?

PostGIS convierte el Sistema Gestor de Bases de Datos PostgreSQL en una base de datos espacial añadiendo soporte para estas tres funcionalidades: tipos espaciales, índices espaciales y funciones espaciales. Dado que está construido sobre PostgreSQL, PostGIS hereda automáticamente en su implementación importantes funcionalidades «empresariales» así como estándares abiertos.

2.2.1. Pero, ¿qué es PostgreSQL?

PosgreSQL es un potente sistema gestor de bases de datos (SGBD, o RDBMS, por sus siglas en inglés). Se publica bajo una licencia parecida a la BSD y es por lo tanto software libre y de fuentes abiertas. Como sucede con muchos otros proyectos de fuentes abiertas, PostgreSQL no está controlado por una sola compañía, si no que cuenta con una comunidad mundial de desarrolladores y compañías que lo desarrollan.

PostgreSQL fue diseñado desde el primer momento pensando en que se pudieran extender los tipos – la habilidad de añadir nuevos tipos de datos, funciones e índices en tiempo de ejecución. Debido a esto, la extensión PostGIS puede ser desarrollada por un equipo de desarrollo distinto y aun así integrarse muy firmemente dentro del núcleo de la base de datos PostgreSQL.

2.2.1.1. ¿Por qué elegir PostgreSQL?

Una pregunta habitual entre la gente que usa bases de datos abiertas es, «¿por qué no se construyó PostGIS sobre MySQL?».

PostgreSQL tiene:

  • Una fiabilidad probada e integridad transaccional por defecto (ACID).

  • Soporte escrupuloso de los estándares SQL (SQL92 completo).

  • Funciones extensibles y tipos conectables y extensibles

  • Modelo de desarrollo orientado a la comunidad.

  • Tamaños de columna no limitados (tuplas «TOAST») para soportar objetos SIG grandes.

  • Estructura de índices genéricos (GiST, por sus siglas en inglés) que permiten el índice R-Tree.

  • Facilidad para añadir funciones personalizadas.

A su vez, PostgreSQL proporciona de manera muy sencilla un mecanismo de desarrollo de tipos espaciales nuevos. En el ámbito del software propietario solo Illustra (ahora Informix Universal Server) permitía una extensión así de sencilla. Esto no es una coincidencia, Illustra es una reingeniería del código fuente original de PostgreSQL de los años ochenta.

Dado que la forma de desarrollar nuevos tipos en PostgreSQL era tan clara, tenía sentido empezar por allí. Cuando MySQL lanzó tipos espaciales básicos en su versión 4.1, el equipo de PostGIS le echó un vistazo a su código y dicho ejercicio no hizo si no reforzar la decisión original de elegir PostgreSQL.

Debido a que los tipos de objetos espaciales de MySQL se construyeron como un caso especial sobre el tipo de cadena de caracteres, las modificaciones a MySQL se extendieron por toda su base de código. El desarrollo de PostGIS 0.1 llevó un mes aproximadamente. Hacer un «MyGIS» 0.1 hubiera costado muchísimo más, y como tal, nunca hubiera visto la luz del día.

2.2.2. ¿Por qué no ficheros?

Los Shapefile (y otros formatos como los archivos de Esri Geodatabase y los GeoPackage) han sido una forma estándar de almacenar e interaccionar con información espacial desde los primeros programas GIS. No obstante, estos ficheros «planos» tienen las siguientes desventajas:

  • Los archivos necesitan un software especial para leerlos y escribirlos. SQL es una abstracción para acceso aleatorio a datos y análisis. Sin esa abstracción, tendrías que escribir todo el código para acceder y analizar por tí mismo.

  • Usuarios/as concurrentes pueden causar corrupción de archivos y ralentización. Aunque es posible escribir código que asegure que múltiples escrituras en el mismo fichero no corrompan los datos, para cuando se haya solucionado ese problema y también el problema asociado del rendimiento, nos encontraremos con que se habrá escrito gran parte de lo que constituye un sistema de bases de datos. Entonces, ¿por qué no usar una base de datos estándar?

  • Preguntas complicadas necesitan software complicado para responderlas. Las perguntas complicadas e interesantes (uniones espaciales, agresgaciones, etc) que se pueden expresar en una linea de SQL en la base de datos llevan cientos de lineas de código especializado cuando se programa para utilizar archivos.

Gran parte de los usuarios de PostGIS están desplegando sistemas donde múltiples aplicaciones deben acceder a los datos, por lo que acceder a ellos mediante el estándar SQL simplifica el desarrollo y despliegue. Algunos usuarios trabajan con grandes volúmenes de datos, tal vez incluso repartidos entre múltiples ficheros, que pueden almacenarse en una única tabla de la base de datos.

En resumen, la combinación del soporte para múltiples usuarios, consultas ad hoc complejas y rendimiento sobre conjuntos de datos grandes son lo que hace la diferencia entre bases de datos espaciales y sistemas basados en archivos.

2.2.3. Una breve historia de PostGIS

En mayo de 2001, Refractions Research <http://www.refractions.net/> lanzó la primera versión de PostGIS. PostGIS 0.1 tenía objetos, índices y un puñado de funciones. El resultado fue una base de datos capaz de almacenar y recuperar, pero no de analizar.

Según aumentaba el número de funciones, se fue haciendo clara la necesidad de un principio organizador. La especificación «Simple Features for SQL» (SFSQL) del Open Geospatial Consortium proporcionó esa estructura con guías para nombrar las funciones y requerimientos.

Con el apoyo de PostGIS para analisis simples y uniones espaciales, Mapserver se convirtió en la primera apliacción externa en proporcionar una visualización de los datos en la base de datos.

En los siguientes años el número de funciones de PostGIS creció, pero su potencia siguió limitada. Muchas de las funciones más interesantes (p. ej. ST_Intersects(), ST_Buffer(), ST_Union()) eran muy difíciles de programar. Escribirlas de cero podía llevar años de trabajo.

Por suerte, un segundo proyecto, «Geometry Engine, Open Source» or GEOS apareció en ese momento. La biblioteca GEOS ofrece los algoritmos necesarios para implementar la especificación SFSQL. Enlazando con GEOS, PostGIS consiguió dar un soporte completo para SFSQL a partir de la versión 0.8.

Según crecía la capacidad de gestión de datos, apareció otro problema: la representación que se usaba para almacenar las geometrías se demostró relativamente ineficiente. Para objetos pequeños como puntos y lineas cortas, los metadatos de la representación llegaban a tener una sobrecarga del 200%. Por motivos de eficiencia era necesario «poner en dieta» la representación. Encogiendo el cabecero de los metadatos y las dimensiones necesarias se redujo mucho la sobrecarga. En PostGIS 1.0, esta representación nueva, más rápida y ligera se había convertido en la opción por defecto.

Los lanzamientos recientes de PostGIS siguen añadiendo funcionalidades y mejoras de rendimiento, así como añadiendo soporte para nuevas funcionalidades del sistema central de PostgreSQL.

2.2.4. ¿Quién usa PostGIS?

Para una lista completa de casos de estudio mirar la página PostGIS case studies.

2.2.4.1. Instituto Geográfico Nacional, Francia

IGN es la agencia cartográfica nacional de Francia y usa PostGIS para almacenar el mapa topográfico de alta resolución del país, el «BDUni». BDUni tiene más de 100 millones de elementos y es mantenido por un equipo de campo de más de 100 personas quienes verifican las observaciones y diariamente añaden nuevos registros a la base de datos. La instalación del IGN usa el sistema transaccional de la base de datos para asegurar la consistencia durante los procesos de actualización y un warm standby system para mantener el sistema funcionando aún en el caso de producirse un fallo del mismo.

2.2.4.2. RedFin

RedFin es una agencia inmobiliaria con un servicio web para explorar propiedades y estimar su valor. Su sistema fue originalmente construido sobre MySQL, pero vieron que moverlo a PostgreSQL y PostGIS proporcionaba grandes beneficios en rendimiento y fiabilidad.

2.2.5. ¿Qué aplicaciones soportan PostGIS?

PostGIS se ha convertido en una base de datos espacial ampliamente usada y el número de terceros programas que lo utilizan para almacenamiento y recuperación de datos se ha incrementado también. Los programas que utilizan PostGIS incluyen tanto software libre como propietario en sistemas de servidor o de escritorio.

La siguiente tabla muestra una lista de algunos de los programas que utilizan PostGIS:

Abiertos/Libres

Closed/Proprietary/Paid services

  • Carga/Extracción

    • Shp2Pgsql

    • ogr2ogr

    • Dxf2PostGIS

    • GeoKettle

  • Basados en Web

    • Mapserver

    • GeoServer /geoNode

    • pg_tileserv

    • pg_featureserv

    • Deegree

    • Carto

    • QGIS Server

    • MapGuide Open Source (usando FDO)

  • Escritorio

    • QGIS

    • OpenJUMP

    • GRASS

    • pgAdmin

    • DBeaver

    • gvSIG

    • SAGA

    • uDig

  • Carga/Extracción

    • Safe FME Desktop Traductor/Convertidor

    • Dbt

  • Basados en Web

    • Cadcorp GeognoSIS

    • ESRI ArcGIS Server / Online

  • Services / DbaaS

    • Aiven for PostgreSQL

    • Amazon RDS / Aurora for PostgreSQL

    • Carto

    • Crunchy Bridge

    • Microsoft Azure for PostgreSQL

    • Google Cloud SQL for PostgreSQL

  • Escritorio

    • Cadcorp SIS

    • ESRI Desktop/Pro

    • GeoConcept

    • Global Mapper

    • Manifold

    • MapInfo

    • Microimages TNTmips GIS