Re: [GRASS-dev] r.copy doesn't respect computational region??

2024-03-03 Thread Michael Barton via grass-dev 
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  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  wrote:
> 
> On Sun, Mar 3, 2024 at 2:48 AM Vaclav Petras via grass-dev
>  wrote:
 On March 2, 2024 1:00:23 AM GMT+01:00, Michael Barton via grass-dev 
  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.
>> 
>> https://urldefense.com/v3/__https://github.com/OSGeo/grass-legacy/blob/2734c86fd5cb976b4a94b04a2cdc75b4613f6a77/general/manage/cmd/g.copy.html*L6__;Iw!!IKRxdwAv5BmarQ!Y6OmEvsONiL6z0N7vRJlQqVXljNtzIOk8D1PWEriQg2IARIxPIAf1QzY53D3FI_FTS25VthLEr8Wg6Qn7TZhlg$
> 
> Here is also the GRASS GIS 4.0 manual page (:
> https://urldefense.com/v3/__https://github.com/OSGeo/grass-legacy/blob/releasebranch_4_0/man/man1/g.copy__;!!IKRxdwAv5BmarQ!Y6OmEvsONiL6z0N7vRJlQqVXljNtzIOk8D1PWEriQg2IARIxPIAf1QzY53D3FI_FTS25VthLEr8Wg6TQstBnZg$
> 
> To easily read it, click the "Raw" button, save to disk as
> "g.copy.man", then render the man page with:
> 
> man ./g.copy.man
> 
> Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.copy doesn't respect computational region??

2024-03-03 Thread Markus Neteler via grass-dev 
On Sun, Mar 3, 2024 at 2:48 AM Vaclav Petras via grass-dev
 wrote:
>> On March 2, 2024 1:00:23 AM GMT+01:00, Michael Barton via grass-dev 
>>  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.
>
> https://github.com/OSGeo/grass-legacy/blob/2734c86fd5cb976b4a94b04a2cdc75b4613f6a77/general/manage/cmd/g.copy.html#L6

Here is also the GRASS GIS 4.0 manual page (:
https://github.com/OSGeo/grass-legacy/blob/releasebranch_4_0/man/man1/g.copy

To easily read it, click the "Raw" button, save to disk as
"g.copy.man", then render the man page with:

man ./g.copy.man

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.copy doesn't respect computational region??

2024-03-03 Thread Michael Barton via grass-dev 
Thanks. I’ll check it out
__
Michael Barton

Sent from  my iPhone
Please excusr any typoz

On Mar 2, 2024, at 6:48 PM, Vaclav Petras  wrote:




On Sat, 2 Mar 2024 at 07:04, Paulo van Breugel via grass-dev 
mailto:grass-dev@lists.osgeo.org>> wrote:


On March 2, 2024 1:00:23 AM GMT+01:00, Michael Barton via grass-dev 
mailto: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).

https://grass.osgeo.org/grass-stable/manuals/addons/r.clip.html


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.

https://github.com/OSGeo/grass-legacy/blob/2734c86fd5cb976b4a94b04a2cdc75b4613f6a77/general/manage/cmd/g.copy.html#L6

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.

Vaclav



>
>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
>
>Executive Director, Open Modeling Foundation 
>(https://openmodelingfoundation.github.io>)
>Director, Network for Computational Modeling in Social & Ecological Sciences 
>(https://comses.net)
>
>personal website: http://www.public.asu.edu/~cmbarton
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.copy doesn't respect computational region??

2024-03-02 Thread Vaclav Petras via grass-dev 
On Sat, 2 Mar 2024 at 07:04, Paulo van Breugel 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.
>


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).

https://grass.osgeo.org/grass-stable/manuals/addons/r.clip.html


>
> 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.

https://github.com/OSGeo/grass-legacy/blob/2734c86fd5cb976b4a94b04a2cdc75b4613f6a77/general/manage/cmd/g.copy.html#L6


> 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.

Vaclav


>
>
> >
> >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
> >
> >Executive Director, Open Modeling Foundation (
> https://openmodelingfoundation.github.io<
> https://openmodelingfoundation.github.io/>)
> >Director, Network for Computational Modeling in Social & Ecological
> Sciences (https://comses.net)
> >
> >personal website: http://www.public.asu.edu/~cmbarton
> >
> >
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.copy doesn't respect computational region??

2024-03-02 Thread Paulo van Breugel via grass-dev 



On March 2, 2024 1:00:23 AM GMT+01:00, Michael Barton via grass-dev 
 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
>
>Executive Director, Open Modeling Foundation 
>(https://openmodelingfoundation.github.io)
>Director, Network for Computational Modeling in Social & Ecological Sciences 
>(https://comses.net)
>
>personal website: http://www.public.asu.edu/~cmbarton
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.copy doesn't respect computational region??

2024-03-01 Thread Michael Barton via grass-dev 
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

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev