Re: [GRASS-dev] G__getenv return different results from ctypes and from GRASS modules
Pietro Zambelli wrote: Why the ctypes version return 'PERMANENT' instead of 'user1'? Glynn Clements wrote: The $GISRC file is read the first time that an environment lookup is made. There is no way to force it to be re-read. Nikos Alexandris wrote: This means that I can't use instructions like [...] in a function (pasted below) which I call from within a for loop to go through Mapsets that potentially contain raster maps named differently? Glynn Clements wrote: You can modify the current process' environment with G_setenv(). Pietro Zambelli wrote: Or use the method current() = to set the mapset as current Perfect, shorter! Previously: mapsets = grass.mapsets() for scene_id in mapsets: ### some condition to catch scene_ids of interest here! ### # enter in (a) Mapset of interest grass.run_command(g.mapset, mapset = scene_id, verbose = False ) print Operating inside Scene-Mapset %s\n % scene_id Now: mapsets = grass.mapsets() for scene_id in mapsets: ### some condition to catch scene_ids of interest here! ### # enter in (a) Mapset of interest Mapset(scene_id).current() print \nOperating inside Scene-Mapset %s\n % scene_id This way I've seen (harmless) WARNINGS about matching same raster maps names in other Mapsets. To be sure that only the current and the PERMANENT Mapsets are accessed, I added the following # grant access to current and PERMANENT Mapsets only grass.run_command(g.mapsets, operation = 'set', mapset= '.,PERMANENT', verbose = False ) Thanks, that helped a lot. Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G__getenv return different results from ctypes and from GRASS modules
On Saturday 01 Jun 2013 01:48:39 Glynn Clements wrote:
Nikos Alexandris wrote:
Why the ctypes version return 'PERMANENT' instead of 'user1'?
Glynn Clements wrote:
The $GISRC file is read the first time that an environment lookup is
made. There is no way to force it to be re-read.
This means that I can't use instructions like
[...]
in a function (pasted below) which I call from within a for loop to go
through Mapsets that potentially contain raster maps named differently?
You can modify the current process' environment with G_setenv().
Or use the method
current() = to set the mapset as current
I completely forgot that I've already implemented this functionalities... :-)
see this example:
{{{
In [1]: from grass.pygrass.gis import Mapset
In [2]: veg = Mapset()
In [3]: veg
Out[3]: Mapset('veg')
In [5]: perm = Mapset('PERMANENT')
In [6]: perm.is_current()
Out[6]: False
In [7]: veg.is_current()
Out[7]: True
In [8]: !g.mapset -p
veg
In [9]: perm.current()
In [10]: !g.mapset -p
PERMANENT
In [11]: perm.is_current()
Out[11]: True
In [12]: veg.is_current()
Out[12]: False
}}}
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G__getenv return different results from ctypes and from GRASS modules
Pietro wrote:
Why the ctypes version return 'PERMANENT' instead of 'user1'?
Glynn Clements wrote:
The $GISRC file is read the first time that an environment lookup is
made. There is no way to force it to be re-read.
This means that I can't use instructions like
# retrieve existing Spectral bands
landsat_elements['Spectral Bands'] = \
Mapset().glist('rast', pattern = 'B[123457]')
# alternative naming...
if not landsat_elements['Spectral Bands']:
landsat_elements['Spectral Bands'] = \
Mapset().glist('rast', pattern = 'B[123457]0')
# no results?
if not landsat_elements['Spectral Bands']:
print No Spectral bands named after a B? or B?0 pattern found!
in a function (pasted below) which I call from within a for loop to go
through Mapsets that potentially contain raster maps named differently? I
need to use another way to feed raster maps in a dictionary, right? I need to
change the way raster maps are fed in a dictionary, i.e. use something like
data['Spectral Bands'] = list(zip(*grass.mlist_pairs('rast', 'B[123457]'))
[0])
?
And then, what will be the role of pygrass' Mapset() function?
Thank you (Pietro Glyyn),
Nikos
The following function is called from within a for loop over different
Mapsets:
#
# List Resolution of Landsat Rasters, Controllers for expected names ==
def retrieve_landsat_rasters(verbose = False):
landsat_elements = dict()
# retrieve existing Spectral bands --
landsat_elements['Spectral Bands'] = \
Mapset().glist('rast', pattern = 'B[123457]')
# alternative naming...
if not landsat_elements['Spectral Bands']:
landsat_elements['Spectral Bands'] = \
Mapset().glist('rast', pattern = 'B[123457]0')
# no results?
if not landsat_elements['Spectral Bands']:
print No Spectral bands named after a B? or B?0 pattern found!
# resolution of Spectral bands
landsat_elements['Resolution Spectral'] = \
int(grass.raster_info(landsat_elements['Spectral Bands'][0])['nsres'])
# retrieve existing Temperature channels
landsat_elements['Temperature Channels'] = \
Mapset().glist('rast', pattern = 'B6[12]')
# no results?
if not landsat_elements['Temperature Channels']:
print There are no Landsat Temperature channels named B61, B62!
# temperature channels (resolution = 30 or 60m)
landsat_elements['Resolution Temperature'] = \
int(grass.raster_info(landsat_elements['Temperature Channels'][0])
['nsres'])
# retrieve existing Panchromatic channels ---
landsat_elements['Panchromatic Channel'] = \
Mapset().glist('rast', pattern = 'B8')
# alternative naming
if not landsat_elements['Panchromatic Channel']:
landsat_elements['Panchromatic Channel'] = \
Mapset().glist('rast', pattern = 'B80')
# no results?
if not landsat_elements['Panchromatic Channel']:
print There is no Landsat Panchromatic channel named B8 or B80!
# panchromatic channels (resolution = 15m)
landsat_elements['Resolution Panchromatic'] = \
int(grass.raster_info(landsat_elements['Panchromatic Channel'])['nsres'])
if verbose:
for key in sorted(landsat_elements.keys()):
print %s: %r % (key, landsat_elements[key])
return landsat_elements
#
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G__getenv return different results from ctypes and from GRASS modules
Nikos Alexandris wrote: Why the ctypes version return 'PERMANENT' instead of 'user1'? Glynn Clements wrote: The $GISRC file is read the first time that an environment lookup is made. There is no way to force it to be re-read. This means that I can't use instructions like [...] in a function (pasted below) which I call from within a for loop to go through Mapsets that potentially contain raster maps named differently? You can modify the current process' environment with G_setenv(). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] G__getenv return different results from ctypes and from GRASS modules
Hi all,
Nikos A. found a strange behaviour... that I'm not able to understand...
I'm in the North Carolina (PERMANENT):
{{{
In [1]: import grass.lib.gis as libgis # import the ctypes
In [2]: !g.mapset -p # look in which mapset we are
PERMANENT
In [3]: libgis.G__getenv('MAPSET') # look in which mapset we are using ctypes
Out[3]: 'PERMANENT'
In [4]: !g.mapset user1 # change the mapset
Your shell continues to use the history for the old mapset
You can switch the history by commands:
history -w; history -r /data/gis/nc/user1/.bash_history;
HISTFILE=/data/gis/nc/user1/.bash_history
In [5]: !g.mapset -p # look in which mapset we are
user1
In [6]: libgis.G__getenv('MAPSET') # look in which mapset we are using ctypes
Out[6]: 'PERMANENT'
In [7]: !g.gisenv
MAPSET=user1
GISDBASE=/data/gis
LOCATION_NAME=nc
GUI=text
GISDBASEE=/data/gis
}}}
Why the ctypes version return 'PERMANENT' instead of 'user1'?
the flag p of the module g.mapset use exactly the same function.
http://trac.osgeo.org/grass/browser/grass/trunk/general/g.mapset/main.c#L103
http://trac.osgeo.org/grass/browser/grass/trunk/general/g.gisenv/main.c#L119
There is someone that is able to understand what is not working?
Any idea?
Best regards.
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G__getenv return different results from ctypes and from GRASS modules
Hi,
On Thu, May 30, 2013 at 3:29 PM, Pietro peter.z...@gmail.com wrote:
Hi all,
Nikos A. found a strange behaviour... that I'm not able to understand...
I'm in the North Carolina (PERMANENT):
{{{
In [1]: import grass.lib.gis as libgis # import the ctypes
In [2]: !g.mapset -p # look in which mapset we are
PERMANENT
In [3]: libgis.G__getenv('MAPSET') # look in which mapset we are using
ctypes
Out[3]: 'PERMANENT'
In [4]: !g.mapset user1 # change the mapset
Your shell continues to use the history for the old mapset
You can switch the history by commands:
history -w; history -r /data/gis/nc/user1/.bash_history;
HISTFILE=/data/gis/nc/user1/.bash_history
In [5]: !g.mapset -p # look in which mapset we are
user1
In [6]: libgis.G__getenv('MAPSET') # look in which mapset we are using
ctypes
Out[6]: 'PERMANENT'
In [7]: !g.gisenv
MAPSET=user1
GISDBASE=/data/gis
LOCATION_NAME=nc
GUI=text
GISDBASEE=/data/gis
}}}
Why the ctypes version return 'PERMANENT' instead of 'user1'?
the flag p of the module g.mapset use exactly the same function.
http://trac.osgeo.org/grass/browser/grass/trunk/general/g.mapset/main.c#L103
http://trac.osgeo.org/grass/browser/grass/trunk/general/g.gisenv/main.c#L119
There is someone that is able to understand what is not working?
Any idea?
I have myself experienced similar problem and I think it's related to this
ticket [1].
[1] http://trac.osgeo.org/grass/ticket/717
Anna
Best regards.
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G__getenv return different results from ctypes and from GRASS modules
Pietro wrote: Why the ctypes version return 'PERMANENT' instead of 'user1'? The $GISRC file is read the first time that an environment lookup is made. There is no way to force it to be re-read. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
