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
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
