Qual é o objetivo do PostGIS no PostgreSQL?

49

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?

Zeruno
fonte
2
É PostGIS que fornece esses tipos de dados espaciais, operadores e indexação ...
DPSSpatial
5
Não, ele está falando sobre os tipos de geometria nativa do PostgreSQL.
Evan Carroll
4
A resposta curta é que o PostGIS é (agora) 10x tão funcional quanto os tipos PgSQL. A resposta longa, que engloba a pergunta "por que desenvolver novos tipos, e não apenas melhorar os que já existem", é abordada abaixo.
Paul Ramsey
11
O mesmo aconteceu com o framework Java Spring. Java tinha falhas / recursos ausentes. O Spring corrigiu muitas falhas do Java e adicionou recursos úteis. Java copiou as correções + recursos do Spring. As pessoas então perguntar por Primavera existe ...
Neil McGuigan

Respostas:

86

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.

Paul Ramsey
fonte
Também ... PostGIS é C ++. Este seria um empecilho para uma PostgreSQL merge.Whether ou não deveria ser. Dependências também o impediriam completamente - GDAL? Ha! Eu não consigo nem o núcleo concordar em depender do Perl> 5.8.0. O ritmo de desenvolvimento é lento, mesmo se você tiver direitos de commit; os committers não apenas conseguem liberar todas as coisas de empurrão na árvore, eles precisam passar por uma revisão de código e obter grandes mudanças em meses ou anos. Existem benefícios na qualidade do código, mas com certeza não é rápido.
Craig Ringer
É um problema específico que o Core Pg continua reinventando coisas a serem evitadas dependendo de mais bibliotecas externas. Como isso significaria que $ ancient_unix_42 com $ weird_vendor_compiler em $ dead_architecture precisaria suportá-lo, todos os membros da buildfarm precisariam ser atualizados etc. É um dos problemas de ser maduro e estável, eu acho.
Craig Ringer
@CraigRinger Por que você acha que o PostGIS é C ++? Isso é um insulto :-)
Nicklas Avén
Isso não é? Eu poderia jurar. Mas com certeza não parece. Minha culpa. Na verdade, eu gosto (moderado e contido) de usar C ++ de qualquer maneira.
Craig Ringer
4
Por um período de tempo, o PostGIS teve alguns pedaços de C ++ para criar uma ligação com o GEOS. Uma vez GEOS acrescentou seu próprio C API, as peças foram removidas e PostGIS tornou-se "puro" C.
Paul Ramsey
34

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

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]

Evan Carroll
fonte
Você pode expandir seu último ponto - aquele sobre os índices GiST? O PostgreSQL estava fornecendo R-Tree e agora está fornecendo isso através de um índice GiST, por isso estou confuso sobre esse ponto.
Zeruno
atualizado com o texto direto do FAQ.
Evan Carroll
11
A API GiST é uma coisa PostgreSQL fornecido pelo acesso / gist.h . Você pode vê-lo em uso no PostGIS aqui
Evan Carroll
3
Embora o PostGIS tenha sua própria implementação rtree-on-gist, é muito semelhante à usada pelo PgSQL para o suporte principal de objetos gráficos pela simples razão de que originalmente os copiámos.
Paul Ramsey
11
@Zeruno, Não, modificar o divisor rtree no PgSQL não mudará o comportamento do PostGIS, porque temos o nosso, em gserialized_gist_picksplit_2d (). Você não é, não é tão diferente do PgSQL, se é que existe.
Paul Ramsey
8

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
whyzar
fonte