Re: [GRASS-user] Using RStudio in a GRASS GIS session

[Bernardo Santos via grass-user]

 Hi Sybille,
I have never tried opening Rstudio from the GRASS terminal, but I know that it 
is possible to open R. So as others have mentioned, you could try to first open 
R (from the GRASS terminal) and within it try `library(rgrass)` (or 
`install.packages("rgrass")` if it was not installed yet).
But I also know there are some issues when working with both R/RStudio and 
GRASS in Windows, also related to how GRASS was installed and if R/Rstudio are 
recognized in the PATH variables. Please take a look at these notes here and 
check if any of that helps you: Connecting to GRASS from R in Windows · Issue 
#10 · NINAnor/oneimpact (github.com)
BestBernardo
Em sexta-feira, 19 de abril de 2024 às 08:13:40 GMT+2, Paulo van Breugel 
via grass-user  escreveu:  
 
 From the message that library is not found, I wonder, did you type 

GRASS> rstudio & library(grass) 

all on the command line? 

Just to be sure, you should ope Grass gis. And in the grass gis command line, 
type

rstudio &

Next, after RStudio opens,  you type the following in RStudio

library(grass)




On April 18, 2024 7:56:03 PM GMT+02:00, Veronica Andreo via grass-user 
 wrote:
Hello Sibylle,
Perhaps you can tell us some details about your operative system, which GRASS 
installer you are using (i.e., standalone or OSGeo4W), how did you start GRASS, 
if R and RStudio are installed. 
>From your email, I do not understand why GRASS is not recognized as a command, 
>as it seems you **are** already within a GRASS session on the terminal? (i.e. 
>you have a GRASS prompt there `GRASS>`).
Vero
El jue, 18 abr 2024 a las 12:06, Micha Silver via grass-user 
() escribió:

  
Silly question, do you have the 'rgrass' library installed?
 
i.e. can you do `library(rgrass)` at the R command prompt (without rstudio)?
 

 
 

 
 On 17/04/2024 21:34, sibylle via grass-user wrote:
  
 Dear community

To use RStudio in a GRASS GIS session I used the command line
GRASS> rstudio &
library(rgrass)
(see https://grasswiki.osgeo.org/wiki/R_statistics/rgrass)

Unfortunately I was not able to solve the error message:
- The command "GRASS" is either misspelled or
could not be found.
- The command "library" is either misspelled or
could not be found.

Kind regards
Sibylle



(Wed Apr 17 20:25:17 2024)

GRASS> rstudio &

Der Befehl "GRASS" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
(Wed Apr 17 20:25:17 2024) Command ended with non-zero return code 1 (0 sec)

(Wed Apr 17 20:25:29 2024)

library(rgrass)

Der Befehl "library" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
(Wed Apr 17 20:25:29 2024) Command ended with non-zero return code 1 (0 sec)


___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
 
 -- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918 ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user




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

Re: [GRASS-user] Probabilistic neighborhood analysis

[Bernardo Santos via grass-user]

 Hi Makus,
Nice suggestion, I did not know about this function within r.mapcalc (it is 
quite hidden!)I still do not know how to operationalize it, though.For now, the 
solution with R worked, but it could be useful to have something like that in 
GRASS in the future.Should I open an issue with a suggestion?(I do not have 
time to do it right now)
BestBernardoEm quarta-feira, 11 de janeiro de 2023 09:39:17 GMT+1, Markus 
Neteler  escreveu:  
 
 Hi Bernardo,

Not sure if this helps but there is also this function in r.mapcalc:

https://grass.osgeo.org/grass78/manuals/r.mapcalc.html

graph(x,x1,y1[x2,y2..])        convert the x to a y based on points
in a graph F
graph2(x,x1[,x2,..],y1[,y2..]) alternative form of graph()

The graph() function allows users to specify a x-y conversion using
pairs of x,y coordinates. In some situations a transformation from one
value to another is not easily established mathematically, but can be
represented by a 2-D graph and then linearly interpolated. The graph()
function provides the opportunity to accomplish this. An x-axis value
is provided to the graph function along with the associated graph
represented by a series of x,y pairs. The x values must be
monotonically increasing (each larger than or equal to the previous).
The graph function linearly interpolates between pairs. Any x value
lower the lowest x value (i.e. first) will have the associated y value
returned. Any x value higher than the last will similarly have the
associated y value returned.
[...]

Perhaps a dynamic (set of) graphs could be constructed?

Best,
Markus

On Wed, Dec 14, 2022 at 2:37 PM Bernardo Santos via grass-user
 wrote:
>
> Hi,
>
> I am trying to produce scenarios of past land cover, before hydropower 
> reservoirs were built. To do so, I need to fill empty pixels from a raster in 
> the locations where the reservoirs are currently present, using as input the 
> actual land cover map. I tried doing that with r.neighbors (taking 
> method=mode) with neighborhoods of increasing size, to replace null pixels 
> with the most common land cover class in the neighborhood. I also tried that 
> with r.fill.stats which is basically the same thing.
> However, the results gets very homogeneous, since the interpolated null cells 
> always get the value of the most common land cover class.
>
> Do anyway know of a method in GRASS to perform a "probabilistic" 
> neirighborhood analysis, where cells in a neighborhood are given weights 
> (possibly related to the distance to the central cell and to their frequency) 
> and these weights are used to stocastically sample a value to fill the 
> central cell?
> If not in GRASS, does anyway know of such a method in a different platform, 
> i.e. R?
>
> Thanks!
> Best
> Bernardo
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user



-- 
Markus Neteler, PhD
https://www.mundialis.de - free data with free software
https://grass.osgeo.org
https://courses.neteler.org/blog
  ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] How to use g.extension in GRASS7.8

[Bernardo Santos via grass-user]

 Hi Stefan,
this worked perfectly for now! Thanks!BestBernardo
Em terça-feira, 10 de janeiro de 2023 07:37:15 GMT+1, Stefan Blumentrath 
 escreveu:  
 
 Hei Bernardo,

The problem is likely that the layout of the addon repo changed after 7.8.5, 
thus the path is not constructed correctly by g.extension in that version.

A workaround could be to fetch the add on repo with git (git clone 
https://github.com/osgeo/grass-addons)

And then point g.extension to your local copy:
g.extension extension=r.area url=./grass-addons/src/raster/r.area

You may need a zip file, but you can try the above first...

Good luck.. 

Cheers,
Stefan

> Gesendet: Montag, den 09.01.2023 um 21:14 Uhr
> Von: "Bernardo Santos via grass-user" 
> An: "Markus Neteler" 
> Cc: "GRASS User List" 
> Betreff: Re: [GRASS-user] How to use g.extension in GRASS7.8
> 
>  Hi Markus and Vero,
> Thanks. Indeed, my GRASS version is old:GRASS 7.8.5Ubuntu 18.04.6 LTS
> I unfortunately do not have a way to upgrade it myself since this is a 
> company server shared with other people (and we have been fighting with IT to 
> change to GRASS 8).But maybe it is easier to at lease update GRASS to version 
> 7.8.7 (or 7.8.8).
> I just talked to a colleague (@mauricio.vancince) who mentioned he had the 
> same problem but could overcome it opening the terminal as a superuser and 
> using g.extension r.area -sUnfortunately I do not have admin rights, but I 
> will see what is possible to be done.
> Thanks!BestBernardo 
>    Em segunda-feira, 9 de janeiro de 2023 15:19:07 GMT+1, Markus Neteler 
> escreveu:  
>  
>  Hi Bernardo,
> 
> On Mon, Jan 9, 2023 at 2:58 PM Bernardo Santos
>  wrote:
> >
> > Hi Markus,
> >
> > That was my first try, and then I get the error below:
> >
> > > g.extension extension=r.area
> > Fetching  from GRASS GIS Addons repository (be patient)...
> > svn: E17: URL 
> > 'https://github.com/OSGeo/grass-addons/trunk/grass7/raster/r.area' doesn't 
> > exist
> > ERROR: GRASS Addons  not found
> 
> Ah right. Then your GRASS GIS 7.8 version may be too old. G 7.8.7
> should be ok (G 7.8.8 is on the way these days) but in any case, as
> Vero pointed out, we highly recommend to upgrade to GRASS GIS 8.2.x.
> 
> Best,
> Markus
>  ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
  ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] How to use g.extension in GRASS7.8

[Bernardo Santos via grass-user]

 Hi Markus and Vero,
Thanks. Indeed, my GRASS version is old:GRASS 7.8.5Ubuntu 18.04.6 LTS
I unfortunately do not have a way to upgrade it myself since this is a company 
server shared with other people (and we have been fighting with IT to change to 
GRASS 8).But maybe it is easier to at lease update GRASS to version 7.8.7 (or 
7.8.8).
I just talked to a colleague (@mauricio.vancince) who mentioned he had the same 
problem but could overcome it opening the terminal as a superuser and using 
g.extension r.area -sUnfortunately I do not have admin rights, but I will see 
what is possible to be done.
Thanks!BestBernardo 
Em segunda-feira, 9 de janeiro de 2023 15:19:07 GMT+1, Markus Neteler 
 escreveu:  
 
 Hi Bernardo,

On Mon, Jan 9, 2023 at 2:58 PM Bernardo Santos
 wrote:
>
> Hi Markus,
>
> That was my first try, and then I get the error below:
>
> > g.extension extension=r.area
> Fetching  from GRASS GIS Addons repository (be patient)...
> svn: E17: URL 
> 'https://github.com/OSGeo/grass-addons/trunk/grass7/raster/r.area' doesn't 
> exist
> ERROR: GRASS Addons  not found

Ah right. Then your GRASS GIS 7.8 version may be too old. G 7.8.7
should be ok (G 7.8.8 is on the way these days) but in any case, as
Vero pointed out, we highly recommend to upgrade to GRASS GIS 8.2.x.

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

Re: [GRASS-user] How to use g.extension in GRASS7.8

[Bernardo Santos via grass-user]

 Hi Markus,
That was my first try, and then I get the error below:
> g.extension extension=r.areaFetching  from GRASS GIS Addons 
> repository (be patient)...svn: E17: URL 
> 'https://github.com/OSGeo/grass-addons/trunk/grass7/raster/r.area' doesn't 
> existERROR: GRASS Addons  not found
B
Em segunda-feira, 9 de janeiro de 2023 14:35:48 GMT+1, Markus Neteler 
 escreveu:  
 
 Hi,

On Mon, Jan 9, 2023 at 11:50 AM Bernardo Santos via grass-user
 wrote:
>
> Hi,
>
> I am trying to install the extension r.area using the g.extension tool in 
> GRASS 7.8.
> However, I get the error that it was not found in the Github repo (because 
> the repo changed).
> Here the error:
>
> > g.extension extension=r.area
> Fetching  from GRASS GIS Addons repository (be patient)...
> svn: E17: URL 
> 'https://github.com/OSGeo/grass-addons/trunk/grass7/raster/r.area' doesn't 
> exist
> ERROR: GRASS Addons  not found
>
> I tried adding 
> url=https://github.com/OSGeo/grass-addons/tree/grass8/src/raster/r.area; but 
> it also does not work:
> > g.extension extension=r.area 
> > url=https://github.com/OSGeo/grass-addons/tree/grass8/src/raster/r.area
>  The command:
> g.extension extension=r.area 
> url=https://github.com/OSGeo/grass-addons/tree/grass8/src/raster/r.area 
> operation=add
> produced an error (1) during execution:
> Fetching  from
> <https://github.com/OSGeo/grass-addons/tree/grass8/src/raster/r.area/archive/master.zip>
> (be patient)...
> ERROR: Extension  not found
>
> How should I proceed to install it in GRASS 7.8?

It should work like this (g.extension will figure out the correct path):

g.extension extension=r.area

HTH,
Markus

PS: Full path is only needed when the addon isn't part of the standard
addon repository but found elsewhere.
  ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Probabilistic neighborhood analysis

[Bernardo Santos via grass-user]

 Hi Ken,
The fuzzy logic tools seem interesting! But I am new to the concept so I did 
not really think about how could I set functions/rules that increase with the 
frequency of a land cover class...Do you know any example in this context?
I thought that people working with satellite imagery classification and cloud 
cover would have experience with that, since sometimes it is necessary to 
somehow interpolate and fill values cover by clouds...
BestB 
Em segunda-feira, 26 de dezembro de 2022 16:50:42 GMT+1, Ken Mankoff 
 escreveu:  
 
 What about using the fuzzy logic modules? 

  -k.

Please excuse brevity. Sent from tiny pocket computer with non-haptic feedback 
keyboard.
On Wed, Dec 14, 2022, 13:38 Bernardo Santos via grass-user 
 wrote:

Hi,
I am trying to produce scenarios of past land cover, before hydropower 
reservoirs were built. To do so, I need to fill empty pixels from a raster in 
the locations where the reservoirs are currently present, using as input the 
actual land cover map. I tried doing that with r.neighbors (taking method=mode) 
with neighborhoods of increasing size, to replace null pixels with the most 
common land cover class in the neighborhood. I also tried that with 
r.fill.stats which is basically the same thing.However, the results gets very 
homogeneous, since the interpolated null cells always get the value of the most 
common land cover class.
Do anyway know of a method in GRASS to perform a "probabilistic" neirighborhood 
analysis, where cells in a neighborhood are given weights (possibly related to 
the distance to the central cell and to their frequency) and these weights are 
used to stocastically sample a value to fill the central cell?If not in GRASS, 
does anyway know of such a method in a different platform, i.e. R?
Thanks!BestBernardo___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

Re: [GRASS-user] Probabilistic neighborhood analysis

[Bernardo Santos via grass-user]

 Hi Vero,
Thanks for the suggestion.I tried it, but it only gives different weights to 
the values within the neighborhood according to a distance decay function. 
However, the values are still determined "deterministically".
What I could do is to use the function terra::focal() in R, since within it I 
can define a function to be computed for the neighborhood and use sample() to 
make this operation probabilistic. It seems to work, but it quite time 
consuming though.
BestBernardo
Em segunda-feira, 26 de dezembro de 2022 16:13:02 GMT+1, Veronica Andreo 
 escreveu:  
 
 Hello Bernardo, 

I haven't tested myself, but have you tried r.neighbors with the different 
weight-related options?
Vero

El mié, 14 dic 2022 a las 10:38, Bernardo Santos via grass-user 
() escribió:

Hi,
I am trying to produce scenarios of past land cover, before hydropower 
reservoirs were built. To do so, I need to fill empty pixels from a raster in 
the locations where the reservoirs are currently present, using as input the 
actual land cover map. I tried doing that with r.neighbors (taking method=mode) 
with neighborhoods of increasing size, to replace null pixels with the most 
common land cover class in the neighborhood. I also tried that with 
r.fill.stats which is basically the same thing.However, the results gets very 
homogeneous, since the interpolated null cells always get the value of the most 
common land cover class.
Do anyway know of a method in GRASS to perform a "probabilistic" neirighborhood 
analysis, where cells in a neighborhood are given weights (possibly related to 
the distance to the central cell and to their frequency) and these weights are 
used to stocastically sample a value to fill the central cell?If not in GRASS, 
does anyway know of such a method in a different platform, i.e. R?
Thanks!BestBernardo___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[GRASS-user] How to use g.extension in GRASS7.8

[Bernardo Santos via grass-user]

Hi,
I am trying to install the extension r.area using the g.extension tool in GRASS 
7.8.However, I get the error that it was not found in the Github repo (because 
the repo changed).Here the error:
 > g.extension extension=r.areaFetching  from GRASS GIS Addons 
 > repository (be patient)...svn: E17: URL 
 > 'https://github.com/OSGeo/grass-addons/trunk/grass7/raster/r.area' doesn't 
 > existERROR: GRASS Addons  not found
I tried adding 
url=https://github.com/OSGeo/grass-addons/tree/grass8/src/raster/r.area; but it 
also does not work:> g.extension extension=r.area 
url=https://github.com/OSGeo/grass-addons/tree/grass8/src/raster/r.area The 
command:g.extension extension=r.area 
url=https://github.com/OSGeo/grass-addons/tree/grass8/src/raster/r.area 
operation=addproduced an error (1) during execution:Fetching  
from(be
 patient)...ERROR: Extension  not found
How should I proceed to install it in GRASS 7.8?
BestBernardo
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Probabilistic neighborhood analysis

[Bernardo Santos via grass-user]

Hi,
I am trying to produce scenarios of past land cover, before hydropower 
reservoirs were built. To do so, I need to fill empty pixels from a raster in 
the locations where the reservoirs are currently present, using as input the 
actual land cover map. I tried doing that with r.neighbors (taking method=mode) 
with neighborhoods of increasing size, to replace null pixels with the most 
common land cover class in the neighborhood. I also tried that with 
r.fill.stats which is basically the same thing.However, the results gets very 
homogeneous, since the interpolated null cells always get the value of the most 
common land cover class.
Do anyway know of a method in GRASS to perform a "probabilistic" neirighborhood 
analysis, where cells in a neighborhood are given weights (possibly related to 
the distance to the central cell and to their frequency) and these weights are 
used to stocastically sample a value to fill the central cell?If not in GRASS, 
does anyway know of such a method in a different platform, i.e. R?
Thanks!BestBernardo___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Running r-grass examples when building a R package

[Bernardo Santos via grass-user]

 Hi Stefan,(and thanks Roger and Floris for replying as well)
Your solution worked perfectly, Stefan. Thanks a lot!In the case of continuous 
integration within Github as it is the case, it seems we must ask GRASS to be 
installed in the virtual machine.
This could be done with Stefan's suggestion, adding these lines to the yaml 
file within .github/workflows:
- name: Install GRASS GIS and other dependencies        run: |          sudo 
apt-get update -qq          sudo apt-get install -y -qq grass grass-dev 
grass-doc wget
You can also see it here: Install GRASS for CI by ninsbl · Pull Request #11 · 
NINAnor/oneimpact (github.com)
I guess this could be documented for GRASS/R users somewhere? Maybe in some 
wiki?Any suggestion on where to add this?

BestBernardo

Em sexta-feira, 26 de agosto de 2022 13:27:46 GMT+2, Stefan Blumentrath 
 escreveu:  
 
  
Hi Bernardo,
 
  
 
Seems like GRASS GIS isn`t installed on the CI VM.
 
  
 
Please see:
 
https://github.com/NINAnor/oneimpact/pulls
 
  
 
You may add UbuntuGIS PPAs if you want other versions than shipped by plain 
Ubuntu.
 
  
 
Cheers
 
Stefan
 
  
 
From: grass-user On Behalf Of Bernardo 
Santos via grass-user
Sent: fredag 26. august 2022 12:56
To: grass-st...@lists.osgeo.org; GRASS User List 
Subject: [GRASS-user] Running r-grass examples when building a R package
 
  
 
Dear all,
 
  
 
I am building a R package and some of the functions use rgrass to connect to a 
GRASS project and run thingfs within GRASS.
 
I have now set up a webpage for the package using pkgdown in integrated to 
Github actions. This means when I push new commits all the examples of R 
functions are run again and the webpage is updated with the results of the 
examples. Here is the webpage: https://ninanor.github.io/oneimpact/
 
  
 
All works fine, except the functions calling GRASS. When I run the examples 
form my local computer everything works, but in the Github actions it does not 
run, apparently because the command
 
  
 system("grass78 --config path", intern = T) 
to find the GRASS folder and use within rgrass::initGRASS does not work, so the 
connection between R and GRASS do not exist.
 
  
 
Does someone in the group has experience with that and could help with hints to 
solve it?
 
Is there a recommended way to make sure Github actions know where GRASS is and 
use it?
 
  
 
Best
 
Bernardo
   ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Running r-grass examples when building a R package

[Bernardo Santos via grass-user]

Dear all,
I am building a R package and some of the functions use rgrass to connect to a 
GRASS project and run thingfs within GRASS.I have now set up a webpage for the 
package using pkgdown in integrated to Github actions. This means when I push 
new commits all the examples of R functions are run again and the webpage is 
updated with the results of the examples. Here is the webpage: 
https://ninanor.github.io/oneimpact/
All works fine, except the functions calling GRASS. When I run the examples 
form my local computer everything works, but in the Github actions it does not 
run, apparently because the command
system("grass78 --config path", intern = T)to find the GRASS folder and use 
within rgrass::initGRASS does not work, so the connection between R and GRASS 
do not exist.
Does someone in the group has experience with that and could help with hints to 
solve it?Is there a recommended way to make sure Github actions know where 
GRASS is and use it?
BestBernardo___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Using a script as a GRASS addon

[Bernardo Santos via grass-user]

Dear all,
I have been following some forums and instructions from GRASS documentation to 
be able to write new GRASS addons - or what I call an addon, basically a python 
script that does what I want, and follow the same standards of published GRASS 
addons, with description of the addon and usage, parameters etc, followed be 
the script with procedures.
It seems to work, but I am not sure how I can test them as GRASS addons. Right 
now, to be able to run them I need to call python like this:
python r.ls.func_connectivity.py input=map1 output=map1_func_connect 
gap_crossing=60
Is there a way I can run that without needing to call python and to use the 
".py" in the end of the script? Like a folder where I can place the files, or a 
way to build it as a formal GRASS addon. What I want is to be able to test it 
and use it (even if only locally for now) as
r.ls.func_connectivity input=map1 output=map1_func_connect gap_crossing=60

Is this documented somewhere?
Best wishes,Bernardo
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] standalone grass installer version 7.6

[Bernardo Santos via grass-user]

Hi,
I have an application I developed a few years ago that still uses python 2.7 
and has a wxPython GUI, that I used to use until GRASS 7.6. Later on it got 
outdated and, even though a colleague and I are updating it, it still does not 
run in GRASS 7.8 or 8.
In the meanwhile, is it still possible to download and install GRASS 7.6 for 
using it? Is the standalone installer for Windows available somewhere? Or I 
would have to build it from the source?
BestBernardo___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] grass command to subset the columns of a vector

[Bernardo Santos via grass-user]

 Hi Micha,
thanks for the suggestion, it solves my question on how to perform this middle 
step of listing the columns that do not match the intended ones. I'll use it 
for now! =)
BestBEm quinta-feira, 10 de fevereiro de 2022 09:45:29 GMT+1, Micha Silver 
 escreveu:  
 
 
On 09/02/2022 15:56, Bernardo Santos via grass-user wrote:
> Dear Markus
>
> Thanks for your answer. I thought about v.db.dropcolumn earlier. 
> However, I am trying to include this within a function, following a 
> workflow in which the input vector might have columns with different 
> names, in which case it would be good to be able to select the ones to 
> keep instead of the ones to remove.
> For instance, let's say I want to be able to provide either of the 
> following input vectors:
> - "vector1", with columns "a, b, c, d, e"
> - "vector2", with columns "j, a, k, f, e"
> Let's say I want to keep only "a" and "e".
>
> If I use v.db.dropcolumn, I'll have to first list the names of all 
> columns (maybe with v.db.select), then match all the column names that 
> I do not want to keep ("b, c, d" in the first case, "j, k, f" in the 
> second), then drop them with v.db.dropcolumn. I thought just selecting 
> which ones I want to keep would be simpler and more straightforward, 
> if there is a tool for that.
>
> So far I am doing a long step (I am creating a temporary vector to 
> avoid changing the input):
> 1) v.extract -t input=vector1 output=temp_vector (here I select only 
> the features, not attribute table)
> 2) v.db.addtable map=temp_vector columns=a,e (here I do not bother 
> with the names of the undesirable columns)
> 3) v.db.update map=temp_vector column=e value=1 (here I set a value 
> but I could take it from the original vector1)
>
> Following what you suggest, I could do:
> 1) g.copy vector=vector1,temp_vector
> 2) (find out a way to list the undesirable column names)


Here's a possible solution. (Somewhat clunky, but workable)

You can get the column names using v.info -c, then grep out the column 
names you want to keep. Then loop thru the column names that are left 
and do v.db.dropcolumn for each.


i.e.:

# I have a vector "terraces" with 4 columns.

v.info -c terraces
Displaying column types/names for database connection of layer <1>:
INTEGER|cat
INTEGER|OBJECTID
DOUBLE PRECISION|Shape_Leng
INTEGER|Validated


#Keep only 2: "cat" and "Validated"

g.copy vect=terraces,terraces_tmp
Copying vector  to current mapset as 


# Get a list of columns to drop

to_drop=`v.info -c terraces_tmp | cut -d'|' -f2 | grep -E -v 'Validate|cat'`
Displaying column types/names for database connection of layer <1>:


echo $to_drop
OBJECTID Shape_Leng


# Loop thru columns to drop and run v.db.dropcolumn on each

for col in $to_drop; do v.db.dropcolumn terraces_tmp col=${col}; done


# Result

v.info -c terraces_tmp
Displaying column types/names for database connection of layer <1>:
INTEGER|cat
INTEGER|Validated


HTH,

Micha


> 3) v.db.dropcolumn columns=list_undesidable_columns
>
> Neither of the solutions is so straightforward, that's why I thought 
> there should be (or could be) another way.
> In R, for instance, I can easily subset columns of an sf object using 
> dplyr::select(vector1, a, e). I guess in PostGIS it is also possible 
> to do that with "SELECT statements", even though I am less skilled 
> there. It would be great to have a module in GRASS to do it as well...
>
> Best
> Bernardo
> Em quarta-feira, 9 de fevereiro de 2022 09:28:06 GMT+1, Markus Neteler 
>  escreveu:
>
>
> Hi Bernardo,
>
> On Wed, Feb 9, 2022 at 1:39 AM Bernardo Santos via grass-user
>  wrote:
> >
> > Dear list,
> >
> > Is there a GRASS GIS command (maybe a v.db.* one) to subset, in a 
> single command, the columns of a vector?
> >
> > What I have: vector "vect" with 5 columns "a, b, c, d, e" in the 
> attribute table
> > What I want: vector "vect_sub" with only, for instance, "a, c, e"
> >
> > I can use v.extract to subsample rows, but not columns. What is the 
> easiest way of doing that, what needing many commands (like creating 
> or copying the vector to a new one, creating a new attribute table, 
> then copying only the columns I want).
>
> Isn't this simply
>
> https://grass.osgeo.org/grass80/manuals/vector.html
> --> v.db.dropcolumn - Drops a column from the attribute table
> connected to a given vector map.
>     --> It offers single and multiple column dropping: 
> columns=name[,name,...]
>
>
> > I looked for that in the documentation but did not found it so easily.
>
>
> Please suggest where to improve the documentation.
>
> Markus
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918

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

Re: [GRASS-user] grass command to subset the columns of a vector

[Bernardo Santos via grass-user]

 Dear Markus
Thanks for your answer. I thought about v.db.dropcolumn earlier. However, I am 
trying to include this within a function, following a workflow in which the 
input vector might have columns with different names, in which case it would be 
good to be able to select the ones to keep instead of the ones to remove.For 
instance, let's say I want to be able to provide either of the following input 
vectors:- "vector1", with columns "a, b, c, d, e"- "vector2", with columns "j, 
a, k, f, e"Let's say I want to keep only "a" and "e".
If I use v.db.dropcolumn, I'll have to first list the names of all columns 
(maybe with v.db.select), then match all the column names that I do not want to 
keep ("b, c, d" in the first case, "j, k, f" in the second), then drop them 
with v.db.dropcolumn. I thought just selecting which ones I want to keep would 
be simpler and more straightforward, if there is a tool for that.
So far I am doing a long step (I am creating a temporary vector to avoid 
changing the input):1) v.extract -t input=vector1 output=temp_vector (here I 
select only the features, not attribute table)2) v.db.addtable map=temp_vector 
columns=a,e (here I do not bother with the names of the undesirable columns)3) 
v.db.update map=temp_vector column=e value=1 (here I set a value but I could 
take it from the original vector1)
Following what you suggest, I could do:1) g.copy vector=vector1,temp_vector2) 
(find out a way to list the undesirable column names)3) v.db.dropcolumn 
columns=list_undesidable_columns
Neither of the solutions is so straightforward, that's why I thought there 
should be (or could be) another way.In R, for instance, I can easily subset 
columns of an sf object using dplyr::select(vector1, a, e). I guess in PostGIS 
it is also possible to do that with "SELECT statements", even though I am less 
skilled there. It would be great to have a module in GRASS to do it as well...

BestBernardo Em quarta-feira, 9 de fevereiro de 2022 09:28:06 GMT+1, Markus 
Neteler  escreveu:  
 
 Hi Bernardo,

On Wed, Feb 9, 2022 at 1:39 AM Bernardo Santos via grass-user
 wrote:
>
> Dear list,
>
> Is there a GRASS GIS command (maybe a v.db.* one) to subset, in a single 
> command, the columns of a vector?
>
> What I have: vector "vect" with 5 columns "a, b, c, d, e" in the attribute 
> table
> What I want: vector "vect_sub" with only, for instance, "a, c, e"
>
> I can use v.extract to subsample rows, but not columns. What is the easiest 
> way of doing that, what needing many commands (like creating or copying the 
> vector to a new one, creating a new attribute table, then copying only the 
> columns I want).

Isn't this simply

https://grass.osgeo.org/grass80/manuals/vector.html
--> v.db.dropcolumn - Drops a column from the attribute table
connected to a given vector map.
    --> It offers single and multiple column dropping: columns=name[,name,...]

> I looked for that in the documentation but did not found it so easily.

Please suggest where to improve the documentation.

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

[GRASS-user] grass command to subset the columns of a vector

[Bernardo Santos via grass-user]

Dear list,
Is there a GRASS GIS command (maybe a v.db.* one) to subset, in a single 
command, the columns of a vector?
What I have: vector "vect" with 5 columns "a, b, c, d, e" in the attribute 
tableWhat I want: vector "vect_sub" with only, for instance, "a, c, e"
I can use v.extract to subsample rows, but not columns. What is the easiest way 
of doing that, what needing many commands (like creating or copying the vector 
to a new one, creating a new attribute table, then copying only the columns I 
want).I looked for that in the documentation but did not found it so easily.
Thanks!Bernardo___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.mfilter do not process map edges

[Bernardo Santos via grass-user]

 Hi Vero,
thanks for your answer. I have just opened an issue with what I hope it is a 
reprex.Here it is: [Bug] r.mfilter do not process map edges · Issue #2184 · 
OSGeo/grass (github.com)
BestBernardo
Em terça-feira, 8 de fevereiro de 2022 13:02:34 GMT+1, Veronica Andreo 
 escreveu:  
 
 Hello Bernardo, 

Could you please create an issue with the reprex here: 
https://github.com/OSGeo/grass/issues/new/choose ?

Thanks,Vero
El mar, 1 feb 2022 a las 7:54, Bernardo Santos via grass-user 
() escribió:

Hello,
I am performing neighborhood analyses with the r.mfilter module.It is very good 
because of its versatility - one can define the filtering matrix as one 
wants.However, it does not process the edges of the map, or at least it seems 
so.If the filter matrix size is e.g. 25x25 pixels, the output shows the 25 
pixels of the edgesimilar to the input map.
Other modules for neighborhood analyses, however, such as r.neighbors, have a 
way to deal with that in the borders - dealing with null values.
Does anyone know a way of having such an output - without border effects - for 
r.mfilter?If not, is it possible to implement it? (I cannot contribute much 
here because of my limited C knowledge...)
If necessary, I can provide a reprex!Thanks in advance!
Bernardo  ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

[GRASS-user] r.mfilter do not process map edges

[Bernardo Santos via grass-user]

Hello,
I am performing neighborhood analyses with the r.mfilter module.It is very good 
because of its versatility - one can define the filtering matrix as one 
wants.However, it does not process the edges of the map, or at least it seems 
so.If the filter matrix size is e.g. 25x25 pixels, the output shows the 25 
pixels of the edgesimilar to the input map.
Other modules for neighborhood analyses, however, such as r.neighbors, have a 
way to deal with that in the borders - dealing with null values.
Does anyone know a way of having such an output - without border effects - for 
r.mfilter?If not, is it possible to implement it? (I cannot contribute much 
here because of my limited C knowledge...)
If necessary, I can provide a reprex!Thanks in advance!
Bernardo  ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] rgrass7 and rmarkdown: how to avoid showing the percentage of processing

[Bernardo Santos via grass-user]

Hi,
when using rgrass7 and rmarkdown, is there a way of avoiding showing the 
percentage of processingo of each command within execGRASS?It might get really 
polluted, mainly when I perform a loop or many processings.See the figure below:

I tried adding "message = FALSE, warning = FALSE" to the chunks, but it does 
not work.
BestBernardo

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

Re: [GRASS-user] r.neighbors vs r.resamp.filter

[Bernardo Santos via grass-user]

 Hi Maris,
thanks for your answer.For me what you say is clear when it comes to 
r.resamp.interp (output has a finer scale resolution then the input) or 
r.resamp.stats (result has a coarser resolution).However, it is not so clear 
when it comes to r.resamp.filter.
I used a "roadsmajor" map form the NC dataset as an example to calculate the 
density, considering a neighborhood of 150m (just some random value, multiple 
of the map resolution, 30m).Here is a gist for the code: 
neighbors_vs_resamp_filter.py (github.com), run from the PERMANENT mapset.
Both r.neighbors and r.resamp.filter produce maps with similar resolution 
(=30m, the original resolution), and the results are quite comparable, 
visually, even though different.Probably (at least part of) the differences are 
due to different filters/algorithms. I am not sure exactly how many pixels are 
considered in each filter when I set the radius as 150m in r.resamp.filter, for 
example. Maybe if I chose a Gaussian filter (which is possible in both modules) 
the results would be more similar.
I understand r.neighbors has other statistics it is possible to compute (which 
are not present in r.resamp.filter), and r.resamp.filter has multiple types of 
combination of filters which are not possible in r.neighbors, so they 
complement each other.
But, if I use the "average" method in r.neighbors, can they be comparable? Am I 
missing something central here?

BestBernardo


Em quarta-feira, 3 de novembro de 2021 18:30:25 GMT+1, Maris Nartiss 
 escreveu:  
 
 If the computational region is set to match input map, r.neighbours
will produce output in the same resolution. r.resamp.* will work if
the computational region differs from the input map.
Do not use r.neighbours with a different computational region, as
GRASS internally is using nearest neighbour method for resampling –
the result might not be what you expect to have.

TL;DR:
for same resolution output – r.neighbours
for different resolution (e.g. count per km²) – r.resamp.*

Māris.

trešd., 2021. g. 3. nov., plkst. 15:26 — lietotājs Bernardo Santos via
grass-user () rakstīja:
>
> Dear all,
>
> I am working with human infrastructure data (houses, trails, roads and 
> railways, dams, etc) and I need to create maps of density (in space) of each 
> type of infrastructure, for different spatial extents (i.e. considering 
> different neighborhood sizes). So far I've been using r.neighbors to do this, 
> but some colleagues and collaborators are using r.resamp.filter instead. I 
> took a good look at each and made some tests to compare, but I am not sure 
> what are the real differences between each. Has this been developed or 
> discussed somewhere?
>
> My inputs are rasterized versions of points, lines, or polygon features.
>
> If it is better, I can bring a reprex here to discuss it more deeply.
>
> Best regards,
> Bernardo Niebuhr
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
  ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.neighbors vs r.resamp.filter

[Bernardo Santos via grass-user]

Dear all,
I am working with human infrastructure data (houses, trails, roads and 
railways, dams, etc) and I need to create maps of density (in space) of each 
type of infrastructure, for different spatial extents (i.e. considering 
different neighborhood sizes). So far I've been using r.neighbors to do this, 
but some colleagues and collaborators are using r.resamp.filter instead. I took 
a good look at each and made some tests to compare, but I am not sure what are 
the real differences between each. Has this been developed or discussed 
somewhere?
My inputs are rasterized versions of points, lines, or polygon features.

If it is better, I can bring a reprex here to discuss it more deeply.
Best regards,Bernardo Niebuhr___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] GRASS and GEE integration

[Bernardo Santos via grass-user]

Hello everyone,
I (finally) recently found out about some of the great capabilities of Google 
Earth Engine.It is great to be able to get access to so many satellite images 
and datasets and process them without having to download them, build databases, 
and process them on local computers.
However, I was wondering it would be great to be able to use all the 
capabilities from GRASS GIS modules and addons integrated with GEE.Does anyone 
know about initiatives to do some kind of integration in this direction?
Thanks!Bernardo
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.viewshed for multiple points

[Bernardo Santos]

 Hi,
sorry for not having searched enough before posting.I have just found the addon 
r.viewshed.cvs which seems to do the job!
BestBernardo

Em terça-feira, 24 de novembro de 2020 22:56:17 GMT+1, Bernardo Santos 
 escreveu:  
 
 Dear list,
I need to calculate a viewshed surface for multiple points (and have, in the 
end, a single surface of where any of those points can see). In fact this is to 
deal with the other way around: I want to know, in any position, if it is 
possible to see back to one of those points modeled.
r.viewshed seems to do the job, but for a single point at a time.Is there any 
implementation doing this for multiple points, like a poit vector as input 
instead of a pair (x,y)?
Thank!Best wishesBernardo


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

[GRASS-user] r.viewshed for multiple points

[Bernardo Santos]

Dear list,
I need to calculate a viewshed surface for multiple points (and have, in the 
end, a single surface of where any of those points can see). In fact this is to 
deal with the other way around: I want to know, in any position, if it is 
possible to see back to one of those points modeled.
r.viewshed seems to do the job, but for a single point at a time.Is there any 
implementation doing this for multiple points, like a poit vector as input 
instead of a pair (x,y)?
Thank!Best wishesBernardo


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

Re: [GRASS-user] TPI (terrain position index) in GRASS GIS

[Bernardo Santos]

 Hi Stefan,
Sure, that makes all sense! I am not used to DEM-realted indices, but I could 
have just thought a little...Thanks a lot!
B

Em quinta-feira, 8 de outubro de 2020 12:50:35 GMT+2, Stefan Blumentrath 
 escreveu:  
 
 #yiv0189279323 #yiv0189279323 -- _filtered {} _filtered {} _filtered 
{}#yiv0189279323 #yiv0189279323 p.yiv0189279323MsoNormal, #yiv0189279323 
li.yiv0189279323MsoNormal, #yiv0189279323 div.yiv0189279323MsoNormal 
{margin:0cm;margin-bottom:.0001pt;font-size:11.0pt;font-family:sans-serif;}#yiv0189279323
 a:link, #yiv0189279323 span.yiv0189279323MsoHyperlink 
{color:#0563C1;text-decoration:underline;}#yiv0189279323 a:visited, 
#yiv0189279323 span.yiv0189279323MsoHyperlinkFollowed 
{color:#954F72;text-decoration:underline;}#yiv0189279323 
p.yiv0189279323msonormal0, #yiv0189279323 li.yiv0189279323msonormal0, 
#yiv0189279323 div.yiv0189279323msonormal0 
{margin-right:0cm;margin-left:0cm;font-size:11.0pt;font-family:sans-serif;}#yiv0189279323
 span.yiv0189279323EmailStyle18 
{font-family:sans-serif;color:windowtext;}#yiv0189279323 
.yiv0189279323MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv0189279323 
div.yiv0189279323WordSection1 {}#yiv0189279323 
Hi Brenado,
 
  
 
TPI is rather simple and can be computed with r.neighbors + r.mapcalc:
 
  
 
r.neighbors -c input=dem output=dem_avg_9 size=9
 
r.mapcalc expression=”TPI_9=dem-dem_avg_9”
 
g.remove -f type=raster name=dem_avg_9
 
  
 
Cheers
 
Stefan
 
  
 
From: grass-user On Behalf Of Bernardo 
Santos
Sent: torsdag 8. oktober 2020 12:35
To: GRASS User List 
Subject: [GRASS-user] TPI (terrain position index) in GRASS GIS
 
  
 
Hi everyone,
 
  
 
Do any of you know if we can calculate TPI (terrain position index) in GRASS 
GIS?
 
Or should we go for other tools such as SAGA GIS?
 
  
 
Best wishes,
 
Bernardo Niebuhr
   ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] TPI (terrain position index) in GRASS GIS

[Bernardo Santos]

Hi everyone,
Do any of you know if we can calculate TPI (terrain position index) in GRASS 
GIS?Or should we go for other tools such as SAGA GIS?
Best wishes,Bernardo Niebuhr
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] tiled version for r.neighbors

[Bernardo Santos]

 Hi Moritz,
thanks for the hacks, they seem very useful!I am not so worried about the speed 
right now but more with the "do-ability" of the job.For some of the things I 
tried to do I just got stuck on 0 or 3% and the process did not go further, at 
least in the simple computers I use.I may try a modification of your code in 
the coming weeks, it does not seem so hard indeed. I come back here if can (or 
cannot) do it. Thanks!
regardgin the r.patch part, what you mean is that it could be better to have a 
calll to the module r.patch instead of to this function "rpatch_map" that is 
used in the source code?
BestBernardo

Em quarta-feira, 7 de outubro de 2020 13:08:16 GMT+2, Moritz Lennert 
 escreveu:  
 
 On 7/10/20 12:37, Bernardo Santos wrote:
> Dear community,
> 
> I have recently found that some functions such as r.mapcalc and 
> r.textile have their "tiled" versions, whichi is perfect for processing 
> things in large extents and fine scale resolution.
> I need to perform a moving window analysis, such as using r.neighbors, 
> over large areas. Is there already any implementation of a 
> "r.neighbors.tiled" or something like that?
> (If not, that would definitely be very useful!)

AFAIK, there is no r.neighbors.tiled. Actually, the two others you cite 
were quick hacks from me which I decided to make available in case they 
could be useful.

Several tests by others using r.mapcalc.tiled have not shown significant 
speed increase, and so there is currently a discussion about how to 
solve this (the current idea is to try with r.patch instead of the 
internal python-based patching routine). Unfortunately, I don't have 
much time for GRASS GIS these days, so will not be able to do anything 
about this.

You could have a look at the existing *.tiled modules (see link to the 
code at the bottom of the online man page) to see how they work (not 
very complicated) and try to cook your own for r.neighbors. :-)

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

[GRASS-user] tiled version for r.neighbors

[Bernardo Santos]

Dear community,
I have recently found that some functions such as r.mapcalc and r.textile have 
their "tiled" versions, whichi is perfect for processing things in large 
extents and fine scale resolution. 
I need to perform a moving window analysis, such as using r.neighbors, over 
large areas. Is there already any implementation of a "r.neighbors.tiled" or 
something like that?(If not, that would definitely be very useful!)
Best wishesBernardo
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Mapsets with multiple users

[Bernardo Santos]

Dear list,
I am working on a project where we have a server with a GRASS GIS database that 
is accessed by several people.The project has several mapsets which comprise 
thematic folders, with e.g. climate data, human infrastructure data, land use 
data etc.Although all people can access the maps, often we also create new 
layers of information in one of those mapsets (e.g. density of points or 
distance from features, both based on existing layers, or the addition of new 
layers), and there is more than one person contributing to that.However, in 
this moment we get some problems, since only the owners of each mapset can 
write into it.
Have you worked in projects like that already?What would you recommend us to 
do, to keep all the data safe (I understand that this is what the current GRASS 
GIS internal rules assure) and at the same time do not centralize the work on a 
single person (the owner of the mapset(s))?
Thanks in advance for advice!Best wishes
Bernardo NiebuhrSwedish University of Agricultural SciencesUppsala, Sweden
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] function to write raster info, based on r.stats

[Bernardo Santos]

Dear community,
I am writing a function in python that takes the results from r.stats, adds 
headers, and makes some transformations in the value (such as converting areas 
from m2 to hectares), and then writes that on an output file.
The way I am writing the output, however, is completely inneficient. Take a 
look here:script to edit and save statistics from raster maps in GRASS GIS, 
using r.stats
For small maps there is not an issue, but for large maps this may be a huge 
problem. Any hints on how to write files in an efficient way in python?
Thanks in advance.Best regardsBernardo Niebuhr


Links na mensagem (1)

|  |  | 
script to edit and save statistics from...
 |

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

Re: [GRASS-user] New Google Scholar profile: "GRASS Development Team"

[Bernardo Santos]

 Hey there!
Here a few more:https://doi.org/10./2041-210X.12750 
(this one is a package based on GRASS)
https://doi.org/10.1016/j.biocon.2018.05.023(this one uses GRASS for analyses)
Best,Bernardo

Em quarta-feira, 9 de janeiro de 2019 12:25:42 BRST, Markus Neteler 
 escreveu:  
 
 Hi Laurent,

On Wed, Jan 9, 2019 at 1:29 PM Laurent C.  wrote:
>
> Hi Markus,
>
> Great, thanks!
> Feel free to add those outputs for which I used GRASS:
> https://doi.org/10.31223/osf.io/vqgx4
> https://doi.org/10.17605/OSF.IO/38W4T
> https://dx.doi.org/10.3390/w10020207

sure, added!

Markus

> Le dim. 9 déc. 2018 à 10:24, Markus Neteler  a écrit :
>> for  fun, to easily track GRASS GIS related publications I have
>> created a new Google Scholar profile:
>>
>> GRASS Development Team (a virtual team!)
>> https://scholar.google.com/citations?user=gJ0ZB0cJ
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user  ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Fw: [LEEClab/LS_METRICS] Testing LSMetrics on Mac OS (#4)

[Bernardo Santos]

 Hello everyone,
My colleague Tatiana have been trying to install and use GRASS GIS 7.2 (and 
7.4) on Mac OS El Capitán but she had no success, even when turning off her 
protection system. We tried googling some solutions for that, as well as 
looking at intructions, but nothing worked (I am not a Mac user, so the extent 
of my help is limited). Can anyone help us with that?

Below you may find her last e-mail describing the problem.

Best,Bernardo

   - Mensagem encaminhada - De: Tatiana Motta-Tavares 
Para: LEEClab/LS_METRICS 
Cc: Bernardo Niebuhr 
; Author Enviado: 
terça-feira, 13 de novembro de 2018 10:23:01 BRSTAssunto: Re: 
[LEEClab/LS_METRICS] Testing LSMetrics on Mac OS (#4)
 
Hi everyone! Tatiana here.

Yes, I have a Macbook pro (it's kind old, I have it since 2012) with OS X El 
Capitan.
I first tried to install the GRASS 7.4, and what's happen is the vault from 
Apple security system don't let it open. But it didn't show any warning or 
message, just don't open. The computes freezes and I must restart the computer 
to proceed. Then I tried to turning off all the system security but nothing 
changes.



When I explore the Activity Monitor to figure out what is happening, I was 
running out of RAM because of a "CoreServicesUIAgent" application. By google 
it, it is related to frameworks.



Next step I'm going to try GRASS 7.2 with all the frameworks previously 
installed. Let's see what happens now.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
   
Links na mensagem (1)

|  |  | 
Downloads - GRASS GIS for Mac
 |

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

Re: [GRASS-user] Example project on GitLab

[Bernardo Santos]

 Hi Vaclav,
thanks for that, it'll be very useful. I think a similar approach can be used 
to build repositories for addons within GitHub, right?Do you see clear 
advantages of using GitLab instead of GitHub for this purposes?
Best,Bernardo Niebuhr

Em segunda-feira, 5 de novembro de 2018 17:50:38 BRST, Vaclav Petras 
 escreveu:  
 
 

On Mon, Nov 5, 2018 at 2:43 PM Ken Mankoff  wrote:

I think I will find it useful in helping some of my custom scripts to official 
plugins.


Glad to hear that! Thanks for sharing your code!

 
On Fri, Nov 2, 2018 at 7:08 PM Vaclav Petras  wrote:

Dear users and devs,
I've created an example project at GitLab. It is a GRASS GIS module written in 
Python. It uses GitLab CI to build the module and publish its documentation as 
a website.

https://gitlab.com/vpetras/r.example.plus
If you are familiar with GitHub, GitLab will feel familiar as well (we can 
discuss the differences later), but the following terminology comparison may 
come useful:

https://about.gitlab.com/2017/09/11/comparing-confusing-terms-in-github-bitbucket-and-gitlab/
Otherwise, I hope the project should describe itself and if something is 
missing or is not documented enough, your can submit an issue or a merge 
request.
Best,Vaclav
PS: We can create a GitLab group for GRASS GIS and move this project there.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

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

Re: [GRASS-user] New addon v.rast.bufferstats

[Bernardo Santos]

Hi Stephan,
That is very interesting, and I see interesting potential uses for that.Does it 
work for any type of input vector (points, polygons, lines)?
I am willing to test it and give you feedback.Some time ago I helped a friend 
develop something alike, but (unfortunately) he was working on ArcGIS, so 
although the plugin is free, the main software is paid. We wanted to translate 
it into a free platform but we didn't have time to do that.The rationale is the 
same, but it performs statistics form vector layers instead - area, counts, 
etc.Take a look here:https://github.com/LEEClab/MSBuffer
BestBernardo
   Em sexta-feira, 24 de agosto de 2018 04:02:18 BRT, Stefan Blumentrath 
 escreveu:  
 
 Hi Rich,

My application for the module is characterizing sampling sites in ecological 
research.
It is mainly a port of 
https://grass.osgeo.org/grass64/manuals/addons/v.what.rast.buffer.html to 
Python - with some enhancements like multiple buffers, DB output, tabulating 
classified raster data (e.g. land cover maps). The purpose is "to provide local 
environmental context to" a series of input geometries.

As mentioned, the module is not incredibly fast, but might help to replace 
users/researcher time with CPU hours...
So, what is appropriate, depends on how much data you throw at the module, your 
patience and how efficient your alternative workflows are...

Would be cool if you could share your experience, in case you try it...

Cheers
Stefan




-Original Message-
From: grass-user  On Behalf Of Rich Shepard
Sent: torsdag 23. august 2018 23:20
To: grass-user grass-user (grass-user@lists.osgeo.org) 

Subject: Re: [GRASS-user] New addon v.rast.bufferstats

On Thu, 23 Aug 2018, Stefan Blumentrath wrote:

> I just uploaded a new addon "v.rast.bufferstats" that extracts 
> different raster statistics in multiple buffers around vector 
> geometries. It is looping over input geometries and thus not very 
> performant with lots of input geometries. But it can be convenient for 
> e.g. characterizing the surrounding of study sites...

Stefan,

  This looks interesting. For what applications would it be appropriate?

Regards,

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

Re: [GRASS-user] Spyder IDE with GRASS

[Bernardo Santos]

 Hi Alex,
I have no sollutions, but I am also interested on that, if someone has hints...
Bernardo
Em sexta-feira, 1 de junho de 2018 14:35:27 BRT, Moody, Alex 
 escreveu:  
 
  
I occasionally try to use GRASS via the Spyder IDE but have not found a 
solution that works so far. I am working in Windows 7 with various versions of 
GRASS (72, 74, 75) through the OSGEO install. My attempts include
 
  
 
1.  Manually installing Spyder into the OSGEO python site-packages 
directory. When I run spyder after launching a GRASS session or from the OSGEO 
shell, nothing happens. I’ve seen the Wiki page discussing Spyder that mentions 
the commandspyder –w . 2>dev/null &, though I am not sure what this is 
attempting to do
 
2.  Making a conda environment and using subprocess per the Wiki. I imagine 
this fails because GRASS isn’t install in this environment. I wonder if there 
is a way to set the environment to use the GRASS python executable?
 
  
 
Has anyone had success using Spyder that could offer some further pointers?
 
  
 
Thanks,
 
Alex 
 ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user  ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] g.region on different mapsets of the same location

[Bernardo Santos]

Dear all,
I am running some GIS procedures in a series of maps present in the same 
location. To speed up the process, I opened different GRASS GIS sections in the 
same location, but in different mapsets, and then, in each section/mapset I ran:
r.in.gdal input input_map_of_this_mapset.tif 
output=input_map_of_this_mapsetg.region map=input_map_of_this_mapset... (a 
series of procedures)
Do you think I'll have problems in this process?Does g.region in a given mapset 
affects the region in other mapsets?(I should also use a temporary region, but 
I am also not sure if these temporary region files are set for the whole 
location or are limited to the current mapset).
Or should I do that in different locations?
Thanks a lot!Bernardo Niebuhr


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

[GRASS-user] Whats happens with r.neighbors at boundaries with NULL cells

[Bernardo Santos]

Dear list,
I have been using r.neighbors for many procedures in some applications lately, 
but I am not sure how it deals with NULL data at the boundaries of the input 
map, and if there are option on how to deal with them.
In some examples I ran for, say, a window of size = 1 pixel, I 'lost' one pixel 
at all boundaries in the output file - they had information in the input but 
were NULL in the output. However, it seems to me that this should not happen, 
since it is written in the manual that 'r.neighbors doesn't propagate NULLs, 
but computes the aggregate over the non-NULL cells in the neighborhood.'
In other examples I ran, I had an opposite result. Not only I had information 
for all the non-NULL cells of the input raster, I also had information in 1 
pixel around it, in pixels that were originally NULL in the input map.And when 
I use the option selection=input_raster, then I exclude this information and 
have only information for the original non-NULL cells of the input map, in the 
output raster.
Anyway, maybe I couldn't test the command properly, but these variation is 
generating some issues later on, when I use these maps for other purposes. 
Could anyone help clarify that?
I can provide some maps for testing, if needed.Best,
Bernardo Niebuhr___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] zonal statistics/metrics - beyond simple statistics

[Bernardo Santos]

 Hi Moritz,
thanks for the comments.
I didn't know that r.mask had a 'cat' option, this makes the whole process more 
direct. The same for using g.region raster=MASK.
Also, the hint about keeping info as text (as you did in i.segment.stats) and 
raster is a very good idea to make the process faster. I'll implement those 
things to speed up the code.
I don't know if it makes it clearer, but what we wanted is to calculate several 
metrics and statistics, using Brazilian city limits as zones (a total of ~5,600 
cities), based on land use maps for the whole country (resolution = 30m), for 
all years from 2000 to 2016. Also, we didn't wanted to calculate only 
general/basic statistics such as average, sum, etc., but also more specific 
metrics such as the area and percentage of different cover classes, edge 
amount, number of forest patches, isolation between forest patches and 
others.That's why I chose to build it in a way we write a given function (that 
calculated any of these metrics) and then we use it as an argument for the 
process, so that we loop over polygons and over input rasters to calculate 
these metrics for each city.
That was my initial aim, but I guess this may also be useful in other cases.
I know r.li (but didn't tested r.pi yet), the metrics it calculates are very 
interesting but somehow limited (of course I could write other ones based on 
the r.li.daemon core function, but I am not very well versed in C to use it 
yet...). Even though, I agree I could use maybe a combination of r.li and make 
some calculations with the output info of r.univar and r.stats to get the same 
numbers, and maybe I would be able to avoid loops.I'll think about it.
Thanks, Moritz and Stephan!BernardoEm quinta-feira, 12 de abril de 2018 
13:15:17 BRT, Moritz Lennert <mlenn...@club.worldonline.be> escreveu:  
 
 On 12/04/18 16:56, Bernardo Santos wrote:
> For example, I am still not sure how I would use a combination of 
> r.univar/r.stats and some kind of input raster map to produce, say, 
> zonal info of number of habitat patches, structural or functional 
> connectivity, isolation, or other more complex metrics used in landscape 
> ecology.
> That's way I was building something like that, so that we can just write 
> an alternative function using any raster input map that returns the 
> value of one of such metrics, and then use it to calculate them over 
> sets of zones.

Have you looked into the landscape metrics modules, notably the r.li 
suite of modules, but also the r.pi suite in the addons (although ISTR 
that the latter is not really usable in its current state) ?

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

Re: [GRASS-user] zonal statistics/metrics - beyond simple statistics

[Bernardo Santos]

 Hi Stephan,
nice points you raised. I didn't know about the Unix philosophy, and indeed it 
seems as a more solid / simple way of building things...
And yeah, I agree that these metrics/statistics I mentioned are not 'general' 
at all.What I meant by general is that we can write any other function that has 
one or more raster/vector maps as input, makes some calculation and returns a 
value, and just use this function as input for this 'GeneralizedZonalStats', 
without having to change anything else...
But yes, I agree that calling that 'Generalized' or 'General' may not be the 
best option...
Best,Bernardo
Em quinta-feira, 12 de abril de 2018 12:18:20 BRT, Stefan Blumentrath 
<stefan.blumentr...@nina.no> escreveu:  
 
 #yiv8564277711 #yiv8564277711 -- _filtered #yiv8564277711 
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv8564277711 
{panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv8564277711 
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv8564277711 
{panose-1:0 0 0 0 0 0 0 0 0 0;}#yiv8564277711 #yiv8564277711 
p.yiv8564277711MsoNormal, #yiv8564277711 li.yiv8564277711MsoNormal, 
#yiv8564277711 div.yiv8564277711MsoNormal 
{margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:New 
serif;}#yiv8564277711 a:link, #yiv8564277711 span.yiv8564277711MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv8564277711 a:visited, #yiv8564277711 
span.yiv8564277711MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv8564277711 
p.yiv8564277711msonormal0, #yiv8564277711 li.yiv8564277711msonormal0, 
#yiv8564277711 div.yiv8564277711msonormal0 
{margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:New 
serif;}#yiv8564277711 p.yiv8564277711msonormal0, #yiv8564277711 
li.yiv8564277711msonormal0, #yiv8564277711 div.yiv8564277711msonormal0 
{margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:New 
serif;}#yiv8564277711 p.yiv8564277711msonormal, #yiv8564277711 
li.yiv8564277711msonormal, #yiv8564277711 div.yiv8564277711msonormal 
{margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:New 
serif;}#yiv8564277711 p.yiv8564277711msochpdefault, #yiv8564277711 
li.yiv8564277711msochpdefault, #yiv8564277711 div.yiv8564277711msochpdefault 
{margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:New 
serif;}#yiv8564277711 span.yiv8564277711msohyperlink {}#yiv8564277711 
span.yiv8564277711msohyperlinkfollowed {}#yiv8564277711 
span.yiv8564277711emailstyle18 {}#yiv8564277711 p.yiv8564277711msonormal1, 
#yiv8564277711 li.yiv8564277711msonormal1, #yiv8564277711 
div.yiv8564277711msonormal1 
{margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:serif;}#yiv8564277711
 span.yiv8564277711msohyperlink1 
{color:blue;text-decoration:underline;}#yiv8564277711 
span.yiv8564277711msohyperlinkfollowed1 
{color:purple;text-decoration:underline;}#yiv8564277711 
p.yiv8564277711msonormal01, #yiv8564277711 li.yiv8564277711msonormal01, 
#yiv8564277711 div.yiv8564277711msonormal01 
{margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:serif;}#yiv8564277711
 span.yiv8564277711emailstyle181 
{font-family:sans-serif;color:#1F497D;}#yiv8564277711 
p.yiv8564277711msochpdefault1, #yiv8564277711 li.yiv8564277711msochpdefault1, 
#yiv8564277711 div.yiv8564277711msochpdefault1 
{margin-right:0cm;margin-left:0cm;font-size:10.0pt;font-family:New 
serif;}#yiv8564277711 span.yiv8564277711EmailStyle30 
{font-family:sans-serif;color:#1F497D;}#yiv8564277711 
.yiv8564277711MsoChpDefault {font-size:10.0pt;} _filtered #yiv8564277711 
{margin:70.85pt 70.85pt 70.85pt 70.85pt;}#yiv8564277711 
div.yiv8564277711WordSection1 {}#yiv8564277711 
Hi Bernado,
 
  
 
It depends what you consider general. Even if I work with landscape ecology 
myself, I would assume landscape metrics or functional connectivity to be 
rather “special” than “general” statistics.
 
  
 
Putting a lot of functionality into one module can be very useful for some 
cases, but can come with a number of drawbacks as well.
 
  
 
A general Unix concept is to do one thing and do it well, and rather write 
modular programs that work together than very complex single tools…
 
  
 
Cheers
 
Stefan
 
  
 
1:https://en.wikipedia.org/wiki/Unix_philosophy
 
  
 
From: Bernardo Santos <bernardo_brand...@yahoo.com.br>
Sent: torsdag 12. april 2018 16.57
To: Helmut Kudrnovsky <hel...@web.de>; grass-user@lists.osgeo.org; Stefan 
Blumentrath <stefan.blumentr...@nina.no>
Subject: Re: RE: [GRASS-user] zonal statistics/metrics - beyond simple 
statistics
 
  
 
Hi Stephan,
 
  
 
Some minutes before you sent me this e-mails, I'd just found out about 
v.db.select -r. It worked and made the process much faster. Thanks for that 
anyway.
 
  
 
In my case, the polygons do not overlap. Indeed, many things could be done with 
r.univar, r.stats or a combination of them and their output info. However, my 
aim was to think about a way of generalizing it, so that we would be able to 
use m

Re: [GRASS-user] zonal statistics/metrics - beyond simple statistics

[Bernardo Santos]

 Hi Stephan,

Some minutes before you sent me this e-mails, I'd just found out about 
v.db.select -r. It worked and made the process much faster. Thanks for that 
anyway.
In my case, the polygons do not overlap. Indeed, many things could be done with 
r.univar, r.stats or a combination of them and their output info. However, my 
aim was to think about a way of generalizing it, so that we would be able to 
use many other functions from the raster maps using the same architecture for 
calculating the zonal statistics/metrics.
For example, I am still not sure how I would use a combination of 
r.univar/r.stats and some kind of input raster map to produce, say, zonal info 
of number of habitat patches, structural or functional connectivity, isolation, 
or other more complex metrics used in landscape ecology.That's way I was 
building something like that, so that we can just write an alternative function 
using any raster input map that returns the value of one of such metrics, and 
then use it to calculate them over sets of zones.
Best,B
PS: thanks for sharing your code! This v.rast.bufferstats seems very useful, 
and I can think of some very interesting applications of that. I helped a 
friend to write something similar but using ArcPy as a ArcMap toolbox, and we 
applied it to some interesting cases in the delimitation of Protected Areas' 
buffer zones (but still did not published it). But doing that with a free and 
open source tool would be much more interesting! Em quarta-feira, 11 de 
abril de 2018 18:32:18 BRT, Stefan Blumentrath <stefan.blumentr...@nina.no> 
escreveu:  
 
 #yiv6359193583 #yiv6359193583 -- _filtered #yiv6359193583 
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv6359193583 
{panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv6359193583 
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv6359193583 
#yiv6359193583 p.yiv6359193583MsoNormal, #yiv6359193583 
li.yiv6359193583MsoNormal, #yiv6359193583 div.yiv6359193583MsoNormal 
{margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:New 
serif;}#yiv6359193583 a:link, #yiv6359193583 span.yiv6359193583MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv6359193583 a:visited, #yiv6359193583 
span.yiv6359193583MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv6359193583 
p.yiv6359193583msonormal0, #yiv6359193583 li.yiv6359193583msonormal0, 
#yiv6359193583 div.yiv6359193583msonormal0 
{margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:New 
serif;}#yiv6359193583 span.yiv6359193583EmailStyle18 
{font-family:sans-serif;color:#1F497D;}#yiv6359193583 
.yiv6359193583MsoChpDefault {font-size:10.0pt;} _filtered #yiv6359193583 
{margin:70.85pt 70.85pt 70.85pt 70.85pt;}#yiv6359193583 
div.yiv6359193583WordSection1 {}#yiv6359193583 
Hi Bernado,
 
  
 
Please find attached the «work-in-progress» version of v.rast.bufferstats for 
some more inspiration.
 
  
 
v.db.select -r does what you are looking for:
 
https://grass.osgeo.org/grass74/manuals/v.db.select.html
 
  
 
However, if the polygons you are working with don`t overlap, looping should not 
be required, and you should be able to use r.univar with zones or r.stats for 
all polygons at once…
 
  
 
