Re: [GRASS-user] sample a strds at specific locations (areas)

[Veronica Andreo]

I had a similar problem some time ago, just that it was not raster
resolution, but region resolution that I changed to solve my problem (see
this thread and MM's answer:
http://osgeo-org.1560.x6.nabble.com/v-to-rast-for-polygons-not-overlapping-center-of-raster-cell-td5355686.html#a5355729
)

IIUC, MM's proposed solution to my case then does not work anymore because
v.to.rast call inside v.rast.stats is affected by the region alignment to
the raster to be queried. So, the solution is indeed now, to change raster
resolution... ? Then the region would be aligned to it (them)?

If one has large areas or long time series and has to resample all rasters
to get smallish polygons rasterized, I do not see the advantage of this new
behavior... but maybe I'm missing something

Cheers,
Vero

El mié., 6 feb. 2019 16:54, Stefan Blumentrath 
escribió:

> Ciao Madi, Vero,
>
>
>
> Starting with GRASS 7.6, also centroids are used to get the raster
> representation of your area vector map. That increases the likelihood of
> smaller areas to be rasterized.
>
> Increasing the resolution of the current region alone does not help,
> because v.rast.stats temporarily changes the computational region to align
> with the input raster map(s) (see also:
> https://trac.osgeo.org/grass/ticket/3523 and
> https://trac.osgeo.org/grass/ticket/3598 for discussion) Even if the
> first ticket is closed, comments are welcome.
>
> It might make sense to add a flag to v.rast.stats like in r.slope.aspect
> to not align the computational region.
>
>
>
> Furthermore, with regards to efficiency, v.strds.stats could gain some
> speed if multi-raster support in v.rast.stats - added in G 7.6 - would be
> handed down to the addon. Might almost double the speed for larger STRDS…
>
>
>
> Cheers
>
> Stefan
>
>
>
> *From:* grass-user  *On Behalf Of 
> *Veronica
> Andreo
> *Sent:* onsdag 6. februar 2019 17:20
> *To:* Margherita Di Leo 
> *Cc:* GRASS user list 
> *Subject:* Re: [GRASS-user] sample a strds at specific locations (areas)
>
>
>
> Hi Madi
>
>
>
> El mié., 6 feb. 2019 a las 16:31, Margherita Di Leo ()
> escribió:
>
> I have a question regarding v.strds.stats. I get the following warning
> message:
>
>
>
> WARNING: Not all vector categories converted to raster. Converted 120 of
> 265.
>
>
>
> What could be the reason for that?
>
>
>
> Some vector areas might not be converted because they are too small with
> respect to the pixel size that you try to query. Others will tell better
> but I think the polygon must overlap the center of the pixel in order to be
> converted into raster. One solution could be to resample your rasters to a
> higher resolution.
>
> HTH,
>
> Vero
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] sample a strds at specific locations (areas)

[Stefan Blumentrath]

Ciao Madi, Vero,

Starting with GRASS 7.6, also centroids are used to get the raster 
representation of your area vector map. That increases the likelihood of 
smaller areas to be rasterized.
Increasing the resolution of the current region alone does not help, because 
v.rast.stats temporarily changes the computational region to align with the 
input raster map(s) (see also: https://trac.osgeo.org/grass/ticket/3523 and 
https://trac.osgeo.org/grass/ticket/3598 for discussion) Even if the first 
ticket is closed, comments are welcome.
It might make sense to add a flag to v.rast.stats like in r.slope.aspect to not 
align the computational region.

Furthermore, with regards to efficiency, v.strds.stats could gain some speed if 
multi-raster support in v.rast.stats - added in G 7.6 - would be handed down to 
the addon. Might almost double the speed for larger STRDS…

Cheers
Stefan

From: grass-user  On Behalf Of Veronica 
Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo 
Cc: GRASS user list 
Subject: Re: [GRASS-user] sample a strds at specific locations (areas)

Hi Madi

El mié., 6 feb. 2019 a las 16:31, Margherita Di Leo 
(mailto:direg...@gmail.com>>) escribió:
I have a question regarding v.strds.stats. I get the following warning message:

WARNING: Not all vector categories converted to raster. Converted 120 of 265.

What could be the reason for that?

Some vector areas might not be converted because they are too small with 
respect to the pixel size that you try to query. Others will tell better but I 
think the polygon must overlap the center of the pixel in order to be converted 
into raster. One solution could be to resample your rasters to a higher 
resolution.
HTH,
Vero
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] sample a strds at specific locations (areas)

[Veronica Andreo]

Hi Madi

El mié., 6 feb. 2019 a las 16:31, Margherita Di Leo ()
escribió:

> I have a question regarding v.strds.stats. I get the following warning
> message:
>
> WARNING: Not all vector categories converted to raster. Converted 120 of
> 265.
>
> What could be the reason for that?
>

Some vector areas might not be converted because they are too small with
respect to the pixel size that you try to query. Others will tell better
but I think the polygon must overlap the center of the pixel in order to be
converted into raster. One solution could be to resample your rasters to a
higher resolution.
HTH,
Vero
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Adding map to layer manager (wxpython GUI) from grass console?

[Rich Shepard]

On Wed, 6 Feb 2019, Joe wrote:


GRASS 7.2.2 (gisdemo_ncspm):~ > d.rast map=basins@PERMANENT
ERROR: Neither MONITOR (managed by d.mon command) nor
  GRASS_RENDER_IMMEDIATE (used for direct rendering) defined



Joe,

First, open a display monitor:

d.mon start=wx0

When you're finished, close the monitor:

d.mon stop=wx0

Of course, you can open multiple monitors (I don't know the maximum as I've
used only 2 at most) by incrementing the wxN integer.

HTH,

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

Re: [GRASS-user] sample a strds at specific locations (areas)

[Margherita Di Leo]

I have a question regarding v.strds.stats. I get the following warning
message:

WARNING: Not all vector categories converted to raster. Converted 120 of
265.

What could be the reason for that?

Thanks,

On Tue, Feb 5, 2019 at 3:30 PM Margherita Di Leo  wrote:

> Grazie Vero!! Kudos to Luca (author) :-)
>
> On Tue, Feb 5, 2019 at 3:27 PM Veronica Andreo 
> wrote:
>
>> Hi Madi,
>>
>> check the add-on v.strds.stats (
>> https://grass.osgeo.org/grass74/manuals/addons/v.strds.stats.html) that
>> does exactly that :)
>>
>> cheers,
>> Vero
>>
>> El mar., 5 feb. 2019 a las 15:21, Margherita Di Leo ()
>> escribió:
>>
>>> Hi,
>>>
>>> I need to sample a strds at specific locations, but rather than point
>>> locations I need to pass a vector with areas. I need to know the average
>>> value within each area at each given time. How could I do this?
>>>
>>> Thanks in advance
>>>
>>> --
>>> Margherita Di Leo
>>> ___
>>> grass-user mailing list
>>> grass-user@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/grass-user
>>
>>
>
> --
> Margherita Di Leo
>


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

Re: [GRASS-user] High tension with r.resamp.rst

[Ghislain Vieilledent]

Ciao Nikos,
The pdf is available at the web link provided in the email. Thanks for giving a 
look.
Cheers,
Ghislain

Le 6 février 2019 15:19:22 GMT+01:00, Nikos Alexandris 
 a écrit :
>* Ghislain Vieilledent | CIRAD 
>[2019-02-06 14:11:04 +0100]:
>
>>Dear GRASS GIS user,
>>
>>I am using r.resamp.rst to interpolate climatic data at 30sec 
>>resolution over Africa.
>>
>>Grass script, data, and results are available here:
>>https://nextcloud.fraisedesbois.net/index.php/s/CKzsZCSCqMTY9rq
>>
>>#===
>>
>># Import Africa shapefile
>>v.in.ogr --overwrite input=gisdata/vectors/Africa layer=Africa
>output=Africa
>>
>># Rasterize Africa at 30 arc-sec resolution
>>g.region -ap vector=Africa res=0:00:30
>>v.to.rast input=Africa type=area output=Africa use=val value=1
>>
>># Import climate
>>r.in.gdal --overwrite input=gisdata/rasters/test1.1_044.tif
>output=test1_1
>>
>># Resample with RST
>>g.region -ap raster=test1_1
>># Note: use maskmap=Africa to save computation time
>>r.resamp.rst --overwrite input=test1_1 elevation=test1_1_rst \\
>> ew_res=0.00833 ns_res=0.00833 maskmap=Africa
>>r.info test1_1_rst
>>
>># Resample to exact resolution 0:00:30
>>g.region -ap res=0:00:30
>>r.resample --overwrite input=test1_1_rst output=test1_1_30s
>>
>># Export
>>r.out.gdal --overwrite input=test1_1_30s \\
>> output=output/test1_1_30s.tif type=Float32 \\
>> createopt='compress=lzw,predictor=2'
>>
>>#===
>>
>>When I use r.info on the interpolated raster, it indicates a tension 
>>of 7278 in the comments which seems very high to me as the default 
>>value is 40.
>>
>>|   Comments:
>>|tension=7278.552524
>>|dnorm=5.495598, zmult=1.00
>>|KMAX=50, KMIN=35, errtotal=0.000535
>>|zmin_data=0.056488, zmax_data=3.756866
>>|zmin_int=-0.066779, zmax_int=3.214336
>>
>>On the other side, results do not look so bad (see test.pdf figure).
>
>I am following this thread out of curiosity/interest on resampling. 
>The
>.pdf file is not attached.  How big is it?
>
>Nikos
>
>
>>Would you have any comment on this high value for the tension and do 
>>you think interpolation has been performed correctly ?
>>
>>Best regards,
>>
>>Ghislain

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] sharing GRASS mapsets

