Re: [GRASS-dev] r.hazard.flood is not running in windows7( Grass 6.5)
Hi Swapan, On Sun, Jul 20, 2014 at 10:47 PM, Swapan Ghosh swap.g...@gmail.com wrote: Dear all, I succesfully the module r.hazards.flood.py in windows xp but fail in windows 7. how does it fail? do you get any error messages? do you have the dependencies installed (r.area) ? which revision of grass are you using? standalone or osgeo4w? have you tried also running it on grass 6.4.4 and/or nightly build 7.0.0? Please let us know. cheers, madi -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.hazard.flood is not running in windows7( Grass 6.5)
SWAPAN GHOSH wrote Dear all, I succesfully the module r.hazards.flood.py in windows xp but fail in windows 7. Please help me. Regards, Swapan Ghosh ___ grass-dev mailing list grass-dev@.osgeo http://lists.osgeo.org/mailman/listinfo/grass-dev please provide more information how and what fails? did you set the region right, e.g. g.region -p -a rast=elevation@PERMANENT align=elevation@PERMANENT tested here with System Info GRASS Version: 6.4.5svn GRASS SVN Revision: 61153 GDAL/OGR: 1.11.0 PROJ4: Rel. 4.8.0, 6 March 2012 Python: 2.7.4 wxPython: 2.8.12.1 Platform: Windows-Vista-6.0.6002-SP2 (OSGeo4W) (Mon Jul 21 11:47:06 2014) r.hazard.flood --verbose map=elevation@PERMANENT flood=FLOOD mti=MTI [...] Done. (Mon Jul 21 11:47:25 2014) Befehl ausgeführt (18 Sek) System Info GRASS Version: 7.0.0svn GRASS SVN Revision: 61281 Erstellungsdatum: 2014-07-21 Build Platform: i686-pc-mingw32 GDAL/OGR: 1.11.0 PROJ.4: 4.8.0 GEOS: 3.4.2 SQLite: 3.7.17 Python: 2.7.4 wxPython: 2.8.12.1 Platform: Windows-Vista-6.0.6002-SP2 (OSGeo4W) (Mon Jul 21 11:51:42 2014) r.hazard.flood --verbose map=elevation@PERMANENT flood=FLOOD mti=MTI [...] Done. (Mon Jul 21 11:51:57 2014) Befehl ausgeführt (15 Sek) r.hazard.flood in winGRASS6.4.5svn and winGRASS7.0.0svn works. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/r-hazard-flood-is-not-running-in-windows7-Grass-6-5-tp5152002p5152074.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.hazard.flood is not running in windows7( Grass 6.5)
Actually, it needs external python installation. I solve it... but my question is that.why we need external py install.other wise get the following message [image: Inline image 1] Regards, Swapan Ghosh On Mon, Jul 21, 2014 at 3:28 PM, Helmut Kudrnovsky hel...@web.de wrote: SWAPAN GHOSH wrote Dear all, I succesfully the module r.hazards.flood.py in windows xp but fail in windows 7. Please help me. Regards, Swapan Ghosh ___ grass-dev mailing list grass-dev@.osgeo http://lists.osgeo.org/mailman/listinfo/grass-dev please provide more information how and what fails? did you set the region right, e.g. g.region -p -a rast=elevation@PERMANENT align=elevation@PERMANENT tested here with System Info GRASS Version: 6.4.5svn GRASS SVN Revision: 61153 GDAL/OGR: 1.11.0 PROJ4: Rel. 4.8.0, 6 March 2012 Python: 2.7.4 wxPython: 2.8.12.1 Platform: Windows-Vista-6.0.6002-SP2 (OSGeo4W) (Mon Jul 21 11:47:06 2014) r.hazard.flood --verbose map=elevation@PERMANENT flood=FLOOD mti=MTI [...] Done. (Mon Jul 21 11:47:25 2014) Befehl ausgeführt (18 Sek) System Info GRASS Version: 7.0.0svn GRASS SVN Revision: 61281 Erstellungsdatum: 2014-07-21 Build Platform: i686-pc-mingw32 GDAL/OGR: 1.11.0 PROJ.4: 4.8.0 GEOS: 3.4.2 SQLite: 3.7.17 Python: 2.7.4 wxPython: 2.8.12.1 Platform: Windows-Vista-6.0.6002-SP2 (OSGeo4W) (Mon Jul 21 11:51:42 2014) r.hazard.flood --verbose map=elevation@PERMANENT flood=FLOOD mti=MTI [...] Done. (Mon Jul 21 11:51:57 2014) Befehl ausgeführt (15 Sek) r.hazard.flood in winGRASS6.4.5svn and winGRASS7.0.0svn works. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/r-hazard-flood-is-not-running-in-windows7-Grass-6-5-tp5152002p5152074.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.hazard.flood is not running in windows7( Grass 6.5)
Actually, it needs external python installation. I solve it... but my question is that.why we need external py install.other wise get the following message first, please don't use winGRASS 6.5, it's some kind of abandoned and not meant for productive use. so try winGRASS 6.4.5svn (latest stable in the 6.4-series) or winGRASS 7.0.0svn (first stable in the 7.0-series) first before installing an external python. an external python isn't normally necessary, but sometimes there are some glitches with windows and python. AFAICT the best thing is to use winGRASS within the OSGe4W-framework (http://trac.osgeo.org/osgeo4w/). for example the tests mentioned before by me are done in the OSGe4W-framework without any external python installation. in summary this isn't a r.hazard.flood issue, but a windows-python quirk ... - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/r-hazard-flood-is-not-running-in-windows7-Grass-6-5-tp5152002p5152094.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.hazard.flood is not running in windows7( Grass 6.5)
Dear all, Thank you very much for the help. Swapan On Mon, Jul 21, 2014 at 4:29 PM, Helmut Kudrnovsky hel...@web.de wrote: Actually, it needs external python installation. I solve it... but my question is that.why we need external py install.other wise get the following message first, please don't use winGRASS 6.5, it's some kind of abandoned and not meant for productive use. so try winGRASS 6.4.5svn (latest stable in the 6.4-series) or winGRASS 7.0.0svn (first stable in the 7.0-series) first before installing an external python. an external python isn't normally necessary, but sometimes there are some glitches with windows and python. AFAICT the best thing is to use winGRASS within the OSGe4W-framework (http://trac.osgeo.org/osgeo4w/). for example the tests mentioned before by me are done in the OSGe4W-framework without any external python installation. in summary this isn't a r.hazard.flood issue, but a windows-python quirk ... - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/r-hazard-flood-is-not-running-in-windows7-Grass-6-5-tp5152002p5152094.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass gis story movie
Hi, 2014-07-15 20:31 GMT+02:00 Peter Löwe peter.lo...@gmx.de: the GRASS GIS Story has already been uploaded by someone to Youtube (https://www.youtube.com/watch?v=U3Hf0qI4JLc). Uploading it a second time won't do harm, but neither will solve some Youtube-related issues: Youtube does not allow for advanced search queries on the movies' content: The version already available on Youtube can _not_ be found by the search queries like GRASS GIS William Shatner. Further, there is no proper way to _cite_ the movie in a publication. In my feeling the movie has already become a historical document for the OSGeo community. In the sense of information preservation it would be good to have a version which long time preserved, citable and fully searchable. ah, it explains why I didn't find, I put link to [1]. BTW, the local movie seems to be not playable (at least on my computer). Martin [1] http://grass.osgeo.org/HostedVideoAlbums/video/GRASS-History-The-GRASS-Story/15/ -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass gis story movie
Hi, 2014-07-19 20:02 GMT+02:00 Vaclav Petras wenzesl...@gmail.com: in case you don't know about this document: The Future of GRASS? http://www.tldp.org/HOWTO/GIS-GRASS/future.html I add this link to [1]. Martin [1] http://grass.osgeo.org/home/history/documents/ -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] PROJSHARE changed to /usr/share/proj from /usr/local/share/proj
Hi, just FYI: since PROJ4.8 is now widely available and standard, I have taken liberty to change configure[.in] from PROJSHARE=/usr/local/share/proj to PROJSHARE=/usr/share/proj which results now in: --with-proj-share=/usr/share/proj being used by default. Rationale: This helps to avoid an ugly error message in the location wizard (EPSG dialog) when GRASS wasn't explicitly compiled with --with-proj-share. If no objections, I'll backport r61296 to relbr70. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass gis story movie
On Mon, Jul 21, 2014 at 3:37 PM, Martin Landa landa.mar...@gmail.com wrote: ... BTW, the local movie seems to be not playable (at least on my computer). The reason might be that it is in MOV format. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r61282 - in grass/trunk: include/defs lib/raster3d lib/raster3d/test
On Sun, Jul 20, 2014 at 9:56 AM, Sören Gebbert soerengebb...@googlemail.com wrote: 2014-07-20 6:06 GMT+02:00 Vaclav Petras wenzesl...@gmail.com: On Sat, Jul 19, 2014 at 8:02 PM, svn_gr...@osgeo.org wrote: Unfortunately changed the editor that i use the indention and converted all tabs into spaces at save time. Hence, the commit contains 95% tab to space conversion noise. I would actually agree with the change. I think that the GRASS indentation style is a bug since mixed tabs and spaces are enforced as a rule (not just allowed). However, it was decided that it won't be fixed and that current practice should be preserved. [1] Mixing tabs and spaces is really a mess. And i am part of the problem, since i am using several different computer for development and different editors, each with its own habits. Fortunately, there is a script which can enforce the unusual indent style [2]. And also `svn diff --ignore-space-change` for cases like this commit. Thank you for this hint, i will try to use it. See also improved: http://trac.osgeo.org/grass/wiki/Submitting/C#Indentation And just as a reminder for others, for Python code, use pep8 directly for new code. For existing code use: http://trac.osgeo.org/grass/wiki/Submitting/Python#Style pep8 --config=tools/pep8config.txt directory_to_check ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r61280 - in grass/trunk/gui: icons/grass wxpython/lmgr
Hi, 2014-07-19 19:18 GMT+02:00 Vaclav Petras wenzesl...@gmail.com: the right layer/item in layer manager layer tree, so I've just added new icons derived from the SVG version of current icons [1] which are contain only symbol for type of the layer and not unnecessary symbol for layer nor unwanted symbol for add. nice. I'm not sure what to do with SVGs. Should I try to put them to OSGeo repository? Is creating ticket the right way? probably to ask original author of the icons? Martin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PROJSHARE changed to /usr/share/proj from /usr/local/share/proj
Hi, 2014-07-21 15:46 GMT+02:00 Markus Neteler nete...@osgeo.org: If no objections, I'll backport r61296 to relbr70. +1 for backport. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2371: Vector digitizer does not colourize isles correctly
#2371: Vector digitizer does not colourize isles correctly ---+ Reporter: huhabla| Owner: grass-dev@… Type: defect | Status: new Priority: minor | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: digitizer,vector,topology |Platform: Linux Cpu: x86-64 | ---+ Changes (by martinl): * component: Default = wxGUI -- Ticket URL: http://trac.osgeo.org/grass/ticket/2371#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] using rand(x,y) in r.mapcalc (grass7)
On Sun, Jul 6, 2014 at 12:25 AM, Glynn Clements gl...@gclements.plus.com wrote: Glynn Clements gl...@gclements.plus.com wrote: ... In ticket #2272, I attached a portable implementation of lrand48(). If desired, we could add this to libgis and use that in preference to any implementation-specific PRNG. This would be excellent. If you want a different result each time, set GRASS_RND_SEED to a different value each time, e.g. IMHO this is not intuitive at all. I would suggest to invert the behaviour for GRASS 7: - per default generate random numbers which differ, - if the user needs reproducability, then have a env var to enable that. The main thing is that I believe that reproducibility should be the default. I humbly disagree. This is not what the user expects. It is also the opposite of how for example R behaves: R runif(1) [1] 0.5624295 runif(1) [1] 0.1683853 http://en.wikibooks.org/wiki/R_Programming/Random_Number_Generation#Seed If you want to perform an exact replication of your program, you have to specify the seed using the function set.seed(). If people have to take explicit action to introduce randomness, The problem is that most will not even realize the current behaviour of rand(). they're more likely to consider the issues involved. If randomised seeds are the default, the lack of reproducibility may not be considered until it is too late. The R community (and some users here) think the opposite... when you ask for rand() then you expect a random number. Just to avoid this: https://xkcd.com/221/ Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass-dev Digest, Vol 101, Issue 50
It is also on the GRASS for Mac site and runs fine. http://grassmac.wikidot.com/downloads (bottom of the page) Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Jul 21, 2014, at 7:08 AM, grass-dev-requ...@lists.osgeo.orgmailto:grass-dev-requ...@lists.osgeo.org grass-dev-requ...@lists.osgeo.orgmailto:grass-dev-requ...@lists.osgeo.org wrote: From: Martin Landa landa.mar...@gmail.commailto:landa.mar...@gmail.com Subject: Re: [GRASS-dev] grass gis story movie Date: July 21, 2014 at 6:37:51 AM MST To: Peter Löwe peter.lo...@gmx.demailto:peter.lo...@gmx.de Cc: Markus Neteler markus.nete...@fmach.itmailto:markus.nete...@fmach.it, GRASS developers list grass-dev@lists.osgeo.orgmailto:grass-dev@lists.osgeo.org Hi, 2014-07-15 20:31 GMT+02:00 Peter Löwe peter.lo...@gmx.demailto:peter.lo...@gmx.de: the GRASS GIS Story has already been uploaded by someone to Youtube (https://www.youtube.com/watch?v=U3Hf0qI4JLc). Uploading it a second time won't do harm, but neither will solve some Youtube-related issues: Youtube does not allow for advanced search queries on the movies' content: The version already available on Youtube can _not_ be found by the search queries like GRASS GIS William Shatner. Further, there is no proper way to _cite_ the movie in a publication. In my feeling the movie has already become a historical document for the OSGeo community. In the sense of information preservation it would be good to have a version which long time preserved, citable and fully searchable. ah, it explains why I didn't find, I put link to [1]. BTW, the local movie seems to be not playable (at least on my computer). Martin [1] http://grass.osgeo.org/HostedVideoAlbums/video/GRASS-History-The-GRASS-Story/15/ -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] using rand(x,y) in r.mapcalc (grass7)
On 21-07-14 19:01, Markus Neteler wrote: On Sun, Jul 6, 2014 at 12:25 AM, Glynn Clements gl...@gclements.plus.com wrote: Glynn Clements gl...@gclements.plus.com wrote: ... In ticket #2272, I attached a portable implementation of lrand48(). If desired, we could add this to libgis and use that in preference to any implementation-specific PRNG. This would be excellent. If you want a different result each time, set GRASS_RND_SEED to a different value each time, e.g. IMHO this is not intuitive at all. I would suggest to invert the behaviour for GRASS 7: - per default generate random numbers which differ, - if the user needs reproducability, then have a env var to enable that. The main thing is that I believe that reproducibility should be the default. I humbly disagree. This is not what the user expects. It is also the opposite of how for example R behaves: R runif(1) [1] 0.5624295 runif(1) [1] 0.1683853 http://en.wikibooks.org/wiki/R_Programming/Random_Number_Generation#Seed If you want to perform an exact replication of your program, you have to specify the seed using the function set.seed(). If people have to take explicit action to introduce randomness, The problem is that most will not even realize the current behaviour of rand(). they're more likely to consider the issues involved. If randomised seeds are the default, the lack of reproducibility may not be considered until it is too late. The R community (and some users here) think the opposite... when you ask for rand() then you expect a random number. And not only the R community I am sure. In all statistical packages I have ever worked with one can see the same behaviour, a random number is random (i.e., each time a different seed), unless the seed is explicitly defined by the user. And it seems to be the default behaviour by python/numpy: import numpy as np np.random.random() 0.8351426142559701 np.random.random() 0.4813823441998394 np.random.random() 0.7279314267025369 Just to avoid this: https://xkcd.com/221/ Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2372: GRASS 7 on windows starts with minimized CMD window
#2372: GRASS 7 on windows starts with minimized CMD window --+- Reporter: marisn | Owner: grass-dev@… Type: defect | Status: closed Priority: critical | Milestone: 7.0.0 Component: Startup | Version: svn-releasebranch70 Resolution: fixed|Keywords: wingrass Platform: MSWindows 8 | Cpu: Unspecified --+- Changes (by marisn): * status: new = closed * resolution: = fixed Comment: Works as a charm. No more problems with multiple user accounts. Thank you! -- Ticket URL: http://trac.osgeo.org/grass/ticket/2372#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 7.0beta3 planning
On Fri, Jul 18, 2014 at 8:39 AM, Helmut Kudrnovsky hel...@web.de wrote: what do you think about releasing beta3? have look in http://lists.osgeo.org/pipermail/grass-dev/2014-July/069983.html [GRASS-dev] GRASS 7: g.gui.rlisetup [...] Backport of r60219 is needed. http://trac.osgeo.org/grass/changeset/60219; Done in r61304. g.gui.rlisetup isn't starting in winGRASS7.0 Please test tomorrow's binary snapshot. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7: g.gui.rlisetup
(for the record) On Wed, Jul 9, 2014 at 4:48 PM, Anna Petrášová kratocha...@gmail.com wrote: On Wed, Jul 9, 2014 at 8:04 AM, Helmut Kudrnovsky hel...@web.de wrote: Backport of r60219 is needed. http://trac.osgeo.org/grass/changeset/60219 ... Done in r61304. BTW: I used the script: [neteler@oboe grass70]$ ~/software/grass-addons/tools/svn7merge 60219 Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7.0beta3 planning
On Fri, Jul 18, 2014 at 12:22 AM, Vaclav Petras wenzesl...@gmail.com wrote: what do you think about releasing beta3? Yes and no: it is time to do it but without the current blocker. The problems mentioned in this thread were fixed and fixes backported except for r60590 which is safe for GRASS by itself and thus can be safely backported now. ... r60590 Add G_fatal_longjmp() (needed for QGIS) glynn include/defs/gis.h, lib/gis/error.c http://trac.osgeo.org/grass/changeset/60590 ... if so, please do (someone) that. There is a lot of things in the tracker but they can be postponed I think: It is important to make real issues either blocker or at least critical to avoid that it slips through. ... I think we need to shift this listing either to a Wiki or to trac bugs. It is not efficient to do it via email (let's use that for the ping'ing). Concerning the BAT file support, is that now in relbr7? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] Broken r.stream.snap?
On Mon, Jul 14, 2014 at 12:05 PM, Johannes Radinger johannesradin...@gmail.com wrote: Hi, the module r.stream.snap which has been included now in the main code of GRASS 7 does not produce an output table which is linked to the output vector map. Can anyone reproduce that behavior? Yes. There is simply no DB code in r.stream.snap... Hope someone picks up bug report #2362. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2255: g.mlist warnings for layers found in other mapsets
#2255: g.mlist warnings for layers found in other mapsets -+-- Reporter: pvanbosgeo | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.1.0 Component: LibRaster| Version: unspecified Keywords: g.mlist, d.rast.leg, d.rast |Platform: Unspecified Cpu: Unspecified | -+-- Changes (by neteler): * keywords: g.mlist, d.rast.leg = g.mlist, d.rast.leg, d.rast Comment: Replying to [comment:3 hcho]: Fixed in r60261. (backported in r61040) Glynn posted some comments here: http://lists.osgeo.org/pipermail/grass-dev/2014-June/069628.html -- Ticket URL: http://trac.osgeo.org/grass/ticket/2255#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.0beta3 planning
On Mon, Jul 21, 2014 at 5:23 PM, Markus Neteler nete...@osgeo.org wrote: On Fri, Jul 18, 2014 at 12:22 AM, Vaclav Petras wenzesl...@gmail.com wrote: what do you think about releasing beta3? Yes and no: it is time to do it but without the current blocker. There is currently 10 blockers for 7.0 and 7.1, 3-5 are duplicates of Python issue. In addition to that. The g.list, g.mlist, g.remove and g.mremove chnages are in fact blockers since they are changing API. There is a lot of things in the tracker but they can be postponed I think: It is important to make real issues either blocker or at least critical to avoid that it slips through. ... I think we need to shift this listing either to a Wiki or to trac bugs. It is not efficient to do it via email (let's use that for the ping'ing). The query on Trac seems appropriate. We can add it to reports (as what?) or you can put a query result to a page. Some pages are using it. == List of tickets == [[TicketQuery(component=wxGUIkeywords=wxiclassorder=priority)]] http://trac.osgeo.org/grass/wiki/wxGUIDevelopment/wxIClass#Listoftickets http://trac.osgeo.org/grass/query?status=assignedstatus=newstatus=reopenedorder=prioritycol=idcol=summarycol=milestonecol=statuscol=typecol=prioritycol=componentcol=versioncol=keywordscol=timecol=changetimemilestone=7.0.0type=!enhancement Concerning the BAT file support, is that now in relbr7? No, relbr7 is using the older workaround. And about BAT and Python in general in trunk. I'm now confused about what was implemented and why. Vaclav Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1464: Bug on v.buffer
#1464: Bug on v.buffer ---+ Reporter: leonidas | Owner: grass-dev@… Type: defect| Status: closed Priority: critical | Milestone: 7.0.0 Component: Vector| Version: svn-trunk Resolution: fixed |Keywords: v.buffer Platform: All | Cpu: All ---+ Changes (by neteler): * status: new = closed * resolution: = fixed Comment: Closing as fixed. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1464#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] #1343: v.buffer2: difference between Linux 32bit and 64bit
#1343: v.buffer2: difference between Linux 32bit and 64bit
---+
Reporter: mmetz | Owner: grass-dev@…
Type: defect| Status: reopened
Priority: critical | Milestone: 6.4.5
Component: Default | Version: svn-develbranch6
Resolution:|Keywords: v.buffer
Platform: Linux | Cpu: x86-64
---+
Changes (by neteler):
* milestone: 7.0.0 = 6.4.5
Comment:
Done in G7, downgrading to G6 where GEOS support was added in r59970.
{{{
# G6:
v.buffer input=roadsmajor@PERMANENT output=roadsmajor_buf1_2000
distance=1000
}}}
Appears to work, closing (reopen if not).
Some fun performance comparison:
* G6.4.svn: 43.19 sec
* G7.0.svn: 7.59 sec
--
Ticket URL: https://trac.osgeo.org/grass/ticket/1343#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] #1343: v.buffer2: difference between Linux 32bit and 64bit
#1343: v.buffer2: difference between Linux 32bit and 64bit ---+ Reporter: mmetz | Owner: grass-dev@… Type: defect| Status: closed Priority: critical | Milestone: 6.4.5 Component: Default | Version: svn-develbranch6 Resolution: fixed |Keywords: v.buffer Platform: Linux | Cpu: x86-64 ---+ Changes (by neteler): * status: reopened = closed * resolution: = fixed -- Ticket URL: http://trac.osgeo.org/grass/ticket/1343#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] #2103: Make SUBMITTING files more accessible
#2103: Make SUBMITTING files more accessible --+- Reporter: wenzeslaus | Owner: grass-dev@… Type: task | Status: closed Priority: normal | Milestone: 7.0.0 Component: Docs | Version: svn-trunk Resolution: fixed|Keywords: submitting, addons, doxygen Platform: Unspecified | Cpu: Unspecified --+- Changes (by wenzeslaus): * status: new = closed * resolution: = fixed Comment: * All `SUBMITTING` files were converted to Trac wiki:Submitting pages (r61014). - wiki:Submitting/General - wiki:Submitting/C - wiki:Submitting/Python - wiki:Submitting/wxGUI - wiki:Submitting/Docs * All RFC documents were also moved to Trac wiki:RFC pages (r60890). * `SUBMITTING` files in addons tracked in #2104. * The [source:grass/trunk/doc doc] directory remains unresolved. * Various files may stay in their plain text form and only in source code. - source:grass/trunk/AUTHORS - source:grass/trunk/COPYING - source:grass/trunk/GPL.TXT - source:grass/trunk/CHANGES (last change 8 year ago) * `README` files here and there in the source code probably don't need any markup or publication. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2103#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] #2314: output r.out.xyz
#2314: output r.out.xyz -+-- Reporter: pvanbosgeo | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Default | Version: svn-trunk Keywords: separator, pipe, r.out.xyz, r.stats |Platform: MSWindows 7 Cpu: All | -+-- Comment(by wenzeslaus): Now relates to [http://lists.osgeo.org/pipermail/grass- dev/2014-July/069871.html discussion] ([http://osgeo- org.1560.x6.nabble.com/Re-GRASS-SVN-r60679-grass-trunk-lib-python-script- td5143645i20.html nabble) for r60679 because `shell=True` is used as a part of the proposed solution. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2314#comment:32 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] #2147: db.databases not working in GRASS 7
#2147: db.databases not working in GRASS 7
--+-
Reporter: cmbarton | Owner: grass-dev@…
Type: defect| Status: new
Priority: normal| Milestone: 7.0.0
Component: Database | Version: svn-trunk
Keywords: db.databases, sqlite |Platform: All
Cpu: OSX/Intel |
--+-
Comment(by wenzeslaus):
Is something mentioned here still an issue?
If unclear state of source code is the remaining issue (as suggested by
last comments), please, check the file again. The best think to do is
probably
{{{
cd db/drivers/sqlite
svn status
}}}
However, `svn revert db/drivers/sqlite/listdb.c` and `svn up` and also
`svn diff` and `svn info` can be useful too.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2147#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] #1625: Disk performance degrades by several orders of magnitude on two processes
#1625: Disk performance degrades by several orders of magnitude on two processes -+-- Reporter: sprice | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Default | Version: svn-trunk Keywords: |Platform: MacOSX Cpu: x86-64 | -+-- Comment(by wenzeslaus): Replying to [comment:4 hamish]: is there anything to be done for this ticket? or is it just an observation? I don't know. Perhaps writing a a benchmark/test which will test/show that two processes in parallel behaves as expected. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1625#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] #2017: ogsf compilation error
#2017: ogsf compilation error
---+
Reporter: martinl| Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker| Milestone: 7.0.0
Component: Compiling | Version: svn-trunk
Keywords: libc, ogsf, libavutil, ffmpeg |Platform: Linux
Cpu: x86-64 |
---+
Comment(by wenzeslaus):
Replying to [comment:22 hamish]:
A reminder, ffmpeg is not used with trunk, only for creating animations
directly in tcl/tk NVIZ in grass 6.
suggest to remove it from libogsf and configure.in in trunk.
I removed ffmpeg in r61305. I've used `autoconf2.13`. Compilation after
`make distclean` works. wxNVIZ and `m.nviz.image` (and `g.gui.animation`)
work.
I updated [source:grass/trunk/REQUIREMENTS.html REQUIREMENTS.html] but I
don't know what is appropriate update for the following files:
* [source:grass/trunk/mswindows/osgeo4w/config.h.vc
mswindows/osgeo4w/config.h.vc]
* [source:grass/trunk/macosx/ReadMe.rtf macosx/ReadMe.rtf]
* [source:grass/trunk/macosx/pkg/resources/ReadMe.rtf
macosx/pkg/resources/ReadMe.rtf]
I don't understand why, if I leave the parameters
{{{
--with-ffmpeg=no --with-ffmpeg-includes=/usr/include/libavcodec
/usr/include/libavformat /usr/include/libswscale /usr/include/libavutil
}}}
in my `./configure` call, no error is reported.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2017#comment:24
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] #1983: wingrass: permission denied to open grass70.py
#1983: wingrass: permission denied to open grass70.py -+-- Reporter: mmetz| Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Installation | Version: svn-trunk Keywords: wingrass, installer |Platform: MSWindows 7 Cpu: All | -+-- Comment(by wenzeslaus): Continued in #2290. Please close afterwards in case that this is really a duplicate. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1983#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] #2290: Wrong file permissions for grassXY.py on Windows (was: Grass not starting)
#2290: Wrong file permissions for grassXY.py on Windows (was: Grass not starting) --+- Reporter: dnewcomb | Owner: grass-dev@… Type: defect| Status: new Priority: critical | Milestone: 7.0.0 Component: Installation | Version: svn-releasebranch70 Keywords: installation |Platform: MSWindows 7 Cpu: x86-64| --+- Changes (by wenzeslaus): * keywords: = installation Comment: Possible duplicate of #1983. Please continue discussion here. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2290#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] #2099: G_OPT_M_COLR not recognized in Python script
#2099: G_OPT_M_COLR not recognized in Python script
-+--
Reporter: annakrat | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: LibGIS | Version: svn-trunk
Keywords: color table, parser |Platform: Linux
Cpu: Unspecified |
-+--
Comment(by wenzeslaus):
`t.rast.colors --interface-description` seems to work. `... | grep null`
gives nothing. `t.rast.colors --help` gives full output and no error:
{{{
Description:
...
Keywords:
...
Usage:
t.rast.colors [-rwlngae] input=name [color=string] [raster=name]
[volume=name] [rules=name] [--help] [--verbose] [--quiet]
Flags:
...
Parameters:
...
}}}
Test script with `G_OPT_M_COLR` should be created.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2099#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] #2292: compiling grass in windows 8
#2292: compiling grass in windows 8 ---+ Reporter: neuba | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Packaging | Version: unspecified Keywords: wingrass |Platform: Unspecified Cpu: x86-64 | ---+ Comment(by wenzeslaus): If this is really an issue, raise the priority to major. Also, neuba, if the files you attached contains a patch, please try to create a diff if possible, so your suggested update is immediately visible. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2292#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] #278: wxGUI: don't allow for negative column number
#278: wxGUI: don't allow for negative column number
--+-
Reporter: msieczka | Owner: martinl
Type: defect| Status: assigned
Priority: minor | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: parser|Platform: All
Cpu: All |
--+-
Comment(by wenzeslaus):
In GRASS, values ` 0` should be now specified in C as:
{{{
...
opt-options = 1-;
}}}
and in Python as:
{{{
...
#% options: 1-
}}}
So, v.in.ascii needs this fix, so that standard Parser mechanism is used
instead of custom error handling.
GUI now allows to input negative numbers but label contains valid range
1- and Run gives an standard error message generated by module (parser):
{{{
ERROR: Value -4 out of range for parameter x
Legal range: 1-
}}}
GUI would not allow to input values out of range if both limits would be
specified. GUI needs to be improved, so it can handle also range with min
or max only.
Modules using custom range handling, such as `v.in.ascii`, should be
chanaged to use parser.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/278#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
