¿Por qué debería preocuparse por PostGIS? – ¿Una introducción suave a las bases de datos espaciales

? No es muy interesante.

Así podría pensar una persona promedio que trabaja con SIG o visualizaciones de datos. Debo admitir que las bases de datos no son lo más sexy del mundo (lo siento, los DBA), pero si está reclamando (o apuntando) hacer análisis o visualización con datos (espaciales) de una manera más seria, definitivamente no debe ignorarlos. Espero que esta entrada de blog pueda darte una idea de qué tipo de beneficios podría ofrecerte el uso eficiente de bases de datos espaciales.

Los términos de bombo van y vienen en ÉL y hubo un gran bombo alrededor de big data todavía hace unos años, pero ahora se está desvaneciendo lentamente. Bueno, los datos siguen siendo grandes y en realidad son más grandes que nunca. El tamaño de los archivos crece y, en «ciencia de datos» y geociencias, las personas deben lidiar con datos que pueden estar fácilmente en el rango de gigabytes. Cuanto más grandes sean los datos, más atención debemos prestar a la forma en que los almacenamos y analizamos.

Ahí es donde entra en escena una base de datos.

En el desarrollo de software, trabajar con bases de datos es una necesidad. Pero para las personas en otros subdominios de la informática (como los SIG), los beneficios de una base de datos pueden no ser siempre tan obvios. Por supuesto, las personas tienden a usar las herramientas más familiares para ellos, aunque no sería la forma más eficiente de lograr objetivos. Pero a veces, salir de tu zona de confort realmente puede traerte grandes beneficios. Me he estado dando cuenta lentamente del potencial que yace en el SQL espacial.

Esta entrada de blog es principalmente para personas que trabajan con datos geoespaciales, pero que no han tocado PostGIS, o tal vez ni siquiera han oído hablar de él. No voy a pasar por cómo instalar PostgreSQL / PostGIS, sino más bien tratar de darle una visión general de lo que es y para qué sirve.

Mi flujo de trabajo y ejemplos se centran principalmente en la combinación de QGIS + PostGIS, pero debe tener en cuenta que también puede trabajar solo con PostGIS, su propio código o con algunos otros clientes SIG.

Post what ¿qué?

Ya durante mis estudios SIG había escuchado la frase ‘PostGIS es una extensión espacial de Postgres’ varias veces. No quería decir que tuviera idea de lo que eso significa. No tenía idea de lo que es Postgres, y mucho menos una extensión espacial.

Intentemos frenarlo de la forma más sencilla posible.

Algunas personas pueden odiarme por esta comparación, pero me arriesgaré: si nunca ha trabajado con bases de datos, puede pensar en tablas de bases de datos como hojas de Excel masivas. Pero una hoja de Excel inteligente masiva desde donde se puede en un milisegundo averiguar qué valor está en la tercera columna en la fila número 433 285. Y en lugar de escribir funciones dentro de la hoja en una sola celda, las escribe en la ventana de comandos SQL. Por lo tanto, un lugar para almacenar datos y desde donde puede sacarlos de manera eficiente.

PostGIS es un extensor de base de datos espacial de código abierto y disponible gratuitamente para el Sistema de Gestión de Bases de Datos PostgreSQL (también conocido como DBMS). Así que PostgreSQL (también conocido como Postgres) es LA base de datos y PostGIS es como un complemento a esa base de datos. La última versión de PostGIS ahora viene con PostgreSQL.

En pocas palabras, PostGIS agrega funciones espaciales como tipos de datos de distancia, área, unión, intersección y geometría especial a PostgreSQL.Las bases de datos espaciales almacenan y manipulan objetos espaciales como cualquier otro objeto de la base de datos.

