Re: [GRASS-dev] compilation of grass on AIX 7.1
On Wed, Jun 19, 2013 at 6:10 AM, Hamish hamis...@yahoo.com wrote: Markus N wrote: - diglib test updated in lib/vector/diglib/ -- still failing there, we try to understand That has been fixed in 56699, it was related to LFS. hmm, this is quite similar, I wonder if it is related: grass: FTBFS on ppc64 and s390x http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672719#17 Errors in: /build/buildd-grass_6.4.1-2.1-s390x-GTALEw/grass-6.4.1/lib/vector/diglib ... cd OBJ.s390x-ibm-linux-gnu; \ LD_LIBRARY_PATH=:/build/buildd-grass_6.4.1-2.1-s390x-GTALEw/grass-6.4.1/dist.s390x-ibm-linux-gnu/lib ./test; diff ./test.tmp ../ test.ok Killed make[6]: *** [OBJ.s390x-ibm-linux-gnu/test] Error 2 That seems to me a problem on big endian systems, not related to LFS, fixed after 6.4.1. I would recommend to upgrade GRASS to either the latest 6.4.3 snapshot or to 7.0. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compilation of grass on AIX 7.1
http://bugs.debian.org/672719: LD_LIBRARY_PATH=:/build/buildd-grass_6.4.1-2.1-s390x-GTALEw/grass-6.4.1/dist.s390x-ibm-linux-gnu/lib ./test; diff ./test.tmp ../ test.ok Killed make[6]: *** [OBJ.s390x-ibm-linux-gnu/test] Error 2 Markus M: That seems to me a problem on big endian systems, not related to LFS, fixed after 6.4.1. I would recommend to upgrade GRASS to either the latest 6.4.3 snapshot or to 7.0. that's copied from an old bug report; Debian builds of modern versions are ok for all of alpha, amd64, armel, armhf, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, powerpcspe, s390, sh4, and sparc. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G7 compile error:
Thanks Hamish for your clarification. I skipped now the ffmeg support in my compilation and now the make process runs smoothly. :) cheers, /johannes On Tue, Jun 18, 2013 at 11:56 PM, Hamish hamis...@yahoo.com wrote: Johannes wrote: Interestingly the compilation was working some days (maybe already weeks) ago. Right, the code had been changed by a few people to work with their local version of libav at the expense of people using other versions. So in the last week or so I put in a bunch of conditionals to try and make it work for everyone using versions from the last year or three. In some cases that makes it stricter. The reason that distros are abandoning ffmpeg is that the API changes all the time and it is hard for the packagers to keep up, so they seem to be transitioning to a more stable but-compatible fork, and hopefully these troubles become less. And yes, for the grass7 code just leave off --with-ffmpeg since it isn't used in the wxNVIZ currently/yet. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] v.line.center port to G7
Hi, As I'd like to use the v.line.center add-on also in G7, I though about porting the tool. I think there are just minor changes needed to adapt the parameter names of the used modules v.to.db and v.segment to the newer G7. The add-on is a shell script. The folder of the tool contains a Makefile and the html description. The make file contains: MODULE_TOPDIR = ../.. PGM = v.line.center include $(MODULE_TOPDIR)/include/Make/Script.make default: script The Makefile in the /scripts folder has also been adapted and the v.line.center subdir has been added. However when I try to run make I get following error: GRASS GIS 7.0.svn 56779M compilation log -- Started compilation: Wed Jun 19 09:51:21 CEST 2013 -- Errors in: /usr/local/src/grass7_trunk/scripts/v.line.center -- In case of errors please change into the directory with error and run 'make'. If you get multiple errors, you need to deal with them in the order they appear in the error log. If you get an error building a library, you will also get errors from anything which uses the library. -- Finished compilation: Wed Jun 19 09:51:38 CEST 2013 make: *** [default] Error 1 radinger@grassgis:/usr/local/src/grass7_trunk$ cd /usr/local/src/grass7_trunk/scripts/v.line.center/ radinger@grassgis:/usr/local/src/grass7_trunk/scripts/v.line.center$ make make: *** No rule to make target `/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/scripts/v.line.center', needed by `script'. Stop. As I could not find any other shell script in that folder I am not sure if the problem is the shell script in general? Attached the slightly adapted script (v.to.db, v.segment). /Johannes v.line.center Description: Binary data ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] grass.find_program() failing
Hi,
there are new troubles on Windows8, apparently grass.find_program() is failing.
Regularly .py application errors pop up, asking to assign a software to this
extension. The real problem may be different, example:
GRASS 7.0.svn g.manual.py -i
D2/5: filename = C:/OSGeo4W/apps/grass/grass-7.0.svn/scripts/g.manual.py
D2/5: G_file_name(): path = C:\Users\neteler\Documents\GIS DataBase/nc_spm_08_gr
ass7/user1
D2/5: G_file_name(): path = C:\Users\neteler\Documents\GIS DataBase/nc_spm_08_gr
ass7/user1
FEHLER: Browser explorer not found
GRASS 7.0.svn
GRASS 7.0.svn which explorer.exe
/c/Windows/system32/explorer.exe
Unrelated or not, a recent commit where my test of finding a GRASS module
in order to not crash otherwise was commented out. Certainly I had tested
it and it used to work.
Related to the python version?
GRASS 7.0.svn python
Python 2.7.4 (default, Apr 6 2013, 19:54:46) [MSC v.1500 32 bit (Intel)] on win
32
...
GRASS 7.0.svn which python
/osgeo4w/bin/python.exe
I thought we wanted to use the one from extrabin\ first?
GRASS 7.0.svn g.version -g
version=7.0.svn
date=2013
revision=56788
build_date=2013-05-19
Markus
On Tue, Jun 18, 2013 at 10:47 AM, svn_gr...@osgeo.org wrote:
Author: hamish
Date: 2013-06-18 01:47:37 -0700 (Tue, 18 Jun 2013)
New Revision: 56772
Modified:
grass-addons/grass6/raster/r.hazard.flood/r.hazard.flood.py
Log:
commented out check for r.area, grass.messageify
Modified: grass-addons/grass6/raster/r.hazard.flood/r.hazard.flood.py
===
--- grass-addons/grass6/raster/r.hazard.flood/r.hazard.flood.py 2013-06-18
08:11:22 UTC (rev 56771)
+++ grass-addons/grass6/raster/r.hazard.flood/r.hazard.flood.py 2013-06-18
08:47:37 UTC (rev 56772)
@@ -50,9 +50,9 @@
import grass.script as grass
except:
try:
- from grass.script import core as grass
+from grass.script import core as grass
except:
-sys.exit( grass.script can't be imported.)
+sys.exit(grass.script can't be imported.)
if not os.environ.has_key(GISBASE):
print You must be in GRASS GIS to run this program.
@@ -66,6 +66,11 @@
r_flood_map = options['flood']
r_mti = options['mti']
+#FIXME: find_program() not working for modules
+## check if we have the r.area addon
+#if not grass.find_program('r.area'):
+#grass.fatal(_(The r.area module is required, please install it
from Addons first))
+
# Detect cellsize of the DEM
info_region = grass.read_command('g.region', flags = 'p', rast = '%s' %
(r_elevation))
dict_region = grass.parse_key_val(info_region, ':')
@@ -130,7 +135,7 @@
grass.run_command('g.remove', rast = 'r_flood_th')
grass.run_command('g.remove', rast = 'r_flood')
-grass.run_command('g.message' , message = 'Done!')
+grass.message(_('Done.'))
if __name__ == __main__:
options, flags = grass.parser()
___
grass-commit mailing list
grass-com...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-commit
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.line.center port to G7
On 19 June 2013 10:37, Johannes Radinger johannesradin...@gmail.com wrote: Hi, Hi As I'd like to use the v.line.center add-on also in G7, I though about porting the tool. I think there are just minor changes needed to adapt the parameter names of the used modules v.to.db and v.segment to the newer G7. The add-on is a shell script. The folder of the tool contains a Makefile and the html description. The make file contains: MODULE_TOPDIR = ../.. PGM = v.line.center include $(MODULE_TOPDIR)/include/Make/Script.make default: script The Makefile in the /scripts folder has also been adapted and the v.line.center subdir has been added. However when I try to run make I get following error: GRASS GIS 7.0.svn 56779M compilation log -- Started compilation: Wed Jun 19 09:51:21 CEST 2013 -- Errors in: /usr/local/src/grass7_trunk/scripts/v.line.center -- In case of errors please change into the directory with error and run 'make'. If you get multiple errors, you need to deal with them in the order they appear in the error log. If you get an error building a library, you will also get errors from anything which uses the library. -- Finished compilation: Wed Jun 19 09:51:38 CEST 2013 make: *** [default] Error 1 radinger@grassgis:/usr/local/src/grass7_trunk$ cd /usr/local/src/grass7_trunk/scripts/v.line.center/ radinger@grassgis:/usr/local/src/grass7_trunk/scripts/v.line.center$ make make: *** No rule to make target `/usr/local/src/grass7_trunk/dist.i686-pc-linux-gnu/scripts/v.line.center', needed by `script'. Stop. As I could not find any other shell script in that folder I am not sure if the problem is the shell script in general? Attached the slightly adapted script (v.to.db, v.segment). bash it doesn't work more with grass7, you have to convert it in python ;-) /Johannes -- 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] grass.find_program() failing
On 19 June 2013 11:15, Markus Neteler nete...@osgeo.org wrote: Hi, there are new troubles on Windows8, apparently grass.find_program() is failing. grass.find_program() is not working as reported in https://trac.osgeo.org/grass/ticket/2008 The problem seems to be in Popen in the core.py -- 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] v.line.center port to G7
Johannes wrote: As I could not find any other shell script in that folder I am not sure if the problem is the shell script in general? Attached the slightly adapted script (v.to.db, v.segment). Luca wrote: bash it doesn't work more with grass7, you have to convert it in python ;-) Sure Bash shell scripts work with GRASS 7, as do classic Bourne, C-shell, Perl, PHP and whatever else. I'm doing that all the time. In many cases Bash is the quickest and cleanest way to do the job. (just cut and paste a few recent lines from the recent command line history) Other times it is horrible and you want a real programming language. What doesn't work out of the box is the Script.make build support, but since building and installing shell scripts is just copying the file into your personal $GRASS_ADDON_PATH dir and making sure the file is executable, it's not a big problem. For GRASS 7 it is encouraged to write scripts meant to be used by others in a more platform-independent language, so that MS Windows users don't stay second-class citizens as they have been until now, and we can do away with a lot of the sort-of-working unix-on- Windows kludges and errors due to missing UNIX powertools, features, etc. But if the script is just for you, use whatever language you like. If GRASS doesn't support that it's a bad bug. Likewise, getting python scripts working reliably on WinGRASS 6.4 is a pretty critical bug which we haven't figured out yet. Even though the core-provided scripts there are all written in Bourne shell we should still support it for users' personal scripts and interoperability between versions. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules
--+-
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: closed
Priority: normal | Milestone: 6.4.4
Component: Python | Version: svn-releasebranch64
Resolution: invalid |Keywords: find_program()
Platform: Linux| Cpu: x86-64
--+-
Changes (by hamish):
* status: new = closed
* resolution: = invalid
Comment:
actually it works, what I was missing what that the argument needed to be
in [square] brackets. (why?)
6.4.3svn on linux:
{{{
import grass.script as grass
grass.find_program('r.sun,', ['help'])
True
}}}
I will fix/sync the purely parallel-evolution :) version of the test in
the r.hazard.flood script in grass6 addons; the exercise came about since
I was trying to test python addons scripts in grass 6.4 (works on linux
with g.extension, not on Windows due to .bat wrapper files and .py
extension $0 != $0 fun with g.parser).
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:1
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] #2009: thumbnails.py failure
#2009: thumbnails.py failure
+---
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Compiling | Version: svn-trunk
Keywords: r.colors, v.colors |Platform: All
Cpu: Unspecified |
+---
Comment(by glynn):
Replying to [comment:4 hamish]:
I note in trunk there is some rendering error in the top-left corners of
all the image boxes, manifested as a missing pixel. (in GRASS 6 there
was/is a similar bug in d.barscale + Xdriver)
Finally, this is a clear case where the Xdriver does a better job than
the Cairo driver, compare the thumbnails in trunk with the crispness of
the devbr6 versions:
source:grass/branches/develbranch_6/raster/r.colors/thumbnails
... sometimes you want 1px lines to be exactly 1px wide, and no anti-
aliasing.
Both of these are a result of the d.* modules having been minimally
ported from the 6.x display API.
Closed paths should be closed with D_close() rather than by
D_cont_{abs,rel} back to the starting point. The latter will result in the
path being treated as open and thus having end caps.
Single-pixel lines should be drawn along the centre-line of a pixel row or
column, not along the boundary between rows/columns. IOW, the vertices
should have coordinates which are offset from an integer value by 0.5,
rather than being integers.
The display API can't realistically do this automatically because it can't
easily and reliably determine when it needs to fix the coordinates and
when it should use them verbatim. E.g. d.vect shouldn't fix boundaries
which happen to be axis-aligned rectangles because they'll be misaligned
with the rest of the data.
OTOH, if you have a 200-dpi display, single-pixel lines may as well just
not be drawn, because you probably won't be able to see them. For a quick
fix, setting the line width to 2 pixels is probably simpler than changing
the coordinates.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2009#comment:5
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] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules
--+-
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: closed
Priority: normal | Milestone: 6.4.4
Component: Python | Version: svn-releasebranch64
Resolution: invalid |Keywords: find_program()
Platform: Linux| Cpu: x86-64
--+-
Comment(by glynn):
Replying to [comment:1 hamish]:
actually it works, what I was missing what that the argument needed to
be in [square] brackets. (why?)
Because it's a list of arguments to be passed to the program.
It would be trivial to change the function, i.e.
{{{
-def find_program(pgm, args = []):
+def find_program(pgm, *args):
}}}
but it would also be necessary to change anything which uses it with
arguments, currently:
* raster/r.colors/thumbnails.py
* vector/v.colors/thumbnails.py
* gui/wxpython/gui_core/gselect.py
* gui/wxpython/gui_core/mapdisp.py
* gui/wxpython/core/render.py
* scripts/i.in.spotvgt/i.in.spotvgt.py
* scripts/r.in.aster/r.in.aster.py
* scripts/i.spectral/i.spectral.py
* scripts/g.extension/g.extension.py
* scripts/v.db.univar/v.db.univar.py
If it's going to be changed, sooner is better than later.
PS: there's no reason for r.colors and v.colors to have near-identical
copies of the thumbnails.py script. It should be moved to tools.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2008#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] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules
---+
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: reopened
Priority: critical | Milestone: 6.4.4
Component: Python| Version: svn-releasebranch64
Resolution:|Keywords: find_program()
Platform: All | Cpu: x86-64
---+
Changes (by neteler):
* priority: normal = critical
* platform: Linux = All
* status: closed = reopened
* resolution: invalid =
Comment:
Replying to [comment:1 hamish]:
actually it works, what I was missing what that the argument needed to
be in [square] brackets.
For me that fails even after make distclean:
{{{
Welcome to wxGUI Interactive Python Shell 0.9.8
Type help(grass) for more GRASS scripting related information.
Type AddLayer() to add raster or vector to the layer tree.
Python 2.7.3 (default, Aug 9 2012, 17:23:57)
[GCC 4.7.1 20120720 (Red Hat 4.7.1-5)] on linux2
Type help, copyright, credits or license for more information.
import grass.script as grass
grass.find_program('r.sun,', ['help'])
False
grass.version()
{'build_date': '2013-05-19', 'proj4': '4.8.0', 'geos': '', 'sqlite':
'3.7.13', 'libgis_revision': '56211', 'libgis_date': '2013-05-12 13:07:51
+0200 (Sun, 12 May 2013)', 'version': '7.0.svn', 'date': '2013', 'gdal':
'1.9.1', 'revision': '56793M'}
}}}
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:3
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] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules
---+
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: reopened
Priority: critical | Milestone: 6.4.4
Component: Python| Version: svn-releasebranch64
Resolution:|Keywords: find_program()
Platform: All | Cpu: x86-64
---+
Comment(by hamish):
Glynn wrote:
+def find_program(pgm, *args):
would that allow it to be called like:
grass.find_program('r.sun', 'help')
? (I tried a quick test, it didn't like it)
the goal here is to avoid needless extra typing when the only possible
extra options are the $@'s.
If it's going to be changed, sooner is better than later.
i.e. before 6.4.3 is released and we have to stay backwards compatible
with the awkward version for the life of 6.x. I think it is still early
enough to change it everything that uses it if we like to, but the window
is closing fast.
Hamish wrote:
grass.find_program('r.sun,', ['help'])
MarkusN:
For me that fails even after make distclean:
sorry, I had a typo in it, 'r.sun' not 'r.sun,'.
another question with it: should it be changed to test if the program
exists in the PATH and is executable, instead of testing if the program
returns an exit code of 0? (e.g. gdalwarp with no options returns '1'
but 'xml2' with no options returns '0')
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:4
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] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules
---+
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: reopened
Priority: critical | Milestone: 6.4.4
Component: Python| Version: svn-releasebranch64
Resolution:|Keywords: find_program()
Platform: All | Cpu: x86-64
---+
Comment(by zarch):
Replying to [comment:2 glynn]:
Replying to [comment:1 hamish]:
actually it works, what I was missing what that the argument needed to
be in [square] brackets. (why?)
Because it's a list of arguments to be passed to the program.
It would be trivial to change the function, i.e.
{{{
-def find_program(pgm, args = []):
+def find_program(pgm, *args):
}}}
Moreover insert a mutable object as default arguments it's dangerous and
should be avoid, see the example below:
{{{
def myfunc(mylist=[]):
... mylist.append(5)
... return mylist
...
myfunc()
[5]
myfunc()
[5, 5]
myfunc()
[5, 5, 5]
myfunc()
[5, 5, 5, 5]
}}}
Why not change the function in:
{{{
def find_program(cmd):
... return cmd in grass.get_commands()[0]
...
find_program('r.sun')
True
}}}
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:5
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] #2009: thumbnails.py failure
#2009: thumbnails.py failure +--- Reporter: neteler | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Compiling | Version: svn-trunk Keywords: r.colors, v.colors |Platform: All Cpu: Unspecified | +--- Comment(by hamish): Replying to [comment:5 glynn]: Single-pixel lines should be drawn along the centre-line of a pixel row or column, not along the boundary between rows/columns. it is enough for me to know that single-pixel lines are still possible, the rest, as they say, is just details can tuned up along the way. fwiw I'm mostly concerned about things like d.legend and d.barscale which like to be crisp rectangles and not anti-aliased. thanks, Hamish ps- curved lines in symbol rendering are a lot less wiggly now, see r56778. but it's still not perfect: I believe that add_coor()'s x,y in stroke.c can go all-floating point now. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2009#comment:6 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] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules
---+
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: reopened
Priority: critical | Milestone: 6.4.4
Component: Python| Version: svn-releasebranch64
Resolution:|Keywords: find_program()
Platform: All | Cpu: x86-64
---+
Comment(by hamish):
Replying to [comment:5 zarch]:
Why not change the function in:
{{{
def find_program(cmd):
... return cmd in grass.get_commands()[0]
...
find_program('r.sun')
True
}}}
because we want to use the function as a replacement for `which`, so find
arbitrary helper apps like xml2 and gdalwarp which are not grass modules.
Also, get_commands() is not very robust.
thanks,
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:6
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] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules
---+
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: reopened
Priority: critical | Milestone: 6.4.4
Component: Python| Version: svn-releasebranch64
Resolution:|Keywords: find_program()
Platform: All | Cpu: x86-64
---+
Comment(by zarch):
Replying to [comment:6 hamish]:
Replying to [comment:5 zarch]:
Why not change the function in:
{{{
def find_program(cmd):
... return cmd in grass.get_commands()[0]
...
find_program('r.sun')
True
}}}
because we want to use the function as a replacement for `which`, so
find arbitrary helper apps like xml2 and gdalwarp which are not
grass modules. Also, get_commands() is not very robust.
What about:
{{{
def which(pgm):
for p in os.getenv('PATH').split(os.path.pathsep):
p = os.path.join(p, pgm)
if os.path.exists(p) and os.access(p, os.X_OK):
return p
}}}
In python3.3 they add this function in shutil.which
http://hg.python.org/cpython/file/6860263c05b3/Lib/shutil.py#l1068
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2008#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] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules
---+
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: reopened
Priority: critical | Milestone: 6.4.4
Component: Python| Version: svn-releasebranch64
Resolution:|Keywords: find_program()
Platform: All | Cpu: x86-64
---+
Comment(by annakrat):
Replying to [comment:7 zarch]:
What about:
{{{
def which(pgm):
for p in os.getenv('PATH').split(os.path.pathsep):
p = os.path.join(p, pgm)
if os.path.exists(p) and os.access(p, os.X_OK):
return p
}}}
In python3.3 they add this function in shutil.which
http://hg.python.org/cpython/file/6860263c05b3/Lib/shutil.py#l1068
The function from the link is more complicated, than what you suggest
above. Why not to use the official one?
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:8
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] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: reopened Priority: critical | Milestone: 6.4.4 Component: Python| Version: svn-releasebranch64 Resolution:|Keywords: find_program() Platform: All | Cpu: x86-64 ---+ Comment(by zarch): Replying to [comment:8 annakrat]: http://hg.python.org/cpython/file/6860263c05b3/Lib/shutil.py#l1068 The function from the link is more complicated, than what you suggest above. Why not to use the official one? Yes, I completely agree, the official one is much more save and it is the one that we should use. My function was just a proof of concept and then I realize that the python developers already implemented it. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:9 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] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: reopened Priority: critical | Milestone: 6.4.4 Component: Python| Version: svn-releasebranch64 Resolution:|Keywords: find_program() Platform: All | Cpu: x86-64 ---+ Comment(by annakrat): Replying to [comment:9 zarch]: Replying to [comment:8 annakrat]: http://hg.python.org/cpython/file/6860263c05b3/Lib/shutil.py#l1068 The function from the link is more complicated, than what you suggest above. Why not to use the official one? Yes, I completely agree, the official one is much more save and it is the one that we should use. My function was just a proof of concept and then I realize that the python developers already implemented it. What about the name? I suggest to keep the old one (find_program) but it's not strong opinion. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:10 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] #2003: wxGUI carto composer: traceback on exit
#2003: wxGUI carto composer: traceback on exit ---+ Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: minor | Milestone: 6.4.3 Component: wxGUI | Version: svn-releasebranch64 Keywords: cartographic composer |Platform: Linux Cpu: x86-64 | ---+ Comment(by annakrat): Should be fixed in r56799 in grass 7. Please test. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2003#comment:1 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] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: reopened Priority: critical | Milestone: 6.4.4 Component: Python| Version: svn-releasebranch64 Resolution:|Keywords: find_program() Platform: All | Cpu: x86-64 ---+ Comment(by annakrat): Replying to [comment:10 annakrat]: Replying to [comment:9 zarch]: Replying to [comment:8 annakrat]: http://hg.python.org/cpython/file/6860263c05b3/Lib/shutil.py#l1068 The function from the link is more complicated, than what you suggest above. Why not to use the official one? Yes, I completely agree, the official one is much more save and it is the one that we should use. My function was just a proof of concept and then I realize that the python developers already implemented it. What about the name? I suggest to keep the old one (find_program) but it's not strong opinion. ok, please test new implementation of find_program (see link above) r56800 in grass 7. Changes applied also to addons (r56801). -- Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:11 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] Unexpected EVI range from i.vi
Moritz Lennert wrote: g.region -pagc e=784935 n=2695215 rows=1 cols=1 res=30 ^^---^^^--^--^-^^ n=2695230 s=2621340 w=658560 e=784950 -v nsres=73890 ewres=126390 -^^ rows and cols has precedence over res, but res=30 plus -a still has an effect, so you get an extension that is in multiples of 30, with a resolution equal to the total extension, since you asked for one row and one col. So, e=784935 and n=2695215 are set as requested but the -a flag cut's off a bit while aligning... Thanks, N ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Unexpected EVI range from i.vi
Markus Metz wrote: .. Anyhow, just to have a quick-check on r.what, should I upload the bands in question somewhere? Would anyone have the time to explain/check why r.what gives different results depending on the extent/resolution for the same coordinates? Which, might be expected, but why does g.region rows=1 cols=1 set the resolution to... see below: That explained Moritz. I would only add that you should align the region to the raster (not the raster's resolution, these are two different things), before using r.what, otherwise the raster lib will do some internal nn resamplng (if the region's resoltion is larger than the raster's resolution). Right, thanks N ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Unexpected EVI range from i.vi
Markus M: Feeding the test values and the evi(2) formula to r.mapcalc, the results are more or less in the expected range, still beyond [-1, 1], but not much. --- [cut] --- O-K, let's get this from the start (if there is still energy...). First thing: the region! # with or without -a, it sets the same extent here g.region rast=B.Trimmed.ToAR.1 -pag res=30 n=2815500 s=2621340 w=658560 e=875880 nsres=30 ewres=30 rows=6472 cols=7244 cells=46883168 As described in the first post, reflectances(?, -- using i.landsat.toar method=uncorrected in this case for testing) derived from Landsat7 bands that pertain to the scene LE71610432005160ASN00, range between... # blue (required for evi) r.info -r B.Trimmed.ToAR.1 min=0.0756932461701407 max=0.526690453931338 # red r.info -r B.Trimmed.ToAR.3 min=0.0186573080153069 max=0.53363342702351 # nir r.info -r B.Trimmed.ToAR.4 min=0.0122557420404096 max=0.815443599640871 # the EVI index i.vi viname=evi blue=B.Trimmed.ToAR.1 red=B.Trimmed.ToAR.3 nir=B.Trimmed.ToAR.4 output=evi # ranges between... r.info -r evi min=-5905.44171917482 max=6952.80543731566 # locating these high values r.stats evi -g | grep '\-5905' 784935 2695215 -5905.4417191748 786465 2694675 -5905.4417191748 766185 2685615 -5905.4417191748 # and r.stats evi -g | grep '6952\.' 783435 2690025 6952.8054373157 # querying for DN, ToAR and respective EVIs in the end # for example in coordinates=783435,2690025 r.what coordinates=783435,2690025 map=B.Trimmed.1,B.Trimmed.ToAR.1,B.Trimmed.3,B.Trimmed.ToAR.3,B.Trimmed.4,B.Trimmed.ToAR.4,evi_DN,evi 783435|2690025||114|0.228143006540123|56|0.106632395012542|28| 0.0712654621906476|0.296610169491526|6952.80543731566 # doing the math in R # with 0.228143006540123, 0.106632395012542 and 0.0712654621906476 # gives... blue - 0.228143006540123 red - 0.106632395012542 nir - 0.0712654621906476 evi - ( 2.5 * ( nir - red) ) / (nir + 6 * red - 7 * blue + 1.0) evi [1] -0.7751909 Right, this is nice! Using r.mapcalc how? You mean for the specific coordinates/values (I guess... ) I get the same results like in R, not -5905.44171917482 or 6952.80543731566, respectively. Why are the way out of range values correct if R produces reasonable results? Sorry, too many things to work-out these days -- I wasn't clear I guess. I meant that r.mapcalc can't be wrong! I.e., I manually derive for the whole extent of the L7 bands in question, an EVI: r.mapcalc evi_manual = ( 2.5 * (B.Trimmed.ToAR.4 - B.Trimmed.ToAR.3) ) / (B.Trimmed.ToAR.4 + 6.0 * B.Trimmed.ToAR.3 - 7.5 * B.Trimmed.ToAR.1 + 1) This results in r.info -r evi_manual min=-5905.44171917482 max=6952.80543731566 What am I doing wrong? Thanks, N ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2013: wxgui: vector colors menu confused with raster one
#2013: wxgui: vector colors menu confused with raster one +--- Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: menus |Platform: Linux Cpu: x86-64 | +--- hi, in g7 vector menu - manage colors goes to the raster color manage menu not the vector one? thanks -- Ticket URL: https://trac.osgeo.org/grass/ticket/2013 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] #2013: wxgui: vector colors menu confused with raster one
#2013: wxgui: vector colors menu confused with raster one +--- Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: menus |Platform: Linux Cpu: x86-64 | +--- Comment(by hamish): maybe in toolboxes.xml because toolbox name=ManageColors exists in both raster and vector menus? -- Ticket URL: https://trac.osgeo.org/grass/ticket/2013#comment:1 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] #2003: wxGUI carto composer: traceback on exit
#2003: wxGUI carto composer: traceback on exit ---+ Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: minor | Milestone: 6.4.3 Component: wxGUI | Version: svn-releasebranch64 Keywords: cartographic composer |Platform: Linux Cpu: x86-64 | ---+ Comment(by hamish): Replying to [comment:1 annakrat]: Should be fixed in r56799 in grass 7. Please test. I tried applying the patch by hand in a linux 6.4.3svn build: ran it twice without the patch, got the error both times; ran 5 times with the patch, no errors. problem seems solved. thanks. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2003#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
[GRASS-dev] pyGRASS i.atcorr problem (invalid literal for int() with base 10: '0, 255')
Hi,
I am running into an issue with i.atcorr in pyGRASS:
Atmospheric Correction
MM DD hh.ddd: 3 25 51.06
Center: ( 95.02001 , 23.115005 )
Timestamp: 25 Mar 2011
LE71340442011084PFS00.toar.1
LE71340442011084PFS00.surf.1
Traceback (most recent call last):
File ./python-pygrass.py, line 188, in module
i.atcorr(input=b, elevation=dem, visibility=vis,
parameters=prm, output=b_out, flags=ra, range=[0,1],
rescale=[0.0,1.0],overwrite=OVR)
File /usr/local/grass-7.0.svn/etc/python/grass/pygrass/modules/shortcuts.py,
line 49, in __getattr__
return self.cls('%s.%s' % (self.prefix, name.replace('_', '.')))
File
/usr/local/grass-7.0.svn/etc/python/grass/pygrass/modules/interface/module.py,
line 101, in __init__
self.params_list = [Parameter(p) for p in tree.findall(parameter)]
File
/usr/local/grass-7.0.svn/etc/python/grass/pygrass/modules/interface/parameter.py,
line 59, in __init__
diz['default']) if 'default' in diz else None
ValueError: invalid literal for int() with base 10: '0,255'
I am not requesting for [0,255] so it maybe a default set up in
pyGRASS somewhere... or maybe something changed...
Thanks for any help,
Yann
--
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules
---+
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: reopened
Priority: critical | Milestone: 6.4.4
Component: Python| Version: svn-releasebranch64
Resolution:|Keywords: find_program()
Platform: All | Cpu: x86-64
---+
Comment(by glynn):
Replying to [comment:7 zarch]:
What about:
{{{
def which(pgm):
for p in os.getenv('PATH').split(os.path.pathsep):
p = os.path.join(p, pgm)
if os.path.exists(p) and os.access(p, os.X_OK):
return p
}}}
That won't work on windows, where PATHEXT also has to be considered.
There are probably other cases which it doesn't handle, e.g. the
executable exists but cannot be run for whatever reason. The previous
implementation (which will be reinstated today unless someone provides a
legitimate reason not to) is robust against such issues.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2008#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 GIS] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules
---+
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: reopened
Priority: critical | Milestone: 6.4.4
Component: Python| Version: svn-releasebranch64
Resolution:|Keywords: find_program()
Platform: All | Cpu: x86-64
---+
Comment(by glynn):
Replying to [comment:4 hamish]:
Glynn wrote:
+def find_program(pgm, *args):
would that allow it to be called like:
grass.find_program('r.sun', 'help')
Yes.
another question with it: should it be changed to test if the program
exists in the PATH and is executable,
No.
instead of testing if the program returns an exit code of 0? (e.g.
gdalwarp with no options returns '1' but 'xml2' with no options returns
'0')
The exit code test can be changed if that's a problem. subprocess.call()
will raise an OSError (with errno=ENOENT) if the executable doesn't exist.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:13
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
