[GRASS-user] GRASS export GeoTiff adventure :-)

Markus Metz markus_metz at gmx.de
Sat Aug 2 14:43:10 EDT 2008



Nikos Alexandris wrote:
>>> 3. GeoTiff metadata are lost always (?) while exporting with
>>> r.out.gdal.  
>>>       
>> Also when checking with gdalinfo?
>>     
> No, I was talking about a known error [1]. How important is this error?
>   
Oh, it is the colour table! That caused me headache too. Some viewers 
don't like built-in colour table, so they should be deleted before using 
r.out.gdal with r.colors -r. Colour tables are not too big when using 
BYTE as output type (max 255 entries), but they can become too big 
(thousands or millions of entries) with any bigger output type. AFAIK 
r.out.gdal only supports colour table export for BYTE and UINT16. In 
case of imagery, colour tables are not important anyway. It can be 
different if I have a raster with painfully developed categories/classes 
and would really like that other people use the same colour table like me.
>>> 4. The createopt="INTERLEAVE=PIXEL" is not respected by r.out.gdal (?)  
>>>       
> Well, the original photos are "INTERLEAVE=PIXEL" and I suppose, from
> what I read, it's a requirement for "limited" viewers (!) [2][3].
> Exporting single maps gives "INTERLEAVE=BAND"!
>   
Same here, I exported a single map using "INTERLEAVE=PIXEL" and get 
"INTERLEAVE=BAND"
Then I used gdal_translate -co "INTERLEAVE=PIXEL"  and still get 
"INTERLEAVE=BAND", no warning message, nothing. This is a gdal problem 
or I missed something in the documentation. Unfortunately, I don't have 
a "limited" viewer to test it, only open source stuff using gdal and 
there it works...

>>> 6. Is it better to export the red, green and blue GRASS raster maps
>>> one-by-one and merge them with gdal_translate (or gdal_merge.py)?  
>>>       
>> If I want a RGB GeoTIFF, I rather export the group.
>>     
> What about the error message "ERROR 6: SetColorTable() not supported for
> multi-sample TIFF files." which appears 3 times for a group that
> contains 3 maps (red, green and blue in our case)?
>   
See r.out.gdal man page: ... "the message can be ignored." What happened 
is that r.out.gdal tried to export a colour table, but couldn't, which 
might be better anyway. Colour tables are not crucial for imagery 
anyway, and it might be safer not to export a colour table. Actually it 
would be nice to have this as an option in r.out.gdal: export colortable 
yes/no
> Exporting a group gives "correctly" something like:
> [...]
> Band 1 Block=2500x1 Type=Byte, ColorInterp=Red
>   Metadata:
>     COLOR_TABLE_RULES_COUNT=1
>     COLOR_TABLE_RULE_RGB_0=0.000000e+00 2.550000e+02 0 0 0 255 255 255
> Band 2 Block=2500x1 Type=Byte, ColorInterp=Green
>   Metadata:
>     COLOR_TABLE_RULES_COUNT=1
>     COLOR_TABLE_RULE_RGB_0=0.000000e+00 2.550000e+02 0 0 0 255 255 255
> Band 3 Block=2500x1 Type=Byte, ColorInterp=Blue
>   Metadata:
>     COLOR_TABLE_RULES_COUNT=1
>     COLOR_TABLE_RULE_RGB_0=0.000000e+00 2.550000e+02 0 0 0 255 255 255
>   
BLOCKXSIZE and BLOCKYSIZE affect tiles, they have no effect if not used 
with TILES=YES. Default is TILED=NO, files are by default stripped 
giving blocks of, in your case 2500x1. Translating a stripped file with 
TILES=YES gives you Block=256x256 (default gdal values). So I think 
there is nothing wrong with it, it matches the original photos anyway.
> Maciek suggested to compress the overviews to save disk space. Would
> this cause a viewing problem in Arc? (Have no access to any commercial
> package currently).
>   
Don't create overviews in this case. And yes, there can well be problems 
with ESRI products, they are not that good in raster handling. ArcGIS 
9.2+ uses gdal (says http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal), 
there should not be a problem. ArcView on the other hand I don't know. 
It might work without colour table, TFW=YES,and a not too fancy data 
type. Why not using ESRI .hdr labelled (gdal code: EHdr) in this case?
> [1] "Warning 1: Lost metadata writing to GeoTIFF ... too large to fit in
> tag.": The color table metadata are too large. It is recommended to use
> a different output format.
>
> More in the manual of r.out.gdal:
> http://grass.osgeo.org/grass64/manuals/html64_user/r.out.gdal.html
>
> [2] http://www.gdal.org/frmt_gtiff.html under section "Creation Options"
>
> [3]
> http://gfoss.blogspot.com/2008/06/gdal-raster-data-tips-and-tricks.html
> under section "Export to (limited) TIFF readers such as ArcView, or
> ImageMagick"
>
>   


More information about the grass-user mailing list