Estou manipulando e processando rasters globais com resolução de 30m. O tamanho total da varredura é geralmente [1.440.000 560.000]. Como tenho acesso a um supercomputador, escrevi um código que me permite dividir rasters globais em blocos gerenciáveis, executar alguns cálculos em paralelo e gravá-los no disco rapidamente.
Eu bati em uma parede, no entanto, quando se trata de exibir resultados. Normalmente, construo uma varredura virtual de ladrilhos que cobrem o globo e o coloco no QGIS. Mas é incrivelmente lento (minutos para carregar, se houver). E se eu tentar fazer panorâmicas ou zoom, são mais alguns minutos. Minha primeira abordagem para resolver esse problema foi criar visões gerais usando o gdaladdo. No entanto, isso leva uma eternidade para criar (como em dias), o que não é propício ao desenvolvimento de algoritmos. Aqui está uma lista das coisas que tentei e por que / como elas falharam.
crie visões gerais no vrt. Como mencionado acima, são necessários mais de 2 dias para completar 8 níveis. Isso é inaceitável para meus propósitos.
crie visões gerais nos blocos individuais e, de alguma forma, mescle-se a um vrt que contém as visões gerais. Sou capaz de criar visões gerais sobre os blocos rapidamente (supercomputador), mas não consegui refazê-las. Eu tentei:
2a gdal_merge nos blocos com visões gerais, mas as visões gerais não foram mantidas (ou pelo menos não reconhecidas pelo QGIS) no tiff de saída.
2b. gdalbuildvrt nos blocos com visões gerais, mas, como acima, as visões gerais não foram mantidas. [Isso não está correto, veja editar.]
2c. Também tentei um híbrido de visões gerais de construção para os blocos dos níveis 1-6 e de construção 7-8 diretamente no vrt (basicamente opção 2b), mas ainda está demorando uma eternidade apenas nesses dois níveis. Fiz alguns testes e vi que as visões gerais do bloco são realmente usadas para criar visões gerais do vrt, mas ainda está na ordem de um dia para concluir as visões gerais do vrt.
Então, espero que alguém aqui tenha algumas sugestões sobre onde devo ir a seguir. Aqui estão algumas opções que estou considerando:
Crie manualmente as pirâmides globais. Tenho receio de recombiná-los em um arquivo .ovr, pois presumo que isso seja complicado.
Use um servidor de mapas (Geoserver). Sei muito pouco sobre isso e estou preocupado que isso não supere os obstáculos do tempo, acrescentando complexidade ao meu processo.
Divida o domínio por continentes ou alguma outra região. Eu realmente quero evitar essa opção.
Você pode perguntar "por que você precisa ver o globo inteiro com uma resolução de 30m?" Um exemplo: pego uma máscara de pixels de água (globalmente) e a esqueletizo para encontrar rios e realizar medições. Meu algoritmo de esqueletização requer um pouco de ajuste (para poda de galhos, remoção de loops, limpeza geral etc.), e a saída é necessariamente a 30m. Como os rios e as paisagens são diversos em todo o mundo, eu preciso ser capaz de ver os efeitos de quaisquer mudanças que eu implementei.
Também examinei o QGIS para garantir que não haja configurações com as quais eu possa jogar para processar rasters enormes mais rapidamente, mas não vi nada. Com falta de comprar unidades SSD, acho que está dando a partida o mais rápido possível. (Meus HDDs têm E / S de ~ 250 MB / s).
Descobri que a criação de visões gerais em blocos individuais e, em seguida, a criação de um vrt aparentemente mantém as visões gerais - a seção "Pirâmide" do QGIS nos metadados do arquivo está vazia, mas na seção "Dimensões" há uma entrada para cada nível de visão geral (por exemplo, X 720000, Y 140; X 360000, Y 70, etc.). Então, eu estava errado sobre 2b.
Também acho que, se eu apenas colocar todos os blocos no QGIS, ele renderiza em menos de um minuto, enquanto se eu puxar o vrt que faz referência aos blocos, leva mais de 5 minutos (não sei quanto tempo exatamente desde que eu matei o bloco) processo).
Fiz alguns testes em um computador com um SSD e descobri que era possível carregar, exibir e renderizar os vrts globais (sem nenhuma visão geral) com sucesso e a uma taxa aceitável. Encomendei um SSD PCIe de 1 TB na esperança de que ele me permita fazer o mesmo no meu computador. Será atualizado com os resultados.
I also tried a hybrid of building overviews for the tiles for levels 1-6 and building levels 7-8 directly on the vrto mesmo que a ordem que você recomenda e que é naturalmente a correta. Eu não calcularia 2 4 8 ... visões gerais do VRT se blocos individuais os tivessem para economizar tempo e espaço em disco. O ROI pequeno encontraria visões gerais de alguns blocos e isso deve ser rápido o suficiente.Respostas:
Você parece ter duas preocupações principais: VRT id lento na navegação e lento na criação de visões gerais globais.
Embora eu tenha certeza de que o GDAL VRT costumava ser lento para mim e para o meu MapServer há muitos anos, pode ser que a situação tenha mudado. Fiz uma camada de teste com 10000 imagens aéreas (tamanho da imagem / bloco de 10000x10000 a 12000x12000 pixels) e agora o GDAL VRT é realmente mais rápido que o índice de shapefile nativo do MapServer e serve com o computador de teste 6 blocos (256x256) por segundo em um teste simples com 1 segmento em que os GetMaps atingem sempre o primeiro nível de visão geral. O mosaico com 10000 imagens ainda é bastante pequeno e acho que no meu teste o Linux tinha o arquivo VRT inteiro na memória cache. Quantas imagens você tem no seu VRT?
O capítulo a seguir pode conter informações antigas, lidas com responsabilidade:
Há alguma evidência de que o VRT é lento quando contém um grande número de imagens. Isso ocorre porque o VRT é um índice no formato XML e não suporta índice espacial, o que leva à verificação completa de todo o arquivo XML todas as vezes. Não há nada que você possa fazer para melhorar isso com o GDAL simples, mesmo que haja alguma discussão sobre a implementação do índice espacial para VRT http://osgeo-org.1560.x6.nabble.com/gdal-dev-Don-t-we- tenha alguma idéia para GSoC-2017-td5309810.html .
Se você deseja instalar um novo software, a solução mais fácil seria usar o MapServer com tileindex http://www.mapserver.org/optimization/tileindex.html . Se você criar um tileindex com gdaltindex http://www.gdal.org/gdaltindex.html e criar um índice para o tileindex também com shptree http://www.mapserver.org/utilities/shptree.htmlo MapServer deve ser capaz de acessar muito rapidamente todos os arquivos de imagem que você possui. Crie visões gerais para blocos individuais e atenda a camada através do WMS para QGIS e você resolveu a primeira parte do problema, mas não o problema com as visões gerais globais. Mesmo se você tiver criado visões gerais para os blocos individuais, será lento abrir milhares de arquivos de imagem para cobrir uma área grande e, portanto, você deverá limitar o número de arquivos criando imagens de visão geral que cubram uma área maior. Isso é o que você já tentou fazer criando visões gerais para o buraco VRT com gdaladdo.
Não conheço nenhuma ferramenta pronta no mundo GDAL / MapServer para criar automaticamente pirâmides globais. Você pode converter blocos do VRT global em um conjunto de imagens com tamanho de pixel maior escrevendo um script que execute gdal_translate http://www.gdal.org/gdal_translate.html com um -prowjin ou -srswin deslizante. Em seguida, você pode combinar os blocos resultantes em uma nova camada de visão geral com gdalbuildvrt ou gdaltindex.
Como você também considera o uso do GeoServer, eu recomendaria ter um saque no script gdal_retile http://www.gdal.org/gdal_retile.html escrito para lidar com o seu caso. Também é possível usar os blocos que o gdal_retile cria diretamente como visões gerais do QGIS, construindo VRT sobre eles. No entanto, o primeiro problema com enormes arquivos VRT lentos permaneceria.
fonte
Ok, resolvi ambos os meus problemas ... principalmente comprando um SSD NVMe. A leitura / gravação do meu disco passou de 125 MB / s para 1200 MB / s.
Programaticamente, existem algumas coisas que você pode fazer para ajudar na velocidade de leitura / gravação. Primeiro, considere o tamanho do bloco da sua tiff. Se você estiver usando um tiff com listras, ao ampliar para uma região específica, o software GIS precisará ler cada linha completa da região, incluindo as partes do tiff que não serão exibidas, para exibir a região. Por exemplo, se você aplicar zoom em uma região de 256 x 256 pixels, se tiver um tiff listrado, o software precisará ler pelo menos 256 blocos (um por linha). Se você tiver um tiff lado a lado (lado a lado em 256 x 256), o número máximo de blocos que devem ser lidos é 4 (e no mínimo 1). Portanto, a primeira coisa que você pode fazer é garantir que você esteja usando um mosaico (opção de criação TILED = YES em gdal),
Em segundo lugar, uma abordagem híbrida das visões gerais parece funcionar bem. Se você puder paralelizar suas operações, poderá adicionar visões gerais aos blocos individuais rapidamente, mas isso o beneficiará apenas em resoluções menores que o tamanho do bloco. Criei visões gerais internas dos níveis 2 4 8 16 32 e 64 nos blocos individuais. Em seguida, crie um VRT e crie visões gerais dos níveis 128, 256 e 512 no VRT (lembre-se de que estes são para conjuntos de dados globais com resolução de 30 m - seus níveis mudarão dependendo do número de pixels em sua tiff). O tempo total para criar visões gerais individuais é da ordem de minutos (depende de quantos threads você pode executar e de quantas peças você possui), mas a criação de visões gerais no VRT ainda é da ordem de uma hora. A melhoria do tempo de execução em relação à minha postagem inicial se deve ao SSD e à criação de menos níveis no VRT.
Em terceiro lugar, você pode jogar com a opção GDAL_MAX_DATASET_POOL_SIZE ao criar vrts, conforme descrito na parte inferior desta página . Ele define o número máximo de tiffs para manter na memória de uma só vez.
Em quarto lugar, descobri que a compactação com o PACKBITS fornece os tempos de exibição mais rápidos. Os arquivos não são tão pequenos quanto o LZW, mas é uma troca que você pode estar disposto a fazer.
O resultado é um VRT que carrega rapidamente e amplia / aproxima quase que perfeitamente.
fonte