To specify multiple creation options use a comma separated list (createopt="TFW=YES,COMPRESS=DEFLATE").
For possible createopt and metaopt parameters please consult the individual supported formats pages on the GDAL website. The createopt parameter may be used to create TFW or World files ("TFW=YES","WORLDFILE=ON").
r.out.gdal also supports the export of multiband rasters as a group, when the imagery group's name is entered as input. (created imagery groups with the i.group module)
As with most GRASS raster modules, the current region extents and region resolution are used, and a MASK is respected if present. Use g.region's "align=", or "raster=" options if you need to realign the region settings to match the original map's before export.supported raster formats written by r.out.gdal depends on the local GDAL installation, printed with the -l flag. Available may be (incomplete list):
AAIGrid: Arc/Info ASCII Grid BMP: MS Windows Device Independent Bitmap BSB: Maptech BSB Nautical Charts DTED: DTED Elevation Raster ELAS: ELAS ENVI: ENVI .hdr Labelled FIT: FIT Image GIF: Graphics Interchange Format (.gif) GTiff: GeoTIFF HDF4Image: HDF4 Dataset HFA: Erdas Imagine Images (.img) JPEG2000: JPEG-2000 part 1 (ISO/IEC 15444-1) JPEG: JPEG JFIF MEM: In Memory Raster MFF2: Atlantis MFF2 (HKV) Raster MFF: Atlantis MFF Raster NITF: National Imagery Transmission Format PAux: PCI .aux Labelled PCIDSK: PCIDSK Database File PNG: Portable Network Graphics PNM: Portable Pixmap Format (netpbm) VRT: Virtual Raster XPM: X11 PixMap Format
Out of the GDAL data types, the closest match for GRASS CELL, FCELL and DCELL rasters are respectively Int32, Float32 and Float64. These are not exact equivalents, but they will preserve the maximum possible data range and number of decimal places for each respective GRASS raster data type. Please keep in mind that not all CELL rasters will require Int32 - e.g., 0-255 CELL raster are covered by the Byte type as well. Moreover, some GDAL-supported formats do not support all the data types possible in GDAL and GRASS. Use r.info to check the data type and range for your GRASS raster, refer to specific format documentation (on the GDAL website), format vendor's documentation, and e.g. the Wikipedia article Typical boundaries of primitive integral types for details.
GDAL data type minimum maximum Byte 0 255 UInt16 0 65,535 Int16, CInt16 -32,768 32,767 UInt32 0 4,294,967,295 Int32, CInt32 -2,147,483,648 2,147,483,647 Float32, CFloat32 -3.4E38 3.4E38 Float64, CFloat64 -1.79E308 1.79E308
If there is a need to keep file sizes small, use the simplest data type covering the data range of the raster(s) to be exported, e.g., if suitable use Byte rather than UInt16; use Int16 rather than Int32; or use Float32 rather than Float64. In addition, the COMPRESS createopt used can have a very large impact on the size of the output file.
Some software may not recognize all of the compression methods available for a given file format, and certain compression methods may only be supported for certain data types (depends on vendor and version).
If the export settings are set such that data loss would occur in the output file (i.e, due to the particular choice of data type and/or file type), the normal behaviour of r.out.gdal in this case would be to issue an error message describing the problem and exit without exporting. The -f flag allows raster export even if some of the data loss tests are not passed, and warnings are issued instead of errors.
r.out.gdal exports may appear all black or gray on initial display in other GIS software. This is not a bug of r.out.gdal, but often caused by the default color table assigned by that software. The default color table may be grayscale covering the whole range of possible values which is very large for e.g. Int32 or Float32. E.g. stretching the color table to actual min/max would help (sometimes under symbology).gdaladdo after exporting can speed up display. The overviews are created internally within the exported file. The amount of levels (power-of-two factors) are controlled with the overviews parameter. The higher the overview level defined by the user the more lower resolution internal overviews are added Note that other software might create their own overviews, ignoring existing overviews.
When writing out multi-band GeoTIFF images for users of ESRI software or ImageMagick, the interleaving mode should be set to "pixel" using createopt="INTERLEAVE=PIXEL". BAND interleaving is slightly more efficient, but not supported by some applications. This issue only arises when writing out multi-band imagery groups.
Here are some things to try:
Cloud Optimized GeoTIFFs (COG) can be created with the creation options createopt=TILED=YES,COMPRESS=DEFLATE, followed by gdaladdo to build overviews.
g.region raster=basin_50K -p r.out.gdal input=basin_50K output=basin_50K.tif
g.region raster=elevation -p r.out.gdal in=elevation output=elevation.tif createopt="PROFILE=GeoTIFF,TFW=YES"
g.region raster=elevation -p r.out.gdal in=elevation output=elevation.tif createopt="COMPRESS=DEFLATE"
g.region raster=elevation -p # overviews=5 corresponds to 'gdaladdo ... 2 4 8 16 32' r.out.gdal in=elevation output=elevation.tif createopt="COMPRESS=DEFLATE" overviews=5
i.group group=nc_landsat_rgb input=lsat7_2002_30,lsat7_2002_20,lsat7_2002_10 g.region raster=lsat7_2002_30 -p r.out.gdal in=nc_landsat_rgb output=nc_landsat_rgb.tif type=Byte \ createopt="PROFILE=GeoTIFF,INTERLEAVE=PIXEL,TFW=YES"
g.region raster=elevation -p r.out.gdal input=elevation output=elelevation.img format=HFA type=Float32
g.list group i.group group=tm7 subgroup=tm7 input=tm7_10,tm7_20,tm7_30,tm7_40,tm7_50,tm7_60,tm7_70 i.group -l tm7 g.region raster=tm7_10 -p r.out.gdal tm7 output=lsat_multiband.tif gdalinfo lsat_multiband.tif
When exporting data with r.out.gdal, assigning a nodata value (specific parameter of the module) means that any band values equal to this nodata value will be interpreted as nodata. Using an additional alpha channel means that all pixels with an alpha value of 0 are transparent. The alpha channel thus represents per-pixel encoding of nodata, just like the GRASS MASK (null file). That means when using an alpha channel, you do not need to "free up" any particular value, but you can use any value you like to replace NULL cells, as long as the value can be represented by the Byte data type. It does not matter if that value is already present in any of the input bands.
Hence for "visual-only" RGB data export it is needed to create an additional alpha channel that encodes all NULL cells and in the RGB bands to be exported replace NULL cells with some value in the range 0-255. For example:
# for simplicity variables are used RMAP="lsat7_2000_30" GMAP="lsat7_2000_20" BMAP="lsat7_2000_10" OUTNAME="lsat7_2000_RGBA.tif" # extract alpha r.mapcalc "out_a = if(isnull($RMAP) || isnull($GMAP) || isnull($BMAP), 0, 255)" # replace NULL cells with a valid value, extract colors # exporting 8 bit RGB data, not GIS data, therefore the `#` operator: r.mapcalc "out_r = if(isnull($RMAP), 0, #$RMAP)" r.mapcalc "out_g = if(isnull($GMAP), 0, #$GMAP)" r.mapcalc "out_b = if(isnull($BMAP), 0, #$BMAP)" # create group for export i.group group=out_rgba input=out_r,out_g,out_b,out_a # remove any MASK because this works only if there are # no NULL cells in the bands to be exported r.mask -r # export the group: # add PROFILE=BASELINE to createopt to produce a standard TIFF file # without any GTiff extensions r.out.gdal input=out_rgba output=$OUTNAME -cm createopt="PHOTOMETRIC=RGB,ALPHA=YES" gdalinfo $OUTNAME
Last changed: $Date: 2019-01-15 01:57:42 -0800 (Tue, 15 Jan 2019) $
© 2003-2019 GRASS Development Team, GRASS GIS 7.6.2svn Reference Manual