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

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?

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.

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

• no tiene ID de sistema de referencia espacial / SRSID.
• nunca se puede volver a proyectar.
• Incluso en un esferoide, proporcionan una funcionalidad muy limitada.
• No están estandarizados.
• No proporcionan índices GIST.

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]

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