Re: [GRASS-user] r.region question
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 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.region question
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 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.region question
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 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.region question [RESOLVED]
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 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.region question
Hi Rich, On Wed, Aug 15, 2018 at 5:21 PM, Rich Shepard 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 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