Por lo tanto, en una base de datos normal almacenamos datos de diferentes tipos (numéricos, texto, marcas de tiempo, imágenes.) y cuando sea necesario, puede consultar (recuperar) eso para responder preguntas con sus datos. Las preguntas pueden ser sobre «cuántas personas han iniciado sesión en su sitio web» o «cuántas transacciones se han realizado en una tienda en línea». En su lugar, las funciones espaciales pueden responder preguntas como «qué tan cerca está la tienda más cercana», «este punto está dentro de esta área» o «cuál es el tamaño de este país».

Por lo que los datos se almacenan en filas y columnas. Debido a que PostGIS es una base de datos espacial, los datos también tienen una columna de geometría con datos en un sistema de coordenadas específico definido por el identificador de referencia espacial (SRID). Pero recuerde que, aunque utilizaría PostGIS principalmente para datos espaciales, también es posible almacenar datos no espaciales allí, ya que todavía tiene todas las funcionalidades de una base de datos PostgreSQL normal.

La excelente intro de Boundless PostGIS, presenta tres conceptos básicos que asocian los datos espaciales con una base de datos. Estos elementos combinados proporcionan una estructura flexible para optimizar el rendimiento y el análisis.

1. Tipos de datos espaciales como punto, línea y polígono. Familiar para la mayoría de los que trabajan con datos espaciales;
2. La indexación espacial multidimensional se utiliza para el procesamiento eficiente de operaciones espaciales;
3. Las funciones espaciales, planteadas en SQL, son para consultar propiedades y relaciones espaciales.

SQL, o «Lenguaje de consulta estructurado», es un medio para hacer preguntas y actualizar datos en bases de datos relacionales. Una consulta select (que se usa para hacer las preguntas) generalmente es un comando de la siguiente forma

SELECT some_columns FROM some_data_source WHERE some_condition;

Las funciones específicas de PostGIS generalmente están en la forma de ST_functionName.

Usted escribe estos comandos en la línea de comandos después de iniciar sesión en su base de datos o en su herramienta GUI de base de datos (por ejemplo, pgAdmin o QGIS DB Manager). Así que sí, SQL requiere que escribas algo realmente. Hacer clic con el botón derecho del ratón puede estar subestimado en general, pero para alguien que no escribe ningún código, SQL es un buen primer paso para escribir sus propios comandos y quizás código posterior.

También hay otras bases de datos espaciales además de PostGIS. SQL Server Spatial, ESRI ArcSDE, Oracle Spatial y GeoMesa son otras opciones para administrar y analizar datos espaciales. Pero se dice que PostGIS tiene más funcionalidades y, en general, un mejor rendimiento. También los otros mencionados (excepto GeoMesa) no son de código abierto.

Si es nuevo en esto, ahora podría estar confundido: ¿así que es un lugar para almacenar datos y tienes que obtener información de una manera compleja escribiendo algunas cosas extrañas en la línea de comandos? Espéralo. También hay algunos beneficios reales que PostGIS puede ofrecerle si realmente se compromete con él.

Pedí algunas ideas para la publicación del blog de Twitter y obtuve muchos buenos comentarios. A partir de ahí tuve la idea de dividir esto en dos partes. En la primera parte, analizaré los beneficios que PostGIS puede aportar a su trabajo diario. En la segunda parte me centraré más en SQL espacial.

PostGIS puede permitirle adoptar una nueva forma de trabajo. Esta nueva forma puede ser más fácilmente reproducible, puede comenzar a usar el control de versiones más fácilmente y puede habilitar flujos de trabajo multiusuario.

Los archivos a menudo requieren un software especial para leer y escribir. SQL es una abstracción para el acceso y análisis de datos aleatorios. Sin esa abstracción, necesitará un software específico para realizar las operaciones o deberá escribir todo el código de acceso y análisis usted mismo.

Hacer su análisis en SQL en lugar de simplemente realizar operaciones aleatorias para archivos con algunas herramientas aleatorias con parámetros aleatorios, le permite compartir y reproducir sus resultados con mayor facilidad. Es posible que tenga ese «Shapefile maestro» actualmente en algún lugar, donde ha realizado varias operaciones de unión espacial y recorte a un Shapefile para que sea como se supone que debe ser. ¿Y si eso desaparece?

