[GRASS-dev] Specify color as #RRGGBB

Dear all, in r69683 I've added few lines to support colors hexadecimal numbers for colors when prefixed by hash. That's the syntax often used in HTML (CSS) and by other programs and formats. Now instead of d.vect map=hospitals color=80:170:255 you can do this: d.vect map=hospitals

Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

Hi Nikos, On Wed, Oct 5, 2016 at 7:39 PM, Nikos Alexandris wrote: > could you name some good examples (not to the > manual/s), some real modules with integrated tests? I am much in need > for good code. > I'm not sure if they are good, but here are some examples

Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

On Tue, Oct 4, 2016 at 4:55 PM, Anna Petrášová wrote: > [...] > c) test correctness of results. > It just depends how you write them, and yes, for some modules c) is > more difficult to implement than for others. > On Thu, Oct 6, 2016 at 5:00 PM, Anna Petrášová

Re: [GRASS-dev] [GRASS-SVN] r69651 - grass/trunk/vector/v.external

Hi Martin, regarding r69651, would you consider moving the code to a function in a separate file or preferable putting it to the library? There is several modules which have similar code. Thanks, Vaclav On Mon, Oct 3, 2016 at 11:47 AM, wrote: > Author: martinl > Date:

Re: [GRASS-dev] Adding an expert mode to the parser

On Wed, Sep 28, 2016 at 4:35 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > On Tue, Sep 27, 2016 at 5:55 PM, Vaclav Petras <wenzesl...@gmail.com> > wrote: > > > > On Mon, Sep 26, 2016 at 5:50 PM, Vaclav Petras <wenzesl...@gmail.com> > wrote: >

Re: [GRASS-dev] missing / wrong link in raster3d.html

On Wed, Sep 28, 2016 at 7:29 AM, Paulo van Breugel wrote: > On https://grass.osgeo.org/grass70/manuals/raster3d.html the link to '3D > raster introduction' (https://grass.osgeo.org/grass > 70/manuals/3d%20rasterintro.html) does not exist. It probably should > point to

Re: [GRASS-dev] Adding an expert mode to the parser

On Tue, Sep 27, 2016 at 5:38 PM, Sören Gebbert wrote: > However, the correct use of GRASS_REGION is still unclear to me. There is a function in grass.script [1] which can generate the right string. It calls g.region with -u, so you can modify the region with

Re: [GRASS-dev] Adding an expert mode to the parser

On Tue, Sep 27, 2016 at 5:01 PM, Sören Gebbert wrote: > From my understanding, the GRASS_REGION environmental variable is > supported by G_get_window() [1]. However, most raster modules > uses Rast_window_rows() and Rast_window_cols() to get the current >

Re: [GRASS-dev] Adding an expert mode to the parser

On Mon, Sep 26, 2016 at 5:50 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: > If the --help is just for scanning and the issue is that it simply too > long, hiding some parameters is not the only option we have. For many (and > more in the future hopefully) parameters we hav

Re: [GRASS-dev] Adding an expert mode to the parser

On Fri, Sep 23, 2016 at 5:22 PM, Markus Neteler wrote: > * various commands: "Use the low-memory version" - also more advanced I guess this is a typical example where we need to be careful. I can imagine a situation when a beginner has a lot of data and low-end hardware. By

Re: [GRASS-dev] Adding an expert mode to the parser

On Fri, Sep 23, 2016 at 5:22 PM, Markus Neteler wrote: > Maybe not hide then but at least group the parameters and flags rather > than alpha-order or random mix. > This is something which can be done right now. The options and flags are presented in the order as they are

Re: [GRASS-dev] Adding an expert mode to the parser

On Mon, Sep 26, 2016 at 5:24 PM, Veronica Andreo wrote: > I'm with MaDi in that if I see a very long list of flags and parameters in > the terminal when using --h, i just go to the manual... I just use --h in > CLI for a quick recalling of flags/options... A reduced list of

Re: [GRASS-dev] Adding an expert mode to the parser

On Sun, Sep 25, 2016 at 3:49 PM, Markus Neteler wrote: > when doing each job in its own mapset and reintegrate it in a single > target mapset as if able to process then in parallel in one mapset by > simply specifying the respective region to the command of interest. > Yes,

Re: [GRASS-dev] Adding an expert mode to the parser

