Re: [GRASS-dev] GRASS 7 crashes on startup on Mac
Hi Michael, On Tue, May 14, 2013 at 12:32 AM, Anna Petrášová kratocha...@gmail.comwrote: On Mon, May 13, 2013 at 11:51 PM, Michael Barton michael.bar...@asu.eduwrote: Perhaps I discovered the problem. Both the distribution version (downloaded in the past hour) and (of course) the compiled version of menudata.xml are empty. Yes, that's what I was thinking. Could you try to run this separately: python core/toolboxes.py xml/menudata.xml which should be done during compilation but it seems to fail somehow. It should generate the xml menu file. any update? I know you announced to be out of office but maybe you can try it anyway? Anna Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On May 13, 2013, at 2:18 PM, Anna Petrášová kratocha...@gmail.com wrote: There might be a problem with compilation. Is there any error? Could you check file menudata.xml in gui/wxpython/xml/ and the same file in distribution? Is it there and what's inside? On Mon, May 13, 2013 at 10:51 PM, Michael Barton michael.bar...@asu.eduwrote: Anna, I deleted all the GUI code and did a new svn up and make distclean. Just finished compiling and have the same error on startup. The GUI crashes. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On May 13, 2013, at 1:23 PM, Anna Petrášová kratocha...@gmail.com wrote: Hi Michael, On Mon, May 13, 2013 at 9:52 PM, Michael Barton michael.bar...@asu.eduwrote: I just compiled GRASS 7 Trunk. It crashes on startup with the following error: this is related to the new toolboxes and menu customization. I don't know what is wrong because it was tested successfully also on Windows. Could you check what you have in directory toolboxes which should be in the same folder as saved settings file? Also try make distclean or just make clean in gui/wxpython and remove manually the gui files from distribution. Anna GRASS 7.0.svn (nc_spm_08):~ Traceback (most recent call last): File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py, line 140, in module sys.exit(main()) File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py, line 133, in main app = GMApp(workspaceFile) File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py, line 45, in __init__ wx.App.__init__(self, False) File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py, line 7981, in __init__ self._BootstrapApp() File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py, line 7555, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py, line 79, in OnInit workspace = self.workspaceFile) File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/lmgr/frame.py, line 106, in __init__ self._menuTreeBuilder = LayerManagerMenuData() File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/lmgr/menudata.py, line 31, in __init__ MenuTreeModelBuilder.__init__(self, filename) File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/core/menutree.py, line 61, in __init__ xmlTree = etree.parse(filename) File /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/etree/ElementTree.py, line 862, in parse tree.parse(source, parser) File /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/etree/ElementTree.py, line 587, in parse self._root = parser.close() File /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/etree/ElementTree.py, line 1254, in close self._parser.Parse(, 1) # end of data xml.parsers.expat.ExpatError: no element found: line 1, column 0 No changes on my end since compiling it without a problem a week ago. Michael __ C. Michael Barton Director, Center for
Re: [GRASS-dev] [GRASS GIS] #1976: r.mapcalc: Allow rounding of floating numbers
GRASS GIS t...@osgeo.org writes: #1976: r.mapcalc: Allow rounding of floating numbers -+-- Reporter: pvanbosgeo | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Raster | Version: unspecified Keywords: r.mapcalc|Platform: Unspecified Cpu: Unspecified | -+-- Comment(by mmetz): Replying to [ticket:1976 pvanbosgeo]: The round() function in r.mapcalc always returns an integer, regardless of its argument types. Integers are always 32-bit, so the result is limited to the range +/- 2147483647 (2^31-1). Suggestion: extend the function to allow to round numbers outside the integer range, and to round with a specific number of decimal places, like e.g., the function round() in R. Try trunk r56313. The output type of round() is now the same like the input type. Rounding to a given number of decimal places is supported with round(x, y) with y = number of decimal places. The new function round(x, y) supports a negative number of decimal places: for example, round(119, -1) results in 120, and round(119, -2) results in 100. #secure method=pgpmime mode=sign Great - sounds like a perfect solution to me. Thanks, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1838: r.mask: allow use of vector map as input
#1838: r.mask: allow use of vector map as input
--+-
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: closed
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-trunk
Resolution: fixed|Keywords: mask, vector, r.mask
Platform: Unspecified | Cpu: Unspecified
--+-
Comment(by nikosa):
Replying to [comment:2 mmetz]:
Replying to [comment:1 neteler]:
Sounds very reasonable. Maybe they can develop the method? It will
include
(perhaps) SQL select option and column selection, then the
rasterization...
`r.mask` got new `vector`, `layer`, `cats`, and `where` options in
r54302. The `input` option has been renamed to `raster`.
..
When a MASK is created from a raster, the extents and resolution of the
raster map are used because r.reclass is used (that's the unchanged
default behaviour as in GRASS 6), but when a MASK is created from a
vector, the current region settings are used.
Thanks!
Nevertheless, currently, if the region extent doesn't match, the produced
raster MASK is empty. Manually, I need to extract the vector features of
my interest (`v.extract`), set the region (`g.region vect=`) and then use
`r.mask` along with the `vector=` option.
Would it be easy to make the region adjustment, when using a vector,
automatic? Even if the user supplies an where=SQL clause? If this action
is not difficult to code, are there reasons for a user he would not want
to match (at least) the region extent to the queried vector map?
I need to integrate in a script this exact operation (hardcoded example
here, the idea is to support scripting of course):
{{{
r.mask vect=wrs2_descending where=PATH=161 and ROW=076
}}}
It would be nicer to get this done automatically.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1838#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 7 crashes on startup on Mac
Hi Anna, Thanks for the reminder. Just got set up here in Valencia and starting the course today. So it will be a few days at best before I can try to compile this on my MacBook Air. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On May 20, 2013, at 9:06 AM, Anna Petrášová kratocha...@gmail.commailto:kratocha...@gmail.com wrote: Hi Michael, On Tue, May 14, 2013 at 12:32 AM, Anna Petrášová kratocha...@gmail.commailto:kratocha...@gmail.com wrote: On Mon, May 13, 2013 at 11:51 PM, Michael Barton michael.bar...@asu.edumailto:michael.bar...@asu.edu wrote: Perhaps I discovered the problem. Both the distribution version (downloaded in the past hour) and (of course) the compiled version of menudata.xml are empty. Yes, that's what I was thinking. Could you try to run this separately: python core/toolboxes.py xml/menudata.xml which should be done during compilation but it seems to fail somehow. It should generate the xml menu file. any update? I know you announced to be out of office but maybe you can try it anyway? Anna Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262tel:480-965-6262 (SHESC), 480-727-9746tel:480-727-9746 (CSDC) fax: 480-965-7671tel:480-965-7671 (SHESC), 480-727-0709tel:480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.eduhttp://csdc.asu.edu/ On May 13, 2013, at 2:18 PM, Anna Petrášová kratocha...@gmail.commailto:kratocha...@gmail.com wrote: There might be a problem with compilation. Is there any error? Could you check file menudata.xml in gui/wxpython/xml/ and the same file in distribution? Is it there and what's inside? On Mon, May 13, 2013 at 10:51 PM, Michael Barton michael.bar...@asu.edumailto:michael.bar...@asu.edu wrote: Anna, I deleted all the GUI code and did a new svn up and make distclean. Just finished compiling and have the same error on startup. The GUI crashes. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262tel:480-965-6262 (SHESC), 480-727-9746tel:480-727-9746 (CSDC) fax: 480-965-7671tel:480-965-7671(SHESC), 480-727-0709tel:480-727-0709 (CSDC) www: http://csdc.asu.eduhttp://csdc.asu.edu/, http://shesc.asu.eduhttp://shesc.asu.edu/ http://www.public.asu.edu/~cmbarton On May 13, 2013, at 1:23 PM, Anna Petrášová kratocha...@gmail.commailto:kratocha...@gmail.com wrote: Hi Michael, On Mon, May 13, 2013 at 9:52 PM, Michael Barton michael.bar...@asu.edumailto:michael.bar...@asu.edu wrote: I just compiled GRASS 7 Trunk. It crashes on startup with the following error: this is related to the new toolboxes and menu customization. I don't know what is wrong because it was tested successfully also on Windows. Could you check what you have in directory toolboxes which should be in the same folder as saved settings file? Also try make distclean or just make clean in gui/wxpython and remove manually the gui files from distribution. Anna GRASS 7.0.svn (nc_spm_08):~ Traceback (most recent call last): File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py, line 140, in module sys.exit(main()) File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py, line 133, in main app = GMApp(workspaceFile) File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py, line 45, in __init__ wx.App.__init__(self, False) File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py, line 7981, in __init__ self._BootstrapApp() File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py, line 7555, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py, line 79, in OnInit workspace = self.workspaceFile) File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/lmgr/frame.py, line 106, in __init__ self._menuTreeBuilder = LayerManagerMenuData() File /Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/lmgr/menudata.py, line 31, in __init__
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
Markus Metz wrote: Happy to see this exchange of ideas. It would be great if this could be implemented. Do you think it is useful I make a feature request on the bug tracker (with link to this email thread) so the idea doesn't get lost? Instead of r.mapcalc A = if(B==0, (round(C/0.0001)-1175699902)/(300797-1175699902) *100.0, 1) --overwrite try r.mapcalc A = if(B==0, (round(C/0.0001)-1175699902.0)/(300797.0-1175699902.0) *100.0, 1) --overwrite or better with whitespaces r.mapcalc A = if(B == 0, (round(C / 0.0001) - 1175699902.0) / (300797.0 - 1175699902.0) * 100.0, 1) --overwrite adding .0 to numbers forces all calculations to be done with floating point double precision That won't help; the problem is that round() returns an integer. It wouldn't be particularly hard to change it so that the return type is the same as the argument type, but that might break existing scripts. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS Visual Studio build
Hi Rashad, 2013/5/20 Rashad M mohammedrasha...@gmail.com Hi All, Is there any visual studio build of GRASS GIS. Not to my knowledge. If no why? The GRASS build system is based on UNIX Makefiles. Best regards Soeren -- Regards, Rashad ___ 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] Overflow warning in r.mapcalc calculation
Rainer M. Krug wrote: Sounds like a sensible approach without adding to many new functions. But I would actually split the two, i.e. have two more arguments, where one specifies the type, and the other one the number of decimals to round to, i.e. round(x, 0, I) would be the default, rounding to whole number and return an integer That interface isn't possible. r.mapcalc doesn't have a string type, and there's no way that a function's return type can depend upon the value of a parameter. In this case I would suggest different functions, e.g. round(x) - as it is now roundI(x, dec) - round to integer, dec0 is ignored, dec0 as below roundD(x, dec) - round to double, where dec is the number of decimals it should be rounded to roundF(x, dec) - round to float, where dec is the number of decimals it should be rounded to if dec is positive, it is the number of decimals, if negative the ... (no idea what it is called, but if it is -1, 111 is rounded to 110, -2 111 is rounded to 100) default from dec would be 0. These different functions would also have the advantage of probably being faster then one single function. 1. I wouldn't bother with separate functions, but instead use the type of the second argument to determine the return type, i.e. round(x, 1)- CELL round(x, 1.0f) - FCELL round(x, 1.0) - DCELL The value of the second argument can be ignored, or it can be used for other purposes. 2. Rounding to a given number of decimals is unnecessarily limiting. The algorithm for generalised rounding is essentially: roundTo(x, k) = round(x / k) * k. Rounding to N decimal places is just a case of using k=1/10^N. If you allow k to be specified directly, then you can round to arbitrary steps (e.g. k=5 would round to the nearest multiple of 5, etc). 3. However: there's a slight problem with doing it that way: 0.1 isn't exactly representable in binary, so e.g. x/0.1 isn't equal to x*10; it would be more accurate to use: roundTo(x, k) = round(x * k) / k where k is the reciprocal of the step, so k=10^N to round to N decimal places (or k=2 to round to 1/2). The downside is that the interface is less useful if you want to round to something other than a fixed number of decimal places. E.g. if you wanted to round to the nearest multiple of 45 degrees, you'd need to use k=1.0/45, which isn't exactly representable. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Overflow warning in r.mapcalc calculation
On 05/20/2013 01:46 PM, Glynn Clements wrote: Markus Metz wrote: Happy to see this exchange of ideas. It would be great if this could be implemented. Do you think it is useful I make a feature request on the bug tracker (with link to this email thread) so the idea doesn't get lost? Instead of r.mapcalc A = if(B==0, (round(C/0.0001)-1175699902)/(300797-1175699902) *100.0, 1) --overwrite try r.mapcalc A = if(B==0, (round(C/0.0001)-1175699902.0)/(300797.0-1175699902.0) *100.0, 1) --overwrite or better with whitespaces r.mapcalc A = if(B == 0, (round(C / 0.0001) - 1175699902.0) / (300797.0 - 1175699902.0) * 100.0, 1) --overwrite adding .0 to numbers forces all calculations to be done with floating point double precision That won't help; the problem is that round() returns an integer. It wouldn't be particularly hard to change it so that the return type is the same as the argument type, but that might break existing scripts. Hi Glynn, In case you haven't seen it, Markus Metz has implemented in trunk r56313 http://trac.osgeo.org/grass/changeset/56313 the option to have the same raster type as output of round() as the input type, see ticket 1976 (http://trac.osgeo.org/grass/ticket/). I sure hope it does not brake existing scripts, as this is a very useful enhancement I think. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1838: r.mask: allow use of vector map as input
#1838: r.mask: allow use of vector map as input --+- Reporter: mlennert | Owner: grass-dev@… Type: enhancement | Status: closed Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Resolution: fixed|Keywords: mask, vector, r.mask Platform: Unspecified | Cpu: Unspecified --+- Comment(by pvanbosgeo): One reason a user would not want to match the region extent to the queried vector map could be that he/she is only interested in an area that partly overlaps with the vector map, with polygons falling only partly within the region. This still works with our suggestion, but only if the region is set back to the initial one after the mask is created I guess. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1838#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] interp_type: cubic | bicubic
Hi, 2013/5/16 Glynn Clements gl...@gclements.plus.com: Whichever is used, it should be consistent. I.e. either nearest/linear/cubic or nearest/bilinear/bicubic. The former might be preferable if we want to extend it to 3D interpolation (i.e. use nearest/linear/cubic regardless of the dimensionality, rather than using separate 2D/3D terminology). OK, done in r56327, any review welcome of course. Probably would make sense to incorporate into raster lib as INTERP_TYPE (see lib/raster/sample.c) other methods, at least `lanczos`. 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 GIS] #1838: r.mask: allow use of vector map as input
#1838: r.mask: allow use of vector map as input
--+-
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: closed
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-trunk
Resolution: fixed|Keywords: mask, vector, r.mask
Platform: Unspecified | Cpu: Unspecified
--+-
Comment(by nikosa):
Replying to [comment:6 pvanbosgeo]:
One reason a user would not want to match the region extent to the
queried vector map could be that he/she is only interested in an area that
partly overlaps with the vector map, with polygons falling only partly
within the region. This still works with our suggestion, but only if the
region is set back to the initial one after the mask is created I guess.
If a user is interested in an area that partly overlaps with the vector
map, he doesn't really want to
{{{
r.mask vector=SomeVector
}}}
He rather needs to manually find the area of interest that will become a
MASK. This sounds as an exception, rather than a general rule. What do
you think?
Thanks
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1838#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
[GRASS-dev] grass7 - mac osx- 64bit python
Hi, is one week now that i'm testing a grass7 build, using wx cocoa (svn version built from source) i'm really happy to say that almost everything is working fine! .. few debug reported here : - profile tool : -- the pen widget doesn't draw a line and no profile is plotted but ... if i select the measure tool make a measurement and then without quitting the measurement tool (boucle click on the canvas) i open the profile tool .. then the profile is plotted correctly - add text layer : -- doesn't change the font size - map composer run but doesn't have a toolbar nothing is printed in the shell during the guy session, should i set some env var to have more verbose - nviz doesn't render the 3d canvas, but there is no crash :) , the rendering-progress-bar load , this the log in the wx console Traceback (most recent call last): File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 366, in OnPaint self.DoPaint() File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 406, in DoPaint self.UpdateMap() File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 1166, in UpdateMap self.SwapBuffers() File /usr/local/lib/wxPython-2.9.4.0/lib/python2.7/site- packages/wx-2.9.4-osx_cocoa/wx/glcanvas.py, line 124, in SwapBuffers return _glcanvas.GLCanvas_SwapBuffers(*args, **kwargs) wx._core . PyAssertionError : C++ assertion context failed at /BUILD/wxPython- src-2.9.4.0/src/osx/cocoa/glcanvas.mm(289) in SwapBuffers(): should have current context if there is something i can do to do more testing i will be happy to work on it. p.s. with wx 2.9 we have great webkit support @Anna have already tried to work on webkit in wx ? i will start to investigate this to see how to add a new tab to include the Ipython notebook if of interest, at this link there is a simple pyqt app that does something similar : https://github.com/damianavila/vIPer/blob/master/viper.py Massimo. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1838: r.mask: allow use of vector map as input
#1838: r.mask: allow use of vector map as input --+- Reporter: mlennert | Owner: grass-dev@… Type: enhancement | Status: closed Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Resolution: fixed|Keywords: mask, vector, r.mask Platform: Unspecified | Cpu: Unspecified --+- Comment(by hamish): To be honest, I find it hard to justify not running `v.to.rast` + r.mask as a two step process. You either respect the current region setting, or the v.to.rast operation is partially undefined. Having the module change the region (and if so, internally, via WIND_OVERRIDE the grass.use_temp_region() python function) for any reason seems like a slight misfeature to me. Consider the case that the vector is much larger than the raster (national coastline, I'm offen making coastal land.mask rasters from that), you wouldn't want to rasterize the entire country at the current raster resolution. Of course it's possible to only shrink the region with a little scripting work, and it could be a nice efficiency trick to do that, but be careful that the logic for it might fail for lat/lon near the dateline) do one thing well, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1838#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] #1838: r.mask: allow use of vector map as input
If you have a vector layer with (some) polygons that occur partly within
the region of interest, finding the area that should become a mask means in
that case spitting the polygon(s). Yes, of course you could do that, but
you can equally well (easier in fact) set the region to match your vector
layer (or the region of interest) manually.
An exception? I don't know, each user will use the functions available in a
different way. I personally would prefer the current implementation, or
more in general, to avoid functions to set the region automatically. In my
opinion that better fits the general work flow in GRASS: the user
explicitly sets the region, and functions operate on that region.
On the other hand, r.mask with a raster as input is an exception as
mentioned already mentioned, and one could argue that it is better to have
the same behaviour both when using raster or vector as input.
It is important thought that r.mask does not change the region if you use
raster as input, and that is something I really think should remain the
case when using a vector as input. That means that even if you would
implement the suggestion above, adjusting the region to the extend of the
vector layer before creating the mask, that region should be set back to
the initial extend after the mask is created.
On Mon, May 20, 2013 at 3:15 PM, GRASS GIS t...@osgeo.org wrote:
#1838: r.mask: allow use of vector map as input
--+-
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: closed
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-trunk
Resolution: fixed|Keywords: mask, vector, r.mask
Platform: Unspecified | Cpu: Unspecified
--+-
Comment(by nikosa):
Replying to [comment:6 pvanbosgeo]:
One reason a user would not want to match the region extent to the
queried vector map could be that he/she is only interested in an area that
partly overlaps with the vector map, with polygons falling only partly
within the region. This still works with our suggestion, but only if the
region is set back to the initial one after the mask is created I guess.
If a user is interested in an area that partly overlaps with the vector
map, he doesn't really want to
{{{
r.mask vector=SomeVector
}}}
He rather needs to manually find the area of interest that will become a
MASK. This sounds as an exception, rather than a general rule. What do
you think?
Thanks
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1838#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] #1838: r.mask: allow use of vector map as input
+ 1 On Mon, May 20, 2013 at 4:32 PM, GRASS GIS t...@osgeo.org wrote: #1838: r.mask: allow use of vector map as input --+- Reporter: mlennert | Owner: grass-dev@… Type: enhancement | Status: closed Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Resolution: fixed|Keywords: mask, vector, r.mask Platform: Unspecified | Cpu: Unspecified --+- Comment(by hamish): To be honest, I find it hard to justify not running `v.to.rast` + r.mask as a two step process. You either respect the current region setting, or the v.to.rast operation is partially undefined. Having the module change the region (and if so, internally, via WIND_OVERRIDE the grass.use_temp_region() python function) for any reason seems like a slight misfeature to me. Consider the case that the vector is much larger than the raster (national coastline, I'm offen making coastal land.mask rasters from that), you wouldn't want to rasterize the entire country at the current raster resolution. Of course it's possible to only shrink the region with a little scripting work, and it could be a nice efficiency trick to do that, but be careful that the logic for it might fail for lat/lon near the dateline) do one thing well, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1838#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] #1838: r.mask: allow use of vector map as input
#1838: r.mask: allow use of vector map as input --+- Reporter: mlennert | Owner: grass-dev@… Type: enhancement | Status: closed Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Resolution: fixed|Keywords: mask, vector, r.mask Platform: Unspecified | Cpu: Unspecified --+- Comment(by nikosa): O-K, I see. So, not even a flag -v that will work *only* when a vector= and will obtain the bounding box coordinates of the queried vector map/feature(s)? -- Ticket URL: https://trac.osgeo.org/grass/ticket/1838#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] #1838: r.mask: allow use of vector map as input
Paulo van Breugel wrote: Hi Paulo! If you have a vector layer with (some) polygons that occur partly within the region of interest, finding the area that should become a mask means in that case spitting the polygon(s). Yes, of course you could do that, but you can equally well (easier in fact) set the region to match your vector layer (or the region of interest) manually. I don't really understand the above. An exception? I don't know, each user will use the functions available in a different way. I personally would prefer the current implementation, or more in general, to avoid functions to set the region automatically. In my opinion that better fits the general work flow in GRASS: the user explicitly sets the region, and functions operate on that region. Sure, I agree. On the other hand, r.mask with a raster as input is an exception as mentioned already mentioned, and one could argue that it is better to have the same behaviour both when using raster or vector as input. My idea comes from what (I maybe wrongly consider as a fact) the r.mask module is used for: a user wants to use a MASK in order to filter out (or in) cells while processing raster data. So the question is: I need to MASK that vector feature(s) out from my raster processing workflow: So I'll MASK'em. Intuitively, but maybe now wise as you and Hamish note, a user could simply say: r.mask vector=VectorMap where=Some SQL statement and the module will set-up for him/her a MASK based on what he/her expects. It is important thought that r.mask does not change the region if you use raster as input, and that is something I really think should remain the case when using a vector as input. That means that even if you would implement the suggestion above, adjusting the region to the extend of the vector layer before creating the mask, that region should be set back to the initial extend after the mask is created. Yes, of course the *current region settings* should be respected. Anyway, thank you for your time answering/commenting. It's just an idea that might make life easier... if... Thanks, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1838: r.mask: allow use of vector map as input
Nikos Alexandris wrote: So the question is: I need to MASK that vector feature(s) out (or in) from my raster processing workflow: So I'll MASK'em. Intuitively, but maybe now maybe _not_ wise wise as you and Hamish note, a user could simply say: r.mask vector=VectorMap where=Some SQL statement and the module will set-up for him/her a MASK based on what he/her expects. N ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass7 - mac osx- 64bit python
Hi, On Mon, May 20, 2013 at 3:37 PM, epi massimodisa...@gmail.com wrote: Hi, is one week now that i'm testing a grass7 build, using wx cocoa (svn version built from source) i'm really happy to say that almost everything is working fine! glad to hear that, I quickly tested wxGUI some time ago on wxPython 2.9 on linux so the most apparent bugs should be fixed. Unfortunately most bugs you listed here are not reproducible on my ubuntu with 2.9 classic wxPython. .. few debug reported here : - profile tool : -- the pen widget doesn't draw a line and no profile is plotted but ... if i select the measure tool make a measurement and then without quitting the measurement tool (boucle click on the canvas) i open the profile tool .. then the profile is plotted correctly hm, I don't have this behavior, it's working properly. The only problem is that the dashed line does not disappear after rerendering. - add text layer : -- doesn't change the font size - map composer run but doesn't have a toolbar again, both work for me nothing is printed in the shell during the guy session, should i set some env var to have more verbose this is normal, everything goes to gui command console, only when you switch to debug mode it goes to terminal - nviz doesn't render the 3d canvas, but there is no crash :) , the rendering-progress-bar load , this the log in the wx console please try again, I just updated the code for 2.9 Traceback (most recent call last): File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 366, in OnPaint self.DoPaint() File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 406, in DoPaint self.UpdateMap() File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 1166, in UpdateMap self.SwapBuffers() File /usr/local/lib/wxPython-2.9.4.0/lib/python2.7/site- packages/wx-2.9.4-osx_cocoa/wx/glcanvas.py, line 124, in SwapBuffers return _glcanvas.GLCanvas_SwapBuffers(*args, **kwargs) wx._core . PyAssertionError : C++ assertion context failed at /BUILD/wxPython- src-2.9.4.0/src/osx/cocoa/glcanvas.mm(289) in SwapBuffers(): should have current context if there is something i can do to do more testing i will be happy to work on it. I cannot do much about the bugs which I can't reproduce, especially when there is no error... p.s. with wx 2.9 we have great webkit support @Anna have already tried to work on webkit in wx ? not yet, I probably missed something when I compiled wx 2.9, it was not working and then I didn't try again. Thanks and keep testing:) Anna i will start to investigate this to see how to add a new tab to include the Ipython notebook if of interest, at this link there is a simple pyqt app that does something similar : https://github.com/damianavila/vIPer/blob/master/viper.py Massimo. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass7 - mac osx- 64bit python
thanks Anna! that's my bathymetry http://geofemengineering.it//data/nviz_mac_wx-29_cocoa.png I tried to changing resolution, use the slope map as color, light settings and other tools , everything was working properly :) few question : is it possible to unlock the layer manager and the map display so that when i move the layer manager the map window doesn't move with it ? an important bug: i was looking for possible options in the preference settings to unlock the movement of mapdispaly when the layer manager is mived, but i had to force quit the gui every time i tried to do something in that panel when i click on apply in the console i have : Settings applied to current session but not saved then the gui is no more responsive and i forced it to quit .. will be nice to be able to set the transparence for the fringe panels :) i'll try to export the verbose debug ant test again all the other widgets. and generate more useful logs, thanks Massimo. Il giorno 20/mag/2013, alle ore 13:20, Anna Petrášová kratocha...@gmail.com ha scritto: Hi, On Mon, May 20, 2013 at 3:37 PM, epi massimodisa...@gmail.com wrote: Hi, is one week now that i'm testing a grass7 build, using wx cocoa (svn version built from source) i'm really happy to say that almost everything is working fine! glad to hear that, I quickly tested wxGUI some time ago on wxPython 2.9 on linux so the most apparent bugs should be fixed. Unfortunately most bugs you listed here are not reproducible on my ubuntu with 2.9 classic wxPython. .. few debug reported here : - profile tool : -- the pen widget doesn't draw a line and no profile is plotted but ... if i select the measure tool make a measurement and then without quitting the measurement tool (boucle click on the canvas) i open the profile tool .. then the profile is plotted correctly hm, I don't have this behavior, it's working properly. The only problem is that the dashed line does not disappear after rerendering. - add text layer : -- doesn't change the font size - map composer run but doesn't have a toolbar again, both work for me nothing is printed in the shell during the guy session, should i set some env var to have more verbose this is normal, everything goes to gui command console, only when you switch to debug mode it goes to terminal - nviz doesn't render the 3d canvas, but there is no crash :) , the rendering-progress-bar load , this the log in the wx console please try again, I just updated the code for 2.9 Traceback (most recent call last): File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 366, in OnPaint self.DoPaint() File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 406, in DoPaint self.UpdateMap() File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 1166, in UpdateMap self.SwapBuffers() File /usr/local/lib/wxPython-2.9.4.0/lib/python2.7/site- packages/wx-2.9.4-osx_cocoa/wx/glcanvas.py, line 124, in SwapBuffers return _glcanvas.GLCanvas_SwapBuffers(*args, **kwargs) wx._core . PyAssertionError : C++ assertion context failed at /BUILD/wxPython- src-2.9.4.0/src/osx/cocoa/glcanvas.mm(289) in SwapBuffers(): should have current context if there is something i can do to do more testing i will be happy to work on it. I cannot do much about the bugs which I can't reproduce, especially when there is no error... p.s. with wx 2.9 we have great webkit support @Anna have already tried to work on webkit in wx ? not yet, I probably missed something when I compiled wx 2.9, it was not working and then I didn't try again. Thanks and keep testing:) Anna i will start to investigate this to see how to add a new tab to include the Ipython notebook if of interest, at this link there is a simple pyqt app that does something similar : https://github.com/damianavila/vIPer/blob/master/viper.py Massimo. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #820: r.in.wms doesn't work in WinGRASS installer distribution
Hi, Processing PNG files in i.maxlik (Windows-based GRASS), I got (and keep getting) the following message: (Mon May 20 09:22:53 2013) i.maxlik group=sattar@user1 subgroup=subgroup sigfile=unsupervised_signature class=unsupervised_map ERROR: Unable to open signature file unsupervised_signature (Mon May 20 09:22:53 2013) Command finished (0 sec) I am trying to produce an unsupervised classification, but keep getting hung up in 'i.maxlik'. I have tried reloading the latest version of Grass along with the 'visual' software, but no luck - I seem to be stuck! I can see from the email exchanges that you are all very busy, but I would be grateful if someone could help me to move on. Many thanks, Colin. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass7 - mac osx- 64bit python
On Mon, May 20, 2013 at 8:21 PM, epi massimodisa...@gmail.com wrote: thanks Anna! that's my bathymetry http://geofemengineering.it//data/nviz_mac_wx-29_cocoa.png I tried to changing resolution, use the slope map as color, light settings and other tools , everything was working properly :) few question : is it possible to unlock the layer manager and the map display so that when i move the layer manager the map window doesn't move with it ? this behavior is only on Mac. Do also other multiple-window applications behave this way (like gimp)? an important bug: i was looking for possible options in the preference settings to unlock the movement of mapdispaly when the layer manager is mived, but i had to force quit the gui every time i tried to do something in that panel when i click on apply in the console i have : Settings applied to current session but not saved then the gui is no more responsive and i forced it to quit it is working for me. I have no idea and probably debug messages won't help much. You could put some print statements in the code to localize more the problem (starting at gui_core/preferences.py). .. will be nice to be able to set the transparence for the fringe panels :) I see i'll try to export the verbose debug ant test again all the other widgets. thanks again. BTW, Michael Barton has had recently problem to start grass 7 wxGUI due to new (a few weeks ago) toolboxes system (for menu customization). You doesn't seem to have any problem, is that right? Anna and generate more useful logs, thanks Massimo. Il giorno 20/mag/2013, alle ore 13:20, Anna Petrášová kratocha...@gmail.com ha scritto: Hi, On Mon, May 20, 2013 at 3:37 PM, epi massimodisa...@gmail.com wrote: Hi, is one week now that i'm testing a grass7 build, using wx cocoa (svn version built from source) i'm really happy to say that almost everything is working fine! glad to hear that, I quickly tested wxGUI some time ago on wxPython 2.9 on linux so the most apparent bugs should be fixed. Unfortunately most bugs you listed here are not reproducible on my ubuntu with 2.9 classic wxPython. .. few debug reported here : - profile tool : -- the pen widget doesn't draw a line and no profile is plotted but ... if i select the measure tool make a measurement and then without quitting the measurement tool (boucle click on the canvas) i open the profile tool .. then the profile is plotted correctly hm, I don't have this behavior, it's working properly. The only problem is that the dashed line does not disappear after rerendering. - add text layer : -- doesn't change the font size - map composer run but doesn't have a toolbar again, both work for me nothing is printed in the shell during the guy session, should i set some env var to have more verbose this is normal, everything goes to gui command console, only when you switch to debug mode it goes to terminal - nviz doesn't render the 3d canvas, but there is no crash :) , the rendering-progress-bar load , this the log in the wx console please try again, I just updated the code for 2.9 Traceback (most recent call last): File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 366, in OnPaint self.DoPaint() File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 406, in DoPaint self.UpdateMap() File /usr/local/grass-7.0.svn/etc/gui/wxpython/nviz/mapwi ndow.py, line 1166, in UpdateMap self.SwapBuffers() File /usr/local/lib/wxPython-2.9.4.0/lib/python2.7/site- packages/wx-2.9.4-osx_cocoa/wx/glcanvas.py, line 124, in SwapBuffers return _glcanvas.GLCanvas_SwapBuffers(*args, **kwargs) wx._core . PyAssertionError : C++ assertion context failed at /BUILD/wxPython- src-2.9.4.0/src/osx/cocoa/glcanvas.mm(289) in SwapBuffers(): should have current context if there is something i can do to do more testing i will be happy to work on it. I cannot do much about the bugs which I can't reproduce, especially when there is no error... p.s. with wx 2.9 we have great webkit support @Anna have already tried to work on webkit in wx ? not yet, I probably missed something when I compiled wx 2.9, it was not working and then I didn't try again. Thanks and keep testing:) Anna i will start to investigate this to see how to add a new tab to include the Ipython notebook if of interest, at this link there is a simple pyqt app that does something similar : https://github.com/damianavila/vIPer/blob/master/viper.py Massimo. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.maxlik
(updating subject line) On Mon, May 20, 2013 at 9:10 PM, Dr Colin Hindmarch colinhindma...@talktalk.net wrote: Hi, Processing PNG files in i.maxlik (Windows-based GRASS), I got (and keep getting) the following message: (Mon May 20 09:22:53 2013) i.maxlik group=sattar@user1 subgroup=subgroup sigfile=unsupervised_signature class=unsupervised_map ERROR: Unable to open signature file unsupervised_signature (Mon May 20 09:22:53 2013) Command finished (0 sec) I am trying to produce an unsupervised classification, but keep getting hung up in 'i.maxlik'. I have tried reloading the latest version of Grass along with the 'visual' software, but no luck - I seem to be stuck! I can see from the email exchanges that you are all very busy, but I would be grateful if someone could help me to move on. Did you generate beforehand the signature file with i.gensig? Perhaps this page is useful for you: http://grasswiki.osgeo.org/wiki/Image_classification Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Submission for Addons repository
Hello, I have a GRASS module that I'd like to submit to the Add-ons SVN repository so that users can install it via g.extension. The module is currently hosted here: https://github.com/selimnairb/r.findtheriver I've followed the instructions here: http://grass.osgeo.org/grass64/source/SUBMITTING and think that I'm ready to submit the code. What's the next step? Thanks, Brian Miles Ph.D. candidate Department of Geography University of North Carolina at Chapel Hill Saunders Hall Campus Box 3220 Chapel Hill, NC 27599-3220 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Submission for Addons repository
Brian wrote: I have a GRASS module that I'd like to submit to the Add-ons SVN repository so that users can install it via g.extension. The module is currently hosted here: https://github.com/selimnairb/r.findtheriver I've followed the instructions here: http://grass.osgeo.org/grass64/source/SUBMITTING and think that I'm ready to submit the code. What's the next step? Hi Brian, see https://trac.osgeo.org/grass/wiki/HowToContribute#WriteaccesstotheGRASS-Addons-SVNrepository regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Backporting the start_rast option in r.walk
Hi, I am a happy user the start_rast option in r.walk in GRASS 7, Recently I realised that the option is not available on the stable version of GRASS (6.4.2) when a student here tried one of my scripts. Is there any plan to backport this, or should the student switch to GRASS 7? Cheers, Pierre -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