Johnnie escribió un buen ejemplo en Twitter sobre cómo borró accidentalmente todos sus datos, pero fue capaz de reproducirlos con un mínimo esfuerzo con los scripts SQL que guardó en GIT.

Las personas que trabajan con el desarrollo de software probablemente (o con suerte) estén familiarizadas con el control de versiones. No voy a profundizar en eso en esta publicación de blog, pero puedes (y deberías) tener tus scripts SQL en un sistema de control de versiones, como GIT. Piense en ello como un libro de cocina que guarda en su estantería y actualiza constantemente para encontrar siempre las mejores recetas para un análisis de datos sabroso. Solo que puedes comprar una nueva copia de este libro de cocina exacto de Amazon de nuevo si tu casa se quema.

Una base de datos también puede ayudarlo a mantener sus datos espaciales en mejor orden. Ninguno de nosotros es realmente perfecto y probablemente seguirá creando tablas como temp_1, final_final, pero una base de datos le ofrece una mejor oportunidad para estandarizar su estructura de datos que solo los archivos (por ejemplo, estandarizando los tipos de datos en sus tablas).

¿Y qué pasa con esos grandes conjuntos de datos? Con una base de datos espacial, es posible trabajar con grandes conjuntos de datos. No solo es más fácil, sino que a veces es casi imposible trabajar en conjuntos de datos más grandes sin una base de datos. ¿Alguna vez ha intentado abrir un archivo csv de 2 gb? ¿O trató de hacer un poco de geoprocesamiento para un GeoJSON de 800 mb? ¿Sabías que los Shapefiles tienen un límite de tamaño? Por supuesto, puede abordar algunos de estos problemas utilizando Geopaquetes u otros formatos de archivo, pero en general PostGIS es la herramienta óptima para manejar datos grandes (geoespaciales).

Una característica muy agradable de las bases de datos es que puede automatizar más fácilmente los procesos que normalmente realiza manualmente. Por ejemplo, al usar la función de NOTIFICACIÓN de PostgreSQL, puede actualizar sus mapas de QGIS automáticamente. Además, si está trabajando con herramientas ETL (por ejemplo, FME) para automatizar su trabajo, leer/escribir desde/hacia tablas PostGIS es mucho más fácil que con archivos.

Si no eres como yo (actualmente hago estas cosas por mi cuenta y por diversión), es posible que tengas una cosa llamada equipo. También conocido como compañeros de trabajo. Es posible que necesiten acceder a los mismos datos que usted. El uso de una base de datos en su flujo de trabajo permite trabajar en paralelo en un nivel completamente diferente al de tener archivos en una unidad compartida.

Una razón principal de esto es que los usuarios simultáneos pueden causar corrupción. Si bien es posible escribir código adicional para garantizar que varias escrituras en el mismo archivo no corrompan los datos, para cuando haya resuelto el problema y también resuelto el problema de rendimiento asociado, habría escrito la mayor parte de un sistema de base de datos.

Por supuesto, la adopción de un nuevo flujo de trabajo tiene ventajas y desventajas. Al igual que mantener sus archivos en orden, al final del día, también mantener una base de datos puede ser mucho trabajo. Por ejemplo, actualizar tu PostGIS a una nueva versión puede ser un verdadero problema, como se señaló en Twitter. Un gran poder conlleva una gran responsabilidad.

Pero hablemos más de esa parte de energía.

Parte 2: El mundo mágico de spatial SQL

Spatial SQL realmente puede acelerar su procesamiento (cuando se usa sabiamente). A continuación se muestra una comparación entre hacer el mismo proceso con un Shapefile y el procesamiento de QGIS y luego en PostGIS con ST_GeneratePoints.

