Cómo evitar rásteres de salida muy grandes utilizando algoritmos de hierba

Question

Yo uso r.cost.points de la GRASS algoritmos en QGIS a crear un acumulado de gastos de viaje mapa que se basa en la fricción de la superficie de ráster. Mi problema es que el archivo de salida es más de 20 veces más grande que el de entrada.

El archivo de entrada es un mapa de bits en .tif formato y 5 MB de tamaño de archivo. El archivo de salida es un .tif así pero tamaño de archivo aumenta a 110 mb.

Yo no entiendo muy bien este aumento, porque ambos tienen la misma extensión, la resolución, el Tipo de Datos (Float64) y el Tipo de archivo.

Los valores almacenados son diferentes: mientras que la fricción mapa contiene sólo pequeñas valores enteros que informar a los gastos de viaje para cruzar una gridcell (que van desde la 1 a la 36), la salida de mapa contiene el acumulado de los gastos de viaje de los valores (que van desde 252-46677.400562602). Pero aún así ambos son Float64 lo que deberían ser comparables en términos de requisitos de espacio AFAIK.

La comparación de las dos Propiedades de los Metadatos, la única diferencia es el No Data Value que es en el caso de que el archivo de entrada -1.7e+308 y en el caso de que el archivo de salida nan...

Mi principal problema ahora es que quiero proceso de un archivo de entrada de 10 GB que causa problemas de espacio, mientras que la salida se crea... ¿alguien Puede explicar por qué se produce este problema y cómo puedo evitar estos aumentos?

Usted puede probar esto en su ordenador con los datos de este ejemplo aquí , ya que la fricción de la superficie y de aquí el origen de la capa que contiene los destinos.

ediciones yo también lo he probado con una versión rasterizada de la capa de origen, pero esto aún crea un Archivo de 98MB.

Yo uso la interfaz gráfica de usuario, pero la orden se ve en la consola como esta.

0   GRASS GIS 7 execution commands
        g.proj -c proj4="+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=-54 +x_0=0 +y_0=0 +ellps=WGS84 +units=m +no_defs"
        r.external input="/home/user/R/R-projects/3_accessibility_map/output/toy_data/2_friction/friction_1.tif" band=1 output=tmp1480016848937 --overwrite -o
        r.external input="/home/user/R/R-projects/3_accessibility_map/output/toy_data/1_rasterized/towns2.tif" band=1 output=tmp1480016848938 --overwrite -o
        g.region n=-1340309.99994 s=-1451939.99994 e=-555477.497208 w=-667107.497208 res=30.0
        r.cost  input=tmp1480016848937 start_raster=tmp1480016848938 -n max_cost="0" null_cost="0" memory="4000" output=output5ae5c0b98f304e92ada91772b870452b --overwrite
        g.region raster=output5ae5c0b98f304e92ada91772b870452b
        r.out.gdal --overwrite -c createopt="TFW=YES,COMPRESS=LZW" input=output5ae5c0b98f304e92ada91772b870452b output="/home/user/Desktop/test2.tif"

hormiga de las primeras líneas de la salida

2016-11-24T20:47:51 0   GRASS GIS 7 execution console output
        Cleaning up temporary files...

        Starting GRASS GIS...

        Executing '/home/user/.qgis2//processing/grass7_batch_job.sh' ...

        WARNING: Datum <unknown> not recognised by GRASS and no parameters found

        Default region was updated to the new projection, but if you have multiple mapsets `g.region -d` should be run in each to update the region from the default

Answer 1

Bien. He jugado con este conjunto de datos. Me podrían identificar los siguientes factores que influyen en la trama de tamaño de archivo en diferentes grados:

1. La extensión geográfica de
2. Resolución
3. Compresión cuando la escritura de los Gtiff
4. La longitud de los valores almacenados
5. La diversidad de valores almacenados

