[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