[GRASS-dev] Re: [GRASS GIS] #1424: Profile tool always casts to integers (incl. csv output)

[GRASS GIS]

#1424: Profile tool always casts to integers (incl. csv output)
-------------------------------------+--------------------------------------
 Reporter:  hamish                   |       Owner:  grass-dev@…              
     Type:  defect                   |      Status:  new                      
 Priority:  major                    |   Milestone:  6.4.2                    
Component:  wxGUI                    |     Version:  svn-releasebranch64      
 Keywords:  profile tool, precision  |    Platform:  All                      
      Cpu:  All                      |  
-------------------------------------+--------------------------------------

Comment(by hamish):

 basic patch added to the ticket. But before applying in svn:
  `grass.raster_info(raster)['datatype']`
 should be used to choose export precision based on the raster map's type,
 something like:

 {{{
 @@ -585,9 +585,18 @@
                                    message = _("Unable to open file <%s>
 for writing.") % pfile,
                                    caption = _("Error"), style = wx.OK |
 wx.ICON_ERROR | wx.CENTRE)
                      return False
 +
 +                rast_type = grass.raster_info(raster)['datatype']
 +                if rast_type == 'CELL':
 +                    write_fmt = '%.3f,%d\n'
 +                if rast_type == 'FCELL':
 +                    write_fmt = '%.3f,%.7g\n'
 +                if rast_type == 'DCELL':
 +                    write_fmt = '%.3f,%.15g\n'
 +
                  for datapair in r['datalist']:
 -                    file.write('%d,%d\n' %
 (float(datapair[0]),float(datapair[1])))
 -
 +                    file.write(write_fmt %
 (float(datapair[0]),float(datapair[1])))
 +
                  file.close()

          dlg.Destroy()
 }}}
 (vs trunk; untested)


 ... but why are we doing that at all? for the .csv export why not just re-
 run r.profile and save to the output= file directly, with all the above
 stuff already taken care of? no risk of introducing aliasing or bugs if we
 produce that straight from the source + it would make the code a bit
 simpler.


 a good test for this is to go into Spearfish, and prepare a limited range
 map:
 {{{
 g.region rast=elevation.dem
 r.mapcalc "elev_1k = elevation.dem / 1000.0"
 r.info -r elev_1k
  min=1.066
  max=1.84
 }}}

 then pull that into a lat/long location with r.proj. So both map units
 (decimal degrees) and z-values will show up as obviously wrong if
 something gets cast to an integer.


 Hamish

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/1424#comment:5>
GRASS GIS <http://grass.osgeo.org>