Para esta comparación tuve datos de código postal de Finlandia y la población en cada área de código postal. Tenía esto como un Shapefile y una tabla en mi base de datos local. Creé puntos aleatorios dentro de cada polígono para representar la población. Utilicé el procesamiento QGIS (Puntos aleatorios dentro del polígono del Procesamiento Vectorial) para el Shapefile y en PostGIS el SQL era realmente tan simple como esto:

SELECT ST_GeneratePoints(geom, he_vakiy) from paavo.paavo

Como puede ver en el gráfico anterior, PostGIS tardó menos del 10% del tiempo en hacer el mismo análisis en comparación con QGIS y un Shapefile. Si usted es un analista de SIG y realiza procesos como este todos los días, eso puede ahorrarle bastante tiempo en un año.

Además de un procesamiento más rápido, puede disfrutar de la amplia selección de funciones espaciales que PostGIS tiene para ofrecer. Las funciones que son más útiles para usted dependen totalmente del caso de uso. Además del análisis Voronoi y el análisis SIG más tradicional (búfer, superposición, intersección, clip, etc..) puedes hacer cosas más avanzadas:

• Enrutamiento. Con pgRouting y datos de carreteras, puede encontrar rutas óptimas y realizar diferentes análisis de red;
• Esqueleto de polígonos. Esta función le permite construir el eje medio de un polígono sobre la marcha; Subdivisión de geometría
• . Dividir sus geometrías para un procesamiento posterior puede acelerar significativamente sus procesos;
• Agrupación en clústeres. Encuentre clústeres y patrones a partir de sus datos. Con el bombo de la IA en el pico, los k-means podrían ser aún más interesantes para algunos que antes…

¿Para qué necesitas cosas como la esqueletonización de polígonos? Podría ser una pregunta válida para la mayoría, pero esa vez cuando su análisis espacial lo necesite, estará extremadamente encantado de que alguien haya hecho el trabajo duro (=matemáticas) por usted. La combinación de diferentes funciones espaciales y el uso de las funciones integradas de Postgres con ellas le permitirá realizar análisis espaciales avanzados en su base de datos.

Las preguntas complicadas e interesantes (uniones espaciales, agregaciones, etc.) que son expresables en una línea de SQL en la base de datos requieren mucha potencia computacional y eso es algo que PostGIS le ofrece. Responder a las mismas preguntas con su propio código, puede tomar cientos de líneas de código especializado para responder cuando se programa contra archivos.

PostGIS para dataviz

En muchas de las visualizaciones que tengo en mi cartera, PostGIS ha desempeñado algún tipo de papel en el proceso de visualización. En mi flujo de trabajo, con mayor frecuencia preproceso los datos y luego hago la visualización real en QGIS.

Veamos un ejemplo de uno de esos procesos.

La animación sobre trenes y voronois anterior da un ejemplo lúdico del poder de PostGIS. Tenía unos pocos millones de puntos GPS de tren en mi base de datos local y ya había creado animaciones con los puntos en movimiento. Pero quería probar cómo se vería una animación con líneas de Voronoi.

Primero, porque tenía varios puntos GPS para cada tren por minuto, quería agruparlos para tener un punto representativo por cada minuto por tren. Primero había creado una tabla manualmente para los puntos resultantes. Me escribió la siguiente consulta

INSERT INTO trains.voronoipoints 
SELECT '2018–01–15 09:00:00' AS t, 
geom 
FROM (SELECT St_centroid(St_collect(geom)) AS geom, 
trainno 
FROM (SELECT geom, 
trainno 
FROM trains.week 
WHERE time > '2018–01–15 09:00:00' 
AND time < '2018–01–15 09:01:00') AS a 
GROUP BY trainno) AS b

Si queremos frenar la consulta en piezas, podemos ver las siguientes piezas del rompecabezas:

