¿Cuál es el propósito de PostGIS en PostgreSQL?

49

PostgreSQL ya admite tipos de datos espaciales, operadores e indexación.

¿Qué proporciona exactamente PostGIS que hizo necesario que existiera como una extensión de PostgreSQL?

¿Por qué no todos usamos la funcionalidad espacial de PostgreSQL?

Zeruno
fuente
2
Es PostGIS que proporciona esos tipos de datos espaciales, operadores e indexación ...
DPSSpatial
55
No, está hablando de los tipos de geometría nativos de PostgreSQL.
Evan Carroll
44
La respuesta corta es que PostGIS es (ahora) 10 veces más funcional que los tipos PgSQL. La respuesta larga, que abarca la pregunta "por qué desarrollar nuevos tipos, y no solo mejorar los que ya existen", se aborda a continuación.
Paul Ramsey
1
Lo mismo sucedió con el framework Java Spring. Java tenía fallas / características faltantes. Spring corrigió muchos defectos de Java y agregó características útiles. Java copió las correcciones + características de Spring. La gente pregunta por qué existe la primavera ...
Neil McGuigan

Respuestas:

86

Si vuelve a enrollar el universo a principios de 2001, y no solo deja que los inventores de PostGIS vean el futuro, sino que también deja que el PSC de PgSQL vea el futuro, tal vez PostGIS sea una serie de parches en PgSQL. Pero como mínimo, si hubiéramos comenzado como parches para el núcleo, lo primero con lo que nos habríamos topado es:

  • Las áreas centrales de PgSQL no admiten agujeros, pero el modelo SIG realmente quiere agujeros, ¿podemos cambiar eso?

Y el núcleo de PgSQL hubiera dicho: "no, por supuesto que no, las áreas tienen una semántica bien entendida existente y no podemos hacer cambios incompatibles hacia atrás como ese".

Como desarrolladores no centrales, PostGIS pudo eliminar versiones mensuales y semestrales durante varios años, mientras que el núcleo PgSQL se mantuvo junto con las versiones anuales y más largas. También pudimos agregar cualquier característica que quisiéramos, siempre que teníamos derechos de compromiso en nuestro proyecto, pero obtener derechos de compromiso en PgSQL lleva mucho tiempo.

Cuando PostGIS demostró suficiente valor externo que PgSQL core examinó y se dijo "eh, eso hubiera sido bueno tener en el núcleo como una característica adicional", ya había tanto código de un estándar y un estilo tan diferentes de PgSQL (sin mencionar bajo una licencia incompatible) que la idea de fusión no era realmente posible.

En cambio, PostGIS se ha convertido en el ejemplo canónico de una Extensión Compleja Realmente Grande que ayuda a PgSQL a permanecer modular y extensible. "¿Cómo afectará esto a PostGIS?" Es una pregunta que a menudo se hace cuando PgSQL central evalúa algunos cambios. Esto también es algo bueno, quizás no tan bueno como PostGIS como parte del núcleo, pero lo suficientemente bueno.

Hay otras razones, como la larga lista de dependencias que el núcleo de PgSQL hubiera odiado ver, la consistencia del código generalmente más baja y la limpieza de la API que habrían desesperado por mejorar, y así sucesivamente. Incluso en la concepción, PostGIS era una bola de pelo demasiado grande para que PgSQL se la tragara de una mordida.

Paul Ramsey
fuente
Además ... PostGIS es C ++. Esto sería un showtopper para una fusión PostgreSQL. Ya sea o no debería ser. Las dependencias también lo detendrían por completo: ¿GDAL? ¡Decir ah! Ni siquiera puedo obtener el núcleo para aceptar depender de Perl> 5.8.0. El ritmo de desarrollo es lento incluso si tiene derechos de compromiso; los encargados de la confirmación no solo se liberan para todas las cosas del árbol, deben pasar por la revisión del código y obtener grandes cambios en meses o años. Hay beneficios de calidad de código, pero seguro que no se mueve rápidamente.
Craig Ringer
Es un problema particular que Core Pg sigue reinventando cosas para evitar dependiendo de más bibliotecas externas. Debido a que significaría $ ancient_unix_42 con $ weird_vendor_compiler en $ dead_architecture tendría que ser compatible, todos los miembros de buildfarm necesitarían una actualización, etc. Supongo que es uno de los problemas para ser maduro y estable.
Craig Ringer
@CraigRinger ¿Por qué crees que PostGIS es C ++? Eso es un insulto :-)
Nicklas Avén
¿No es ...? Podría haber jurado. Pero, efectivamente, no lo parece. Culpa mía. De hecho, me gusta el uso (moderado y moderado) de C ++ de todos modos.
Craig Ringer
44
Durante un período de tiempo, PostGIS tenía algunas piezas de C ++ para hacer un enlace a GEOS. Una vez que GEOS agregó su propia API de C, esas piezas fueron eliminadas y PostGIS se convirtió en "puro" C.
Paul Ramsey
34

Eso simplemente no es cierto, PostgreSQL no admite tipos de datos espaciales. Soporta tipos geométricos. Estos están perfectamente bien para algunas cosas, pero están totalmente separados de los sistemas de coordenadas del mundo real. Tipos nativos

Actualizar

En cuanto a la pregunta del índice, está en las preguntas frecuentes

