[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