Velocidad de varios formatos de datos ráster

Tengo problemas para localizar cualquier discusión o evaluación comparativa de diferentes formatos de archivo ráster (por ejemplo, para usar en el análisis de datos en R). ¿Alguien tiene alguna idea de por qué formatos particulares pueden ser más rápidos o más lentos? ¿O deberían las diferencias ser mínimas?

Específicamente, me interesa saber si la conversión de un ráster (por ejemplo, un archivo GEOTIFF) a un formato diferente (por ejemplo, un netCDF) vale la pena con el fin de acelerar la lectura / escritura y otras operaciones.

Aquí hay un artículo de blog antiguo que analiza el tamaño del archivo y el tiempo de acceso de los formatos. No investigué la velocidad de escritura, solo el tiempo de acceso. Diría que probablemente estarían directamente relacionados, pero no podrían responder por ello.

Resumen del artículo: Parece que Packbits le brinda los mejores tiempos de acceso (a expensas del espacio en disco), mientras que Deflate le brinda tiempos de acceso intermedios / lentos para archivos intermedios / pequeños. Además, puede probar los tiempos de acceso de forma más empírica creando miniaturas de varios tamaños y cronometrando cuánto tiempo lleva. Comando de ejemplo:time gdal_translate -outsize <thumbnail dimensions> -of GTiff <compressed image file> <thumbnail file>

Suponiendo que lo único relevante para R en este caso es qué tan rápido puede leer los datos del archivo, como lo haría cualquier otro proceso, entonces eso debería darle una buena indicación.

Para las operaciones de lectura / escritura , puede probar la velocidad de esas operaciones utilizando system.time (). Estos son algunos resultados de cargar un archivo DEM en R (paquete ráster) traducido a cuatro formatos (ASCII, IMG y TIF sin compresión y desinflar). Por ejemplo, en un ráster de ~ 26 MB:

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

'Transcurrido' da el tiempo total (segundos) que se tarda en la operación. Ejecutando las operaciones 10 veces cada una y observando el tiempo medio transcurrido:

              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 sin compresión es el más rápido ... seguido muy de cerca por Deflate (0.1% más lento) y TIFF-Packbits (1.8% más lento), luego IMG (3.2% más lento) y ASC (33% más lento). (Esto está en un Macbook Pro 2.4 GHz con un SSD, operaciones de disco tan rápidas)

Esto es simplemente para cargar los archivos, no manipularlos.

Tal vez no se trate de qué formato de imagen ráster tiene mejores puntos de referencia de apertura, sino qué formatos de imagen ráster son los formatos de fuente ráster más eficientes para abrir y leer como entrada en una matriz numérica R. Y posteriormente, ¿cuál es el formato de salida más eficiente de R, suponiendo que devolvería los resultados a la trama?

De cualquier manera, si va a trabajar con ráster en R, probablemente usará los paquetes rgdal y R ncdf para complementar lo que está contenido en el paquete ráster R. Con dependencia principal en el comando gdalwarp . Necesita resolver dependencias de formato allí para hacer su elección de trama. Encontrará una buena cobertura en SO y en varios foros / blogs / wiki de OSGEO y R.

Pero como este es un foro SIG donde el uso de Python está en relativa ascendencia, notaré que hay ventajas al trabajar con datos ráster en una matriz numpy de Python, con una dependencia similar en las bibliotecas de gdal para la carga, conversión y exportación de ráster. Algunas personas consideran que la gestión de la memoria y la estructura del código en Python son preferibles a la R nativa; quizás eche un vistazo a RPy2 o PypeR , ya que puede ser apropiado para su uso de análisis.

Una gran pregunta es si va a leer todo el ráster del archivo en la memoria antes de procesarlo, o si el archivo es tan grande que lo procesará de forma incremental, o procesará algún subconjunto del archivo general.

Si lo cargará todo en la memoria, tendrá acceso secuencial en su mayoría, y el formato más rápido será un cambio entre el almacenamiento simple y el comprimido (dependiendo de qué tan rápido sea su CPU frente al disco). Cualquiera de los formatos de archivo binario probablemente estará bastante cerca (ASCII será más lento).

Si necesita procesar un subconjunto de un archivo muy grande, entonces un formato que agrupe el subconjunto que desee más cerca puede ser más rápido, por ejemplo: mosaicos o un formato que pueda calcular las compensaciones. A veces, los enfoques sin comprimir ganan aquí porque puede ser trivial calcular dónde reside una parte determinada de la imagen dentro del archivo, especialmente si solo necesita parte de una fila muy grande, pero la compresión se puede hacer de forma granular que funciona bien para algunos patrones de acceso.

Lo sentimos, pero es probable que tengas que hacer una referencia en función de tu patrón de acceso, en lugar de obtener una talla única para todos. Por supuesto, puede depender no solo del formato de archivo y los factores anteriores, sino también de los controladores para ese formato y su software.

La forma en que piensa sobre este tipo de problemas es en términos de cómo su aplicación accede a su archivo, en comparación con cómo se presentan los datos en su archivo. La idea es que si puede acceder a sus datos secuencialmente, será mucho más eficiente que si accede a ellos de manera aleatoria.

GeoTIFF es una colección de "imágenes" o matrices 2D. NetCDF es un almacenamiento de propósito general para matrices multidimensionales. Pero si almacena las matrices de la misma manera en netCDF que en GeoTIFF, obtendrá el mismo rendimiento, más o menos.

También se pueden reorganizar los datos en netCDF, por lo que, en principio, podría optimizar sus patrones de lectura. Supongo que la mayoría de las aplicaciones SIG están optimizadas para el diseño GeoTIFF 2D, por lo que no hay mucho que ganar reorganizando.

Finalmente, diría que realmente solo importa cuando tienes archivos muy grandes, al menos decenas de megabytes.

Leí un par de páginas sobre esto hace varios años y desde entonces he usado tiff con compresión de paquetes, mosaico con un encabezado geotiff, y he estado feliz.

artículo del equipo de arcpad

wiki

Pero después de leer lo siguiente, reconsideraré y tal vez use la variedad desinflar.

Sitio de Arcpad

Muchos paquetes usan GDAL debajo del capó, por ejemplo, rgdal, QGIS, GRASS, etc. Si estuviera usando uno de esos paquetes, entonces pensaría en convertir mis imágenes a vrt. A menudo he visto que recomienda que cuando necesite usar dos comandos GDAL, el archivo intermedio sea un archivo vrt porque la sobrecarga de lectura es mínima (por ejemplo, http://www.perrygeo.com/lazy-raster-processing -with-gdal-vrts.html ). Parece que su flujo de trabajo es: convertir una vez y leer muchas veces. Quizás vrt sería apropiado.

[Editar: enlace ajustado]