>can you zoom a little bit so that the region is smaller than the raster >and then export with r.out.gdal to see whether it is still black? >Are you also getting warning about nulls in the data even if there >are none? >I think there is a bug in the program (and it also does not let you set >the number of decimal digits so it produces numbers with large number >of digits that are useless).
>thanks, Helena Helena, Zooming in to a smaller region than the raster doesn't change the results. I do get warnings about nulls, but it seems to make sense given the shape of the data I'm working with relative to the region. I exported a series of tiffs using r.out.gdal today, using type=Byte and type=UInt16. ArcGIS 9.2 was able to load the UInt16 tiffs, although very, very slowly. The elevation.10m raster from Spearfish took about 2 minutes to load, and it was only 5.6MB in size. The long loading time was due to the enormous size of the color table: 65,536 (2^16) colors. I can't imagine how long it would take Arc to load a 200MB tiff with this many colors. It would probably crash. All of the Byte tiffs were red. A look at the color table in Arc showed that all of the 255 colors were a repeating pattern of white-to-red (i.e., 0-31, 32-63, etc.), with no green or blue colors. I've never had a problem with the output from r.out.tiff, using it for 6 years now. I can view these tiffs in every image viewer and GIS on both Linux and Windows. I imagine the reason for this is the relatively simplified color tables in r.out.tiff tiffs? I would be great if there was a way to get georeferencing information installed in the headers of tiffs created from r.out.tiff. The output from r.out.gdal seems to be either way too detailed, or not mapped properly into a 255 color space. Has anyone had success using the type=Byte in r.out.gdal to get consistently good output for use in other GIS? ~ Eric. _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