On Sun, Sep 25, 2016 at 5:40 PM, Sören Gebbert wrote: > >r.mapclac --raster-region= --north= --south= --west= --east= --res= >> >--ewres= --nsres= --vect-region --raster-align= ... >> > I like this in the sense that if the region setting for the module is something

[GRASS-dev] Submitting rules for images and r.viewshed example

Hi all, looking at r69472 I wonder if we want to change submitting rules. The current guideline is saying 600px width. Consequently both the image and the max are image takes in the page is 600px. The height is assumed to be smaller than that (I assume). The image in r69472 is wider in the page

[GRASS-dev] What is considered as valid location and valid mapset

Hi all, I wonder what is a valid location and what is a valid mapset. The lib/init/grass.py file says: def is_mapset_valid(full_mapset): return os.access(os.path.join(full_mapset, "WIND"), os.R_OK) def is_location_valid(gisdbase, location): return os.access(os.path.join(gisdbase,

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

On Tue, Sep 13, 2016 at 11:15 AM, Markus Neteler wrote: > root@osgeo6:/home/neteler# pip install pygbif > bash: pip: command not found > I don't think it's necessary to install all addon dependencies on the build server for Python where it is easy to work around it. Moreover

Re: [GRASS-dev] v.in.pygbif addon: Manual does not build

On Tue, Sep 13, 2016 at 10:52 AM, Helmut Kudrnovsky wrote: > the difference ist that in v.in.natura2000 it's done in def main(); in > v.in.pygbif it's done before def main() > Right, this must be done only after calling grass.script.parser() function but also in the right scope,

Re: [GRASS-dev] Modified i.rgb.his

On Fri, Sep 9, 2016 at 10:13 AM, Nikos Alexandris wrote: > instead of modifying i.rgb.his and i.his.rgb, which, in my humble view, > would > take time to be accepted, even in trunk, I decided to derive to new > modules: > i.rgb.hsl

[GRASS-dev] Temporary 3D raster or delete 3D raster in C

Hi all, in r3.in.lidar I want to use temporary 3D rasters. There might be ways to avoid the need for it, but 3D raster is just the easiest thing for me. What I need is to delete the temporary raster after I finish the processing. Ideally I would call something like "close and remove" so that no

Re: [GRASS-dev] Fwd: [GRASS-web] Question on history of Raster Tiling in GRASS

On Wed, Aug 31, 2016 at 2:48 PM, Markus Neteler wrote: > > FYI from the "grass-web" list - please assist to provide the answer to Carl. > > For sure this matters: > https://grass.osgeo.org/programming7/segmentlib.html > > which was already in the GRASS GIS 4.1 programmer's

Re: [GRASS-dev] How to: if undefined, set to NULL?

On Sun, Sep 4, 2016 at 9:45 AM, Nikos Alexandris wrote: > Updated in sandbox, see: https://trac.osgeo.org/grass/changeset/69365 > > Is it though correct? > I was not looking at the logic but if (hue == -1.0) { is not safe. Although it will probably work most of the

[GRASS-dev] Delete r.le.* now?

Hi, in November 2014, r.le suite was moved to Addons as being functional and potentially still useful although there is r.li [1, 2]. There were some improvements in r.li around that time [3] and some small improvements in g.gui.rlisetup since than [4]. However, more importantly, the r.le modules

Re: [GRASS-dev] grass 7.2 planning

On Wed, Aug 31, 2016 at 2:52 AM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > For each release news, we would put in the addons added since the last > release of that series. > > So, for 7.0.5, we would add the grass6 addons which were uploaded since > 7.0.4, and for 7.2 a list of all

Re: [GRASS-dev] Download and access statistics for Addons

On Sat, Nov 14, 2015 at 9:31 AM, Vaclav Petras <wenzesl...@gmail.com> wrote: > > On Sat, Nov 14, 2015 at 8:17 AM, Markus Neteler <nete...@osgeo.org> wrote: > >> On Nov 13, 2015 9:51 PM, "Vaclav Petras" <wenzesl...@gmail.com> wrote: >> > Bu

Re: [GRASS-dev] grass 7.2 planning

On Tue, Aug 30, 2016 at 11:08 AM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > - important: please add fixes and your favourite improvements to the >>> 7.2.0-News page (too much for one person to check) >>> >> >> > Fixes are added automatically, no ? And they should no go into the

[GRASS-dev] 7.3 milestone

Hi all, I was thinking if it makes sense to have 7.3 as a milestone. It will never be released, so it is not a standard milestone. Some projects have milestone "Future", "Future Release" or no milestone for such cases. I think the way I'm thinking about it for GRASS GIS is that the milestone is

Re: [GRASS-dev] [GRASS-SVN] r69248 - grass/trunk/gui/wxpython/tplot

On Wed, Aug 24, 2016 at 10:52 AM, Luca Delucchi wrote: > thanks Vaclav, god to know... but I think it could be correct that > function should be called before it will be destroyed > __del__ in Python is complicated. I'm not sure what is the correct way to use it. I only

Re: [GRASS-dev] [GRASS-SVN] r69248 - grass/trunk/gui/wxpython/tplot

On Wed, Aug 24, 2016 at 9:29 AM, wrote: > +self.__del__() > self.Destroy() > `self.__del__()` just doesn't sound right. A function such as release_resources() is recommended in these cases, see e.g.: http://stackoverflow.com/a/6104568/574907

Re: [GRASS-dev] Rendering of vector layers can be slow

On Mon, Aug 8, 2016 at 5:27 AM, Blumentrath, Stefan < stefan.blumentr...@nina.no> wrote: > In this context I am struggling with rendering speed in GRASS 7.0.4. I am > working on a relatively powerful server with local data in native GRASS > format. There were improvements in 7.2, can you

Re: [GRASS-dev] G6 manual pages: text box added to make users aware of G7

On Thu, Aug 18, 2016 at 5:54 AM, Markus Neteler wrote: > > I am not a developer, just something I wondered; why not having one > > permanent address for the manual, which always reflects the latest stable > > release, and if needed, from there add links to older versions?

Re: [GRASS-dev] Final Report

Thanks! On Tue, Aug 16, 2016 at 3:28 AM, Mayank Agrawal wrote: > Here is the Readme - https://github.com/rashadkm/ > webgrass/blob/master/README > I suggest merging README and README.md. ___ grass-dev mailing list

Re: [GRASS-dev] Errored: GRASS-GIS/grass-ci#1438 (master - 5442e14)

On Wed, Aug 10, 2016 at 3:46 PM, Travis CI wrote: > *System message:* > > We are seeing build failures due to new sudo-enabled Precise and Trusty > images. See more details here > . Thank you for > your enduring

Re: [GRASS-dev] m.printws - new module recommendation/announcement

On Wed, Aug 3, 2016 at 3:47 PM, Veronica Andreo wrote: > extract only the m.printws, zip it and use g.extension > > g.extension m.printws url=/home/veroandreo/software/m.printws.zip > Zipping is not necessary, g.extension should work on directories as well.

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

On Tue, Jul 5, 2016 at 9:21 AM, Yann wrote: > Vaclav, what about i.edge? Loads everything into memory without an option for "lowmem" processing. That's not ideal. ___ grass-dev mailing list grass-dev@lists.osgeo.org

Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

On Sun, Jul 3, 2016 at 6:32 PM, Markus Neteler wrote: > The general criteria are > - code follows submission standards > - must be portable > - must be well documented with examples > - must be of interest to a wider audience > I would add "well tested (i.e. very mature) or

Re: [GRASS-dev] Addons: Python error when checking if package is installed - r.randomforest

On Mon, Jun 27, 2016 at 7:18 AM, Markus Neteler wrote: > (I noted that various GRASS scripts use different ways for this check, > the test for 3rd party packages should be standardized.) > I so far promoted lazy import* as a solution to these dependencies. The important part

Re: [GRASS-dev] [SoC]Week-4 WebGrass

Hi Mayank, On Tue, Jun 21, 2016 at 2:32 PM, Mayank Agrawal wrote: > for the v.buffer (v.buffer --interface-description), there is option for > "input vector map" and "output vector map" (screenshot >

Re: [GRASS-dev] map display enhancement

On Mon, Jun 20, 2016 at 10:44 AM, Vincent Bain wrote: > Indeed I was thinking of a process at the display driver level. This > would allow (am I wrong) to mix whatever kind of features (vector, > raster, labels, ...). > If I understand correctly, the general combination would

Re: [GRASS-dev] map display enhancement

On Mon, Jun 20, 2016 at 10:05 AM, Anna Petrášová wrote: > > playing around with multiple layers in the map display I wonder if > > anyone ever suggested to introduce blending modes beside the already > > implemented "opacity" option. I mean it would be great to be able to

[GRASS-dev] Online manual and compiled addons for different releases

Hi, can we please compile manual for addons for 7.2 release, so that the URLs already work? On a more general note, we are now in a strange situation when 7.2 URLs for addons don't work but you can't get new versions of addons for 7.0 if I understand r68591 correctly. There was already one break

Re: [GRASS-dev] [SoC]Week-2 WebGrass

Hi Mayank, On Sun, Jun 5, 2016 at 3:59 PM, Mayank Agrawal wrote: > Updated the startup page to be like the grass software. I was looking at it already in the week and it looks good. But I have same comment for you as I had for Ondrej: In general, you don't need to

Re: [GRASS-dev] GSoC 2016 - PyQt GRASS - Report 2

Hi Ondrej, the screenshots looks good. For the code, it might little bit too soon to judge it, but just keep in mind the need for design we talked about earlier. For some simple help, you can use pylint tool which will demand some code style. Start with the file tools/pylintrc.txt in the GRASS

Re: [GRASS-dev] trac Wiki macro to link to manual page (G7:modulename)

On Wed, Jun 1, 2016 at 7:37 PM, Markus Neteler wrote: > I wonder about the risk to break links? > > ok done in InterMapTxt. > Nice, thanks. That looks good. So, now we are using G70 and G72 for respective branches and releases and G7 for trunk till G8? > > Then I have

Re: [GRASS-dev] trac Wiki macro to link to manual page (G7:modulename)

On Wed, Jun 1, 2016 at 4:19 PM, Markus Neteler wrote: > > But now I wanted to add a new G72: macro for the same purpose. > Unfortunately I cannot find back nor recall how I implemented this > thing :) > > Anyone with an idea? My guess is that they are not macros but some

[GRASS-dev] Tip: Compile addons with make MODULE_TOPDIR=/usr/lib/grass70

On Sat, May 21, 2016 at 4:24 PM, wrote: > Author: amuriy > Date: 2016-05-21 13:24:32 -0700 (Sat, 21 May 2016) > New Revision: 68480 > > Added: >grass-addons/grass7/vector/v.explode/ >grass-addons/grass7/vector/v.explode/Makefile >

Re: [GRASS-dev] Weird v.proj bug: ERROR: Option does not accept multiple answers

On Thu, May 19, 2016 at 6:10 PM, Markus Neteler wrote: > > today I came across a weird error (both 7.0.svn and trunk): > > # NC datasets > GRASS 7.0.5svn (nc_spm_08_grass7):~ > v.proj -l bla > location=nc_spf_grass7 mapset=PERMANENT > > Description: > Re-projects a vector map

Re: [GRASS-dev] Fwd: new trac anti-spam filter

On Wed, May 11, 2016 at 10:00 AM, Markus Neteler wrote: > > But any use can report spam (I think there is a new link in the upper > right corner). Perhaps only admins. I don't see it.

[GRASS-dev] Tests failing with "requires string, provided"

A lot of tests are failing: http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2016-05-02-07-00/report_for_nc_basic_spm_grass7_nc/testfiles.html http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2016-05-03-07-00/report_for_nc_basic_spm_grass7_nc/testfiles.html Seems like PyGRASS

Re: [GRASS-dev] wxGUI programmer's manual ?

Hi Moritz, On Thu, May 12, 2016 at 3:26 AM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > Trying to understand how some of the code in the wxGUI works, I'm > confronted with the absence of documentation of the wxGUI code. > Please, feel free to ask on mailing list if something is

Re: [GRASS-dev] Fwd: new trac anti-spam filter

On Sat, May 7, 2016 at 7:19 PM, Markus Neteler wrote: > > https://trac.osgeo.org/grass/timeline > > > > Cleaned and Bayes filter better trained now. > New spam wiki pages and they seems to contain text from: https://trac.osgeo.org/grass/wiki/BadContent

Re: [GRASS-dev] grass 7.2 planning

On Tue, May 10, 2016 at 10:52 AM, Vaclav Petras <wenzesl...@gmail.com> wrote: > I'll create a ticket, so it is clear what's the plan. Created ticket #3034 for the layers in v.in.lidar, removed the vector output from r.in.lidar in r68418. https://trac.osgeo.org/grass/ticket/3

Re: [GRASS-dev] grass 7.2 planning

On Tue, May 10, 2016 at 10:22 AM, Martin Landa wrote: > 2016-04-30 14:09 GMT+02:00 Martin Landa : > >> I have some things in lidar modules which would be good to do before the > >> branching, namely changing the layer options to flag(s) and removal

Re: [GRASS-dev] grass 7.2 planning

On Thu, May 5, 2016 at 10:12 AM, Markus Neteler wrote: > We have a an additional 7.3.0 (will never be released) which we will > rename to 7.4.0 in future. > So, do we even need 7.3.0 milestone? BTW, we need 7.0.4 version in Trac.

Re: [GRASS-dev] Added i.landsat8.swlst in grass-addons

On Sat, May 7, 2016 at 5:14 PM, Nikos Alexandris wrote: > -The k-flag (keep current computational region) is invers to GRASS >> standards. Maybe better to switch the behavior? >> > > Not sure. It's kind of related to the #1 mistake everyone does, forget >

[GRASS-dev] Trac closes ticketed based on commit message

This might be good to know about: The new (much improved) Trac version (perhaps with some plugin or settings) surprised me again when it closed ticket automatically after putting "closes #..." or "fixes #..." into a commit message. It might be a good feature for us, except when backport, unittest,

Re: [GRASS-dev] Fwd: new trac anti-spam filter

On Sat, May 7, 2016 at 1:17 PM, Markus Neteler wrote: > FYI! > > (I'm in the OSGeo-SAC team but thought to fwd here to avoid any bus factor) > > Indeed, we have spam in our wiki, see > https://trac.osgeo.org/grass/admin/spamfilter/monitor > > I cleaned that one up now. >

Re: [GRASS-dev] grass 7.2 planning

On Sat, Apr 30, 2016 at 8:09 AM, Martin Landa <landa.mar...@gmail.com> wrote: > > 2016-04-29 15:09 GMT+02:00 Vaclav Petras <wenzesl...@gmail.com>: > > > I have some things in lidar modules which would be good to do before the > > branching, namely changing the lay

Re: [GRASS-dev] [GRASS-SVN] r68329 - grass/trunk/lib/gis

On Fri, Apr 29, 2016 at 9:56 AM, Markus Neteler wrote: > > https://trac.osgeo.org/grass/changeset/68329 > > Question: are modules automagically picked up for global block or do > they need to be listed? > I don't see any list of modules to be considered for global and

Re: [GRASS-dev] [GRASS-SVN] r68329 - grass/trunk/lib/gis

On Fri, Apr 29, 2016 at 6:33 AM, wrote: > # v.db.select > v.db.select|nv:null_value > +v.db.select|fs:separator > v.db.select|vs:vertical_separator > Shouldn't the "global block" in renamed_options take care of nv and fs? ### Global fs:separator nv:null_value dt:dtime

Re: [GRASS-dev] grass 7.2 planning

On Fri, Apr 29, 2016 at 7:22 AM, Martin Landa wrote: > 1) to create releasebranch 7_2 ASAP (in the beginning of May) > 1) soft freeze in releasebranch_7_2 ~ 16 May > I have some things in lidar modules which would be good to do before the branching, namely changing the

Re: [GRASS-dev] Added i.landsat8.swlst in grass-addons

On Wed, Apr 20, 2016 at 9:54 AM, Nikos Alexandris wrote: > I hope I didn't do anything wrong in adding this. Due to lack of time, > I didn't check if all is well. Please, let me know in case I overlooked > something that might hinder the normal workflow in the addons

Re: [GRASS-dev] grass.info versus print

On Thu, Apr 14, 2016 at 9:55 AM, Paulo van Breugel wrote: > I would have to go through the individual examples but sometimes it might > be be clear what is a message to inform user about something and what is a > text output of the module. A rule of thumb can be that

Re: [GRASS-dev] grass.info versus print

On Thu, Apr 14, 2016 at 7:33 AM, Paulo van Breugel wrote: > On Thu, Apr 14, 2016 at 1:04 PM, Glynn Clements > wrote: > >> >> In general, scripts should use the g.message wrappers rather than >> Python's "print" statement or os.write(), as that

Re: [GRASS-dev] [GRASS GIS] #2876: r.sun (mode 1): data are not timestamped correctly

On Tue, Apr 12, 2016 at 8:47 AM, Thomas Huld wrote: > The time zone is +1 for Central Europe. Is somebody willing to contribute a table for the manual with examples of time zones and values needed? ___ grass-dev mailing list

Re: [GRASS-dev] creating temporary mapsets in a parallelized python script

On Mon, Apr 11, 2016 at 5:19 PM, Helmut Kudrnovsky wrote: > > I see, then it's easier to fix the script and use grass.use_temp_region > > From the manual: > > script.core.use_temp_region()[source]¶ > Copies the current region to a temporary region with “g.region save=”, then >

Re: [GRASS-dev] usage of os.linesep (was: Re: [GRASS-SVN] r68240 - grass/trunk/scripts/v.report_

On Mon, Apr 11, 2016 at 11:15 AM, Huidae Cho wrote: > What about this then? For reading text files, use \r\n. For reading > outputs from GRASS modules and writing, use os.linesep. > > I think this makes sense because it can handle cross platform files safely > and it's very

Re: [GRASS-dev] grass.info versus print

Hi, Paulo! On Mon, Apr 11, 2016 at 10:04 AM, Paulo van Breugel wrote: > I want to provide the output formatted in three columns. I can use > > nlength = 20 > RES = [MAPy, vif, sqrtvif] > print '{0[0]:{1}s} {0[1]:8.2f} {0[2]:8.2f}'.format(RES, nlength) > > This prints

Re: [GRASS-dev] [GRASS-SVN] r68140 - in grass/trunk/scripts: d.correlate d.frame d.polar d.rast.edit d.rast.leg d.redraw db.dropcolumn db.in.ogr db.out.ogr db.test db.univar g.extension g.extension/te

On Wed, Mar 30, 2016 at 10:26 AM, Markus Neteler wrote: > > On Fri, Mar 25, 2016 at 8:56 AM, Martin Landa wrote: > > Hi, > > > > 2016-03-25 8:54 GMT+01:00 Pietro : > >> Indeed there were no discussion, feel free to revert. > >> >

Re: [GRASS-dev] PEP 394 - The "python" Command on Unix-Like Systems

On Tue, Mar 29, 2016 at 5:33 AM, Pietro wrote: > I have fixed these errors, but since these changes are not fixing > bugs, I've just reverted them. I will commit these change back to > trunk as soon as we can start working on grass72. > I hope this won't become a common

Re: [GRASS-dev] Add a possible decorators to gunittest

On Tue, Mar 29, 2016 at 6:49 AM, Pietro wrote: > > 1. overwrite the environment variables, > 2. execute the test and > 3. restore the environment variables. In case the test involves just calling subprocesses, the best way probably is to change their environment instead of

Re: [GRASS-dev] Rendering from command line does not respect size

On Mon, Mar 28, 2016 at 2:53 PM, Martin Landa <landa.mar...@gmail.com> wrote: > 2015-05-04 2:47 GMT+02:00 Vaclav Petras <wenzesl...@gmail.com>: > > d.mon png width=1500 height=1350 > > d.rast elevation > > > > ERROR: PNG: input file has incorr

Re: [GRASS-dev] RandomForest classifier for imagery groups add-on

On Sat, Mar 26, 2016 at 1:42 PM, Paulo van Breugel wrote: > *2nd try - input random sample of 100 points, 1 (12) and 0 (88), with b > flag* > r.randomforest -b igroup=predictors@SampleSize roi=test2 > output=test2_output ntrees=500 mfeatures=-1 minsplit=2 randst=1

Re: [GRASS-dev] RandomForest classifier for imagery groups add-on

On Sat, Mar 26, 2016 at 12:40 PM, Steven Pawley wrote: > I would like to draw your attention to a new GRASS add-on, r.randomforest, > which uses the scikit-learn and pandas Python packages to classify GRASS > rasters. Thanks, this looks good. Please consider adding

Re: [GRASS-dev] PEP 394 - The "python" Command on Unix-Like Systems

On Fri, Mar 25, 2016 at 2:14 AM, Pietro wrote: > > I commit some changes in pygrass (r68138), temporal library (r68139) > and GRASS scripts (r68140) that were on my trunk from a bit... Nice! But please, check the tests:

Re: [GRASS-dev] 7.0.4 release planning

On Fri, Mar 25, 2016 at 5:18 AM, Martin Landa wrote: > > Please try to solve issues mentioned [2] ASAP. More importantly, see blockers [3]. Note that the query was for 7.0.2 and it requires to be updated after each release [4]. [2]

Re: [GRASS-dev] 7.0.4 release planning

On Fri, Mar 25, 2016 at 8:02 AM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > These 4 all appear to be new features, not a bug fixes. If that is the > case, they should not be backported. +1 ___ grass-dev mailing list

Re: [GRASS-dev] Interest in GSoC 2016

On Fri, Mar 25, 2016 at 8:46 AM, massimo di stefano < massimodisa...@gmail.com> wrote: > Or design the gui code base in a way that will make the adoption of new > rendering systems as easy as possible. > +1. High quality code should be the main focus here.

Re: [GRASS-dev] GRASS 7.0.3 and Numpy 1.10 (or Numpy > 1.8)

On Thu, Mar 24, 2016 at 8:36 AM, Ben Hur Pintor wrote: > I use GRASS for most of my work involving solar radiation modelling using > r.sun. I usually work on Ubuntu 14.04 or OSGeoLive 9.0. A few days ago, I > updated the numpy installations of my system to the latest

Re: [GRASS-dev] [GRASS-SVN] r68127 - grass/trunk/lib/gis

On Wed, Mar 23, 2016 at 11:29 PM, Huidae Cho wrote: > Vaclav, that script completely removes tabs and I didn't want to introduce > a big revision for no reason other than changing those two options to match > the rest of the file. I think there is no need to do that. There

Re: [GRASS-dev] [GRASS-SVN] r68127 - grass/trunk/lib/gis

On Wed, Mar 23, 2016 at 5:29 PM, wrote: > Author: hcho > Date: 2016-03-23 14:29:40 -0700 (Wed, 23 Mar 2016) > New Revision: 68127 > > Modified: >grass/trunk/lib/gis/parser_standard_options.c > Log: > parser: Fix indentation > > Please, see:

Re: [GRASS-dev] r.regression.multi failing

On Wed, Mar 23, 2016 at 11:57 AM, Markus Metz wrote: > > > Now this is treated as an error > > (ERROR: Multiple regression failed"), which I guess is the equivalent of > > grass.error() in a python script? Perhaps it would be possible to > provide a > > warning

Re: [GRASS-dev] r.rgb: syntax error, unexpected $end, expecting VARNAME or NAME or STRING

On Wed, Mar 23, 2016 at 6:44 AM, Markus Neteler wrote: > On Tue, Mar 22, 2016 at 10:37 PM, Markus Metz > wrote: > > On Fri, Mar 18, 2016 at 3:10 PM, Markus Neteler > wrote: > ... > GRASS 7.1.svn (nc_spm_08_grass7): >

Re: [GRASS-dev] raster query/r.what error with a r.external-linked raster

On Tue, Mar 22, 2016 at 10:03 AM, Helmut Kudrnovsky wrote: > > as I'm not used to compile on Linux, what may be the command to > compile with -ggdb? configure? make? > It is a compiler flag and it can be set using before you run ./configure using the CFLAGS environmental

Re: [GRASS-dev] r.rgb: syntax error, unexpected $end, expecting VARNAME or NAME or STRING

On Tue, Mar 22, 2016 at 5:37 PM, Markus Metz wrote: > Is there any reason why this should not work? According to the manual > it should work. > > If neither red or green or blue are given, r.rgb could use > red=${input}.r > green=${input}.g > blue=${input}.b > >

Re: [GRASS-dev] Interest in GSoC 2016

Hi Ondrej, On Thu, Mar 17, 2016 at 2:45 PM, wrote: > My idea was to generalize GUI Code for Qt-based GUI. Nowadays, Qt (PyQt) > is increasingly used (look at QGis, for example) and I think it would be > better to have minimally the roots of GUI in Qt. It’s also much easier

Re: [GRASS-dev] r.rgb: syntax error, unexpected $end, expecting VARNAME or NAME or STRING

On Wed, Mar 16, 2016 at 1:27 PM, Markus Neteler wrote: > > I just needed r.rgb and found the script broken: must be a silly bug > but I don't see it..: > > # NC > > GRASS 7.1.svn (nc_spm_08_grass7): > r.rgb input=elevation > > syntax error, unexpected $end, expecting VARNAME

Re: [GRASS-dev] [GRASS-SVN] r68077 - in grass/branches/releasebranch_7_0/scripts: r.blend r.rgb

Markus, all, On Fri, Mar 18, 2016 at 10:09 AM, wrote: > Author: neteler > Date: 2016-03-18 07:09:42 -0700 (Fri, 18 Mar 2016) > New Revision: 68077 > > r.rgb: more keywords; fix example; r.blend manual: add r.rgb reference > (trunk, r68076) > > > g.region raster=elevation

Re: [GRASS-dev] changes in r.in.aster

On Wed, Mar 16, 2016 at 12:30 PM, Carlos Grohmann wrote: > 3 - This line was giving me errors: > if platform.system() == "Darwin": > cmd = ["arch", "-i386", "gdalwarp", "-t_srs", proj, srcfile, > tempfile ] > > arch: posix_spawnp: gdalwarp: Bad CPU type in

Re: [GRASS-dev] r.rgb: syntax error, unexpected $end, expecting VARNAME or NAME or STRING

On Fri, Mar 18, 2016 at 10:10 AM, Markus Neteler wrote: > > ok. But another error occurs (missing error handling if the output > names were selected to be identica): > ... > > Perhaps there is an elegant solution to catch the (user) error above? Isn't this an issue for every

Re: [GRASS-dev] python manuals pages

On Fri, Mar 4, 2016 at 9:15 AM, Markus Neteler wrote: > > We should look at Travis. > > There was no notice... ...which is an issue. I added CFLAGS in r67999 but I'm not sure how to do it properly. Even it it works, I'm not sure if it is correct (it is probably overriding

Re: [GRASS-dev] python manuals pages

On Fri, Mar 4, 2016 at 3:44 AM, Markus Neteler wrote: > So, apparently r67994 broke it. I suppose due to the lack of update here: > include/defs/gis.h > Sorry, fixed in r67997. We should look at Travis. ___ grass-dev mailing list

Re: [GRASS-dev] Logo and other graphics

On Fri, Feb 26, 2016 at 6:44 AM, Paulo van Breugel wrote: > > For the individual modules / functions, the graphics used in the GRASS > Tools in QGIS may be an option. I don't think there are graphics for all > functions yet, but for many there are (not saying they are all

Re: [GRASS-dev] is it time to release GRASS71?

On Thu, Feb 25, 2016 at 12:04 PM, Martin Landa <landa.mar...@gmail.com> wrote: > 2016-02-25 16:37 GMT+01:00 Vaclav Petras <wenzesl...@gmail.com>: > > I think we make some promises regarding 7.0 and long term support > release in > > the announcements. How this g

Re: [GRASS-dev] is it time to release GRASS71?

On Thu, Feb 25, 2016 at 10:00 AM, Martin Landa wrote: > this system is used also by QGIS, MapServer, moreover it's part of > GRASS history (with one exception - 6.3). I have no strong option > about that. I would say let's follow our tradition to use odd numbers > for dev

Re: [GRASS-dev] is it time to release GRASS71?

On Thu, Feb 25, 2016 at 9:57 AM, Martin Landa wrote: > 2016-02-25 15:34 GMT+01:00 Moritz Lennert : > >> From where are we branching new release? trunk or stable branch? There > >> was a discussion about it in past. Is there a clear opinion

Re: [GRASS-dev] grass ico - size (windows resampling)

On Thu, Feb 25, 2016 at 8:57 AM, Vincent Bain wrote: > Concerning grass_osgeo icon, given both color spaces are very > close to each other, it is quite tricky to get a legible result. Here's > one suggestion (the grey grass background), and the original color > version. > I'm

Re: [GRASS-dev] is it time to release GRASS71?

On Thu, Feb 25, 2016 at 1:08 AM, Pietro wrote: > > Perhaps is time to think to release the next stable release of GRASS > before that the stable release and trunk start to diverge too much... >From where are we branching new release? trunk or stable branch? There was a

Re: [GRASS-dev] is it time to release GRASS71?

Hi, On Thu, Feb 25, 2016 at 4:14 AM, Martin Landa wrote: > 2016-02-25 8:59 GMT+01:00 Luca Delucchi : > > I support this, but I think it should be 7.2 not 7.1. Usually stable > > version is even number > > https://trac.osgeo.org/grass/wiki/Release >

Re: [GRASS-dev] -s flag in temporal modules

On Wed, Feb 24, 2016 at 9:42 AM, Sören Gebbert wrote: > We surely do not need ISO conform time suffixes for raster and vector > names, since they are not SQL compliant. Good point. Not having colon in the file name and vector name is actually a good idea.

<    1   2   3   4   5   6   7   8   9   10   >