• Puede ver algunos de los elementos normales de una consulta SQL (INSERTAR EN, SELECCIONAR, COMO, DESDE, DÓNDE Y AGRUPAR POR)
• geom, trainno y time son nombres de columna en la tabla mi semana en el esquema llamado trains
• La subconsulta a devuelve todos los puntos GPS que se han rastreado dentro del período de tiempo solicitado.
• Debido a que selecciono todos los puntos GPS rastreados en un minuto, es posible que obtenga varios puntos por cada tren. Sólo quería uno, para que las líneas de voronoi parecieran más sensatas. Es por eso que uso ST_Collect para agrupar los puntos y crear una geometría multipunto a partir de ellos. ST_Centroid reemplaza la geometría multipunto con un solo punto ubicado en el centroide (subconsulta b) y los datos se agrupan por números de tren.

Para hacer lo mismo varias veces, tuve un script Python simple para hacer un bucle sobre la misma consulta por unos cientos de veces donde tenía los tiempos de inicio y finalización como parámetros. Después de encontrar con éxito un punto representativo por cada minuto, simplemente ejecuté el siguiente comando (en 11,5 segundos):

SELECT t, ST_VoronoiLines(geom) from trains.voronoipoints

Luego agregué el resultado a QGIS y lo visualicé con Time Manager. Esta podría ser una forma un poco complicada de lograr el resultado y un usuario SQL más experimentado podría haberlo hecho completamente con un solo comando SQL, pero todavía estoy bastante contento con el resultado. Aunque podría ser inútil.

Eventualmente bastante simple, pero el resultado parece matemáticas de nivel superior (¡y lo es!), ya que todo el trabajo duro lo realiza PostGIS. También porque pude hacer el análisis de Voronoi para solo un punto por tren, el tiempo de procesamiento fue de solo segundos para cientos de miles de puntos.

A menudo, el tiempo de procesamiento de sus consultas crece exponencialmente a medida que aumentan las cantidades de datos. Esta es la razón por la que tienes que ser inteligente con tus consultas.

Como regla general, cuantos más datos tiene que obtener una consulta y más operaciones tiene que realizar la base de datos (ordenar, agrupar, etc.), se vuelve más lenta y, por lo tanto, menos eficiente. Una consulta SQL eficiente solo obtiene las filas y columnas que realmente necesita. SQL puede funcionar como un rompecabezas lógico, donde realmente tienes que pensar a fondo lo que quieres lograr.

También debo tener en cuenta que ajustar el rendimiento de sus consultas es una pendiente resbaladiza y puede perderse en el mundo de la optimización sin fin. Encontrar el equilibrio entre una» consulta óptima » y una consulta óptima es realmente importante. Especialmente si no está creando una aplicación para un millón de usuarios, unos pocos milisegundos aquí o allá probablemente no sacudirán su barco.

¿Cómo empezar?

Me atrevo a decir que aprender SQL es aún más beneficioso para un usuario SIG promedio que aprender JavaScript, Python o R. La sintaxis SQL solo ha tenido cambios menores a lo largo de los años y las habilidades SQL son muy transferibles.

He descubierto que la curva de aprendizaje en SQL no es realmente empinada para hacer lo básico, pero puede que le lleve algún tiempo ver realmente los beneficios que puede aportar a su análisis espacial. Pero animo a ser paciente y probar análisis más complicados y apuntar a un procesamiento más rápido. Eventualmente verás la diferencia.

Primero, cuando esté aprendiendo los conceptos básicos de SQL, aprenderá a consultar datos de una sola tabla utilizando técnicas básicas de selección de datos, como seleccionar columnas, ordenar conjuntos de resultados y filtrar filas. A continuación, aprenderá sobre las consultas avanzadas, como unir varias tablas, usar operaciones de conjunto y construir una subconsulta. Por último, aprenderá a administrar tablas de base de datos, como crear una nueva tabla o modificar la estructura de una tabla existente.

Pero también hay herramientas para ayudarte!