[Laura Poggio]

Hi Stefan,
that helps a lot actually. The suggestion to subdivide the mapset is a good
one. But we also need a way to have more than one person (not all users)
able to manage everything. So probably  the GRASS_SKIP_MAPSET_OWNER_CHECK
is a good option if used carefully.

Thanks a lot

Laura

On Wed, 6 Feb 2019 at 14:47, Stefan Blumentrath 
wrote:

> Hi Laura,
>
>
>
> There are several options.
>
>
>
> One option would be to subdivide “ENVIROMENTAL_COVARIATES” into e.g.
> topics.
>
> In my organisation (also environmental research) we organized mapsets with
> prefixes (g_ for mapsets of general interest, gt_ for time series, p_ for
> projects, u_ for users). Different users can take care of different topics
> (but everybody has to clean up his/her own mess).
>
> These mapsets can then easily added to the users search_path with
> g.mapsets (https://grass.osgeo.org/grass74/manuals/g.mapsets.html)…
>
>
>
> An advantage of splitting up ENVIROMENTAL_COVARIATES into smaller mapsets
> is that it is easier to move chunks of data (e.g. from central storage to
> compute units (laptop/server))…
>
>
>
> If your users are allowed to change file ownership, they could in
> principle take over “ENVIROMENTAL_COVARIATES”. However, an important
> point of the ownership check implemented in GRASS is to make sure that
> users do not shoot each others in the foot…
>
> That check can be overwritten with the GRASS_SKIP_MAPSET_OWNER_CHECK
> environment variable (see:
> https://grass.osgeo.org/grass74/manuals/variables.html)
>
>
>
> See also the related issue: https://trac.osgeo.org/grass/ticket/1829
>
>
>
> For both of the latter options there is a significant risk in a multi-user
> environment…
>
>
>
> Hope that helps a bit…
>
>
>
> Cheers
>
> Stefan
>
>
>
> *From:* grass-user  *On Behalf Of *Laura
> Poggio
> *Sent:* onsdag 6. februar 2019 12:22
> *To:* GRASS user list 
> *Subject:* [GRASS-user] sharing GRASS mapsets
>
>
>
> Dear all,
>
> we need to share a GRASS location and its mapsets across multiple users.
>
> We would like to have a structure similar to this:
>
> LOCATION:
>
>  PERMANENT
>
>  ENVIROMENTAL_COVARIATES
>
>  working_mapset_for_each_user
>
>
>
> It is clear in the documentation that a user can only write in a mapset
> that it owns.
>
> However we would need to have multiple users to be able to
> add/delete/modify files to the ENVIROMENTAL_COVARIATES mapset. Is this
> possible at all? any workaround that can be implemented?
>
>
>
> Thanks in advance
>
>
>
> Laura
>
>
>
>
>
>
>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] High tension with r.resamp.rst

[Nikos Alexandris]

* Ghislain Vieilledent | CIRAD  [2019-02-06 
14:11:04 +0100]:


Dear GRASS GIS user,

I am using r.resamp.rst to interpolate climatic data at 30sec 
resolution over Africa.


Grass script, data, and results are available here:
https://nextcloud.fraisedesbois.net/index.php/s/CKzsZCSCqMTY9rq

#===

# Import Africa shapefile
v.in.ogr --overwrite input=gisdata/vectors/Africa layer=Africa output=Africa

# Rasterize Africa at 30 arc-sec resolution
g.region -ap vector=Africa res=0:00:30
v.to.rast input=Africa type=area output=Africa use=val value=1

# Import climate
r.in.gdal --overwrite input=gisdata/rasters/test1.1_044.tif output=test1_1

# Resample with RST
g.region -ap raster=test1_1
# Note: use maskmap=Africa to save computation time
r.resamp.rst --overwrite input=test1_1 elevation=test1_1_rst \\
ew_res=0.00833 ns_res=0.00833 maskmap=Africa
r.info test1_1_rst

# Resample to exact resolution 0:00:30
g.region -ap res=0:00:30
r.resample --overwrite input=test1_1_rst output=test1_1_30s

# Export
r.out.gdal --overwrite input=test1_1_30s \\
output=output/test1_1_30s.tif type=Float32 \\
createopt='compress=lzw,predictor=2'

#===

When I use r.info on the interpolated raster, it indicates a tension 
of 7278 in the comments which seems very high to me as the default 
value is 40.


|   Comments:
|tension=7278.552524
|dnorm=5.495598, zmult=1.00
|KMAX=50, KMIN=35, errtotal=0.000535
|zmin_data=0.056488, zmax_data=3.756866
|zmin_int=-0.066779, zmax_int=3.214336

On the other side, results do not look so bad (see test.pdf figure).


I am following this thread out of curiosity/interest on resampling.  The
.pdf file is not attached.  How big is it?

Nikos


Would you have any comment on this high value for the tension and do 
you think interpolation has been performed correctly ?


Best regards,

Ghislain

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

Re: [GRASS-user] sharing GRASS mapsets

[Stefan Blumentrath]

Hi Laura,

There are several options.

One option would be to subdivide “ENVIROMENTAL_COVARIATES” into e.g. topics.
In my organisation (also environmental research) we organized mapsets with 
prefixes (g_ for mapsets of general interest, gt_ for time series, p_ for 
projects, u_ for users). Different users can take care of different topics (but 
everybody has to clean up his/her own mess).
These mapsets can then easily added to the users search_path with g.mapsets 
(https://grass.osgeo.org/grass74/manuals/g.mapsets.html)…

An advantage of splitting up ENVIROMENTAL_COVARIATES into smaller mapsets is 
that it is easier to move chunks of data (e.g. from central storage to compute 
units (laptop/server))…

If your users are allowed to change file ownership, they could in principle 
take over “ENVIROMENTAL_COVARIATES”. However, an important point of the 
ownership check implemented in GRASS is to make sure that users do not shoot 
each others in the foot…
That check can be overwritten with the GRASS_SKIP_MAPSET_OWNER_CHECK 
environment variable (see: 
https://grass.osgeo.org/grass74/manuals/variables.html)

See also the related issue: https://trac.osgeo.org/grass/ticket/1829

For both of the latter options there is a significant risk in a multi-user 
environment…

Hope that helps a bit…

Cheers
Stefan

From: grass-user  On Behalf Of Laura Poggio
Sent: onsdag 6. februar 2019 12:22
To: GRASS user list 
Subject: [GRASS-user] sharing GRASS mapsets

Dear all,
we need to share a GRASS location and its mapsets across multiple users.
We would like to have a structure similar to this:
LOCATION:
 PERMANENT
 ENVIROMENTAL_COVARIATES
 working_mapset_for_each_user

It is clear in the documentation that a user can only write in a mapset that it 
owns.
However we would need to have multiple users to be able to add/delete/modify 
files to the ENVIROMENTAL_COVARIATES mapset. Is this possible at all? any 
workaround that can be implemented?

Thanks in advance

Laura




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

Re: [GRASS-user] 3D raster remove voxels above DEM

[Moritz Lennert]

On 6/02/19 14:02, Francois Chartier wrote:

Thanks Moritz

My goal is to summarize the steps for 3d interpolation at the end of the 
process. it took me a year to get here and still have a few more steps 
to do which i will contact the User list for.
I am actually doing this as part of a 2nd master thesis with le Cnam in 
Paris as continuing education, so i will formalize the process.


The voxels above the dem are not Null values in this interpolation as 
the vvolrst interpolates the data within the full 'footprint' of the 
g.region; is there a possibility to constrain the interpolation to in 
between the DEM and lower surface, by setting a more customized Region 
than a Block?


You could try r3.mask.

Moritz





On Feb 6, 2019 04:45, "Moritz Lennert" > wrote:


Hi François,

Thanks for sharing the solution you found. From your first mail it was
clear to me what these voxels above the DEM contained. NULL values ?

It would be great if you could summarize all your experience working on
3D data in GRASS GIS in the wiki, at least by amending
https://grasswiki.osgeo.org/wiki/Help_with_3D with your additions or
corrections ? This would be very helpful many others.

Moritz


On 6/02/19 03:46, Francois Chartier wrote:
 > See attached screenshot, I was able to remove voxels above the
DEM and
 > below bedrock surface using r3.out.vtk and selecting export as
 > *pointdata (p)* not voxels.  If exported as a Voxel from
r3.out.vtk, the
 > voxel file did not open properly in Paraview could be due to size of
 > file. I changed option to export as points and it is working.
 > grid resolution is 5 x 5 x 1 m over 4km x 4 km x 65 m thickness
approx.
 > (actual thickness varies between DEM and top of rock).
 >
 > r3.out.vtk -p -s input=jan27551tens100@Toronto
output=C:\Users\Francois
 > Chartier\Documents\GeoModel\WorkingFile\Feb6_VTK_Pts
top=GTADEM@Toronto
 > bottom=rock@PERMANENT
 >
 > Le mar. 5 févr. 2019 à 21:20, Francois Chartier
mailto:fra.chart...@gmail.com>
 > >>
a écrit :

 >
 >     See attached screenshot, I was able to remove voxels above
the DEM
 >     and below bedrock surface using r3.out.vtk and selecting
export as
 >     *pointdata (p)* not voxels.  If exported as a Voxel from
r3.out.vtk,

 >     the voxel file did not open properly in Paraview could be due to
 >     size of file. I changed option to export as points and it is
working.
 >     grid resolution is 5 x 5 x 1 m over 4km x 4 km x 65 m thickness
 >     approx. (actual thickness varies between DEM and top of rock).
 >
 >     r3.out.vtk -p -s input=jan27551tens100@Toronto
 >     output=C:\Users\Francois
 >     Chartier\Documents\GeoModel\WorkingFile\Feb6_VTK_Pts
 >     top=GTADEM@Toronto bottom=rock@PERMANENT
 >
 >
 >     Le dim. 3 févr. 2019 à 16:42, Francois Chartier
 >     mailto:fra.chart...@gmail.com>
>> a
écrit :

 >
 >         Hi,
 >
 >         I would like to remove voxels located at a higher elevation
 >         than  DEM.
 >         I have been trying r3.mapcalc without sucess.
 >         Does the XY resolutions of both raster have to the same?
 >         any ideas how to do this?
 >         Thanks
 >         Francois
 >
 >
 > ___
 > 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] High tension with r.resamp.rst

[Ghislain Vieilledent | CIRAD]

Dear GRASS GIS user,

I am using r.resamp.rst to interpolate climatic data at 30sec resolution 
over Africa.


Grass script, data, and results are available here:
https://nextcloud.fraisedesbois.net/index.php/s/CKzsZCSCqMTY9rq

#===

# Import Africa shapefile
v.in.ogr --overwrite input=gisdata/vectors/Africa layer=Africa output=Africa

# Rasterize Africa at 30 arc-sec resolution
g.region -ap vector=Africa res=0:00:30
v.to.rast input=Africa type=area output=Africa use=val value=1

# Import climate
r.in.gdal --overwrite input=gisdata/rasters/test1.1_044.tif output=test1_1

# Resample with RST
g.region -ap raster=test1_1
# Note: use maskmap=Africa to save computation time
r.resamp.rst --overwrite input=test1_1 elevation=test1_1_rst \\
 ew_res=0.00833 ns_res=0.00833 maskmap=Africa
r.info test1_1_rst

# Resample to exact resolution 0:00:30
g.region -ap res=0:00:30
r.resample --overwrite input=test1_1_rst output=test1_1_30s

# Export
r.out.gdal --overwrite input=test1_1_30s \\
 output=output/test1_1_30s.tif type=Float32 \\
 createopt='compress=lzw,predictor=2'

#===

When I use r.info on the interpolated raster, it indicates a tension of 
7278 in the comments which seems very high to me as the default value is 40.


|   Comments:
|tension=7278.552524
|dnorm=5.495598, zmult=1.00
|KMAX=50, KMIN=35, errtotal=0.000535
|zmin_data=0.056488, zmax_data=3.756866
|zmin_int=-0.066779, zmax_int=3.214336

On the other side, results do not look so bad (see test.pdf figure).

Would you have any comment on this high value for the tension and do you 
think interpolation has been performed correctly ?


Best regards,

Ghislain

--
___

Ghislain VIEILLEDENT

CIRAD - UMR AMAP
botAnique et Modélisation de l'Architecture des Plantes et des végétations
TA A51/PS2
F-34398 Montpellier cedex 05
FRANCE

Phone: +33.6.24.62.65.07
Skype: ghislain.vieilledent
E-mail : ghislain.vieilled...@cirad.fr

Research unit web site: http://amap.cirad.fr
Personal web site: https://ecology.ghislainv.fr
BioSceneMada project: https://bioscenemada.cirad.fr
___
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] 3D raster remove voxels above DEM

[Francois Chartier]

Thanks Moritz

My goal is to summarize the steps for 3d interpolation at the end of the
process. it took me a year to get here and still have a few more steps to
do which i will contact the User list for.
I am actually doing this as part of a 2nd master thesis with le Cnam in
Paris as continuing education, so i will formalize the process.

The voxels above the dem are not Null values in this interpolation as the
vvolrst interpolates the data within the full 'footprint' of the g.region;
is there a possibility to constrain the interpolation to in between the DEM
and lower surface, by setting a more customized Region than a Block?



On Feb 6, 2019 04:45, "Moritz Lennert"  wrote:

Hi François,

Thanks for sharing the solution you found. From your first mail it was
clear to me what these voxels above the DEM contained. NULL values ?

It would be great if you could summarize all your experience working on
3D data in GRASS GIS in the wiki, at least by amending
https://grasswiki.osgeo.org/wiki/Help_with_3D with your additions or
corrections ? This would be very helpful many others.

Moritz


On 6/02/19 03:46, Francois Chartier wrote:
> See attached screenshot, I was able to remove voxels above the DEM and
> below bedrock surface using r3.out.vtk and selecting export as
> *pointdata (p)* not voxels.  If exported as a Voxel from r3.out.vtk, the
> voxel file did not open properly in Paraview could be due to size of
> file. I changed option to export as points and it is working.
> grid resolution is 5 x 5 x 1 m over 4km x 4 km x 65 m thickness approx.
> (actual thickness varies between DEM and top of rock).
>
> r3.out.vtk -p -s input=jan27551tens100@Toronto output=C:\Users\Francois
> Chartier\Documents\GeoModel\WorkingFile\Feb6_VTK_Pts top=GTADEM@Toronto
> bottom=rock@PERMANENT
>
> Le mar. 5 févr. 2019 à 21:20, Francois Chartier  > a écrit :

>
> See attached screenshot, I was able to remove voxels above the DEM
> and below bedrock surface using r3.out.vtk and selecting export as
> *pointdata (p)* not voxels.  If exported as a Voxel from r3.out.vtk,

> the voxel file did not open properly in Paraview could be due to
> size of file. I changed option to export as points and it is working.
> grid resolution is 5 x 5 x 1 m over 4km x 4 km x 65 m thickness
> approx. (actual thickness varies between DEM and top of rock).
>
> r3.out.vtk -p -s input=jan27551tens100@Toronto
> output=C:\Users\Francois
> Chartier\Documents\GeoModel\WorkingFile\Feb6_VTK_Pts
> top=GTADEM@Toronto bottom=rock@PERMANENT
>
>
> Le dim. 3 févr. 2019 à 16:42, Francois Chartier
> mailto:fra.chart...@gmail.com>> a écrit :

>
> Hi,
>
> I would like to remove voxels located at a higher elevation
> than  DEM.
> I have been trying r3.mapcalc without sucess.
> Does the XY resolutions of both raster have to the same?
> any ideas how to do this?
> Thanks
> Francois
>
>
> ___
> 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] sharing GRASS mapsets

