[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:2 annakrat]:
 > Replying to [comment:1 mmetz]:
 > > Replying to [ticket:3374 annakrat]:
 > > > Module r.import has options for output resolution and extent, but
 they are basically ignored when coordinates system matches and r.in.gdal
 is used, they are used only when reprojecting. So when there is no
 reprojection needed:
 > > >
 > > > 1. r.in.gdal has new -r flag, so that should be used if
 extent=region
 > > > 2. when resolution=value or resolution=region, r.import should
 resample the raster. The default (resolution=estimated) means r.in.gdal
 uses resolution of the raster as it is now.
 > > >
 > > > Any objection to this behavior?
 > >
 > > The purpose and intention of [r|v].import is easy import of GIS data
 with optional reprojection. I suggest to have a minimalistic interface for
 the two modules and refer to other modules if more control over the import
 process is needed.
 >
 > I am not suggesting more complicated interface, I just want the
 interface to behave consistently. Or are you suggesting simplification of
 the current interface?
 >
 > From my perspective, everybody (including power users) likes 'easy
 import'. Importing and reprojection in one step is a huge step towards
 making GRASS accessible to beginners. I don't see anything wrong with
 having more control over importing with r.import as long as defaults are
 reasonable. I understand that we don't want people to blindly use default
 nearest neighbor resampling when they should be using bicubic, but on the
 other hand, without r.import, a lot of people would be stuck, or they
 would check 'override projection' and end up with nonsense (which happens
 quite a bit at least in my experience).
 >
 > >
 > > There are a number of r.resamp.* modules available. The appropriate
 module and method depends on both the kind of input data (categorical,
 nominal, metric) and the kind of resampling (upsampling or downsampling).
 IMHO it would be safer to leave this decision to the user.
 >
 > Yes, that's what I want, in this case we would just use the resampling
 method selected in resample option. If users keep defaults, nothing
 changes in the processing, here I talk only about situations when user
 specifes extent=region and resolution=value or resolution=region.
 >
 > Regarding the resampling, we could have a warning when they use nearest
 neighbor but the raster is floating point.

 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.

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