All I wanted to say is that for best allround compatibility, the GEOTiff
output should be kept as simple as possible. If a raster export is meant
to be used in a particular known application, the native raster file
format of this application if existing might be preferable.
The gdal defaults
Markus Metz pisze:
Nikos Alexandris wrote:
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
(Continued...)
Dear GRASSers,
how do you really export as GeoTiffs your raster maps to view in OpenEV,
QGIS?
I think I solved my problem by removing color tables (as Markus Metz
suggested), exported groups, nodata=- and, very important, setting
in my loop over all groups a g.region rast=$i
Nikos Alexandris wrote:
I think I solved my problem by removing color tables
That doesn't solve the problem, I learned. If you remove the associated
colour table, r.out.gdal writes a completely black colour table.
Applications that read the colour table will consequently show a
completely
Markus,
I appreciate it that you clarify the details.
On Sun, 2008-08-03 at 17:22 +0200, Markus Metz wrote:
Nikos Alexandris wrote:
I think I solved my problem by removing color tables
That doesn't solve the problem, I learned. If you remove the associated
colour table, r.out.gdal writes
Nikos Alexandris wrote:
Markus,
I appreciate it that you clarify the details.
It seems I try but fail. Something is still wrong...
If you remove the associated
colour table, r.out.gdal writes a completely black colour table.
Applications that read the colour table will consequently
Markus Metz wrote:
I think I solved my problem by removing color tables
That doesn't solve the problem, I learned. If you remove the associated
colour table, r.out.gdal writes a completely black colour table.
Applications that read the colour table will consequently show a
completely
[...]
I have one last idea. Type is Byte, but NoData Value=-, out of range
for Byte. Maybe that causes a problem? Can you try with nodata=0, then
NULL cells in the GRASS raster should appear black in the GeoTIFF?
If that fails too, maybe it's the COLOR_TABLE_RULE entries. Then try
data
On Sun, 2008-08-03 at 18:12 +0200, Markus Metz wrote:
So nodata=255 does not mean loss of information?
The red, green, blue channels are 8-bit (2 high 8 = 256, values
counting
from 0 up to 255).
It means that NULL cells in the GRASS raster are replaced with 255 or
the specified
On Sun, 2008-08-03 at 19:32 +0100, Glynn Clements wrote:
Nikos Alexandris wrote:
[...]
If you import data which doesn't contain any nulls, then re-export it,
the nodata= option will typically have no effect, as there aren't any
nulls which need to be converted.
OTOH, if the GRASS raster
Many questions... Thank you in advance, Nikos :-)
Importing RGB tiff's (size: 2500, 2500 --- with INTERLEAVE=PIXEL) in
GRASS' database splits them, as expected, in red, green and blue raster
maps. After MASKing out unwanted areas, how should one export the maps
to end-up with tiff files similar
Nikos Alexandris wrote:
1. Using r.composite and exporting with r.out.gdal gives white as
nodata. Whenever I set nodata=0 I don't get a viewable photo
Weird, it might have something to do with exporting a composite, it
should work on single bands and groups.
3. GeoTiff metadata are lost
Markus,
thank you for your precious time. See below some comments.
On Sat, 2008-08-02 at 15:53 +0200, Markus Metz wrote:
Nikos Alexandris wrote:
1. Using r.composite and exporting with r.out.gdal gives white as
nodata. Whenever I set nodata=0 I don't get a viewable photo
Weird, it
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
Forgot to cc...
Sorry for the sloppy looking up, here is the solution for INTERLEAVE=PIXEL.
It is only supported for mulitband images, exporting or translating a
single band will always give INTERLEAVE=BAND. A look at the gdal source
code told me that this is apparently a gdal feature, not a
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:
Thank you for you patience :-)
On Sat, 2008-08-02 at 21:14 +0200, Markus Metz wrote:
Forgot to cc...
Sorry for the sloppy looking up, here is the solution for INTERLEAVE=PIXEL.
It is only supported for mulitband images, exporting or translating a
single band will always give
By the way, what is the correct nodata value for a Byte image? I
mean, won't I loose information if I give nodata=0 to my RGB aerial
photos? And the default nodata=255 is not exactly convenient I think.
On Sat, 2008-08-02 at 12:17 -0700, Dylan Beaudette wrote:
I am glad that this topic is
On 02/08/08 21:17, Dylan Beaudette wrote:
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.
+1
Moritz
___
[...]
What does INTERLEAVE say here? Did you try INTERLEAVE=PIXEL here?
Band 1 Block=2500x1 Type=Byte, ColorInterp=Red
Metadata:
COLOR_TABLE_RULES_COUNT=1
COLOR_TABLE_RULE_RGB_0=0.00e+00 2.55e+02 0 0 0 255 255 255
Band 2 Block=2500x1 Type=Byte, ColorInterp=Green
I think exporting colour tables is one big problem [also see 3, 4]:
GeoTIFFs exported from GRASS suddenly became readable after deleting the
colour table before exporting (my own fiddling around). IMHO, there
should be an option to export colour tables with default to no. There
should also be
21 matches
Mail list logo