¿Por qué no se admiten los índices PostgreSQL R-Tree?

Las primeras versiones de PostGIS usaban los índices PostgreSQL R-Tree. Sin embargo, PostgreSQL R-Trees se ha descartado por completo desde la versión 0.6, y la indexación espacial se proporciona con un esquema R-Tree-over-GiST.

Nuestras pruebas han demostrado que la velocidad de búsqueda de R-Tree y GiST nativos es comparable. Los R-Trees nativos de PostgreSQL tienen dos limitaciones que los hacen indeseables para su uso con las funciones de SIG (tenga en cuenta que estas limitaciones se deben a la implementación actual de R-Tree nativo de PostgreSQL, no al concepto de R-Tree en general):

  • Los índices de R-Tree en PostgreSQL no pueden manejar características que son más grandes que 8K de tamaño. Los índices GiST pueden, utilizando el truco "con pérdida" de sustituir el cuadro delimitador por la propia característica.

  • Los índices de R-Tree en PostgreSQL no son "nulos seguros", por lo que generará un índice en una columna de geometría que contenga geometrías nulas fallará. [Los índices GiST son nulos-seguros]

Evan Carroll
fuente
¿Puede ampliar su último punto, el de los índices GiST? PostgreSQL estaba proporcionando R-Tree y ahora lo está proporcionando a través de un índice GiST, así que estoy confundido sobre ese punto.
Zeruno
actualizado con texto directo de las preguntas frecuentes.
Evan Carroll
1
La API de GIST es una cosa PostgreSQL proporcionada por el acceso / gist.h . Puede verlo en uso en PostGIS aquí
Evan Carroll, el
3
Si bien PostGIS tiene su propia implementación rtree-on-gist, es muy similar a la utilizada por PgSQL para su soporte principal de objetos gráficos por la sencilla razón de que originalmente copiamos la suya.
Paul Ramsey
1
@Zeruno, No, modificar el divisor rtree en PgSQL no cambiará el comportamiento de PostGIS, porque tenemos el nuestro, en gserialized_gist_picksplit_2d (). No es que no sea tan diferente del PgSQL, si es que lo hace.
Paul Ramsey
8

PostGIS es un extensor de base de datos espacial para la base de datos relacional de objetos PostgreSQL . Agrega soporte para objetos geográficos permitiendo que las consultas de ubicación se ejecuten en SQL.

SELECT superhero.name
FROM city, superhero
WHERE ST_Contains(city.geom, superhero.geom)
AND city.name = 'Gotham';

Además del conocimiento básico de la ubicación, PostGIS ofrece muchas características que rara vez se encuentran en otras bases de datos espaciales competidoras como Oracle Locator / Spatial y SQL Server. Consulte la Lista de características de PostGIS para obtener más detalles.

La lista de características de PostGIS también amplía esas capacidades:

PostGIS agrega tipos adicionales (geometría, geografía, ráster y otros) a la base de datos PostgreSQL . También agrega funciones, operadores y mejoras de índice que se aplican a estos tipos espaciales. Estas funciones adicionales, operadores, enlaces de índice y tipos aumentan la potencia del núcleo DBMS PostgreSQL, lo que lo convierte en un sistema de gestión de base de datos espacial rápido, con muchas funciones y robusto.

Lista de características

La serie PostGIS 2+ proporciona:

  • Procesamiento y funciones analíticas para datos vectoriales y ráster para empalmar, cortar en cuadritos, transformar, reclasificar y recopilar / unir con el poder del álgebra de mapa ráster SQL para el procesamiento ráster de grano fino
  • Reproyección espacial Funciones invocables de SQL para datos vectoriales y ráster Soporte para importar / exportar datos vectoriales de archivos de forma ESRI a través de herramientas empaquetadas de línea de comandos y GUI y soporte para más formatos a través de otras herramientas de código abierto de terceros
  • Línea de comandos empaquetada para importar datos ráster desde muchos formatos estándar: GeoTiff, NetCDF, PNG, JPG

  • Renderizado e importación de funciones de soporte de datos vectoriales para formatos de texto estándar como KML, GML, GeoJSON, GeoHash y WKT usando SQL Renderizado de datos ráster en varios formatos estándar GeoTIFF, PNG, JPG, NetCDF, por nombrar algunos usando SQL

  • Funciones invocables SQL de ráster / vector ininterrumpidas para la extrusión de valores de píxeles por región geométrica, estadísticas de ejecución por región, rásteres de recorte por geometría y rásteres de vectorización Soporte de objetos 3D, índice espacial y funciones Soporte de topología de red Cargador de tigre empaquetado / Geocoder / Geocoder inverso / utilizando datos del tigre del censo de EE. UU.

Además, a los puntos / partes mencionados ya en este post. Agregaría como se menciona en el sitio web de PostGIS Cómo funciona

Como PostGIS está en C, puede hacer uso de otras bibliotecas en C y C ++, y lo hace de manera liberal. PostGIS depende de:

  • GEOS para muchos algoritmos de procesamiento de geometría
  • Proj.4 para funciones de reproyección de coordenadas
  • GDAL para procesamiento ráster y soporte de formato
  • LibXML2 para el análisis XML
  • JSON-C para el análisis JSON
  • SFCGAL para soporte 3D extendido y algoritmos de geoprocesamiento adicionales
whyzar
fuente