[GRASS-user] r.region question

[Moritz Lennert]

On 16/08/18 16:32, Rich Shepard wrote:
> On Wed, 15 Aug 2018, Vaclav Petras wrote:
> 
>> No, r.region changes the "region" of the raster map itself, i.e. changes
>> its extent and resolution. The data stays the same. Its changes the
>> metadata. The effect is stretching, shrinking, or moving the raster map.
>> Any suggestions for improvement of the manual page?
> 
> Vaclav,
> 
>     Let me expand on my previous answer. If g.region is a generic function
> that can use geographic coordinates, names, rasters, and vectors what
> additional purpose is served by r.region and v.region? The same applied to
> g.proj and, probably, other tools.

When working with the raster approach to geographical data, the user has 
to make a (more or less arbitrary) choice on the extent of the zone he 
wishes to work on and on the resolution within that zone. This is what 
g.region allows you to do: it defines the raster grid in which raster 
operations will take place. If your original data does not correspond to 
this grid it will be clipped and resampled to the grids definition.

r.region allows you to redefine the intrinsic characteristics of your 
data. Where g.region defines the grid you want to use for operations, 
r.region allows you to modify the definition of the grid of a particular 
raster map (and it will then be saved in that new definition). This is 
useful, for example, when certain data providers define the cell 
location differently (top left corner of the cell, center of the cell, 
etc), and you have to adapt the data to GRASS' definition. So r.region 
is useful to "correct" a specific raster map's definitions.

v.region does not exist.

g.proj handles projections, so even if there are some similarities it is 
quite different in its objectives and its functioning.

> 
>     I've had a couple of discussions over the years with Markus Neteler on a similar
> issue: the reference to the map which is the focus of a module. Sometimes
> the title is 'map' other times it's 'input' or 'name.' Yes, there are
> probably legacy apps and scripts that use all three, but a global search and
> replace can easily fix that. As grass gains more users I suggest it makes
> sense to move toward consistency. For example, make all key:value pairs for
> the focused data 'input.' Everyone understands that and it prevents looking
> at the manual page for each module to find what it calls the data.
> Especially for those of us who do not spend all day within grass.

The current parameter names are consistent, but you might argue whether 
the solution is the best: "map" is used for modules where one map is 
handled and no output maps are created (r.region is one such example, 
but also v.info, etc). "input" is used for modules which also create 
"output".

Personally, I have no fundamental objection to replace all "map" 
parameters with "input", but this would have to be discussed widely on 
the mailing lists.

Moritz