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

[GRASS GIS]

#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 mmetz):

 Replying to [comment:4 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?

 I can't see a caveat, for consistency it makes sense to use the new -r
 flag of r.in.gdal with extent=region.

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