[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 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.

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