velocidad de varios formatos de datos raster

24

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

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

    
pregunta George 02.09.2011 - 17:27

7 respuestas

9

Aquí hay un viejo artículo de blog en el que veo el tamaño del archivo. Y tiempo de acceso de los formatos. No investigué la velocidad de escritura, solo el tiempo de acceso. Yo diría que probablemente estarían directamente relacionados, pero no serían capaces de 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 intermedio / lento para archivos intermedios / pequeños. Además, puede probar los tiempos de acceso de forma más empírica mediante la creación de miniaturas de varios tamaños y el tiempo que demora. Ejemplo de comando: time gdal_translate -outsize <thumbnail dimensions> -of GTiff <compressed image file> <thumbnail file>

Suponiendo que lo único relevante para R en este caso es la rapidez con la que puede leer los datos del archivo, tal como lo haría cualquier otro proceso, eso debería darle una buena indicación.

    
respondido por el R Thiede 03.09.2011 - 12:14
6

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

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

'Transcurrido' indica el tiempo total (segundos) tomado para 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 es en un Macbook Pro de 2.4 GHz con un SSD, por lo que las operaciones de disco son rápidas)

Esto es simplemente para cargar los archivos, no para manipularlos.

    
respondido por el Simbamangu 08.12.2011 - 22:05
4

Tal vez no sea realmente una cuestión 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 se enviarán los resultados al ráster?

De cualquier manera, si va a trabajar con ráster en R, probablemente estará usando rgdal y R ncdf para complementar lo que se encuentra en la R Paquete de raster . Con la dependencia principal en el comando gdalwarp . Necesita trabajar con las dependencias de formato para hacer su elección de ráster. Encontrará un poco de cobertura en SO y varios foros / blogs / wiki OSGEO y R.

Pero como este es un foro GIS donde el uso de Python es relativamente ascendente, observare que hay ventajas al trabajar con datos raster en una matriz numpy de Python, con una dependencia similar de las bibliotecas gdal para la carga, conversión y conversión de raster exportar. Algunas personas consideran preferible la administración de la memoria y la estructura del código en Python en lugar de la R nativa. Tal vez eche un vistazo a RPy2 o PypeR según sea apropiado para su uso de análisis.

    
respondido por el V Stuart Foote 03.09.2011 - 23:17
3

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

Si lo cargará todo en la memoria, entonces estará haciendo un acceso mayormente secuencial, y el formato más rápido será una recuperación entre el almacenamiento simple y el comprimido (dependiendo de qué tan rápido sea su CPU frente al disco). Es probable que cualquiera de los formatos de archivos binarios esté bastante cerca (ASCII será más lento).

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

Lo sentimos, pero es probable que tenga que realizar una prueba comparativa según su 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.

    
respondido por el Zeph 18.09.2015 - 03:20
2

La forma en que piensa acerca de 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 de forma secuencial, será mucho más eficiente que si lo hace de forma aleatoria.

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

Uno también puede 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 GIS están optimizadas para el diseño GeoTIFF 2D, por lo que no hay mucho que ganar al reorganizarlas.

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

    
respondido por el John Caron 08.12.2011 - 03:20
1

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

artículo del equipo de arcpad

wiki

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

sitio Arcpad

    
respondido por el Brad Nesom 02.09.2011 - 23:21
1

Muchos paquetes usan GDAL bajo el 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 se recomienda que cuando necesite usar dos comandos GDAL, entonces el archivo intermedio debería ser un archivo vrt porque la sobrecarga de lectura es mínima (por ejemplo, enlace ). Parece que su flujo de trabajo es: convertir una vez y leer muchas veces. Tal vez vrt sería apropiado.

[Editar: enlace ajustado]

    
respondido por el user55937 17.09.2015 - 04:27

Lea otras preguntas en las etiquetas