Does applying r.region to a portion of a large raster map functionally
reduce the size of the map, equivalent to v.clip applied to vector maps?
Because r.mask and g.region constrain analytical area without changing the
size of the raster file my assumption is that r.region behaves differently.
Rich
Hi Rich,
On Wed, Aug 15, 2018 at 5:21 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:
Does applying r.region to a portion of a large raster map functionally
reduce the size of the map,
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?
https://grass.osgeo.org/grass74/manuals/r.region
equivalent to v.clip applied to vector maps?
See r.clip module in addons for equivalent of v.clip:
https://grass.osgeo.org/grass74/manuals/addons/r.clip.html
Best,
Vaclav
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,
Thanks for clarifying. For the manual page it might help to explicitly
explain the difference(s) of r.region from g.region. It looks to me that
they both do the same thing.
See r.clip module in addons for equivalent of v.clip:
https://grass.osgeo.org/grass74/manuals/addons/r.clip.html
Despite my years of sporatic use of grass I did not develop the habit of
checking add-ons when working on a project involving grass. Mea culpa!
You've shown me the need for a behavioral change on my part. Thanks!
Best regards,
Rich
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.
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.
My $2.00's worth,
Rich
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
On Thu, 16 Aug 2018, Moritz Lennert wrote:
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.
Moritz,
This is a really useful explanation and I appreciate finally learning of
these differences. When I'm able to write to the wiki I can add this
information to an existing or new page.
v.region does not exist.
I forgot this.
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".
This distinction also is new to me. It makes sense yet I've not before
been aware of it. When is "name" the preferred choice?
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.
+1
Regards,
Rich