Velocidade de vários formatos de dados raster

Estou tendo problemas para localizar qualquer discussão ou comparação comparativa de diferentes formatos de arquivo raster (por exemplo, para uso na análise de dados em R). Alguém tem alguma idéia de por que determinados formatos podem ser mais rápidos ou mais lentos? Ou as diferenças devem ser mínimas?

Especificamente, estou interessado em saber se a conversão de uma varredura (por exemplo, um arquivo GEOTIFF) para um formato diferente (por exemplo, um netCDF) vale a pena com o objetivo de acelerar a leitura / gravação e outras operações.

Aqui está um artigo antigo do meu blog que analisa o tamanho do arquivo e o tempo de acesso dos formatos. Não investiguei a velocidade de gravação, apenas o tempo de acesso. Eu diria que eles provavelmente estariam diretamente relacionados, mas não seriam capazes de atestar isso.

Resumo do artigo: Parece que o Packbits oferece os melhores tempos de acesso (em detrimento do espaço em disco), enquanto o Deflate fornece tempos de acesso intermediários / lentos para arquivos intermediários / pequenos. Além disso, você pode testar os tempos de acesso de maneira mais empírica, criando miniaturas de vários tamanhos e cronometrando quanto tempo leva. Comando de exemplo:time gdal_translate -outsize <thumbnail dimensions> -of GTiff <compressed image file> <thumbnail file>

Supondo que a única coisa relevante para R nesse caso seja a rapidez com que ele pode ler dados do arquivo, assim como qualquer outro processo faria, isso deve fornecer uma boa indicação.

Para operações de leitura / gravação , você pode testar a velocidade dessas operações usando system.time (). Aqui estão alguns resultados do carregamento de um arquivo DEM no R (pacote Raster) traduzido em quatro formatos (ASCII, IMG e TIF sem compactação e deflação). Por exemplo, em uma varredura de ~ 26 MB:

> system.time(dem <- raster("~/workspace/TEMP/kideporegion.img"))
 user  system elapsed 
 0.154   0.002   0.157 

'Decorrido' fornece o tempo total (segundos) necessário para a operação. Executando as operações 10 vezes cada e observando o tempo médio decorrido:

              mean   diff
ASC         0.2237 0.3317
IMG         0.1544 0.0318
tif-Deflate 0.1510 0.0099
tif-none    0.1495 0.0000
tif-pack    0.1513 0.0118

TIFF sem compressão é o mais rápido ... seguido de perto por Deflate (0,1% mais lento) e TIFF-Packbits (1,8% mais lento), depois IMG (3,2% mais lento) e ASC (33% mais lento). (Este é um MacBook Pro de 2,4 GHz com um SSD, operações de disco tão rápidas)

Isso é simplesmente carregar os arquivos, não manipulá-los.

Talvez não seja realmente uma questão de qual formato de imagem raster tenha melhores benchmarks de abertura - em vez de quais formatos de imagem raster são os formatos de fonte raster mais eficientes para abrir e ler como entrada em um array numérico R. E posteriormente - qual é o formato de saída mais eficiente de R, assumindo que você retornaria os resultados de volta à varredura.

De qualquer forma, se você estiver trabalhando com raster no R, provavelmente usará os pacotes rgdal e R ncdf para complementar o conteúdo do pacote raster . Com confiança principal no comando gdalwarp . Precisa resolver as dependências de formato para fazer sua escolha de varredura. Você encontrará uma boa cobertura sobre SO e vários fóruns / blogs / wiki do OSGEO e R.

Mas como este é um fórum GIS em que o uso do Python está em ascensão relativa, observarei que há vantagens em trabalhar com dados de varredura em uma matriz numpy do Python, com dependência semelhante das bibliotecas gdal para carregamento, conversão e exportação de varredura. Algumas pessoas acham o gerenciamento de memória e a estrutura de código no Python preferíveis ao R nativo - talvez dê uma olhada no RPy2 ou no PypeR, pois elas podem ser apropriadas para o uso da sua análise.

Uma grande questão é se você vai ler a varredura inteira do arquivo na memória antes de processá-lo ou se o arquivo é tão grande que você o processará de forma incremental ou algum subconjunto do arquivo geral.

Se você carregar tudo na memória, estará fazendo o acesso principalmente seqüencial, e o formato mais rápido será um lance entre armazenamento simples e compactado (dependendo de quão rápido sua CPU é versus disco). Qualquer um dos formatos de arquivos binários provavelmente estará bem próximo (o ASCII será mais lento).

Se você precisar processar um subconjunto de um arquivo muito grande, um formato que agrupe o subconjunto que você deseja se aproximar poderá ser mais rápido - por exemplo: blocos ou um formato que possa calcular compensações. Às vezes, abordagens não compactadas ganham aqui porque pode ser trivial calcular onde reside uma parte da imagem no arquivo, especialmente se você precisar de apenas parte de uma linha muito grande, mas a compactação pode ser feita de maneira granular que funciona bem para alguns padrões de acesso.

Desculpe, mas você provavelmente terá que fazer benchmarks, dependendo do seu padrão de acesso, em vez de obter um tamanho único. Obviamente, isso pode depender não apenas do formato do arquivo e dos fatores acima, mas também dos drivers desse formato e do seu software.

A maneira como você pensa sobre esses tipos de problemas é em termos de como seu aplicativo acessa seu arquivo, e de como os dados são dispostos em seu arquivo. A idéia é que, se você puder acessar seus dados sequencialmente, eles serão muito mais eficientes do que se você os acessasse aleatoriamente.

GeoTIFF é uma coleção de "imagens" ou matrizes 2D. O NetCDF é um armazenamento de uso geral para matrizes multidimensionais. Mas se você armazenar as matrizes da mesma maneira no netCDF e no GeoTIFF, obterá o mesmo desempenho, mais ou menos.

Também é possível reorganizar os dados no netCDF, portanto, em princípio, você pode otimizar seus padrões de leitura. Meu palpite é que a maioria dos aplicativos GIS é otimizada para o layout GeoTIFF 2D, portanto, não há muito a ganhar com a reorganização.

Finalmente, eu diria que realmente importa apenas quando você tem arquivos muito grandes, pelo menos dezenas de megabytes.

Li algumas páginas sobre isso há vários anos e, desde então, usei tiff com compressão de bits de bloco, ladrilhado com um cabeçalho geotiff e fiquei feliz.

artigo da equipe arcpad

wiki

Mas depois de ler o seguinte, vou reconsiderar e talvez usar a variedade de esvaziamento.

Site do Arcpad

Muitos pacotes usam GDAL por baixo do capô, por exemplo, rgdal, QGIS, GRASS, etc. Se eu estivesse usando um desses pacotes, pensaria em converter minhas imagens em vrt. Frequentemente, é recomendável que, quando você precisar usar dois comandos GDAL, o arquivo intermediário seja um arquivo vrt porque a sobrecarga de leitura é mínima (por exemplo, http://www.perrygeo.com/lazy-raster-processing -with-gdal-vrts.html ). Parece que seu fluxo de trabalho é: converta uma vez e leia várias vezes. Talvez o vrt seja apropriado.

[Editar: link ajustado]