Para averiguar esto, ¿qué factores afectan el tamaño de archivo más, me importan y exportan la salida.tif (110MB) en R con la Rgdal paquete. El archivo no comprimido, aunque la compresión se establece cuando he creado este archivo con r.cost.points en GRASS (que parece ser un error).

Primero he probado diferentes compresiones:

    r.acccost<-raster("output/toy_data/3_acc_cost/acccost_grass_rcost_1.tif")
    writeRaster(r.acccost,"output/toy_data/test1.tif",options=c("COMPRESS=LZMA"),overwrite=T)
    writeRaster(r.acccost,"output/toy_data/test2.tif",options=c("COMPRESS=LZW"),overwrite=T)
    writeRaster(r.acccost,"output/toy_data/test3.tif",options=c("COMPRESS=DEFLATE"),overwrite=T)
    writeRaster(r.acccost,"output/toy_data/test4.tif",options=c("COMPRESS=DEFLATE","ZLEVEL=9"),overwrite=T)

El aplicar compresiones de reducción de mi tamaño entre 5 y 30% dependiendo de la aplica el método de compresión:

• LZW comprimido: 104 MB en lugar de los 110
• LZMA comprimido: 77 MB en lugar de los 110
• DEFLATE comprimido: 75 MB en lugar de los 110 con ambos, ZLEVEL 6 (predeterminado) y 9.

Esto no es suficiente para mí, aunque me gustaría ser capaz de aplicar el método de compresión cuando la ejecución de la r.cost.points algoritmo.

De lo que me convierte todos los valores del Ráster de Valores Enteros que reduce la longitud de los números almacenados. Este procedimiento de reducción de mi filesize a 39 MB. Configuración de options="NBITS=5" para reducir el bitsize no influyen considerablemente en los resultados.

    r.acccost<-setValues(r.acccost,as.integer(getValues(r.acccost)))
    writeRaster(r.acccost,"output/toy_data/test5.tif",overwrite=T)

La última cosa que yo hice fue reducir la diversidad de los números en mi trama. Lo hice por la reclasificación de los valores por encima de la media a 1 y menor o igual a la mediana de la a 2. Este procedimiento de reducción de mi tamaño de archivo de sólo 3.2 MB (!)

    r.acccost3<-setValues(r.acccost,ifelse(getValues(r.acccost)>median(getValues(r.acccost),na.rm=T),1,2))
    writeRaster(r.acccost3,"output/toy_data/test6.tif",overwrite=T)

No sé cómo los rásteres de trabajo de forma interna, pero esto explica también por qué el tamaño de mi entrada de mapa en r.cost.points, con relativamente pocos valores, fue sólo 5MB.

Resumiendo:

Puedo ni cambiar la extensión de la trama ni de la longitud y de la diversidad de valores creados cuando se utiliza r.cost.points. Una opción podría ser la de establecer un valor máximo para travelcosts (max_cost=VALUE) a la hora de crear el mapa. Sin embargo, esto crea un conjunto de datos incompletos. Sería muy deseable para ser capaz de influir en la longitud o la diversidad de valores creados, pero esto es así ahora no es posible (ver opciones de r.el costo). El posterior que sería deseable para una gran cantidad de algoritmos que cuando uno trabaja con grandes rásteres que no son sub-ajustable, debido a la naturaleza de la operación.

Yo podría tratar de hacer que el trabajo de compresión que requeriría más de depuración y podría ser una pérdida de tiempo. Además, me puede disminuir la resolución de la que es actualmente 30meters y, probablemente, la mejor manera de empezar.

Para eso que ya tiene una trama creada y sólo busca decrese tamaño de archivo: además de la extensión y la resolución también puede buscar en: la Compresión, la longitud y la diversidad de los valores almacenados. La diversidad tiene, probablemente, el mayor impacto y puede ser fácilmente reducido si reclasificar su trama... lo que reduce la calidad de los datos, sino que también reduce considerablemente el tamaño de archivo. Si no duele mucho, por ejemplo, 50 clases son mucho mejor que 10000 valores únicos cuando se trata de tamaño de archivo.