Baixo desempenho ao armazenar rasters grandes no PostGIS e visualizar no QGIS

minha pergunta diz respeito ao uso e desempenho de várias ferramentas de software em conjunto, como PostgreSQL, PostGIS, QGIS e GDAL.

Sou um usuário de longa data do ArcGIS, Python e R que também está interessado em diversificar o ecossistema GIS de código aberto e o Linux. Recentemente, fiquei muito interessado em usar o QGIS (versão 2.8) junto com o PostgreSQL (versão 9.4) e PostGIS (versão 2.1), e instalei o software em um computador com Windows 8.1 x64 (as especificações do computador são resumidas: ThinkPad X200s com um Core 2 de 2,1 GHz, 8 GB de RAM e um SSD de 240 GB). Depois de aprender a gerenciar meus dados espaciais (~ 100 GB no valor), gostaria de executar o Ubuntu nesta máquina.

No momento, estou simplesmente tentando armazenar e recuperar arquivos e shapefiles e rasters de forma confiável. Até agora, consegui carregar arquivos shapefiles no PostGIS, mas os rasters estão se mostrando mais problemáticos. Concluí com êxito as importações individuais e em lote de pequenos arquivos geoTIFF e GRID, mas rasters maiores (por exemplo, um arquivo IMG ou TIFF de 15619x14655 células com tamanho de 870 MB no disco) demoram uma eternidade para carregar no PostGIS. Eu li e configurei a ferramenta raster2pgsql para criar índices espaciais e carregar rasters por blocos usando estes parâmetros:

raster2pgsql -s 3161 -C -I D:\PostGIS_data\dem.img -t auto raster.dem | psql -h localhost -U postgres -p 5432 -d postgres

O desempenho na importação ainda é muito ruim, e o hardware não é o problema. A visualização de rasters PostGIS no QGIS é ainda pior, carregando lentamente rasters pequenos na melhor das hipóteses ou congelando completamente. Rasters grandes como o que eu mencionei são impossíveis de visualizar no QGIS. A partir das discussões da documentação e do fórum, essa falha parece dever-se ao driver raster PostGIS da GDAL e não ao próprio QGIS. As discussões no fórum mencionam esse problema brevemente e alguns até sugerem que rasters não devem ser armazenados no PostGIS (qual é o ponto em um banco de dados espacial que não lida com rasters sem problemas?). No entanto, eu uso rotineiramente o geodatabase de arquivos da ESRI para armazenar, visualizar e analisar rasters muito grandes (~ 70 GB) de maneira rápida e fácil, e o ArcGIS 10.1 nunca congela ou diminui devido a essas operações de rotina.

Há algo que estou perdendo aqui, um gargalo que não resolvi? O PostgreSQL precisa de ajuste para obter os benefícios de desempenho do PostGIS? Estou faltando uma versão do GDAL que preciso caçar e compilar? Como melhoro o desempenho e a visualização do PostGIS no QGIS de shapefiles e rasters especialmente? Como posso desfrutar da glória do gerenciamento de dados espaciais abrangente e rápido através de um terminal Linux? Qualquer ajuda sobre esta questão seria bem-vinda!

Eu segui este guia por um Duncan Golicher: https://duncanjg.wordpress.com/2012/11/20/the-basics-of-postgis-raster/

Eu estava usando blocos com uma configuração automática originalmente, mas redefinii o bloco para 100x100 células por linha e incluí as pirâmides, como mostrado no guia, da seguinte forma:

raster2pgsql -s 3161 -d -C -I -M -l 4 D:\PostGIS_data\dem.img -t 100x100 raster.dem100 | psql -h localhost -U postgres -p 5432 -d postgres

Consegui importar com êxito o raster de 870MB IMG em um bom momento e exibi-lo no QGIS sem reduzir a velocidade ou travar o aplicativo. O tempo de renderização não é tão rápido quanto eu esperaria, mas é aceitável. Vou ler mais sobre o parâmetro -l para usá-lo corretamente.

Aliás, ao importar o arquivo dem.img como a tabela dem100, outra tabela raster foi criada chamada "o_4_dem100". Quando eu o importo como uma camada no QGIS, ele tem um intervalo de valores entre 201 e 524, enquanto a camada dem100 tem um intervalo de 36 a 524. Estou certo ao supor que essa tabela extra seja a tabela de pirâmide mais estreita intervalo de valores como resultado de serem agregados a uma resolução mais baixa?

Não acho que o hardware inadequado seja o problema. Aqui está um breve resumo do que encontrei até agora.

