[GRASS-dev] TGRASS: mapset management question

[Markus Neteler]

Hi Soeren,

thanks for fixes r66205 + r66206, now I get at least "some" feedback :)

GRASS 7.1.svn (eu_laea):~ > t.list
WARNING: You don't have permission to access the mapset
         <modis_lst_reconstructed>
WARNING: You don't have permission to access the mapset
         <modis_lst_reconstructed>
----------------------------------------------
WARNING: You don't have permission to access the mapset
         <modis_lst_reconstructed>
WARNING: You don't have permission to access the mapset
         <modis_lst_reconstructed>
WARNING: You don't have permission to access the mapset
         <modis_lst_reconstructed>
WARNING: You don't have permission to access the mapset
         <modis_lst_reconstructed>
Space time raster datasets with absolute time available in mapset
<modis_lst_reconstructed>:
modis_lst_reconstructed at modis_lst_reconstructed
WARNING: You don't have permission to access the mapset
         <modis_lst_reconstructed>
WARNING: You don't have permission to access the mapset
         <modis_lst_reconstructed>
WARNING: You don't have permission to access the mapset
         <modis_lst_reconstructed>
WARNING: You don't have permission to access the mapset
         <modis_lst_reconstructed>

Yet the stdrs is reported, great.

Is the warning meant as write access limitation?

You pointed me offlist to the env var GRASS_SKIP_MAPSET_OWNER_CHECK mentioned in
https://grass.osgeo.org/grass71/manuals/variables.html
which indeed changes this

GRASS 7.1.svn (eu_laea):~ > export GRASS_SKIP_MAPSET_OWNER_CHECK=1
GRASS 7.1.svn (eu_laea):~ > t.list
----------------------------------------------
Space time raster datasets with absolute time available in mapset
<modis_lst_reconstructed>:
modis_lst_reconstructed at modis_lst_reconstructed

I wonder why I need to set GRASS_SKIP_MAPSET_OWNER_CHECK=1 when I just
want to read something from the other mapset.

I see that is is (only) used in
lib/gis/mapset_msc.c
in the check_owner() function which is called by
G_mapset_permissions() which is called in
lib/python/temporal/c_libraries_interface.py

If the point of using that env var is to simply suppress the warning
in the upper case, then maybe G_suppress_warnings(1) is better?
Something like

Index: lib/python/temporal/c_libraries_interface.py
===================================================================
--- lib/python/temporal/c_libraries_interface.py    (revision 66229)
+++ lib/python/temporal/c_libraries_interface.py    (working copy)
@@ -294,7 +294,9 @@
             char_list = ""
             mapset = mapsets[count]

+            libgis.G_suppress_warnings(1)
             permission = libgis.G_mapset_permissions(mapset)
+            libgis.G_suppress_warnings(0)
             in_search_path = libgis.G_is_mapset_in_search_path(mapset)

I see it used in various raster modules.
What do you think?

In any case I can report that it works, very good!

GRASS 7.1.svn (eu_laea):~ > t.rast.list
input=modis_lst_reconstructed at modis_lst_reconstructed columns=name
method=comma separator="newline"             where="start_time >
'2014-01-03 17:00:00' and start_time < '2014-01-05 07:00:00'"
WARNING: You don't have permission to access the mapset
         <modis_lst_reconstructed>
WARNING: You don't have permission to access the mapset
         <modis_lst_reconstructed>
WARNING: You don't have permission to access the mapset
         <modis_lst_reconstructed>
WARNING: You don't have permission to access the mapset
         <modis_lst_reconstructed>
MOD11A1.A2014003.LST_Night_1km.reconstruct at modis_lst_reconstructed,MYD11A1.A2014004.LST_Night_1km.reconstruct at modis_lst_reconstructed,MOD11A1.A2014004.LST_Day_1km.reconstruct at modis_lst_reconstructed,MYD11A1.A2014004.LST_Day_1km.reconstruct at modis_lst_reconstructed,MOD11A1.A2014004.LST_Night_1km.reconstruct at modis_lst_reconstructed,MYD11A1.A2014005.LST_Night_1km.reconstruct at modis_lst_reconstructed

So, the remaining issue is just the WARNING.
Working with TGIS data stored in another DB now works, this is really
great and a big help!

thanks again,
Markus