[GRASS-user] Virtual mosaics in GRASS?
Blumentrath, Stefan
Stefan.Blumentrath at nina.no
Sun Oct 23 12:08:08 PDT 2016
Hei,
Recently I conducted some solar radiation analysis at national scale. In order to run this efficiently, I tiled the area into ca. 590 tiles of up to 5000x5000 pixels for the relevant (land) area. For reducing the amount of data I truncated the r.sun output to integer with r.mapcalc (map type is now CELL) and the size of the tiles is up to 25MB each.
Currently I am patching the tiles together by day (r.patch). However, this is
a) time consuming and
b) patching the sparse tiles into a coherent raster map roughly triples the amount of storage occupied (due to the relatively large number of NoData pixels in the patched raster map I guess). One patched map is 48 GB, while the sum of the tiles probably is ca. 15 GB. I will try to see which effect NULL-map compression in G7.2 has, but I doubt that it will bring back the storage efficiency of the tiles...
Therefore, I was wondering if it would be of interest and possible to implement a concept similar to GDAL VRT in GRASS (8?)?
A workaround would probably be to use r.external.out (write out tiles to e.g. GeoTIFF) in combination with gdal_buildvrt and r.external. But I would prefer to stick to native GRASS format (amongst others because then data management is more simple in a work flow which is parallelized by day within one single mapset)... I earlier tried to link a GDAL VRT from GRASS data (having the GDAL-GRASS-plugin installed) back to GRASS but encountered the issue that data was written to the mapset where the tiles reside (instead of the current mapset): https://trac.osgeo.org/grass/ticket/2837
No idea how the performance of a linked VRT consisting of hundreds of LZW-compressed GeoTiffs would be...
I would be happy about any hints, comments, or opinions...
Kind regards,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20161023/d91db26a/attachment.html>
More information about the grass-user
mailing list