QGIS tiene una gran herramienta llamada Administrador de bases de datos. Ofrece una interfaz gráfica de usuario similar para su base de datos, pero de una manera mucho más comprimida y dentro de QGIS. Puede modificar y agregar tablas, agregar índices y hacer muchas de las operaciones básicas de una manera con el botón derecho del ratón.

También debe comprobar pgAdmin, que es la plataforma de administración y desarrollo más popular para PostgreSQL. Hay varias formas de obtener sus datos en PostGIS (por ejemplo, ogr2ogr, shp2pgsql). En general, animo a probar diferentes herramientas y métodos de trabajo con los datos.

He hecho algunos pequeños experimentos combinando Python y PostGIS. Trabajar con Python (o R) y PostGIS juntos puede llevar el procesamiento de datos y la automatización al siguiente nivel. Solo combinar las capacidades básicas de scripting de Python y conectarse a PostGIS usando psycopg2 son buenas maneras de comenzar.

¿Sientes que quieres comenzar con PostGIS?

1. Simplemente descargue los instaladores e instale PostGIS en su máquina local. Siga las instrucciones de los tutoriales;
2. Cargue algunos datos allí. Comience con un solo Shapefile usando QGIS DB Manager o chech, por ejemplo, este tutorial sobre cómo obtener datos de la Tierra natural en PostGIS;
3. Comience a jugar con SQL. Comience con lo básico (seleccionar, filtrar y modificar los datos) y poco a poco verá qué tipo de beneficios podría aportar a su flujo de trabajo.

Conclusiones

Si su forma de trabajar es actualmente ineficiente, simplemente cambiar sus herramientas no hará que su resultado sea mejor ni que el proceso sea menos doloroso. Necesita cambiar su forma de pensar sobre la gestión de datos. Existen numerosas formas de utilizar las bases de datos de manera ineficiente. Confía en mí, los he visto e incluso he probado algunos.

También cambiar las cosas solo por el cambio, no tiene sentido. Si su trabajo diario es solo trazar algunos puntos en un mapa de vez en cuando, puede hacerlo con Shapefiles y archivos csv también en el futuro. Incluso podría ser más eficiente de esa manera.

PERO.

Si desea realizar un análisis espacial serio, automatizar sus procesos o de cualquier manera mover su forma de trabajar con datos espatales al siguiente nivel, le recomiendo encarecidamente que se familiarice con PostGIS y, especialmente, con spatial SQL. Aprender SQL también puede ser divertido. Seriamente.

Por último, pero definitivamente no menos importante. Como señaló Tom: ¡usar PostGIS te da credibilidad geohipster!

Una cosa que mencioné solo brevemente fue que PostGIS es de código abierto y está disponible de forma gratuita. Esto significa que las personas que trabajan con un presupuesto pequeño o sin presupuesto (como yo) no tienen barrera de entrada. Las bases de datos espaciales comerciales pueden ser enormemente costosas. ¡Muchas gracias a todos los desarrolladores activos que trabajan en el proyecto!

Gracias por leer! Consulta mi sitio web para obtener más información sobre mí o envíame un comentario en Twitter.

¿Quieres saber más? Fuentes para esta entrada de blog y otras lecturas de PostGIS

RTFD. La documentación de PostGIS es muy buena.

El gurú de PostGIS Paul Ramsey tiene varias presentaciones sobre el tema desde diferentes puntos de vista en su sitio

Excelentes materiales de Boundless sobre la introducción a PostGIS.

Anita Graser ha escrito una excelente serie de publicaciones de blog sobre el manejo de datos de movimiento en PostGIS.

Echa un vistazo a los libros de PostGIS de Regina Obe

Utilicé este tutorial SIG de Boston cuando instalé por primera vez PostGIS localmente

Extra para personas que hacen dataviz: un interesante experimento sobre el almacenamiento de colores como puntos 3D en PostGIS