#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>