It’s been awhile since I’ve done this but I thought I remembered that a new map created with r.copy is constrained by the computational region. That does not seem to the case, at least in 8.4 dev. Maybe it has been this way for awhile (long while?) and I didn’t notice it.
Michael
C. Michael Barton
Associate Director, School of Complex Adaptive Systems (https://scas.asu.edu)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA
On March 2, 2024 1:00:23 AM GMT+01:00, Michael Barton via grass-dev <grass-dev@lists.osgeo.org> wrote:
It's been awhile since I've done this but I thought I remembered that a new map created with r.copy is constrained by the computational region. That does not seem to the case, at least in 8.4 dev. Maybe it has been this way for awhile (long while?) and I didn't notice it.
I think, but I'm not 100% sure, that has always been the case. In any case, it seems to be the logical behavior, otherwise it wouldn't be a true copy?
Michael
_____________________________
C. Michael Barton
Associate Director, School of Complex Adaptive Systems (https://scas.asu.edu/>\)
Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA
On March 2, 2024 1:00:23 AM GMT+01:00, Michael Barton via grass-dev <grass-dev@lists.osgeo.org> wrote:
It’s been awhile since I’ve done this but I thought I remembered that a new map created with r.copy is constrained by the computational region. That does not seem to the case, at least in 8.4 dev. Maybe it has been this way for awhile (long while?) and I didn’t notice it.
g.copy is a general tool which creates a copy of the data. Perhaps you are interested in r.clip which is a raster tool and is driven by the computational region as expected. r.clip clips according to the current computation region (preserves original raster alignment by default).
In any case, it seems to be the logical behavior, otherwise it wouldn’t be a true copy?
Are the different expectations coming from differences between raster tools and general tools? With r.copy (as opposed to g.copy), you could perhaps argue for respecting the computational region, but I think the “true copy” expectation would still be strong.
On March 2, 2024 1:00:23 AM GMT+01:00, Michael Barton via grass-dev <grass-dev@lists.osgeo.org> wrote:
It’s been awhile since I’ve done this but I thought I remembered that a new map created with r.copy is constrained by the computational region. That does not seem to the case, at least in 8.4 dev. Maybe it has been this way for awhile (long while?) and I didn’t notice it.
g.copy is a general tool which creates a copy of the data. Perhaps you are interested in r.clip which is a raster tool and is driven by the computational region as expected. r.clip clips according to the current computation region (preserves original raster alignment by default).
In any case, it seems to be the logical behavior, otherwise it wouldn’t be a true copy?
Are the different expectations coming from differences between raster tools and general tools? With r.copy (as opposed to g.copy), you could perhaps argue for respecting the computational region, but I think the “true copy” expectation would still be strong.
On Sun, Mar 3, 2024 at 2:48 AM Vaclav Petras via grass-dev
<grass-dev@lists.osgeo.org> wrote:
On March 2, 2024 1:00:23 AM GMT+01:00, Michael Barton via grass-dev <grass-dev@lists.osgeo.org> wrote:
>It's been awhile since I've done this but I thought I remembered that a new map created with r.copy is constrained by the computational region.
>That does not seem to the case, at least in 8.4 dev. Maybe it has been this way for awhile (long while?) and I didn't notice it.
I think, but I'm not 100% sure, that has always been the case.
Here is g.copy documentation from v6.4 it does not mention anything about region. It seems to go back to US Army CERL.
I was mainly just surprised as I thought I remembered (incorrectly it seems) that all raster commands that create new maps respect the computational region.
Michael Barton
School of Human Evolution &Social Change
School of Complex Adaptive System Science
Center for Social Dynamics & Complexity
Arizona State University
...Sent from my iPad
On Mar 3, 2024, at 4:05 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Sun, Mar 3, 2024 at 2:48 AM Vaclav Petras via grass-dev
<grass-dev@lists.osgeo.org> wrote:
On March 2, 2024 1:00:23 AM GMT+01:00, Michael Barton via grass-dev <grass-dev@lists.osgeo.org> wrote:
It's been awhile since I've done this but I thought I remembered that a new map created with r.copy is constrained by the computational region.
That does not seem to the case, at least in 8.4 dev. Maybe it has been this way for awhile (long while?) and I didn't notice it.
I think, but I'm not 100% sure, that has always been the case.
Here is g.copy documentation from v6.4 it does not mention anything about region. It seems to go back to US Army CERL.
not trying to beat a dead horse, but note that g.copy (not r.copy) is not a raster command, rather a general command. It would be important to spend some time understanding the difference between the two.
Regards.
···
I was mainly just surprised as I thought I remembered (incorrectly it seems) that all raster commands that create new maps respect the computational region. Michael Barton School of Human Evolution &Social Change School of Complex Adaptive System Science Center for Social Dynamics & Complexity Arizona State University …Sent from my iPad > On Mar 3, 2024, at 4:05 PM, Markus Neteler