Re: [GRASS-dev] GSoC Ideas

[Martin Landa via grass-dev]

Hi Anna,

pá 1. 3. 2024 v 17:35 odesílatel Anna Petrášová 
napsal:

> Martin, how about using https://github.com/OSGeo/grass/issues/2599 as a
> test?
>

good idea, thanks for pointing this out. Martin

-- 
Martin Landa
https://geomatics.fsv.cvut.cz/en/employees/martin-landa/
http://gismentors.cz/mentors/landa
___
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??

[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

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

[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