Qual é o objetivo do PostGIS no PostgreSQL?

O PostgreSQL já suporta tipos de dados espaciais, operadores e indexação.

O que o PostGIS fornece exatamente o que tornou necessário existir como uma extensão do PostgreSQL?

Por que todos nós não usamos apenas a funcionalidade espacial do PostgreSQL?

Se você refazer o universo até o início de 2001, e não apenas permitir que os inventores do PostGIS vejam o futuro, mas também que o PSC do PgSQL veja o futuro, talvez o PostGIS seja uma série de patches no PgSQL. Mas, no mínimo, se tivéssemos começado como patches, a primeira coisa que teríamos de enfrentar é:

• as áreas principais do PgSQL não suportam buracos, mas o modelo GIS realmente deseja buracos, podemos mudar isso?

E o PgSQL principal teria dito: "não, é claro que não, as áreas têm uma semântica bem compreendida e não podemos fazer mudanças incompatíveis com versões anteriores".

Como desenvolvedores não essenciais, o PostGIS conseguiu eliminar os lançamentos mensais e semestrais por vários anos, enquanto o núcleo do PgSQL avançou junto com os lançamentos anuais e mais longos. Também pudemos adicionar os recursos que desejávamos, sempre, desde que tínhamos direitos de commit em nosso projeto, mas obter direitos de commit no PgSQL leva um tempo muito longo.

No momento em que o PostGIS estava demonstrando valor externo suficiente, o núcleo do PgSQL examinou e disse a si mesmo "huh, isso seria bom ter no núcleo como um recurso extra", já havia muito código de um padrão e estilo tão diferente PgSQL (para não mencionar sob uma licença incompatível) que a idéia de mesclar não era realmente possível.

Em vez disso, o PostGIS se tornou o exemplo canônico de uma Really Large Complex Extension que ajuda o PgSQL a permanecer modular e extensível. "Como isso afetará algo como o PostGIS" é uma pergunta frequentemente feita enquanto o PgSQL principal avalia algumas mudanças. Isso também é bom, talvez não tão bom quanto o PostGIS fazer parte do núcleo, mas bom o suficiente.

Existem outras razões, como a longa lista de dependências que o núcleo do PgSQL odiaria ver, a consistência geralmente mais baixa do código e a limpeza da API que eles teriam perdido o desejo de melhorar, e assim por diante. Mesmo na concepção, o PostGIS era muito grande para o PgSQL engolir em uma única mordida.

Isso simplesmente não é verdade, o PostgreSQL não suporta tipos de dados espaciais. Ele suporta tipos geométricos. Eles são perfeitamente adequados para algumas coisas, mas são totalmente separados dos sistemas de coordenadas do mundo real. Tipos nativos

• não possui ID de sistema de referência espacial / SRSID.
• nunca pode ser reprojetado.
• mesmo em um esferóide, eles fornecem funcionalidades muito limitadas.
• Eles não são padronizados.
• Eles não fornecem índices GIST.

Atualizar

Quanto à questão do índice, está no FAQ

Por que os índices R-Tree do PostgreSQL não são suportados?

As primeiras versões do PostGIS usavam os índices do PostgreSQL R-Tree. No entanto, as R-Trees do PostgreSQL foram completamente descartadas desde a versão 0.6 e a indexação espacial é fornecida com um esquema R-Tree-over-GiST.

Nossos testes mostraram que a velocidade de pesquisa do R-Tree e do GiST nativos é comparável. As Árvores R nativas do PostgreSQL têm duas limitações que as tornam indesejáveis ​​para uso com os recursos GIS (observe que essas limitações se devem à implementação atual da Árvore R nativa do PostgreSQL, e não ao conceito da Árvore em geral):

• Os índices R-Tree no PostgreSQL não podem lidar com recursos maiores que 8K. Os índices GiST podem, usando o truque "com perdas" de substituir a caixa delimitadora pelo próprio recurso.

• Os índices da R-Tree no PostgreSQL não são "nulos seguros"; portanto, a criação de um índice em uma coluna de geometria que contenha geometrias nulas falhará. [Os índices do GiST são seguros para nulos]

O PostGIS é um extensor de banco de dados espacial para o banco de dados relacional de objetos do PostgreSQL . Ele adiciona suporte para objetos geográficos, permitindo que consultas de localização sejam executadas no SQL.

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

Além do reconhecimento básico de localização, o PostGIS oferece muitos recursos raramente encontrados em outros bancos de dados espaciais concorrentes, como Oracle Locator / Spatial e SQL Server. Consulte a Lista de recursos do PostGIS para obter mais detalhes.

A lista de recursos do PostGIS também expande esses recursos:

O PostGIS adiciona tipos extras (geometria, geografia, raster e outros) ao banco de dados PostgreSQL . Ele também adiciona funções, operadores e aprimoramentos de índice que se aplicam a esses tipos espaciais. Essas funções adicionais, operadores, ligações de índice e tipos aumentam o poder do DBMS principal do PostgreSQL, tornando-o um sistema de gerenciamento de banco de dados espacial rápido, cheio de recursos e robusto.

Lista de recursos

A série PostGIS 2+ fornece:

• Funções de processamento e analíticas para dados vetoriais e rasterizados para emendar, cortar, transformar, reclassificar e coletar / unir com o poder da álgebra de mapas rasterizados SQL para processamento rasterizado
• Funções de chamada SQL de reprojeção espacial para dados vetoriais e rasterizados Suporte para importação / exportação de dados vetoriais de shapefile ESRI por meio de ferramentas empacotadas por linha de comando e GUI e suporte para mais formatos através de outras ferramentas de código aberto de terceiros

• Linha de comando empacotada para importar dados rasterizados de vários formatos padrão: GeoTiff, NetCDF, PNG, JPG

• Renderizar e importar funções de suporte a dados vetoriais para formatos de texto padrão, como KML, GML, GeoJSON, GeoHash e WKT usando SQL Renderização de dados rasterizados em vários formatos padrão GeoTIFF, PNG, JPG, NetCDF, para citar alguns usando SQL

• Funções chamaráveis ​​SQL de varredura / vetor sem costura para extrusão de valores de pixel por região geométrica, estatísticas de execução por região, rasters de rascunho por uma geometria e rasters de vetorização suporte a objetos 3D, índice espacial e funções Suporte à topologia de rede / utilizando dados do US Census Tiger

Além disso, aos pontos / partes mencionados já neste post. Eu adicionaria como mencionado no site do PostGIS Como funciona

Como o PostGIS está em C, ele pode fazer uso de outras bibliotecas em C e C ++, e o faz livremente. O PostGIS depende de:

• GEOS para muitos algoritmos de processamento de geometria
• Proj.4 para funções de re-projeção de coordenadas
• GDAL para processamento de varredura e suporte ao formato
• LibXML2 para análise de XML
• JSON-C para análise JSON
• SFCGAL para suporte 3D estendido e algoritmos de geoprocessamento adicionais