PostGIS vs. SQL Server para dados GIS


15

Então, eu estou começando recentemente em uma nova empresa e tenho muitos usuários do ArcGIS que parecem realmente interessados ​​em avançar com uma instância do PostGIS para fornecer alguns dados aos nossos clientes. Embora eu não tenha problemas com isso, somos uma loja do SQL Server a 95% e da Oracle a 5%. Nosso GIS interno atual é executado fora do SQL Server e ainda não recebi nenhuma reclamação.

Eu sei que o SQL Server possui muitos recursos espaciais / geométricos aprimorados a partir de 2012, mas há algum recurso matador no PostGIS que valha a pena invadir a nova plataforma? Eu tentei pesquisar, mas não consigo encontrar nada realmente profundo ou que não seja completamente tendencioso.

Quero dar a eles as melhores ferramentas para realizar seu trabalho, mas também tenho que ponderar o fato de que eu aprenderei Postgres / GIS desde o início e essa é uma jornada inteira por si só.


1
Se estiver fornecendo dados a clientes usando o ArcGIS For Server, a única consideração seria o desempenho. Embora tenha uma gama maior de funcionalidades espaciais, não acho que nada disso seria um recurso matador ou provavelmente exigido pelo ArcGIS. Infelizmente, não tenho referências de desempenho.
MickyT

O mantra antigo do uso que você conhece certamente se aplica aqui. Mudar para uma plataforma diferente sempre parece uma ótima idéia antes de iniciar a mudança. Não muito tempo depois, quando você passa 6 meses e percebe que apenas começou a obter o conhecimento necessário. Já ouviu falar do custo de oportunidade?
Max Vernon

2
Nenhuma experiência com produtos ARC, mas quando se fala apenas de bancos de dados. O PostGIS é uma implementação muito mais madura do banco de dados espacial do que o servidor MSSQL, mais exemplos, mais conteúdo gratuito. Se você precisar fazer algo relacionado espacialmente no db, o PostGIS is terá mais opções. O PostGIS é gratuito, o MS SQL não, os bancos de dados espaciais parecem ter tendência a crescer acima do esperado. Portanto, há dores de cabeça com o licenciamento, etc ... É claro que o Linux + PostGIS tem seus próprios problemas se os administradores estiverem mais acostumados ao ambiente do Windows.
simplexio 29/08/14

Respostas:


21

Eu trabalhei com o Postgres e o SQL Server. Eu achei o Postgres superior na funcionalidade GIS. E enquanto detalharei brevemente minhas descobertas abaixo, sugiro: Dê a si mesmo um período de tempo breve, mas razoável, para revisar a solução desconhecida sobre a que você conhece, com objetivos específicos em mente. Por exemplo, talvez um período de duas semanas para instalar e aprender algumas funcionalidades específicas atualmente em uso. Se você achar que está travado ou não possui funcionalidade nesse período, sabe que não é para você. É um investimento em pesquisa que amplia sua visão e ajuda a perceber que pode estar faltando algo que você desconhecia antes, ou simplesmente confirmar que seu curso atual é o certo agora.

Quanto ao banco de dados, eu achei que o Postgres tinha uma curva de aprendizado mais curta e mais superficial. A documentação é simplesmente incrível. O SQL Server tem bastante documentação, mas acho muito difícil de ler, com poucos exemplos e tutoriais.

PostGIS vs SQL Server Spatial é semelhante ao descrito acima em relação à documentação, mas o PostGIS supera a funcionalidade do SQL Server Spatial. Por exemplo, o Google Maps e, em menor grau, o Bing Maps, recentemente adicionaram suporte completo ao geoJSON à API de mapas. Bem, o PostGIS pode retornar facilmente um resultado geoJSON diretamente de uma consulta ao banco de dados usando ST_AsGeoJSON () . Esse resultado geoJSON pode ser passado diretamente para o que puder entender geoJSON. O SQL Server requer que você use biblioteca e processamento adicionais ou use ogr2ogr. Além disso, o PostGIS possui mais de 300 funções disponíveis para conversão de dados dentro e fora do banco de dados, em comparação com o SQL Server, que tem entre 70 e 100.


Assim que precisar de polígonos, use o PostGIS - você economizará muitos problemas. Se você precisar apenas de pontos, talvez o SQL-Server seja suficiente, mas também poderá usar duas colunas decimais (duas colunas não recomendadas se você precisar fazer cálculos de distância - use o GeoPoint). O GeoPoint não é recomendado se você usar EntityFramwork / LINQ2SQL / AverageCrappyORM.
dilema

0

Parece-me que qual db é melhor não é a sua principal preocupação aqui e, em vez disso, você tem duas considerações diferentes que se contrapõem: conhecimento de negócios versus desejos do cliente. Em última análise, isso será uma decisão comercial, não técnica.

Obviamente, há um custo de oportunidade, como Max observou em um comentário. Não há jeito de contornar isso. Se você estiver seguindo a rota do Postgres, considere obter ajuda, na forma de um bom contrato de consultoria, um dba experiente ou ambos.

Se seus usuários quiserem o PostGIS, isso pode ser uma vitória líquida. Quanto mais de seus serviços você venderá ao fazer a troca? Valerá a pena a oportunidade em termos de custo? Essas não são decisões que serão tomadas com base em qual db é melhor aos seus olhos ou em termos de especificações técnicas, mas em termos da curva de aprendizado e do marketing.


Excelente visão sobre a escolha em questão - obrigado Chris.
LowlyDBA

Qual db é melhor é a principal preocupação aqui. O servidor SQL não pode lidar com esse tamanho de dados (planet.osm). Além disso, ele perde muitos recursos, os quais você realmente precisa, se for fazer mais do que pesquisa acadêmica (blocos de vetor, geojson, etc.). Além disso, ele não pode lidar com polígonos que vão de um lado do equador para o outro (estúpido), o que é uma preocupação se você precisar de brasil, equador, colômbia, drc, gabão, Quênia, Somália, malásia, indonésia, Cingapura, Papua ou o índio, do Pacífico ou Oceano Atlântico, etc Além disso, os erros se o polígono tem a direção errada - em vez de auto-converter ...
Quandary
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.