[Laura Poggio]

Dear all,
we need to share a GRASS location and its mapsets across multiple users.
We would like to have a structure similar to this:
LOCATION:
 PERMANENT
 ENVIROMENTAL_COVARIATES
 working_mapset_for_each_user

It is clear in the documentation that a user can only write in a mapset
that it owns.
However we would need to have multiple users to be able to
add/delete/modify files to the ENVIROMENTAL_COVARIATES mapset. Is this
possible at all? any workaround that can be implemented?

Thanks in advance

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

Re: [GRASS-user] Running GRASS with modules

[Markus Metz]

On Tue, Feb 5, 2019 at 5:20 PM Luí­s Moreira de Sousa <
luis.de.so...@protonmail.ch> wrote:
>
>
>
> Hi Markus,
>
> thank you for the reply. As you can see from the initial message, GRASS
throws the exception even before verifying if a location/mapset binome was
passed as argument or if it exists. The same exception is thrown with a
valid mapset passed as argument. Also, GRASS exits orderly when it does not
have permissions to access the given mapset.

Looking at the initial message, the error eccurs after
Cleaning up temporary files...

that means a location and mapset have already been established, probably
the last used.

Maybe the permissions for $GISBASE/etc/clean_temp are not correct?

$GISBASE is apparently /cm/shared/apps/WUR/ESG/modules/grass/

