Re: [GRASS-dev] [GRASS GIS] #3931: i.topo.corr: handle integer input for correction

[GRASS GIS]

#3931: i.topo.corr: handle integer input for correction
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Imagery  |Version:  svn-trunk
Resolution:   |   Keywords:  i.topo.corr
   CPU:  All  |   Platform:  All
--+-

Comment (by sbl):

 Little correction, FCELL input is not allowed either, though i.atcorr
 outputs FCELL.


 So, an additional step with r.mapcalc is required to change i.atcorr
 output to DCELL (without gain in precision)...

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #3931: i.topo.corr: handle integer input for correction

[GRASS GIS]

#3931: i.topo.corr: handle integer input for correction
-+-
 Reporter:  sbl  |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:
Component:  Imagery  |Version:  svn-trunk
 Keywords:  i.topo.corr  |CPU:  All
 Platform:  All  |
-+-
 i.topo.corr currently seems to only correct input maps of type DCELL or
 FCELL.

 It would be great if it could handle also integer maps as input. Maybe a
 quantization option, like in i.atcor would be a possibility to scale input
 from 1 - 1 to 0.0 - 1.0 by applying the quantization factor (default
 to 1)?

 I am thinking of e.g. linked (r.external) Sentinel-2 data here, which
 comes with integer values...

 Ideally, also output should be saved as integer if input is integer,
 reapplying the quantization.

 That could save a processing step and would possibly allow to save some
 storage space.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev