Re: [GRASS-user] r.resamp.bspline lambda default
Hi Eric, On Wed, Dec 9, 2020 at 4:15 PM Eric Patton wrote: > > Hi, > > I noticed that when r.resamp.bspline is invoked with the --help flag, the > default lambda parameter is reported as 0.01, but in the manual page, there is > this text: > > "For seamless NULL cell interpolation, a small (lambda) value is required and > default is set to 0.005". > > Is this a typo in the doc? Yes, I would say so. With "git blame" it is easy to track changes. It was changes from 0.005 to 0.01 in this change https://github.com/OSGeo/grass/commit/62242c0dc8802cbe9c9b21af36e2afadff128ddf and the needed documentation update didn't happen. Thanks for catching this. Fixed in https://github.com/OSGeo/grass/commit/33d147388119b8dcc65adb9607337805841a0e49 and backported (upcoming 7.8.5). cheers, Markus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.resamp.bspline lambda default
Hi, I noticed that when r.resamp.bspline is invoked with the --help flag, the default lambda parameter is reported as 0.01, but in the manual page, there is this text: "For seamless NULL cell interpolation, a small (lambda) value is required and default is set to 0.005". Is this a typo in the doc? -- Eric ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] unstable results with r.param.scale ?
Hi Māris, Here is the region information : g.region -p projection: 1 (UTM) zone: 10 datum: nad83 ellipsoid: grs80 north: 4009245.5 south: 4008455.5 west: 684018.58 east: 685270.58 nsres: 1 ewres: 1 rows: 790 cols: 1252 cells: 989080 GRASS installed from ubuntugis-unstable (focal). Following Vincent's feedback I will look into the compilation options used. Best, Vincent Le 09/12/2020 à 14:25, Maris Nartiss a écrit : Please state your computation region settings. This seems like a overflow / memory corruption and region settings might play a role here. Māris. -- Vincent Godard CEREGE, OSU Pythéas Aix-Marseille Université Europôle Méditerranéen de l’Arbois - BP 80 13545 Aix-en-Provence cedex 04, France god...@cerege.fr ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] unstable results with r.param.scale ?
Don't have time right now, but running it with valgrind might show the
problem.
Anna
On Wed, Dec 9, 2020 at 8:27 AM Vincent Bain wrote:
> Hello Vincent,
>
> in case it could be related to my recent issue with r.param.scale:
>
> https://lists.osgeo.org/pipermail/grass-user/2020-October/081788.html
>
> In my case there was most probably something wrong with my OpenMP
> configuration.
>
> HTH,
> Vincent.
>
> Le mercredi 09 décembre 2020 à 13:59 +0100, Vincent Godard a écrit :
> > Dear Grass users,
> >
> > I've been using r.param.scale to compute various type of curvatures
> > over
> > a 1 m LiDAR DEM (FCELL) (from opentopography.org) :
> >
> > r.param.scale --o -c input=dem output=curvature size=15 method=profc
> > r.info -r curvature
> >
> > I usually get reasonable results like (checked with independent
> > calculations) :
> >
> > min=-0.203124601340989
> > max=0.0685868278408049
> >
> > But when running this command repeatedly, I randomly (usually every
> > 3rd
> > or 4th time) get very different results like :
> >
> > min=-127112309.998249
> > max=131128979.492382
> >
> > I am running GRASS 7.8.4 on Ubuntu 20.04. The problem is also
> > present
> > when running r.param.scale from QGIS or rgrass7 (in a R session).
> >
> > I have replicated the problem with another high resolution DEM of
> > different source (still FCELL), and also with a 30 m SRTM DEM
> > (CELL),
> > but in this case the occurrence of these odd results is less
> > frequent
> > and they are not contrasting as much with the expected outcome
> > ("only"
> > by a 1 or 2 order of magnitude). The problem is present with or
> > without
> > the -c option, and seems only to affect the computation of
> > curvatures
> > (profc,planc,longc,crosc,minic,maxic).
> >
> > Has anyone encountered something like that, or have any idea about
> > what
> > might be going on?
> >
> > Thanks in advance,
> >
> > Vincent
> >
>
> ___
> 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] r.futures not working
On Wed, Dec 9, 2020 at 8:37 AM Tom Hackbarth wrote: > Dear grass users, > > I am trying to work my way through the r.futures workshop ( > https://grasswiki.osgeo.org/wiki/Workshop_on_urban_growth_modeling_with_FUTURES#Potential_submodel), > but as soon as I get to the point of using the first r.futures module - > r.futures-potential I come to a dead end. > > This is the message I get: > > ___ > > r.futures.potential input=sampling@practice1 output=potential.csv > columns=devpressure_0_5_92,road_dens_perc,forest_1992_smooth_perc,dist_to_water_km,dist_to_protected_km > developed_column=urban_change_clip subregions_column=counties > Computing model... > Traceback (most recent call last): > File "C:\Users\\AppData\Roaming\GRASS7\addons/scripts > /r.futures.potential.py", line 221, in > sys.exit(main()) > File "C:\Users\\AppData\Roaming\GRASS7\addons/scripts > /r.futures.potential.py", line 192, in main > p = subprocess.Popen(cmd, stdout=subprocess.PIPE, > stderr=subprocess.PIPE) > File "D:\Programme\apps\Python37\lib\subprocess.py", line > 756, in __init__ > restore_signals, start_new_session) > File "D:\Programme\apps\Python37\lib\subprocess.py", line > 1155, in _execute_child > startupinfo) > FileNotFoundError: [WinError 2] The system cannot find the file > specified) > > _ > > There seems to be a problem with the Python code. I also tried to work it > out on linux manjaro, but I get more or less the same error message in the > End. > > Is there anyone who can help me on this? I came not even close to > repairing the error, so I am happy about any advice one can give me. > > Thank you in advance. > > Copying response from grass-web: r.futures.potential calls Rscript, so the error means it can't find the Rscript binary. If R is installed, I would recommend reinstalling GRASS, during installation it tries to automatically look for it, so there is a chance it will work then. I would recommend subscribing to grass-user mailing list and ask more questions there. Anna > Best regards > > Tom > ___ > 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.futures not working
Dear grass users, I am trying to work my way through the r.futures workshop ( https://grasswiki.osgeo.org/wiki/Workshop_on_urban_growth_modeling_with_FUTURES#Potential_submodel), but as soon as I get to the point of using the first r.futures module - r.futures-potential I come to a dead end. This is the message I get: ___ r.futures.potential input=sampling@practice1 output=potential.csv columns=devpressure_0_5_92,road_dens_perc,forest_1992_smooth_perc,dist_to_water_km,dist_to_protected_km developed_column=urban_change_clip subregions_column=counties Computing model... Traceback (most recent call last): File "C:\Users\\AppData\Roaming\GRASS7\addons/scripts /r.futures.potential.py", line 221, in sys.exit(main()) File "C:\Users\\AppData\Roaming\GRASS7\addons/scripts /r.futures.potential.py", line 192, in main p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE) File "D:\Programme\apps\Python37\lib\subprocess.py", line 756, in __init__ restore_signals, start_new_session) File "D:\Programme\apps\Python37\lib\subprocess.py", line 1155, in _execute_child startupinfo) FileNotFoundError: [WinError 2] The system cannot find the file specified) _ There seems to be a problem with the Python code. I also tried to work it out on linux manjaro, but I get more or less the same error message in the End. Is there anyone who can help me on this? I came not even close to repairing the error, so I am happy about any advice one can give me. Thank you in advance. Best regards Tom ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] unstable results with r.param.scale ?
Hello Vincent,
in case it could be related to my recent issue with r.param.scale:
https://lists.osgeo.org/pipermail/grass-user/2020-October/081788.html
In my case there was most probably something wrong with my OpenMP
configuration.
HTH,
Vincent.
Le mercredi 09 décembre 2020 à 13:59 +0100, Vincent Godard a écrit :
> Dear Grass users,
>
> I've been using r.param.scale to compute various type of curvatures
> over
> a 1 m LiDAR DEM (FCELL) (from opentopography.org) :
>
> r.param.scale --o -c input=dem output=curvature size=15 method=profc
> r.info -r curvature
>
> I usually get reasonable results like (checked with independent
> calculations) :
>
> min=-0.203124601340989
> max=0.0685868278408049
>
> But when running this command repeatedly, I randomly (usually every
> 3rd
> or 4th time) get very different results like :
>
> min=-127112309.998249
> max=131128979.492382
>
> I am running GRASS 7.8.4 on Ubuntu 20.04. The problem is also
> present
> when running r.param.scale from QGIS or rgrass7 (in a R session).
>
> I have replicated the problem with another high resolution DEM of
> different source (still FCELL), and also with a 30 m SRTM DEM
> (CELL),
> but in this case the occurrence of these odd results is less
> frequent
> and they are not contrasting as much with the expected outcome
> ("only"
> by a 1 or 2 order of magnitude). The problem is present with or
> without
> the -c option, and seems only to affect the computation of
> curvatures
> (profc,planc,longc,crosc,minic,maxic).
>
> Has anyone encountered something like that, or have any idea about
> what
> might be going on?
>
> Thanks in advance,
>
> Vincent
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] unstable results with r.param.scale ?
Please state your computation region settings. This seems like a overflow / memory corruption and region settings might play a role here. Māris. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] unstable results with r.param.scale ?
Dear Grass users,
I've been using r.param.scale to compute various type of curvatures over
a 1 m LiDAR DEM (FCELL) (from opentopography.org) :
r.param.scale --o -c input=dem output=curvature size=15 method=profc
r.info -r curvature
I usually get reasonable results like (checked with independent
calculations) :
min=-0.203124601340989
max=0.0685868278408049
But when running this command repeatedly, I randomly (usually every 3rd
or 4th time) get very different results like :
min=-127112309.998249
max=131128979.492382
I am running GRASS 7.8.4 on Ubuntu 20.04. The problem is also present
when running r.param.scale from QGIS or rgrass7 (in a R session).
I have replicated the problem with another high resolution DEM of
different source (still FCELL), and also with a 30 m SRTM DEM (CELL),
but in this case the occurrence of these odd results is less frequent
and they are not contrasting as much with the expected outcome ("only"
by a 1 or 2 order of magnitude). The problem is present with or without
the -c option, and seems only to affect the computation of curvatures
(profc,planc,longc,crosc,minic,maxic).
Has anyone encountered something like that, or have any idea about what
might be going on?
Thanks in advance,
Vincent
--
Vincent Godard
CEREGE, OSU Pythéas
Aix-Marseille Université
Europôle Méditerranéen de l’Arbois - BP 80
13545 Aix-en-Provence cedex 04, France
god...@cerege.fr
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
