[GRASS-dev] [GRASS GIS] #3374: r.import inconsistent behavior when using r.in.gdal and r.proj

GRASS GIS trac at osgeo.org
Tue Jul 18 14:46:14 PDT 2017


#3374: r.import inconsistent behavior when using r.in.gdal and r.proj
--------------------------+-----------------------------------------
  Reporter:  annakrat     |      Owner:  grass-dev@…
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  7.4.0
 Component:  Raster       |    Version:  svn-trunk
Resolution:               |   Keywords:  r.import, r.in.gdal, r.proj
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-----------------------------------------

Comment (by annakrat):

 Replying to [comment:3 mmetz]:
 >
 > You would at least need to add the resampling methods of r.resamp.stats:
 >
 > {{{
 > average, median, mode, minimum, maximum, range, quart1, quart3, perc90,
 sum, variance, stddev, quantile, count, diversity
 > }}}
 >
 > add explanations about which method is appropriate for which combination
 of the kind of input data and the direction of resolution change
 (upsampling or downsampling) and modify r.import to use r.resamp.stats if
 need be.
 >
 > If the input CRS matches the location's CRS, I would rather have an
 important message that the raster is imported as is and resampling can be
 done with with any of the r.resamp.* modules.

 OK, fair enough. Do we agree on the first point - incorporating the -r
 flag of r.in.gdal or is there some caveat?

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3374#comment:4>
GRASS GIS <https://grass.osgeo.org>



More information about the grass-dev mailing list