Re: [GRASS-dev] addon compilation error
Great, that worked... and good to know what was wrong On 01-07-14 08:54, Luca Delucchi wrote: On 1 July 2014 00:05, Paulo van Breugel p.vanbreu...@gmail.com wrote: That doesn' t seem to work either, I am getting the same error message after adding the py extension I should fix it in r61093, it was a problem on html file ;-) Please try it... ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2332: change r.horizon output names from angle index to angle
#2332: change r.horizon output names from angle index to angle --+- Reporter: zarch| Owner: grass-dev@… Type: enhancement | Status: closed Priority: normal | Milestone: 7.1.0 Component: Default | Version: svn-trunk Resolution: fixed|Keywords: r.horizon Platform: All | Cpu: All --+- Changes (by zarch): * status: new = closed * resolution: = fixed Comment: Done in [http://trac.osgeo.org/grass/changeset/61096 r61096]. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2332#comment:7 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2331: parallelize r.horizon
#2331: parallelize r.horizon --+- Reporter: zarch| Owner: grass-dev@… Type: enhancement | Status: closed Priority: normal | Milestone: 7.1.0 Component: Default | Version: unspecified Resolution: fixed|Keywords: r.horizon Platform: All | Cpu: All --+- Changes (by zarch): * status: new = closed * resolution: = fixed Comment: Done in [http://trac.osgeo.org/grass/changeset/61096 r61096]. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2331#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2338: r.horizon rename parameters
#2338: r.horizon rename parameters
--+-
Reporter: zarch| Owner: grass-dev@…
Type: enhancement | Status: closed
Priority: critical | Milestone: 7.0.0
Component: Raster | Version: svn-trunk
Resolution: fixed|Keywords: r.horizon
Platform: All | Cpu: All
--+-
Changes (by zarch):
* status: new = closed
* resolution: = fixed
Comment:
Replying to [comment:11 annakrat]:
the rest as you suggested
Done in [http://trac.osgeo.org/grass/changeset/61096 r61096].
With the new standard option, do you think
changing gisprompt would be a good idea? It could be
{{{
Opt-gisprompt = old,cell,basename;
}}}
GUI could use that instead of guessing from the parameter name.
The widget could be the standard map selection widget but when
selecting the map, it could try to cut the suffix (in case we
have the standardized delimiter such as `__`). When new series
of maps are created, they could be all added (up to some number).
+1
yes I think that add a basename option to gisprompt could be a good idea.
I close this ticket, we could discuss further about this in
[https://trac.osgeo.org/grass/ticket/2136 #2136].
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2338#comment:12
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
2014-06-09 11:01 GMT+02:00 Glynn Clements gl...@gclements.plus.com:
beside remaining compilation errors [1], wingrass 71 still (after
weeks!!!) even doesn't start...
Traceback (most recent call last):
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py, line 31,
in module
from core import globalvar
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\globalvar.py, li
ne 29, in module
from core.debug import Debug
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py, line 6
6, in module
Debug = DebugMsg()
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py, line 3
7, in __init__
self.SetLevel()
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py, line 4
2, in SetLevel
self.debuglevel = int(grass.gisenv().get('WX_DEBUG', 0))
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l
ine 998, in gisenv
s = read_command(g.gisenv, flags='n')
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l
ine 400, in read_command
ps = pipe_command(*args, **kwargs)
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l
ine 375, in pipe_command
return start_command(*args, **kwargs)
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l
ine 334, in start_command
return Popen(args, **popts)
File C:\OSGEO4~1\apps\Python27\lib\subprocess.py, line 711, in __init__
errread, errwrite)
File C:\OSGEO4~1\apps\Python27\lib\subprocess.py, line 948, in _execute_chil
d
startupinfo)
Martin
[1] http://wingrass.fsv.cvut.cz/grass71/logs/log-r61085-1008/error.log
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Parallelize a job using multiprocess python library without destroying environmental variable
Thanks to both,
I will have a look at your advices/ideas and tell you if I can solve!
All the best,
Annalisa
2014-06-30 20:17 GMT+02:00 Javier Martínez-López
javi.martinez.lo...@gmail.com:
Hi Annalisa,
I still need to learn a lot about this and have not tested Vaclav's
advice yet, which is probably the best way to go, but you can take a
look at some scripts I wrote for doing this:
https://github.com/javimarlop/eHabpy/blob/master/pas/tmp/parallel_segmentation_pca.py
https://github.com/javimarlop/eHabpy/blob/master/pas/parallel_grass_example.py
They are working for me, but as Markus Metz also mentioned me once, if
you are not using a cluster and there is a lot of writing/reading from
the same hard disk, you will probably not speed up considerably the
processing. In any case, I am also very interested in further
developing this script, so any ideas are welcome!
Cheers,
Javier
On Mon, Jun 30, 2014 at 4:05 PM, Vaclav Petras wenzesl...@gmail.com
wrote:
On Mon, Jun 30, 2014 at 5:21 AM, Annalisa Minelli annagra...@gmail.com
wrote:
Hi all,
I'm attempting to parallelize a job in a python script using
multiprocess
library in grass70.
I had a look at the following links:
http://grasswiki.osgeo.org/wiki/Parallel_GRASS_jobs
and http://grasswiki.osgeo.org/wiki/Parallelizing_Scripts.
I would like to work in the same location but in different mapsets
because
my jobs touch the region settings, but I don't know how to set separate
mapset for separate jobs.
Since now I discovered that this processes, if run in the same mapset,
clean all the environmental variables (GISDBASE, LOCATION, MAPSET) so
then
GRASS does not start anymore and I have to restore the .grass70/rc
file..
can anyone hint me on how to set different mapsets for different jobs?
First, look at the PyGRASS GridModule [1] whether this can help you.
For general case, there is unfortunately no API. From what I understand,
you
have to create a file gisrc somewhere and then do something like env =
copy(os.environ) and change GISRC there to your custom gisrc. Then you
the
change the mapset and region by standard GRASS means but you must pass
`env`
parameter to all command/module calls (env is used by Python subprocess
to
set environment just for one process).
Note that GISRC, GISBASE and LOCATION are (system) environmental
variables
while GISDBASE, LOCATION_NAME and MAPSET are GRASS GIS
session/environment
variables and are stored in gisrc file. I don't have an idea what
LOCATION
variable is for (it contains full path to the mapset).
I would be glad to hear what others think about this.
You can of course read source code of GridModule, rendering in wxGUI,
g.gui.animation, or the following snipped but I don't say that it will be
easy to understand and there might be a lot of imperfections.
Vaclav
# we rely on the tmp dir having enough space for our map
tgt_gisdbase = tempfile.mkdtemp()
# this is not needed if we use mkdtemp but why not
tgt_location = 'r.out.png.proj_location_%s' % epsg_code
# because we are using PERMANENT we don't have to create mapset
explicitly
tgt_mapset_name = 'PERMANENT'
src_mapset = Mapset(src_mapset_name)
# get source (old) and set target (new) GISRC enviromental variable
# TODO: set environ only for child processes could be enough and it
would
# enable (?) parallel runs
src_gisrc = os.environ['GISRC']
tgt_gisrc = gsetup.write_gisrc(tgt_gisdbase,
tgt_location, tgt_mapset_name)
# we should use a copy and pass it but then it would not be possible
to
use create_location
os.environ['GISRC'] = tgt_gisrc
if os.environ.get('WIND_OVERRIDE'):
old_temp_region = os.environ['WIND_OVERRIDE']
del os.environ['WIND_OVERRIDE']
else:
old_temp_region = None
# these lines looks good but anyway when developing the module
# switching location seemed fragile and on some errors (while running
# unfinished module) location was switched in the command line
try:
# the function itself is not safe for other (backgroud) processes
# (e.g. GUI), however we already switched GISRC for us
# and child processes, so we don't influece others
gcore.create_location(dbase=tgt_gisdbase,
location=tgt_location,
epsg=epsg_code,
datum=None,
datum_trans=None)
# Mapset object cannot be created if the real mapset does not
exists
tgt_mapset = Mapset(gisdbase=tgt_gisdbase, location=tgt_location,
mapset=tgt_mapset_name)
# set the current mapset in the library
# we actually don't need to switch when only calling modules
#
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
On 1 July 2014 14:00, Martin Landa landa.mar...@gmail.com wrote:
2014-06-09 11:01 GMT+02:00 Glynn Clements gl...@gclements.plus.com:
beside remaining compilation errors [1], wingrass 71 still (after
weeks!!!) even doesn't start...
Traceback (most recent call last):
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\gis_set.py, line
31,
in module
from core import globalvar
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\globalvar.py,
li
ne 29, in module
from core.debug import Debug
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py,
line 6
6, in module
Debug = DebugMsg()
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py,
line 3
7, in __init__
self.SetLevel()
File C:\OSGEO4~1\apps\grass\grass-7.1.svn\gui\wxpython\core\debug.py,
line 4
2, in SetLevel
self.debuglevel = int(grass.gisenv().get('WX_DEBUG', 0))
File
C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l
ine 998, in gisenv
s = read_command(g.gisenv, flags='n')
File
C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l
ine 400, in read_command
ps = pipe_command(*args, **kwargs)
File
C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l
ine 375, in pipe_command
return start_command(*args, **kwargs)
File
C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l
ine 334, in start_command
return Popen(args, **popts)
File C:\OSGEO4~1\apps\Python27\lib\subprocess.py, line 711, in __init__
errread, errwrite)
File C:\OSGEO4~1\apps\Python27\lib\subprocess.py, line 948, in
_execute_chil
d
startupinfo)
I just upload to a friend and it has the same problem :-(
Martin
[1] http://wingrass.fsv.cvut.cz/grass71/logs/log-r61085-1008/error.log
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] gui command console history on Windows
Hi devs, The GRASS71 command console on Windows it is saving the history in only one big multiline text. If I remove to much information it jump to the previous command and start to remove text also from that. This behavior Is it a known problem? -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] gui command console history on Windows
On Tue, Jul 1, 2014 at 10:17 AM, Luca Delucchi lucadel...@gmail.com wrote: Hi devs, The GRASS71 command console on Windows it is saving the history in only one big multiline text. If I remove to much information it jump to the previous command and start to remove text also from that. This behavior Is it a known problem? Well yes, I knew about it but it didn't bother me so much. So you made me look at it and it should be fixed in r61102,3. Testing is welcome of course. Cheers, Anna -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ 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
[GRASS-dev] Installing MS DLLs failed because of 404
Hi, at two MS Windows machines we had a problem that installation of MS runtime libraries during GRASS installation failed. GRASS was not able to run then even though installer linked at GRASS wiki [1] says that libraries are installed. At least at one of the machines the error in GRASS installer log was something like HTTP 404 Not found. However, downloading the file manually works (I determined the URL from installer source code [2]). Then we run the the exe files and copied dlls as the installer is doing [3]. And GRASS works. Of course, on other computer on the same network the download works well. Do you have the any idea why download would fail? Antivirus? The computers have different system configuration but the antivirus program might be the same. Also do you think that the steps from the installer should go to the wiki [1]. The tar.bz2 would be bit unfortunate in this case and we might want to ask for adding there zip/7z too. Thanks, Vaclav [1] http://grasswiki.osgeo.org/wiki/WinGRASS_errors#The_winGRASS_program_exits_immediately_after_I_start_it.21 [2] http://trac.osgeo.org/grass/browser/grass/trunk/mswindows/GRASS-Installer.nsi.tmpl#L973 [3] http://trac.osgeo.org/grass/browser/grass/trunk/mswindows/GRASS-Installer.nsi.tmpl#L938 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Installing MS DLLs failed because of 404
Do you have the any idea why download would fail? The computers have different system configuration some possible issues: - osgeo-server down? - winGRASS-standalone installing without admin rights? - no right to download from internet? - ... I've seen there is now: http://download.osgeo.org/osgeo4w/x86/release/msvcrt/msvcrt-1.0.1-12.tar.bz2 27-Jun-2014 12:09 12M the installer source points to: 974 StrCpy $ARCHIVE_NAME msvcrt-1.0.1-11.tar.bz2 this should be changed in trunk and in all branches. Also do you think that the steps from the installer should go to the wiki [1]. maybe yes, but doubling of packages on the server should be avoided IMHO. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Installing-MS-DLLs-failed-because-of-404-tp5149036p5149075.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Installing MS DLLs failed because of 404
At least at one of the machines the error in GRASS installer log was something like HTTP 404 Not found. http://en.wikipedia.org/wiki/HTTP_404 The 404 or Not Found error message is a HTTP standard response code indicating that the client was able to communicate with a given server, but the server could not find what was requested. [...] A 404 error should not be confused with server not found or similar errors, in which a connection to the destination server could not be made at all. A 404 error indicates that the requested resource may be available again in the future; however, the fact does not guarantee the same content. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Installing-MS-DLLs-failed-because-of-404-tp5149036p5149076.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Installing MS DLLs failed because of 404
On Tue, Jul 1, 2014 at 2:57 PM, Helmut Kudrnovsky hel...@web.de wrote: Do you have the any idea why download would fail? The computers have different system configuration some possible issues: - osgeo-server down? - winGRASS-standalone installing without admin rights? - no right to download from internet? - ... As I wrote manual download worked. So, osgeo sever is fine and general download works as well that's why my guess was some strange security/antivirus settings but I don't know how to prove or disprove this. (My first guess was problem with server because of 404 but it was easy to disprove.) On Tue, Jul 1, 2014 at 2:57 PM, Helmut Kudrnovsky hel...@web.de wrote: Also do you think that the steps from the installer should go to the wiki [1]. maybe yes, but doubling of packages on the server should be avoided IMHO. The guide is there but I don't want to see the user struggling with unpacking tar.bz2 on MS Window. zip or 7z would be helpful. It might be convenient to have both. The package is 12 MB, so size is the issue? http://grasswiki.osgeo.org/wiki/WinGRASS_errors#The_GRASS_GIS_.28winGRASS.29_exits_immediately_after_I_start_it.21 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Installing MS DLLs failed because of 404
The guide is there but I don't want to see the user struggling with unpacking tar.bz2 on MS Window. zip or 7z would be helpful. 7zip can unzip and untar tar.bz2. so if you have installed 7zip, you can do this. The package is 12 MB, so size is the issue? I would say manpower; there are 1-2 persons maintaining OSGeo4W base packages. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Installing-MS-DLLs-failed-because-of-404-tp5149036p5149095.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Installing MS DLLs failed because of 404
On Tue, Jul 1, 2014 at 5:03 PM, Helmut Kudrnovsky hel...@web.de wrote: The guide is there but I don't want to see the user struggling with unpacking tar.bz2 on MS Window. zip or 7z would be helpful. 7zip can unzip and untar tar.bz2. so if you have installed 7zip, you can do this. Excellent. I was not aware of that. Added to the wiki. http://grasswiki.osgeo.org/wiki/WinGRASS_errors#The_GRASS_GIS_.28winGRASS.29_exits_immediately_after_I_start_it.21 The package is 12 MB, so size is the issue? I would say manpower; there are 1-2 persons maintaining OSGeo4W base packages. I can understand that. Since 7-Zip (which is open source) can handle it, I don't see any problem with tar.bz2 (especially when it is now noted in the guide). http://grasswiki.osgeo.org/wiki/WinGRASS_errors#The_GRASS_GIS_.28winGRASS.29_exits_immediately_after_I_start_it.21 - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Installing-MS-DLLs-failed-because-of-404-tp5149036p5149095.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ 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] [GRASS GIS] #1938: r.fillnulls: per hole filling speed-up
#1938: r.fillnulls: per hole filling speed-up --+- Reporter: sbl | Owner: grass-dev@… Type: enhancement | Status: reopened Priority: normal | Milestone: 7.1.0 Component: Python | Version: svn-trunk Resolution: |Keywords: r.fillnulls Platform: All | Cpu: All --+- Changes (by sbl): * status: closed = reopened * component: Shell Scripts = Python * platform: Unspecified = All * milestone: 7.0.0 = 7.1.0 * resolution: fixed = * cpu: Unspecified = All Comment: Please find attached another proposal for speed-up of rst-interpolation by hole. In the diff, there are two sections which can probably be removed in addition: 1) The new r.clump version should account for NoData, so the following r.mapcalc operation can be removed (could not test it since I work with an older version). 2) I was unsure if r.patch has a limit regarding the number of open maps, if not than block-wise application of r.patch can be removed too... Maybe better to use bilinear or bicubic interpolation as default as it is significant faster (and simpler) than rst? -- Ticket URL: http://trac.osgeo.org/grass/ticket/1938#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Martin Landa wrote:
beside remaining compilation errors [1], wingrass 71 still (after
weeks!!!) even doesn't start...
Does anyone want to test the attached patch?
In particular, it needs to be tested with a Python script invoking an
exe with arguments containing characters which are likely to be
meaningful to the shell, including:
| % ^
d.text or r.support may be useful as test cases.
But in the longer term, should we be claiming to support a platform
for which we appear to have no active developers?
--
Glynn Clements gl...@gclements.plus.com
Index: lib/python/script/core.py
===
--- lib/python/script/core.py (revision 61080)
+++ lib/python/script/core.py (working copy)
@@ -41,8 +41,26 @@
class Popen(subprocess.Popen):
-pass
+_builtin_exts = set(['.com', '.exe', '.bat', '.cmd'])
+@staticmethod
+def _escape_for_shell(arg):
+# TODO: what are cmd.exe's parsing rules?
+return arg
+
+def __init__(self, args, **kwargs):
+if ( sys.platform == 'win32'
+ and isinstance(args, list)
+ and not kwargs.get('shell', False)
+ and kwargs.get('executable') is None ):
+cmd = shutil_which(args[0])
+args = [cmd] + args[1:]
+name, ext = os.path.splitext(cmd)
+if ext.lower() not in self._builtin_exts:
+kwargs['shell'] = True
+args = [self._escape_for_shell(arg) for arg in args]
+subprocess.Popen.__init__(self, args, **kwargs)
+
PIPE = subprocess.PIPE
STDOUT = subprocess.STDOUT
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