Cheers
 
Stefan
 
  
 
  
 
  
 
From: Bernardo Santos <bernardo_brand...@yahoo.com.br>
Sent: onsdag 11. april 2018 20.59
To: Helmut Kudrnovsky <hel...@web.de>; grass-user@lists.osgeo.org; Stefan 
Blumentrath <stefan.blumentr...@nina.no>
Subject: Re: [GRASS-user] zonal statistics/metrics - beyond simple statistics
 
  
 
Hi Helmut and Stefan,
 
  
 
thanks for sharing that with me, it is good to know that there are 
similarongoing approaches to solve related issues.
 
  
 
Helmut,
 
very nice addon. However, it seems to me that the part on calculating 
statistics is still based on v.rast.stats, am I right?
 
  
 
Stefan, the question you pose is indeed very related. I took a better look at 
my code and I noticed that what really takes time is not the process of making 
a mask, but what comes before: the rasterization of one of the polygons of the 
input vector.
 
What I do is:
 
1) g.region using the vector layer, aligning it to the first of the input 
rasters
 
2) v.to.rast selecting only one of the polygons at a time from the vector layer
 
3) r.mask using the rasterized polygon
 
4) g.region zoom=rasterized_polygon
 
5) calculate any function for all raster maps (in principle using a loop), 
using this small region and the mask, and attaching the results to the 
attribute table
 
6) repeat 1-5 for all polygons in the input vector
 
  
 
However, I noticed now that what takes time is v.rast.stats, since it depends 
on the whole region selected, which in my case is much bigger than a single 
polygon (the vector is a set of ~6,000 small polygons).
 
Do you guys know if there is a way of using a single polygon from a vector to 
define the region using something like g.region?
 
[this would be really great!!]
 
somethin

Re: [GRASS-user] zonal statistics/metrics - beyond simple statistics

[Bernardo Santos]

 Hi Helmut and Stefan,
thanks for sharing that with me, it is good to know that there are similar 
ongoing approaches to solve related issues.
Helmut,very nice addon. However, it seems to me that the part on calculating 
statistics is still based on v.rast.stats, am I right?
Stefan, the question you pose is indeed very related. I took a better look at 
my code and I noticed that what really takes time is not the process of making 
a mask, but what comes before: the rasterization of one of the polygons of the 
input vector.What I do is:1) g.region using the vector layer, aligning it to 
the first of the input rasters2) v.to.rast selecting only one of the polygons 
at a time from the vector layer3) r.mask using the rasterized polygon4) 
g.region zoom=rasterized_polygon5) calculate any function for all raster maps 
(in principle using a loop), using this small region and the mask, and 
attaching the results to the attribute table6) repeat 1-5 for all polygons in 
the input vector
However, I noticed now that what takes time is v.rast.stats, since it depends 
on the whole region selected, which in my case is much bigger than a single 
polygon (the vector is a set of ~6,000 small polygons).Do you guys know if 
there is a way of using a single polygon from a vector to define the region 
using something like g.region?[this would be really great!!]something 
likeg.region vector=vector_of_interest cat=1
Best,BernardoEm terça-feira, 10 de abril de 2018 06:01:34 BRT, Stefan 
Blumentrath <stefan.blumentr...@nina.no> escreveu:  
 
 Hei Bernardo,

Just for the record: I am currently working on something similar / related.

First of all I would like to improve speed of v.rast.stats for multiple inputs:
https://www.mail-archive.com/grass-dev@lists.osgeo.org/msg52562.html and 
https://trac.osgeo.org/grass/ticket/3523

Adding a functionality to "tabulate areas" or "count categories" is a next step 
I have in mind which I am working on in v.rast.bufferstats (will be a port of 
v.what.rast.buffer [1] to GRASS 7 / pygrass (with some enhancements)). Once I 
have a good solution there I would like to see if it can be moved to 
v.rast.stats. Support for dbf driver is however a challenge...

I will add my "work in progress" script to github, so you can have a look if 
you like.

Cheers
Stefan

1: https://grass.osgeo.org/grass64/manuals/addons/

-Original Message-
From: grass-user <grass-user-boun...@lists.osgeo.org> On Behalf Of Helmut 
Kudrnovsky
Sent: mandag 9. april 2018 23.19
To: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] zonal statistics/metrics - beyond simple statistics

Bernardo Santos wrote
> Dear GRASS list,
> I am developing a Python script to be able to calculate (virtually 
> any) metrics or statistics for zones/polygons in a vector - in analogy 
> to zonal statistics (such as v.rast.stats).The idea is that one can 
> calculate raster-based metrics (such as proportion of habitat, number 
> of patches, or any metric that can be formalized as a function that 
> takes some information from the input raster and returns a value) for 
> each polygon in the vector, and this is updated as a value in a newly 
> created column in the attribute table of this vector.
> Is there already anything like that (some addon/module) that I am 
> missing, just to avoid re-doing something already created?
> If not, what I am doing is to create a loop over all the features in a 
> vector, and for each one I zoom and use the polygon to define a mask 
> (using r.mask), so that the calculation of the selected metric is 
> performed only over that polygon, and this process is repeated.The 
> script allows one to calculate metrics/statistics for multiple raster 
> maps at once, and to incorporate other function for statistics also. 
> It may be found here:https://github.com/LEEClab/GeneralizedZonalStats
> 
> For small vectors this works nicely and I believe it has a great 
> potential. However, when I try to calculate metrics for a large 
> dataset (e.g. the Brazilian map of cities, with almost 6,000 polygons) 
> - and that is when the tool would be interesting -, the process of 
> creating each mask takes too long (387 steps), and the tool becomes kind of 
> useless.
> Then I have two questions:- First, what drives the number of steps 
> GRASS takes to create a mask? Why it is very small for some maps but 
> very large for others? I quite don't understand that yet.- Do you 
> think of a easier or faster way of doing the same thing (instead of using 
> masks)?
> v.rast.stats seems to use r.univar and the option 'zones' for doing 
> so, but then one gets restricted to the statistics calculated by this module.
> Any help or comment would be very welcome!
> Best,Bernardo Niebuhr
> ___
> grass-user mailing list

