[GRASS-dev] Error running g.rename from python
Dear All,
Initially I was able to batch rename files in grassdb using the command
listed below
g.parse_command("g.rename",rast=old_name,new_name)
But now I keep getting this error:
SyntaxError: non-keyword arg after keyword arg
What could be the issue?
Thanks
Regards
Erick
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Error running g.rename from python
Thanks Markus and Glynn,
This worked g.parse_command("g.rename", rast=(old_name,new_name))
Yes I used the development version of GRASS GIS 7 and by using Python tuple
as suggested by Glynn, the command was able to batch rename my files.
Regards
Erick
On Fri, Oct 10, 2014 at 1:23 PM, Glynn Clements
wrote:
>
> Erick Opiyo wrote:
>
> > Initially I was able to batch rename files in grassdb using the command
> > listed below
> >
> > g.parse_command("g.rename",rast=old_name,new_name)
> >
> > But now I keep getting this error:
> >
> > SyntaxError: non-keyword arg after keyword arg
> >
> > What could be the issue?
>
> This:
>
> g.parse_command("g.rename", rast=old_name, new_name)
>
> is a function call with three arguments:
>
> 1. "g.rename"
> 2. rast=old_name
> 3. new_name
>
> The second argument is a keyword argument, the first and third are
> positional (non-keyword) arguments. Python doesn't allow positional
> arguments to follow keyword arguments; positional arguments come
> first, keyword arguments last.
>
> Given the context, it's safe to assume that you want to pass a pair of
> map names as the value to the rast= option. This requires explicit
> parentheses so that the comma is treated as forming a tuple rather
> than as an argument separator:
>
> g.parse_command("g.rename", rast=(old_name,new_name))
>
> The parentheses in a tuple value can only be omitted if it doesn't
> result in the comma being ambiguous (as is the case in a function
> call).
>
> --
> Glynn Clements
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Error while compiling grass 7.0 from source
Hi Mohammed, Thanks for your reply. I run the command (*EXPORT PYTHONPATH=$PYTHONPATH:/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode*) on terminal and grass compiled successfully without any errors (see attached screen shot). Really appreciate your help. Regards Erick <>___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Error in GRASS GIS 7.0 database
Hi List, I was running two commands, listed below, simultaneously in a Linux environment. 1. r.mapcalc was running as a python mulitprocess command the background and 2. r.what was running in the foreground to extract some pixel values for several rast images. I'm not sure what happened or my GRASS GIS database got corrupt. Because whenever I run any command, I get the following error: ERROR: Duplicate t-b resolution field And because of the error above, all my background processes came to halt. Any help or suggestion, will highly be appreciated. Thanks in advance. Erick ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Resolved - Error in GRASS GIS 7.0 database
Hi Nikos, Thanks for the reply. When I run g.region and I give any raster name as an option, I still got the same error. I didn’t try changing the t-b resolution, though. But after further looking around I found out that the file "WIND" inside my mapset was being changed every time, whenever a file was being edited in the database. When I looked at it I found two entries for t-b resolution, I thought it's supposed to be locked only for edit by one process at a time? After removing the duplicate entry the error when away. Erick ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Resolved - Error in GRASS GIS 7.0 database
version=7.0.0svn date=2014 revision=61465 build_date=2014-07-31 build_platform=x86_64-unknown-linux-gnu Should I upgrade? ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Resolved - Error in GRASS GIS 7.0 database
After the upgrade to grass 7.1.svn(2014)-r62856
Most of my initial python scripts can't run, I get the error below.
Traceback (most recent call last):
File "phenology/cloud_filter/grass_modis_filter_MODIS.py", line 13, in
l = dict.keys(g.parse_command("g.mlist",type="rast"))
File "/usr/local/grass-7.1.svn/etc/python/grass/script/core.py", line
465, in parse_command
res = read_command(*args, **kwargs)
File "/usr/local/grass-7.1.svn/etc/python/grass/script/core.py", line
422, in read_command
process = pipe_command(*args, **kwargs)
File "/usr/local/grass-7.1.svn/etc/python/grass/script/core.py", line
397, in pipe_command
return start_command(*args, **kwargs)
File "/usr/local/grass-7.1.svn/etc/python/grass/script/core.py", line
358, in start_command
return Popen(args, **popts)
File "/usr/local/grass-7.1.svn/etc/python/grass/script/core.py", line 62,
in __init__
subprocess.Popen.__init__(self, args, **kwargs)
File "/usr/lib/python2.7/subprocess.py", line 679, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1249, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
I guess, the command g.parse_command is no longer valid in grass 7.1. I
have see in some forums, reference to a new grass python module pygrass.
I assume this is now the default interface of python to grass. I will go
through it and see if I can refactor my codes to use pygrass.
Thanks
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Resolved - Error in GRASS GIS 7.0 database
I have replaced g.mlist with g.list.
And now I have two versions of grass 7.0-r62941 and 7.1-r62932
But, now I get another wired error, shown below: For both 7.0 and 7.1
*7.0*
ERROR: output map exists
Traceback (most recent call last):
File "phenology/cloud_filter/grass_modis_filter_MODIS.py", line 72, in
R3,R2,R4,R1,R5,E3), overwrite=False)
File "/usr/local/grass-7.0.0svn/etc/python/grass/script/core.py", line
465, in parse_command
res = read_command(*args, **kwargs)
File "/usr/local/grass-7.0.0svn/etc/python/grass/script/core.py", line
425, in read_command
return handle_errors(returncode, stdout, args, kwargs)
File "/usr/local/grass-7.0.0svn/etc/python/grass/script/core.py", line
308, in handle_errors
returncode=returncode)
grass.exceptions.CalledModuleError: Module run None ['r.mapcalc',
'expression=...some long expression.)'] ended with error
Process ended with non-zero return code 1. See errors in the (error) output.
*Note: *The line 72 in the file grass_modis_filter_MODIS.py starts with
g.parse_command("r.mapcalc", expression=.
*7.1*
ERROR: output map exists
Traceback (most recent call last):
File "phenology/cloud_filter/grass_modis_filter_MODIS.py", line 72, in
R3,R2,R4,R1,R5,E3), overwrite=False)
File "/usr/local/grass-7.1.svn/etc/python/grass/script/core.py", line
465, in parse_command
res = read_command(*args, **kwargs)
File "/usr/local/grass-7.1.svn/etc/python/grass/script/core.py", line
425, in read_command
return handle_errors(returncode, stdout, args, kwargs)
File "/usr/local/grass-7.1.svn/etc/python/grass/script/core.py", line
308, in handle_errors
returncode=returncode)
grass.exceptions.CalledModuleError: Module run None ['r.mapcalc',
'expression=...some long expression.)'] ended with error
Process ended with non-zero return code 1. See errors in the (error) output.
Thanks
Erick
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Resolved - Error in GRASS GIS 7.0 database
@Luca, I will try the python interface out. @Martin, If I set overwrite=True, then it would make my script overwrite an already processed images, I'm executing the script a numbers of times to match my machine CPU load average and the overwrite check, makes sure that a subsequent process skips an already processes image from a previously executed process. I tried python multiprocess module, but it was slower than executing one process, so to fasten the process, since I'm processing almost 2 TB MODIS images, I have opted to execute the script a number of times. Erick ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
