#73: r.out.gdal tiff output does not work --------------------------+------------------------------------------------- Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: | Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --------------------------+------------------------------------------------- Comment (by hamish):
Replying to [comment:24 mmetz]: Hamish: > > AFAIK this is just the setting of a metadata tag (or not), so not > > really editing the raster data at all. As such I don't mind if > > the user decides to set it when it would otherwise not be. > > There's no processing involved. Replying to [comment:24 mmetz]: > This is the same like r.null setnull=nodata. Is this raster > editing? It is not the same because the raster cells are intact. You can "cleanse" away the metadata with {{{ tifftopnm file.gtiff | pnmtotiff > file.tif }}} and the metadata "nodata" tag is gone and your data is as it once was. > Little word missing? "... if you need to realign the region > settings '''to''' the original map's before export." > > Also maybe remove comments on GDAL datatypes just below the > ranges of datatypes, because they are not really necessary? thanks, done. > > -c flag added > Potentially misleading description: "Do not export long > colortable"? A user might wonder whether short colortables > are always exported? they'd be right. Short tables are still written. - Long: Byte and UInt16 maps write out a RGB value for each 256/66536 possible int. - Short: These are the COLOR_TABLE_RULE_RGB_n metadata created by GRASS by copying over the contents of the colr/ file. They are typically 4-5 lines long and work by ranges not per-possibility. I agree it is unpleasant if the user specifies {{{ createopt="PROFILE=BASELINE" }}} for a bare-bones GeoTIFF and GRASS still writes out COLOR_TABLE_RULE metadata anyway. But typically the user will use that flag to avoid the list of 66536 RGB values, not the list of 5 rules. > > The type range limit testing stuff is still TODO. (both data > > max/min and nodata=) > > The min/max values for all integer types are identical to gdal > and AFAIK universally valid. See min/max values in gdal-1.5.2 > gcore/rasterio.cpp. > > As I understand, min/max values for float32 are indirectly > determined in gdal using typecast from double to float. The > min/max values for float32 and float64 as suggested by me > correspond to IEE 754 to my best knowledge. > > Values farthest away from zero have all bits in the mantissa > set and all but the last in the exponent which is equal to > (1 - 1/2^24^) * 2^128^ for float32 and (1 - 1/2^53^) * 2^1024^ > for float64, taken from http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF. thanks for the refs., most useful I notice gdal's gcore/rasterio.cpp has its Int32 min at -2147483647 not -2147483648. That might make a diff if we wanted to use the min as the default nodata value. ?? (or is that < not <= so ok?) > There is a cplusplus style comment in local_proto.h. OK, it's > in a c style comment, but that could be uncommented soon. just a temporary thing, while we sort this out, and less dangerous than a c-comment nested in another c-comment. > In the TODO line 386 rather use GDALGetDataTypeName(datatype) > than type->answer because type is not required and datatype is > known by then. I've copied your comment into my local copy of main.c. > I guess once the type ranges are confirmed the TODOs can be done. right. I'm no expert on when it is best to terminate a big number with "UL", "L", ".0", "f" or use the likes of "(double)(unsigned int)0xFFFFFFFFu" I notice with the current code that if I make a UInt16 map and don't specify a nodata value the G_message reports it defaults to -32768, but this may just be %d speaking, not the variable. Hamish -- Ticket URL: <http://trac.osgeo.org/grass/ticket/73#comment:25> GRASS GIS <http://grass.osgeo.org>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev