Re: [GRASS-dev] [GRASS GIS] #2020: r.volume gives wrong results on G7
#2020: r.volume gives wrong results on G7 -+-- Reporter: madi| Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Resolution: fixed |Keywords: r.volume Platform: Linux | Cpu: x86-64 -+-- Changes (by madi): * status: new = closed * resolution: = fixed -- Ticket URL: http://trac.osgeo.org/grass/ticket/2020#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-user] GCP GUI error
On Sun, Jan 12, 2014 at 12:10 PM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2014/1/12 Markus Metz markus.metz.gisw...@gmail.com: The GUI for [r|v].ptoj is still not working: the list of mapsets does not match the selected location. thanks for reminder, should be fixed r58679. Anyway this part of forms.py needs to be complete rewriten using signals. The GUI for [r|v].proj is still not working: the list of mapsets is now correct, but the list of raster maps is wrong. Please test before committing changes. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] move v.polytoline?
On 11 December 2013 22:45, Markus Metz markus.metz.gisw...@gmail.com wrote: On Tue, Dec 10, 2013 at 11:14 AM, Luca Delucchi lucadel...@gmail.com wrote: Hi devs, Some days ago I create a really simple script to convert polygon to line [0]. I would like to know what do you think to move it to main code? I'm not sure if it could be useful for end user or not let me know A suggestion for a small improvement: it would be nice if the information to which areas the lines belong to would be kept as attributes (v.to.db option=sides). done in r58698 Markus M -- 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-SVN] r58651 - in grass/trunk: raster raster/r.series.accumulate raster/r.series.accumulate/test_suite temporal temporal/t.rast.accdetect temporal/t.rast.accdetect/test_suite tem
On Thu, Jan 9, 2014 at 3:10 AM, svn_gr...@osgeo.org wrote: Author: huhabla Date: 2014-01-08 18:10:13 -0800 (Wed, 08 Jan 2014) New Revision: 58651 Added: grass/trunk/raster/r.series.accumulate/ grass/trunk/raster/r.series.accumulate/Makefile grass/trunk/raster/r.series.accumulate/main.c grass/trunk/raster/r.series.accumulate/r.series.accumulate.html ... Log: New temporal accumulation modules. Nice to see more modules added! I am posting this here to avoid that it get's lost: r.series.accumulate is an older clone of grass-addons/grass7/raster/r.gdd/ Please merge the updates of r.gdd into r.series.accumulate. Then I believe that r.gdd can be removed from Addons. best Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] GCP GUI error
Hi, 2014/1/13 Markus Metz markus.metz.gisw...@gmail.com: On Sun, Jan 12, 2014 at 12:10 PM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2014/1/12 Markus Metz markus.metz.gisw...@gmail.com: The GUI for [r|v].ptoj is still not working: the list of mapsets does not match the selected location. thanks for reminder, should be fixed r58679. Anyway this part of forms.py needs to be complete rewriten using signals. The GUI for [r|v].proj is still not working: the list of mapsets is now correct, but the list of raster maps is wrong. the problem is that this part of form.py need to be rewritten for which I do not have time at this moment. Should be hopefully fixed in r58701. Please test before committing changes. Sorry for inconvenience. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] GCP GUI error
On Mon, Jan 13, 2014 at 8:15 AM, Martin Landa landa.mar...@gmail.comwrote: Hi, 2014/1/13 Markus Metz markus.metz.gisw...@gmail.com: On Sun, Jan 12, 2014 at 12:10 PM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2014/1/12 Markus Metz markus.metz.gisw...@gmail.com: The GUI for [r|v].ptoj is still not working: the list of mapsets does not match the selected location. thanks for reminder, should be fixed r58679. Anyway this part of forms.py needs to be complete rewriten using signals. The GUI for [r|v].proj is still not working: the list of mapsets is now correct, but the list of raster maps is wrong. the problem is that this part of form.py need to be rewritten for which I do not have time at this moment. Should be hopefully fixed in r58701. The truth is that the whole forms needs to be rewritten and also parser mechanism needs some improvements in the future and this should be considered when rewriting forms. So, I'm not sure who and when is going to do more than small improvements. I noted that there were some efforts considering the parser... ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxPython 3 support
On 13/01/14 00:31, Anna Petrášová wrote: Hi, On Sun, Jan 12, 2014 at 5:40 PM, Maciej Sieczka msiec...@sieczka.org mailto:msiec...@sieczka.org wrote: Hello, Can you please tell what is the status of wxPython 3 support in SVN GRASS6 and 7? so far I tested grass 6 and 7 with wxpython 2.9 only. I am not sure what's the difference between 2.9 and 3 but I hope it's not so big. One important change I stumbled upon recently is that integer division results in float in python 3, while it resulted in integer in python 2. So any module that relies on integer division resulting in integer will need to be updated. I have no idea if such situations exist, though. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxPython 3 support
One important change I stumbled upon recently is that integer division results in float in python 3, while it resulted in integer in python 2. So any module that relies on integer division resulting in integer will need to be updated. I have no idea if such situations exist, though. If it is as you say, you may mention that in some separate email thread and not hidden here in a wxPython GUI thread. Moritz ___ 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] Changes between Python 2 and Python 3 that might need attention in GRASS
On 13/01/14 16:13, Vaclav Petras wrote: One important change I stumbled upon recently is that integer division results in float in python 3, while it resulted in integer in python 2. So any module that relies on integer division resulting in integer will need to be updated. I have no idea if such situations exist, though. If it is as you say, you may mention that in some separate email thread and not hidden here in a wxPython GUI thread. Your wish is my command ! ;-) Here's the doc: http://docs.python.org/3/whatsnew/3.0.html Issues I think might need attention (but this is without verification within the grass python code): - Print Is A Function - Views And Iterators Instead Of Lists - PEP 0238: An expression like 1/2 returns a float. Use 1//2 to get the truncating behavior. - Text Vs. Data Instead Of Unicode Vs. 8-bit Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Changes between Python 2 and Python 3 that might need attention in GRASS
On Mon, Jan 13, 2014 at 4:25 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: Issues I think might need attention (but this is without verification within the grass python code): - Print Is A Function - Views And Iterators Instead Of Lists - PEP 0238: An expression like 1/2 returns a float. Use 1//2 to get the truncating behavior. - Text Vs. Data Instead Of Unicode Vs. 8-bit Perhaps we can insert the following import statement in all the python scripts that we want to make compatible with python3 from __future__ import (nested_scopes, generators, division, absolute_import, with_statement, print_function, unicode_literals) so we can start slowly to move from python2 = python3 what do you think? Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2160: wxPython 3: assertion 'width = -1' failed
#2160: wxPython 3: assertion 'width = -1' failed
--+-
Reporter: msieczka | Owner: grass-dev@…
Type: defect| Status: new
Priority: normal| Milestone: 6.4.4
Component: wxGUI | Version: svn-releasebranch64
Keywords:|Platform: All
Cpu: All |
--+-
In r58684 adding a new layer (raster, vector - whatever) in the GUI
throws:
{{{
(wxgui.py:18403): Gtk-CRITICAL **: IA__gtk_widget_set_size_request:
assertion 'width = -1' failed
}}}
The functionality seems not affected, but even if so, such messages should
not be printed on the user terminal.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2160
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] #2160: wxPython 3: assertion 'width = -1' failed
#2160: wxPython 3: assertion 'width = -1' failed --+- Reporter: msieczka | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 6.4.4 Component: wxGUI | Version: svn-releasebranch64 Keywords:|Platform: All Cpu: All | --+- Comment(by msieczka): 64bit Arch Linux in r58684 built and running against wxPython 3.0. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2160#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
[GRASS-dev] [GRASS GIS] #2161: About GRASS GIS - invalid column index
#2161: About GRASS GIS - invalid column index
--+-
Reporter: msieczka | Owner: grass-dev@…
Type: defect| Status: new
Priority: normal| Milestone: 6.4.4
Component: wxGUI | Version: svn-releasebranch64
Keywords:|Platform: All
Cpu: All |
--+-
r58684 built and running against wxPython 3.0 on 64bit Arch Linux.
Help - About GRASS GIS:
{{{
Traceback (most recent call last):
File /opt/grass64-svn/etc/wxpython/lmgr/frame.py, line
788, in OnAboutGRASS
win = AboutWindow(self)
File /opt/grass64-svn/etc/wxpython/gui_core/ghelp.py,
line 401, in __init__
infoGridSizer.AddGrowableCol(1)
File /usr/lib64/python2.7/site-
packages/wx-3.0-gtk2/wx/_core.py, line 15367, in
AddGrowableCol
return _core_.FlexGridSizer_AddGrowableCol(*args, **kwargs)
wx._core
.
PyAssertionError
:
C++ assertion !m_cols || idx (size_t)m_cols failed at
./src/common/sizer.cpp(1980) in AddGrowableCol(): invalid
column index
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2161
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] #2160: wxPython 3: assertion 'width = -1' failed
#2160: wxPython 3: assertion 'width = -1' failed ---+ Reporter: msieczka | Owner: grass-dev@… Type: defect | Status: new Priority: minor | Milestone: 6.4.4 Component: wxGUI | Version: svn-releasebranch64 Keywords: wxPython3 |Platform: All Cpu: All| ---+ Changes (by annakrat): * keywords: = wxPython3 * priority: normal = minor Comment: Possible duplicate of #2027. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2160#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] [GRASS GIS] #2162: can't close vector map query results window
#2162: can't close vector map query results window --+- Reporter: msieczka | Owner: grass-dev@… Type: defect| Status: new Priority: major | Milestone: 6.4.4 Component: wxGUI | Version: svn-releasebranch64 Keywords:|Platform: Linux Cpu: All | --+- r58684 built and running against wxPython 3.0 on 64bit Arch Linux. As you can see on the attached screenshot, the query results window doesn't have any controls for closing it. The Cancel button does not let close it either. In a result, each query (here in digitizer, but the same applies to queries on vector maps in the main GUI) leaves such a dangling window. They can be closed only by closing their parent map display. This completely breaks digitizer and breaks an important feature in the main GUI. I'm not sure if this is a matter of my desktop environment or GRASS GUI. I'm using a stock Gnome 3.10.1. Can anybody reproduce this? -- Ticket URL: http://trac.osgeo.org/grass/ticket/2162 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] #2161: About GRASS GIS - invalid column index
#2161: About GRASS GIS - invalid column index ---+ Reporter: msieczka | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: wxGUI | Version: svn-releasebranch64 Keywords: wxPython3 |Platform: All Cpu: All| ---+ Changes (by annakrat): * keywords: = wxPython3 Comment: Should be fixed in r58704 (6.4), r58705 (6.5). Grass 7 should be ok (just looking at the code). -- Ticket URL: http://trac.osgeo.org/grass/ticket/2161#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] Changes between Python 2 and Python 3 that might need attention in GRASS
On Mon, Jan 13, 2014 at 11:48 AM, Pietro peter.z...@gmail.com wrote: On Mon, Jan 13, 2014 at 4:25 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: Issues I think might need attention (but this is without verification within the grass python code): - Print Is A Function - Views And Iterators Instead Of Lists - PEP 0238: An expression like 1/2 returns a float. Use 1//2 to get the truncating behavior. - Text Vs. Data Instead Of Unicode Vs. 8-bit Perhaps we can insert the following import statement in all the python scripts that we want to make compatible with python3 from __future__ import (nested_scopes, generators, division, absolute_import, with_statement, print_function, unicode_literals) so we can start slowly to move from python2 = python3 what do you think? Thanks for the overview and suggestions, Moritz and Pietro. I added the -3 flag to python call somewhere in the makefiles, which checks at least the basic things [r56821] (it runs when Python files are compiled to bytecode). The `from __future__ import` is probably a good next step. But I would start slowly, one reason is the manpower, the other is the lack of tests. I would say that this can be checked when one is changing and testing the module anyway (although it should be committed separately), not by one big change for all modules. Two questions. Is the `from __future__ import` Pietro provided save for GRASS minimal Python version (probably 2.6)? And how 2to3 tool can help us? Vaclav [r56821] https://trac.osgeo.org/grass/changeset/56821 -3 : warn about Python 3.x incompatibilities that 2to3 cannot trivially fix 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] [GRASS GIS] #2162: can't close vector map query results window
#2162: can't close vector map query results window +--- Reporter: msieczka| Owner: grass-dev@… Type: defect | Status: new Priority: major | Milestone: 6.4.4 Component: wxGUI | Version: svn-releasebranch64 Keywords: wxPython 3 |Platform: Linux Cpu: All | +--- Changes (by martinl): * keywords: = wxPython 3 -- Ticket URL: http://trac.osgeo.org/grass/ticket/2162#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] #2162: can't close vector map query results window
#2162: can't close vector map query results window +--- Reporter: msieczka| Owner: grass-dev@… Type: defect | Status: new Priority: major | Milestone: 6.4.4 Component: wxGUI | Version: svn-releasebranch64 Keywords: wxPython 3 |Platform: Linux Cpu: All | +--- Comment(by annakrat): It should be fixed in r58708 (grass 6.4). I didn't have the same problem with missing close button but it didn't work anyway. I haven't tested GRASS 7 yet. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2162#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] #1635: allow r.los to run with a point vector layer as input for coordinate identifying the viewing position
On Mon, Jan 13, 2014 at 12:56 AM, GRASS GIS t...@osgeo.org wrote: #1635: allow r.los to run with a point vector layer as input for coordinate identifying the viewing position ... In r58688, I changed `xy` to standard `coordinates` option which enables to interactively pick coordinates from map display if you start G7:r.lake from the main GUI command console, menu or module tree. ... Neither of these three supports multiple coordinates input, although G7:r.lake supports it using seed raster which makes more sense in this case except for cases when you want to add just few points (e.g. 2). The important thing is that supporting multiple coordinates goes far behind supporting more inputs, probably algorithm itself needs to be improved to fulfill the multiple point input required by the original request. Separate tickets for each modules would be better in this case. ... For the record: I check (hopefully) all other GRASS 7 modules, here the remaining candidates for update to use G_OPT_M_COORDS: * display/d.profile/main.c (maybe) * misc/m.transform/main.c (maybe) * raster/r.circle/main.c * raster/r.horizon/main.c Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r58651 - in grass/trunk: raster raster/r.series.accumulate raster/r.series.accumulate/test_suite temporal temporal/t.rast.accdetect temporal/t.rast.accdetect/test_suite tem
I tried to merge the modifications of r.gdd into r.series.accumulate in r58713. Please test if the results are as you expect. Best Soeren 2014/1/13 Markus Neteler nete...@osgeo.org: On Thu, Jan 9, 2014 at 3:10 AM, svn_gr...@osgeo.org wrote: Author: huhabla Date: 2014-01-08 18:10:13 -0800 (Wed, 08 Jan 2014) New Revision: 58651 Added: grass/trunk/raster/r.series.accumulate/ grass/trunk/raster/r.series.accumulate/Makefile grass/trunk/raster/r.series.accumulate/main.c grass/trunk/raster/r.series.accumulate/r.series.accumulate.html ... Log: New temporal accumulation modules. Nice to see more modules added! I am posting this here to avoid that it get's lost: r.series.accumulate is an older clone of grass-addons/grass7/raster/r.gdd/ Please merge the updates of r.gdd into r.series.accumulate. Then I believe that r.gdd can be removed from Addons. best Markus ___ 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] #1644: OS X: Files are installed outside of --prefix
#1644: OS X: Files are installed outside of --prefix ---+ Reporter: Sharpie | Owner: grass-dev@… Type: defect| Status: closed Priority: major | Milestone: 6.4.4 Component: Installation | Version: svn-releasebranch64 Resolution: fixed |Keywords: Platform: MacOSX| Cpu: Unspecified ---+ Changes (by kyngchaos): * status: new = closed * resolution: = fixed Comment: fixed - help links now installed on startup in user space rel64: r58715 dev6: r58714 trunk: r58716 -- Ticket URL: https://trac.osgeo.org/grass/ticket/1644#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] #2152: cd command does not work in GUI Command console
#2152: cd command does not work in GUI Command console
-+--
Reporter: wenzeslaus | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: wxGUI| Version: 6.4.3
Keywords: cd, command console |Platform: All
Cpu: Unspecified |
-+--
Comment(by wenzeslaus):
Replying to [comment:1 neteler]:
The lacking --help support affects rather all modules.
Note that I meant `cd --help` as a test of standard system `cd` command.
No connection to GRASS modules and any kind of support of their `--help`
was intended.
Attached a diff (GRASS 7 code) and a screenshot for review.
If see the feature at the screenshot, but I'm not getting the same result.
I don't understand how the patch would add the feature which is at the
screenshot, i.e. the support for complete of predefined long flags.
None of the predefined flags is autocompleted in the GUI Command console,
however, they worked without the patch and works with the patch:
{{{
g.region --help
...
r.proj --overwrite ...
}}}
The patch is little bit more crucial for GRASS than the not working `cd`
command, so I would say that the patch is somehow hidden here.
For me, the patch changes parser, so that modules now accepts also
{{{
g.region --h
}}}
and not only
{{{
g.region --o
}}}
I cannot say the effect in the GUI without a detailed analyses but it
seems right.
I actually like the patch for the parser, I wanted propose `--h` and
inclusion of `--help` in the manual page myself.
I just don't like the wording of the `--help` description, especially the
slash:
{{{
--help Command line help/usage summary
}}}
What about
{{{
--help Prints usage summary
}}}
We use word ''print'' for `-p` and `-g` options already.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2152#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