Unfortunately the error "Permission denied" does not tell which permission,
execute, read, write?

Markus M

>
> Whatever is causing this exception it must be happening in the early
start up of GRASS.
>
> Thank you.
>
> --
> Luís Moreira de Sousa
> RingID: ring:7ca91d83f4f9dec82fec9f1144b8e5c1ef2a110c
> URL: https://ldesousa.github.io
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, 5 February 2019 14:50, Markus Metz <
markus.metz.gisw...@gmail.com> wrote:
>
>
>
> On Tue, Feb 5, 2019 at 11:54 AM Luí­s Moreira de Sousa <
luis.de.so...@protonmail.ch> wrote:
> >
> > Dear all,
> >
> > I am using GRASS in an HPC platform where libraries are managed with
modules [0]. Recently I made GRASS 7.6 available as a shared module. This
involved copying the compiled folder to a shared location and then creating
a modulefile [1] (which essentially sets the correct PATH environment
variable). I am able to load the GRASS module and run it; however, when
other users try to do the same they get this error:
>
> Are other users trying to work in your mapset? This is not allowed, a
user must be owner of the mapset. Users can read data from other mapsets
owned by other users, but the current mapset must be owned by the current
user.
>
> A new mapset can be created on startup with
> grass76 -c /path/to/new_mapset
>
> this will create the folder "new_mapset" and populate it with some basic
files neede to recognize this folder as a GRASS mapset. Now you can read
data from already existing mapsets in the same GRASS database and location.
>
> HTH,
>
> Markus M
>
> >
> > $ grass76
> > Cleaning up temporary files...
> > Traceback (most recent call last):
> >   File "/cm/shared/apps/WUR/ESG/modules/grass/bin/grass76", line 2209,
in 
> > main()
> >   File "/cm/shared/apps/WUR/ESG/modules/grass/bin/grass76", line 2087,
in main
> > clean_temp()
> >   File "/cm/shared/apps/WUR/ESG/modules/grass/bin/grass76", line 1784,
in clean_temp
> > call([gpath("etc", "clean_temp")], stdout=nul)
> >   File "/cm/shared/apps/WUR/ESG/modules/grass/bin/grass76", line 247,
in call
> > return subprocess.call(cmd, **kwargs)
> >   File "/usr/lib64/python2.7/subprocess.py", line 524, in call
> > return Popen(*popenargs, **kwargs).wait()
> >   File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
> > errread, errwrite)
> >   File "/usr/lib64/python2.7/subprocess.py", line 1327, in
_execute_child
> > raise child_exception
> > OSError: [Errno 13] Permission denied
> >
> > Naturally, GRASS is unable to access some asset it needs, the question
is what? All users have read and execute permissions on the shared module
folders and files. When it is launched, is GRASS trying to write somewhere?
Which other assets GRASS needs to read when it is launched?
> >
> > Thank you.
> >
> > [0] http://modules.sourceforge.net/
> > [1] https://modules.readthedocs.io/en/latest/modulefile.html
> > --
> > Luís Moreira de Sousa
> > RingID: ring:7ca91d83f4f9dec82fec9f1144b8e5c1ef2a110c
> > URL: https://ldesousa.github.io
> >
> > Sent with ProtonMail Secure Email.
> >
> > ___
> > 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