> grass-user@.osgeo

[GRASS-user] zonal statistics/metrics - beyond simple statistics

[Bernardo Santos]

Dear GRASS list,
I am developing a Python script to be able to calculate (virtually any) metrics 
or statistics for zones/polygons in a vector - in analogy to zonal statistics 
(such as v.rast.stats).The idea is that one can calculate raster-based metrics 
(such as proportion of habitat, number of patches, or any metric that can be 
formalized as a function that takes some information from the input raster and 
returns a value) for each polygon in the vector, and this is updated as a value 
in a newly created column in the attribute table of this vector.
Is there already anything like that (some addon/module) that I am missing, just 
to avoid re-doing something already created?
If not, what I am doing is to create a loop over all the features in a vector, 
and for each one I zoom and use the polygon to define a mask (using r.mask), so 
that the calculation of the selected metric is performed only over that 
polygon, and this process is repeated.The script allows one to calculate 
metrics/statistics for multiple raster maps at once, and to incorporate other 
function for statistics also. It may be found 
here:https://github.com/LEEClab/GeneralizedZonalStats

For small vectors this works nicely and I believe it has a great potential. 
However, when I try to calculate metrics for a large dataset (e.g. the 
Brazilian map of cities, with almost 6,000 polygons) - and that is when the 
tool would be interesting -, the process of creating each mask takes too long 
(387 steps), and the tool becomes kind of useless.
Then I have two questions:- First, what drives the number of steps GRASS takes 
to create a mask? Why it is very small for some maps but very large for others? 
I quite don't understand that yet.- Do you think of a easier or faster way of 
doing the same thing (instead of using masks)? v.rast.stats seems to use 
r.univar and the option 'zones' for doing so, but then one gets restricted to 
the statistics calculated by this module.
Any help or comment would be very welcome!
Best,Bernardo Niebuhr___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Map boudaries in r.diversity (and r.li)