O driver de varredura PostGIS da GDAL teve problemas de desempenho anteriores ( veja aqui também ). Embora esses problemas tenham sido observados em 2012, eu me pergunto se o GDAL 1.11.2 encontrado no QGIS 2.8 ainda tem esse problema. Certamente existem outras pessoas que usam QGIS e PostGIS para visualização e armazenamento de varredura?

Em uma possível observação relacionada, também tive problemas de desempenho ao abrir tabelas de atributos PostGIS no QGIS com tabelas de ~ 4,7 m de registros . Depois de algumas sugestões nesse segmento e sem corrigir o problema, finalmente enviei um relatório de erro ao QGIS que acabou sendo fechado e vinculado ao seguinte relatório de erro semelhante . Embora o relatório de erros esteja fechado, ele não parece ser corrigido ...

Para resumir meus esforços até agora:

• Otimizei o servidor PostgreSQL para dados espaciais.
• Criei índices espaciais para tabelas de geometria e executei um VACUUM.
• O comportamento do QGIS para abrir tabelas de atributos grandes (~ 4,7 milhões de registros) parece tentar ler todos os registros, em vez de retornar um subconjunto para visualização instantânea. Isso leva a um desempenho ruim.

• O desempenho na renderização de grandes tabelas de geometria PostGIS não parece ser um problema.

• Com o raster2pgsql, os rasters foram indexados, agrupados e importados como tabelas rasterizadas com pirâmides no PostGIS.

• Rasters de qualquer tamanho razoável ainda são incrivelmente lentos para importar para o PostGIS, muito menos para abrir e girar no QGIS.

Também é importante notar que, ao importar grandes rasters ou abrir grandes tabelas de atributos com o PostGIS, o consumo de memória para raster2pgsql e qgis-bin é superior a 1 GB. Como o @Michael e o @Paul mencionaram em resposta à minha pergunta inicial, parece que o PostGIS não deve trazer muitos benefícios, se houver, para o armazenamento de rasters. No entanto, nesse momento, questiono por que eu executaria o QGIS + PostGIS para minhas necessidades de GIS, especialmente quando os fileGDBs ESRI ativam atributos de varredura, conjuntos de dados em mosaico e outras operações de varredura facilitadas pelo banco de dados geográficos. Então, talvez esteja realmente faltando alguma coisa ou o QGIS e o PostGIS não atendam às minhas necessidades de GIS. Acho o último difícil de acreditar.

Se você deseja exibir rasters grandes no QGIS, é necessário criar pirâmides, para uma imagem tif no sistema de arquivos ou para uma imagem registrada no Postgis.

A diferença de desempenho na renderização do QGIS entre uma grande varredura no sistema de arquivos ou no Postgis é mínima. Os usuários não perceberão a diferença. Mas - se e somente se - você constrói as pirâmides com a opção -l.

Se você importar a imagem sem a opção -l, ou apenas com -l 4 ela, não funcionará .

Se você usar, por exemplo, -l 2,4,8,16quatro níveis de pirâmides serão criados, como na camada abaixo:

Se você quiser ter uma melhor experiência do usuário, adicione mais níveis de pirâmides, como -l 2,4,8,16,32,64,128,256. Isso criará oito níveis de pirâmides.

Para resumir, a resposta para esta pergunta é: importe a varredura com a opção -le use o mesmo número de níveis de pirâmide que você usa para a mesma varredura no sistema de arquivos.

Por exemplo:

raster2pgsql -s 3161 -d -C -I -M -l 2,4,8,16,32,64,128,256 D:\PostGIS_data\dem.img -t 100x100 raster.dem100 | psql -h localhost -U postgres -p 5432 -d postgres

Estou tendo exatamente os mesmos problemas com a renderização de rasters no QGIS do PostGIS (veja minha pergunta recente ). Encontrei esta postagem útil e aumentando ligeiramente a seguinte renderização de varredura aprimorada:

shared_buffers = 5000MB work_mem = 100MB maintenance_work_mem = 100MB

No entanto, com isso dito, eu concordo totalmente que o desempenho dos rasters PostGIS no QGIS não é ótimo. Estou lidando com 608 geotiffs compactados que carregam muito bem como um VRT, mas são essencialmente inutilizáveis ​​no PostGIS. Tente aumentar o desempenho do servidor dbase, mas além disso não posso ser muito útil. Eu também talvez precise confiar no sistema de arquivos para servir rasters dentro da minha organização.

Não tenho certeza se foi o seu caso, mas descobri -Ique não deve ser usado junto com os dados anexados -a.

Eu estava importando muitos arquivos TIF para um banco de dados e, -Ina verdade, cria o índice novamente e executa analysena tabela para cada arquivo, o que leva 10 vezes mais tempo.

-Ideve ser usado apenas ao criar a tabela, com a -popção