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

[Dylan Beaudette]

I am glad that this topic is getting some traction again. I have
noticed that r.out.gdal does not always produce images readable in
ESRI products. Heck, sometime the resulting TIFF would not even be
readable by QGIS. This was some time ago, and associated with several
blog postings / trac tickets:

Posts:
1. http://casoilresource.lawr.ucdavis.edu/drupal/node/337
2. http://gfoss.blogspot.com/2008/06/gdal-raster-data-tips-and-tricks.html

Ticket:
3. http://trac.osgeo.org/grass/ticket/73

It would be a good idea to get this fixed in GRASS64 before marching
into GRASS7 as import/export operations are fundamental to GIS work.

Cheers,

Dylan



On Sat, Aug 2, 2008 at 11:43 AM, Markus Metz <markus_metz at gmx.de> wrote:
>
>
> 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"
>>
>>
>
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>