[Bernardo Santos]

Dear list,
I am using r.diversity to calculate indices of landscape diversity using land 
use maps as input. However, the output maps do not include the edges - the 
moving window excludes the edge pixels. Am I missing something?
Is there a way to create a flag (maybe by setting something in the r.li setup 
file) to include or not these pixels? (i.e., the NULL cells outside the map 
limits won't transform the diversity indices in NULL in these boundary cells)I 
know this may bias the result at the map boundaries, creating a king of edge 
effect, but this could be a decision of the users (with a proper warning, 
maybe).
For instance, when I use moving windows with r.neighbors, I can choose to have 
information for these cells by using select=input_map, in which the same input 
map is used to generate information for these boundary cells.
Thanks for you attention.BestBernardo Niebuhr___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] LSMetrics - addon development

[Bernardo Santos]

 Dear Moritz, 
thanks for the answer and the examples. I'll try to put the functions and files 
in this format and test them like that.I am not sure how to build these 
makefile files but I'll try to follow the patterns I find in the other examples 
of modules.Once this is done, I'll post it here.
Which GRASS version I should use to do that?
Regarding the comparison with the other GRASS tools, LSMetrics is complementary 
to many of the functions the r.li suite offers. I still could not test r.pi 
since I had some trouble installing it, but I'll try it again  so that I can 
compare both packages. I believe they are also somehow complementary in many of 
the functions.
Best,Bernardo


Em quarta-feira, 7 de fevereiro de 2018 13:15:03 BRST, Moritz Lennert 
<mlenn...@club.worldonline.be> escreveu:  
 
 Dear Bernardo,

On 07/02/18 14:55, Bernardo Santos wrote:
> Dear list,
> 
> We have been developing a python application called LSMetrics to 
> calculate landscape metrics for environmental management and ecological 
> research. All functions/metrics use GRASS modules in the process of 
> calculation. More information here:
> https://github.com/LEEClab/LS_METRICS/wiki

Great, thanks !

Out of curiosity: could you maybe explain how this application compares 
to the existing r.li suite of modules in GRASS core 
(https://grass.osgeo.org/grass74/manuals/r.li.html) and the r.pi suite 
of modules in GRASS addons (there seems to be a problem with building 
the manual pages, but you can get an idea by looking at the 
description.html file here: 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.pi) ? 
I am no expert in the field of landscape metrics and am just wondering 
how this all fits into the picture.

> 
> Basically we have several python functions, each of which calculates a 
> different metric. All of them are then called by a single function that 
> can coordinate the calculation of several metrics for several maps in a row.
> Currently the metrics can be calculated for input maps using a grafical 
> interface (we call it from the GRASS shell using "python 
> LS_metrics_v1_0_0.py") or by calling python shell from the GRASS shell 
> and then using python scripting to call the functions (importing 
> functions and then calling them directly). We wish to transform these 
> function into one (or more than one) grass addon.
> 
> Then I have two questions:
> - Do you think it would be better to build a single addon (e.g. called 
> r.ls.metrics) so that each metrics is defined by a parameter (e.g. 
> method = "patch_size", "fragment_size", "structural connectivity" ...), 
> or rather a set of addons, each one corresponding to a single landscape 
> metrics (e.g. r.ls.patch_size, r.ls.fragment_size, ...)?

The other two suites have gone for separate modules for each metric. I'm 
not sure what the rationale was behind that choice, but I guess we 
should try to be consistent across similar module suites.

> 
> - Also, I have looked on how to build the addon in GRASS help pages but 
> I am not sure about some details. Can you send me some references to 
> ease that process?

The basic idea for a module for addons is to create a directory with the 
source file(s), the html file for the manual page and a Makefile.

Please follow the general submitting rules as explained at 
https://trac.osgeo.org/grass/wiki/Submitting.

To get an idea of the structure of a suite of modules in Addons, you 
could look at the recently added r.sentinel tools: 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.sentinel

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

[GRASS-user] LSMetrics - addon development

[Bernardo Santos]

Dear list,
We have been developing a python application called LSMetrics to calculate 
landscape metrics for environmental management and ecological research. All 
functions/metrics use GRASS modules in the process of calculation. More 
information here:https://github.com/LEEClab/LS_METRICS/wiki

Basically we have several python functions, each of which calculates a 
different metric. All of them are then called by a single function that can 
coordinate the calculation of several metrics for several maps in a 
row.Currently the metrics can be calculated for input maps using a grafical 
interface (we call it from the GRASS shell using "python LS_metrics_v1_0_0.py") 
or by calling python shell from the GRASS shell and then using python scripting 
to call the functions (importing functions and then calling them directly). We 
wish to transform these function into one (or more than one) grass addon.
Then I have two questions:- Do you think it would be better to build a single 
addon (e.g. called r.ls.metrics) so that each metrics is defined by a parameter 
(e.g. method = "patch_size", "fragment_size", "structural connectivity" ...), 
or rather a set of addons, each one corresponding to a single landscape metrics 
(e.g. r.ls.patch_size, r.ls.fragment_size, ...)?
- Also, I have looked on how to build the addon in GRASS help pages but I am 
not sure about some details. Can you send me some references to ease that 
process?
Thanks a lot. Below you can find more information regarding the 
metrics.BestBernardo Niebuhr
_
Metrics calculated:Metrics related to structural connectivity:- patch size- 
fragment size (excludes corridors with a given edge depth)- structural 
connectivity- proportion of habitat (within a window around each pixel)Metrics 
related to functional connectivity- functionally connected area (considering 
the capacity of organisms to cross gaps between habitat patches)- functional 
connectivityMetrics related to habitat edges- distance from edges- 
clasisfication edge/core/matrix (considering a given edge depth)- proportion of 
edge and core (within a window around each pixel)Metrics of landscape 
diversity(we are currently using the r.diversity add on to calculate that)

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

[GRASS-user] Contributions to GRASS wiki

[Bernardo Santos]

Hi list,
Is it possible for us common users to contribute to the GRASS wiki?I have been 
learning a lot from it - for instance, while using grass scripting - , and 
sometimes I see some details that could improve the understanding by other 
users, and could use my time while learning to contribute to that (the ideal 
would be that some one checks it after that).
Is this possible?
Thanks!Bernardo___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS GIS and alternative command line terminals in Windows

[Bernardo Santos]

 Hello all,
Despite all these functionalities that Helmut cited, I agree with Sajid that it 
is much easier and friendly to use the terminal in UNIX systems than in 
Windows. It would be great if an equivalent alternative was available...
Best,Bernardo
Em quinta-feira, 23 de novembro de 2017 14:17:44 BRST, Helmut Kudrnovsky 
 escreveu:  
 
 Sajid Pareeth-2 wrote
> What I am looking for is a way to
> use GRASS GIS in UNIX like third party terminals in windows, so that I can
> use basic UNIX based commands.

also pipes e.g. to be used with grep, works in the windows own cmd




-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user  ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Cannot open GRASS welcome GUI

[Bernardo Santos]

Hi Helmut,
it is installed. I tried to reinstall it with apt-get but the most updated 
version was already installed.
Then I could run it by updating wxpython usingconda install wxpythonand then 
re-installing grass-gui using apt-get.
Now it is working.Thanks!
Bernardo Niebuhr


Em quarta-feira, 18 de outubro de 2017 10:10:06 BRST, Helmut Kudrnovsky 
 escreveu:  
 
 >ERROR: wxGUI requires wxPython. No module named wxversion

as the error message says: have you wxversion installed? Have a look into
your package manager if it's on your system.



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Cannot open GRASS welcome GUI

[Bernardo Santos]

Hi,
I am running GRASS GIS on ubuntu 14.04. I was trying to run g.extension and 
started GRASS through command line using grass -textIt then set the text 
version as default.
Now I cannot open GRASS with the welcoming screen anymore, which asks the 
location and mapset before starting grass.When I type grass -gui, I get this 
error message:
Cleaning up temporary files...
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
ERROR: Error in GUI startup. See messages above (if any) and if necessary, 
please report this error to the GRASS developers.
On systems with package manager, make sure you have the right GUI package, 
probably named grass-gui, installed.
To run GRASS GIS in text mode use the -text flag.
Use '--help' for further options
 grass72 --help
See also: https://grass.osgeo.org/grass72/manuals/helptext.html
Exiting...
However, my wxpython version is updated, and I did not found what to do in list 
posts. This is probably very basic, but I could not solve it (even by 
reinstalling grass).
Thanks!Bernardo

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