[GRASS-dev] Re: [GRASS GIS] #1409: wxGUI command console does not parse correctly help and first parameter
#1409: wxGUI command console does not parse correctly help and first parameter +--- Reporter: philippbs | Owner: martinl Type: defect | Status: closed Priority: normal | Milestone: 6.4.2 Component: wxGUI | Version: svn-releasebranch64 Resolution: fixed |Keywords: cmd, d. Platform: All| Cpu: x86-64 +--- Comment(by martinl): Backported to relbr64 in r47256. Now ticket can be closed. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1409#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] Adding labels to the WxPython module's buttons
On Wed, Jul 27, 2011 at 2:07 AM, Glynn Clements gl...@gclements.plus.com wrote: Markus Neteler wrote: Devs, since this has been asked so often (incl. myself), I really vote for i18n-tagging these buttons. is it really needed? It is good idea to leave it for underlaying library to get standardized translation within given OS. This will fail if a user wants a different language than that provided by the OS. Me in Japan don't manage to read those buttons easily in Japanese... Translating the GRASS GUI won't help much if the rest of the desktop is in Japanese. Sure, that's why there is a related ticket: Add a change language option in GRASS GUI http://trac.osgeo.org/grass/ticket/879 And using a different language for portions of the GUI which are high-level OS components (e.g. file selection dialogs) may not even be possible. I had added it 1-2 years ago, it worked and it has been reverted since then by someone else (which reintroduced the problem). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Fw: r.sun at a landscape scale
Hi folks, Just forwarding the conversation to add to the record. Doug - Forwarded by Doug Newcomb/R4/FWS/DOI on 07/27/2011 09:23 AM - Doug Newcomb newcomb@gmail.com 04/29/2011 09:15 AM To Doug Newcomb doug_newc...@fws.gov cc Subject Fwd: Re: r.sun at a landscape scale Original Message Subject: Re: r.sun at a landscape scale Date: Tue, 26 Apr 2011 01:16:05 -0700 (PDT) From: Hamish hamis...@yahoo.com To: Doug Newcomb newcomb@gmail.com Hi Doug, Contacting you from the home email. Work webmail non-functional. If you recall the 60ft canopy height layer I created for the state of North Carolina, I've been using that canopy height layer as a base elevation layer for calculating total global solar irradiation for a 60ft grid for the state of north carolina. I have created slope and aspect layers, as well as r.horizon layers at 8 45 degree increments starting at 0 ( East) and going counter-clockwise. I left the albedo and linke options at the defaults. I have calculated the global solar irradiation for all 365 days using these parameters. After a number of tests (see below), I'm of the opinion that the pre-made slope, aspect, lat, lon, and r.horizon maps are either no faster, or introduce such inaccuracies as to be not worth the trouble. In particular I question the usefulness of r.horizon maps: the sun is in a slightly different place on the compass each morning, and the overhead of keeping/loading 360 horizon maps is more than just recalculating it on the fly (and on the fly you get the exact value, not a nearby estimate). Also, having 360 starting r.horizons limits you to 1 degree precision. I value accuracy over processing time (I'm happy to wait a week for an answer if I know the model setup is good), so take with that grain of salt. So I like to use step=0.05 instead of the default step=0.5 even though it takes 10 times longer. I would like to sharpen the accuracy of the calculations by creating grid layers of the linke turbulence similar to how you do it in your python script. My efforts seem to be complicated by the landscape approach I have taken, which includes calculations in coastal plain, piedmont, and mountain areas which have a mixture of urban and rural land uses. I've been to the helioclim http://www.helioclim.net/linke/index.html and and soda http://www.soda-is.com/eng/services/climat_free_eng.php#climatCielClair web sites to try to get more exact estimates on the linke turbulence, but the best they can do is monthly estimates at 5 arc second resolution . Perhaps I want too much :-) for me the Soda linke DB wasn't too useful, AFAIU it's rather elevation dependent and I'm modeling light in fjords with 1000m vertical cliff faces.. their spatial elevation model resolution was just too coarse for me. what we did instead was to pick at each model point (~1 deg) for each month, and then use v.surf.rst to make an interpolated linke map from those. I'm not sure if 5 arc-sec data was available then, or if that was just a reinterpolation from a coarser grid so we ignored it..? I suppose for each position you could uncomment the couple of lines at the bottom of the linke month-day interpolation python script which gives the full year's worth of linkie values, and use the collection of those to make 365 v.surf.rst linkie coverage maps. ? you could also mix and match mountainous and urban values that way. In any event, my thought was to try to take the global monthly estimate tifs, georeference them and pull them into grass. Chop out the NC areas and reproject them into the same workspace as the canopy height data. Take the monthly values as the mid month values and interpolate to 365 days and use those calculations as the basis for the linke turbulence input to calculation. Does that seem like a reasonable approach to you? currently r.series doesn't support linear interpolation extractions, I suppose something could be whipped together using r.mapcalc's graph() linear interpolation, maybe hack that to do cubic interpolations too? BtW, how much does it speed things up to have a lat and long layers in the input? I don't think by much at all, maybe a few percent, at the risk of user error. read through: https://trac.osgeo.org/grass/ticket/498 and http://grass.osgeo.org/wiki/r.sun If you have a new graphics card you can vastly speed it up by using Seth's GPU version: http://grass.osgeo.org/wiki/R.sun#OpenCL (which I still need to work on merging into trunk) Seth wrote: The OpenCL version of r.sun runs over 20x faster than the original version on my machine (2.26 GHz Mac Pro vs. GeForce GTX 285). However, it is hampered by the low memory on your GPU, so you may need to partition your raster. Just some performance fyi, running the r.sun analysis in 1 chunk (n=1) takes about 4 hours and requires about 16 GB of RAM. running a calculation in 8 chunks (n=8) knocks
[GRASS-dev] Catching an issue from external binary using grass Python Script
Greetings I have a Grass Python script that calls an external binary using subprocess like: p=subprocess(COMMAND). Due to some limitations (memory) sometimes i get this copied into Command Output: This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. (this is windows) 1- How can catch this error (with except but I don't know which error to use Thanks Jenny ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1408: WxNviz is crashing in GRASS 7 svn
#1408: WxNviz is crashing in GRASS 7 svn ---+ Reporter: PierreRoudier | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: nviz |Platform: Linux Cpu: x86-64 | ---+ Comment(by annakrat): Hi, try to ask on wxpython-users mailing list, if anyone has the same problem. http://www.wxpython.org/maillist.php Anna -- Ticket URL: http://trac.osgeo.org/grass/ticket/1408#comment:19 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] Re: [GRASS GIS] #1412: Different problem with scalebar in GRASS 6.5
#1412: Different problem with scalebar in GRASS 6.5 --+- Reporter: cmbarton | Owner: grass-dev@… Type: defect | Status: closed Priority: major| Milestone: 6.5.0 Component: wxGUI| Version: svn-develbranch6 Resolution: invalid |Keywords: barscale Platform: Unspecified | Cpu: Unspecified --+- Changes (by cmbarton): * status: new = closed * resolution: = invalid Comment: I rebooted my machine, restarted GRASS, and this error does not seem to be happening any more. (the others reported yesterday still do, and do so on my desktop too). I will close since Martin cannot reproduce and it has magically disappeared from my box too. Michael -- Ticket URL: http://trac.osgeo.org/grass/ticket/1412#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
[GRASS-dev] Re: [GRASS GIS] #1408: WxNviz is crashing in GRASS 7 svn
#1408: WxNviz is crashing in GRASS 7 svn ---+ Reporter: PierreRoudier | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: nviz |Platform: Linux Cpu: x86-64 | ---+ Comment(by cmbarton): I think we can close this since it seems to be a problem with Pierre's computer not being able to run the openGL canvas for some reason. OK? Michael -- Ticket URL: http://trac.osgeo.org/grass/ticket/1408#comment:20 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] Re: [GRASS GIS] #1412: Different problem with scalebar in GRASS 6.5
#1412: Different problem with scalebar in GRASS 6.5 --+- Reporter: cmbarton | Owner: grass-dev@… Type: defect | Status: closed Priority: major| Milestone: 6.5.0 Component: wxGUI| Version: svn-develbranch6 Resolution: invalid |Keywords: barscale Platform: Unspecified | Cpu: Unspecified --+- Comment(by annakrat): It's weird, I still get this error and I tried to fix it (5 min ago, I didn't noticed you closed it). The problem appears when the option north arrow only is checked. I have just commited the patch in G7 (the same error as G65). Please try it. Anna -- Ticket URL: http://trac.osgeo.org/grass/ticket/1412#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
[GRASS-dev] Re: [GRASS GIS] #1412: Different problem with scalebar in GRASS 6.5
#1412: Different problem with scalebar in GRASS 6.5 --+- Reporter: cmbarton | Owner: grass-dev@… Type: defect | Status: closed Priority: major| Milestone: 6.5.0 Component: wxGUI| Version: svn-develbranch6 Resolution: invalid |Keywords: barscale Platform: Unspecified | Cpu: Unspecified --+- Comment(by cmbarton): Did you find out why G7 is displaying 3 N. arrows in a horizontal row, with no fill on one of them? Michael -- Ticket URL: http://trac.osgeo.org/grass/ticket/1412#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] Re: [GRASS GIS] #1412: Different problem with scalebar in GRASS 6.5
#1412: Different problem with scalebar in GRASS 6.5 --+- Reporter: cmbarton | Owner: grass-dev@… Type: defect | Status: closed Priority: major| Milestone: 6.5.0 Component: wxGUI| Version: svn-develbranch6 Resolution: invalid |Keywords: barscale Platform: Unspecified | Cpu: Unspecified --+- Comment(by annakrat): Replying to [comment:7 cmbarton]: Did you find out why G7 is displaying 3 N. arrows in a horizontal row, with no fill on one of them? No, but I guess it's problem with d.barscale and not wxGUI. Anna -- Ticket URL: http://trac.osgeo.org/grass/ticket/1412#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
[GRASS-dev] Re: [GRASS GIS] #1412: Different problem with scalebar in GRASS 6.5
#1412: Different problem with scalebar in GRASS 6.5 --+- Reporter: cmbarton | Owner: grass-dev@… Type: defect | Status: closed Priority: major| Milestone: 6.5.0 Component: wxGUI| Version: svn-develbranch6 Resolution: invalid |Keywords: barscale Platform: Unspecified | Cpu: Unspecified --+- Comment(by cmbarton): It seems to be only a problem with latlon locations. I just tested the other issue (not keeping settings and raising an error), and it seems like you've fixed it. So it seems like there were 2 different issues in 2 different GRASS systems. You've fixed the wxGUI one, but the other one remains and is likely to be in d.barscale. So I will indicate this for trac #1410. We can keep this closed this I believe. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1412#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
[GRASS-dev] Re: [GRASS GIS] #1410: scalebar displays multiples north arrows
#1410: scalebar displays multiples north arrows ---+ Reporter: cmbarton | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Display| Version: svn-trunk Keywords: barscale, d.barscale, north arrow |Platform: All Cpu: Unspecified| ---+ Changes (by cmbarton): * keywords: = barscale, d.barscale, north arrow * platform: Unspecified = All * component: Default = Display Comment: The settings issue (above) turned out to be a wxGUI issue that is now solved. The multiple arrows only seem to appear in a latlon location and seem to be a d.barscale issue. Related to this, is the missing shading (black right triangle and white left triangle is now clear on both sides) intentional or accidental? -- Ticket URL: http://trac.osgeo.org/grass/ticket/1410#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
