Velocidad de varios formatos de datos ráster

25

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.

Jorge
fuente
2
Esta pregunta es relevante para SIG, pero sospecho que es más probable que obtenga respuestas sobre SO, que tiene una fuerte subcomunidad de expertos en R. Si no obtiene una respuesta rápidamente, marque esta pregunta y un moderador la migrará por usted.
whuber

Respuestas:

9

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.

R Thiede
fuente
+1 para el artículo vinculado, pero la información importante está fuera del sitio y se perderá si esa página se cae o se mueve. Sugiero dar una conclusión resumida del artículo para que, en caso de que la página no esté disponible, incluso momentáneamente, los lectores tengan algo con qué trabajar para futuras investigaciones y reflexiones. ¡Gracias!
Matt wilkie
¡Lo suficientemente justo! 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 <dimensiones en miniatura> -of GTiff <archivo de imagen comprimido> <archivo en miniatura>"
R Thiede
1
¡Gracias! Doblé el resumen en la respuesta en sí, para que sea más autónomo (vea el enlace de edición en la parte inferior izquierda de cada respuesta / pregunta).
Matt wilkie
@RThiede tenía una preocupación válida: ¿parece que ahora el enlace al blog ya no es válido?
Matifou
@RThiede Su enlace está muerto, ¿puede proporcionar uno nuevo?
Majid Hojati
6

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.

Simbamangu
fuente
4

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.

V Stuart Foote
fuente
Para manipular datos de netCDF (fuente ráster o de otro tipo) en R, aquí hay enlaces a dos paquetes de netCDF alojados en R CRAN, ncdf4 - cran.r-project.org/web/packages/ncdf4/index.html y RNetCDF - cran. r-project.org/web/packages/RNetCDF/index.html
V Stuart Foote
4

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.

Zeph
fuente
2

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.

John Caron
fuente
+1 para el punto en que el acceso aleatorio, o la lectura de una ubicación arbitraria, es muy diferente de una secuencial una tras otra hasta que todo el archivo se haya leído. Puede que esté fuera de la base, pero creo que Geotiff también admite el almacenamiento en mosaico y el acceso arbitrario, es solo que por tira / fila es el más común y ampliamente compatible. Además, en la actualidad, los "archivos muy grandes" en SIG tienden a estar en el rango de varios GB. ;-)
matt wilkie
2

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

Brad Nesom
fuente
2

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]

usuario55937
fuente