[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work

[GRASS GIS]

#73: r.out.gdal tiff output does not work
--------------------------+-------------------------------------------------
  Reporter:  helena       |       Owner:  grass-dev at 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 mmetz):

 Replying to [comment:38 hamish]:
 > Pretend you are r.out.gdal iterating through the raster cells to output.
 You come across a NULL cell. You have to write down some value, and are
 completely constrained to options available in the output type. What do
 you write out? Overflow/wrap the type? type min? type max? well (as things
 were) whatever you do is going to be arbirtary, and thus could lead to
 data loss, which is grounds for a most serious blocker bug.

 That would require an additional check that the nodata value is not
 present in the raster band to be exported. This is not too difficult.

 What would be more difficult is to select a nodata value that is not
 present in the raster band to be exported if type min and type max are
 present. Offhand, I can only think of a helper data structure (sorted
 heap/binary tree/hash table) where all raster values without duplicates
 are kept which can consume a lot of memory for large floating point
 rasters. This would also require two passes over each raster band, first
 investigating the values and selecting a proper nodata value, second
 replacing NULLs with this nodata value. Then, what to do if a user-
 specified nodata value is within the range of the selected GDAL data type
 but this value is present in the raster? Give a warning but let the user
 override the check, causing data loss?

 Sorry, I haven't thought about this problem of nodata value causing data
 loss, somehow left this to the user.

 Markus M

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/73#comment:39>
GRASS GIS <http://grass.osgeo.org>