Re: [GRASS-dev] [GRASS-PSC] RFC4 discussion call
IMHO lack of answer in a transparent procedure with reasonable response windows just means carry on, everyone agrees. Having a fixed last date for comments might force someone to say something (or used as an argument for STFU later). Just my 0.02, Māris. 2014-12-29 9:50 GMT+02:00 Markus Neteler nete...@osgeo.org: On Mon, Nov 24, 2014 at 2:50 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 24/11/14 14:38, Martin Landa wrote: Dear all, as we are closer and closer to GRASS 7 release I would like to open discussion related to Release procedure - RFC4 [1]. Ideally (I would say) it would make sense to find a way how accept such procedure before we start with GRASS RCs... Thanks for your feedback in advance! Martin [1] http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure Rereading it I found parts that didn't seem clear, so I reordered the sentences slightly to make the meaning clearer. While this is all nice, I am strongly lacking support in the day to day release management. Again the RC1 feedback is actually 0 (zero). The General Procedure in the document is lacking answers to what to do if no or no reasonable feedback occurs. Any ideas? We are in soft freeze for months. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r63797 - in grass/trunk: display/d.barscale display/d.colortable display/d.erase display/d.geodesic display/d.grid display/d.histogram display/d.legend display/d.mon displa
Hi, 2014-12-28 14:08 GMT+01:00 Martin Landa landa.mar...@gmail.com: I would suggest to rename bgcolor to bg_color. it would be nice to solve it before RC1. Any objections? Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r63797 - in grass/trunk: display/d.barscale display/d.colortable display/d.erase display/d.geodesic display/d.grid display/d.histogram display/d.legend display/d.mon displa
On Mon, Dec 29, 2014 at 11:47 AM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2014-12-28 14:08 GMT+01:00 Martin Landa landa.mar...@gmail.com: I would suggest to rename bgcolor to bg_color. it would be nice to solve it before RC1. Any objections? for me it is ok. ciao Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r63797 - in grass/trunk: display/d.barscale display/d.colortable display/d.erase display/d.geodesic display/d.grid display/d.histogram display/d.legend display/d.mon displa
Martin Landa wrote: I would suggest to rename bgcolor to bg_color. it would be nice to solve it before RC1. Any objections? Not an objection as such, but FWIW I'd still prefer a solution which allows background_color=, as well as bg_color=. -- 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] #2259: some temporal modules have empty manual page
#2259: some temporal modules have empty manual page --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: closed Priority: blocker | Milestone: 7.0.0 Component: Docs | Version: svn-trunk Resolution: fixed|Keywords: temporal Platform: Unspecified | Cpu: Unspecified --+- Changes (by lucadelu): * status: new = closed * resolution: = fixed Comment: Replying to [comment:9 neteler]: Luca Delucchi in collaboration with Soeren Gebbert updated the manual pages significantly in r63363. Backported in r63771. With r63808 and r63809 all the temporal manual has description and at least an example. More small improvements are required but I'm going to close this ticket, reopen if needed. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2259#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-SVN] r63797 - in grass/trunk: display/d.barscale display/d.colortable display/d.erase display/d.geodesic display/d.grid display/d.histogram display/d.legend display/d.mon displa
2014-12-29 12:26 GMT+01:00 Glynn Clements gl...@gclements.plus.com: it would be nice to solve it before RC1. Any objections? Not an objection as such, but FWIW I'd still prefer a solution which allows background_color=, as well as bg_color=. what does it mean exactly? back_ground_color or ? Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r63797 - in grass/trunk: display/d.barscale display/d.colortable display/d.erase display/d.geodesic display/d.grid display/d.histogram display/d.legend display/d.mon displa
On Mon, Dec 29, 2014 at 7:11 AM, Martin Landa landa.mar...@gmail.com wrote: 2014-12-29 12:26 GMT+01:00 Glynn Clements gl...@gclements.plus.com: it would be nice to solve it before RC1. Any objections? I think it's not necessary, it doesn't help with anything, everybody will keep using bgcolor anyway. We already have similar cases (pcurvature, nwalkers) which where already changed and we don't plan to add another underscore there. Anna Not an objection as such, but FWIW I'd still prefer a solution which allows background_color=, as well as bg_color=. what does it mean exactly? back_ground_color or ? Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ 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-SVN] r63797 - in grass/trunk: display/d.barscale display/d.colortable display/d.erase display/d.geodesic display/d.grid display/d.histogram display/d.legend display/d.mon displa
On Mon, Dec 29, 2014 at 5:47 AM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2014-12-28 14:08 GMT+01:00 Martin Landa landa.mar...@gmail.com: I would suggest to rename bgcolor to bg_color. it would be nice to solve it before RC1. Any objections? Actually yes, although not strong one. I don't see any advantage in bg_color. It's quite easy to find color there even if your English is rough. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ 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-SVN] r61255 - grass/trunk/gui/wxpython/core
On Tue, Oct 14, 2014 at 10:24 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Mon, Jul 14, 2014 at 3:03 PM, svn_gr...@osgeo.org wrote: Author: wenzeslaus Date: 2014-07-14 12:03:34 -0700 (Mon, 14 Jul 2014) New Revision: 61255 Modified: grass/trunk/gui/wxpython/core/utils.py Log: wxGUI/core: use gray always, sync purple with lib/gis/color_str.c although it is probably wrong before: depending on dict ordering gray or grey was used, (un)checking Transparent in GUI caused switching from gray to grey purple: accoring to Wikipedia it is different from violet and was correctly defined in the GUI before but this was not the same as in library Modified: grass/trunk/gui/wxpython/core/utils.py === --- grass/trunk/gui/wxpython/core/utils.py 2014-07-14 18:27:46 UTC (rev 61254) +++ grass/trunk/gui/wxpython/core/utils.py 2014-07-14 19:03:34 UTC (rev 61255) @@ -945,29 +945,37 @@ # update path if addonPath not in os.environ['PATH']: os.environ['PATH'] = addonPath + os.pathsep + os.environ['PATH'] - -# From lib/gis/col_str.c, except purple which is mentioned -# there but not given RGB values + + +# predefined colors and their names +# must be in sync with lib/gis/color_str.c str2rgb = {'aqua': (100, 128, 255), 'black': (0, 0, 0), 'blue': (0, 0, 255), 'brown': (180, 77, 25), 'cyan': (0, 255, 255), 'gray': (128, 128, 128), + 'grey': (128, 128, 128), 'green': (0, 255, 0), - 'grey': (128, 128, 128), 'indigo': (0, 128, 255), 'magenta': (255, 0, 255), 'orange': (255, 128, 0), - 'purple': (128, 0, 128), 'red': (255, 0, 0), 'violet': (128, 0, 255), + 'purple': (128, 0, 255), 'white': (255, 255, 255), 'yellow': (255, 255, 0)} rgb2str = {} -for (s,r) in str2rgb.items(): -rgb2str[ r ] = s +for (s, r) in str2rgb.items(): +rgb2str[r] = s +# ensure that gray value has 'gray' string and not 'grey' +rgb2str[str2rgb['gray']] = 'gray' +# purple is defined as nickname for violet in lib/gis +# (although Wikipedia says that purple is (128, 0, 128)) +# we will prefer the defined color, not nickname +rgb2str[str2rgb['violet']] = 'violet' Has somebody some idea about the purple and violet color definitions (in lib, formerly in GUI, on Wikipedia) before backport to release branch 7.0? I guess now is the time to change it. Wikipedia Violet is (127, 0, 255) Purple is (128, 0, 128) http://en.wikipedia.org/wiki/Purple http://en.wikipedia.org/wiki/Violet_%28color%29 GRASS GIS Violet (128, 0, 255) Purple is the same as Violet (in the same manner as Grey is Gray) http://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/color_str.c http://trac.osgeo.org/grass/browser/grass/trunk/include/colors.h http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/core/utils.py#L948 I cannot go through this again but perhaps somebody can have a look. Backport this one and change the definitions in library. Or, I would be fine with saying that this is known issue and fix it in 7.1. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G7 scripts: keywords versus keyword
Hi all, 2014-12-28 18:02 GMT+01:00 Markus Neteler nete...@osgeo.org: -#% keywords: general, projection, transformation +#% keywords: general +#% keywords: projection +#% keywords: transformation Shouldn't the name of the key be keyword rather than keywords since only one is allowed? Or it is too heavy change? Probably it should be changed. I would not mind to do the job. We could, however, also accept the plural form. The relevant line of code seems to be line 87 in general/g.parser/parse.c:if (G_strcasecmp(cmd, keywords) == 0) { no objections to change it to 'keyword'. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r63797 - in grass/trunk: display/d.barscale display/d.colortable display/d.erase display/d.geodesic display/d.grid display/d.histogram display/d.legend display/d.mon displa
Hi, 2014-12-29 13:26 GMT+01:00 Anna Petrášová kratocha...@gmail.com: I think it's not necessary, it doesn't help with anything, everybody will keep using bgcolor anyway. We already have similar cases (pcurvature, nwalkers) which where already changed and we don't plan to add another underscore there. I meant color-related options. They are named 'color' or 'something_color'. What about 'background_color' option? Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-PSC] RFC4 discussion call
I agree with Maris that no feedback should be interpreted as agreement. A statement : if there are no further comments or feedback for the 7 days, RC1 will be released on XXX date may help in case somebody has some issues and was just delaying posting them. Also for the PSC, it appears that the release procedure is ready to be voted on? http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure Helena On Dec 29, 2014, at 3:11 AM, Maris Nartiss wrote: IMHO lack of answer in a transparent procedure with reasonable response windows just means carry on, everyone agrees. Having a fixed last date for comments might force someone to say something (or used as an argument for STFU later). Just my 0.02, Māris. 2014-12-29 9:50 GMT+02:00 Markus Neteler nete...@osgeo.org: On Mon, Nov 24, 2014 at 2:50 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 24/11/14 14:38, Martin Landa wrote: Dear all, as we are closer and closer to GRASS 7 release I would like to open discussion related to Release procedure - RFC4 [1]. Ideally (I would say) it would make sense to find a way how accept such procedure before we start with GRASS RCs... Thanks for your feedback in advance! Martin [1] http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure Rereading it I found parts that didn't seem clear, so I reordered the sentences slightly to make the meaning clearer. While this is all nice, I am strongly lacking support in the day to day release management. Again the RC1 feedback is actually 0 (zero). The General Procedure in the document is lacking answers to what to do if no or no reasonable feedback occurs. Any ideas? We are in soft freeze for months. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2516: r.stream.distance elevation above streams produces unexpected null values
#2516: r.stream.distance elevation above streams produces unexpected null values +--- Reporter: madi| Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.1.0 Component: Raster | Version: svn-trunk Keywords: r.stream,r.stream.distance |Platform: Unspecified Cpu: Unspecified | +--- Comment(by hellik): Replying to [comment:2 madi]: Replying to [comment:1 hellik]: Replying to [ticket:2516 madi]: elev2stream map has several null values. where are the null values? I know only the null values at the border of the DEM (red in the screenshot) where no stream information is available. Hi, in my case null values are scattered all over the map, see attached screenshot (the large spots however are water). I realised that the command line i actually gave is slightly different from the one i posted earlier (if matters) and is: r.stream.distance --verbose stream_rast=stream1500 direction=drainage elevation=dem method=downstream distance=dist2stream_2 difference=elev2stream_2 memory=2000 Thanks madi some tests with a DEM subset: {{{ - maybe differences in the r.stream.*-modules between all-in-memory and swapped memory mode; in my tests I can't see any difference - I've done a r.geomorphon run on the DEM; it seems the DEM is very heterogenous. may be these null values are DEM artefacts? - I've done a r.neighbor size=3 and size=5 on the DEM; there seems to be a less number of null values. maybe this indicates DEM artefacts? - I've done a r.stream.distance run with r.stream.extract-outputs (streams and flowdir) instead; there are some differences regarding null values between using r.watershed or r.stream.extract-output as r.stream.distance input }}} -- Ticket URL: https://trac.osgeo.org/grass/ticket/2516#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
[GRASS-dev] [GRASS GIS] #2518: v.in.ogr
#2518: v.in.ogr ---+ Reporter: baharmon | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: Component: Vector | Version: svn-releasebranch70 Keywords: |Platform: MSWindows 8 Cpu: OSX/Intel | ---+ v.in.ogr did not find any layers for shapefiles. I tried both source type file and directory. This was with the daily build from Dec 22nd - GRASS 7.0.0svn(r63776). I checked and it worked fine with an older installation of GRASS 7.1svn (r62255). -- Ticket URL: https://trac.osgeo.org/grass/ticket/2518 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] G7 scripts: keywords versus keyword
On Mon, Dec 29, 2014 at 3:13 PM, Martin Landa landa.mar...@gmail.com wrote: Hi all, 2014-12-28 18:02 GMT+01:00 Markus Neteler nete...@osgeo.org: -#% keywords: general, projection, transformation +#% keywords: general +#% keywords: projection +#% keywords: transformation Shouldn't the name of the key be keyword rather than keywords since only one is allowed? Or it is too heavy change? Probably it should be changed. I would not mind to do the job. We could, however, also accept the plural form. The relevant line of code seems to be line 87 in general/g.parser/parse.c:if (G_strcasecmp(cmd, keywords) == 0) { no objections to change it to 'keyword'. Martin Ok, done in r63871(trunk), r63872 (relbranch70), r63874 (Addons). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Is grass70b4 compiling on FreeBSD ?
Hello all, Is the 'current' beta release version compiling on freebsd? I got the code from the release and I tried with freebsd 10.1 and got some error regarding libiconv, mostly on the new 'temporal' tools. If there's anything I can do to help :) thanks for the work, highly appreciated. F -=--=-=- Fábio Augusto Salve Dias http://sites.google.com/site/fabiodias/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Is grass70b4 compiling on FreeBSD ?
Hi Fábio, On Mon, Dec 29, 2014 at 10:41 PM, Fábio Dias fabio.d...@gmail.com wrote: Hello all, Is the 'current' beta release version compiling on freebsd? ideally yes. I got the code from the release and I tried with freebsd 10.1 and got some error regarding libiconv, mostly on the new 'temporal' tools. If there's anything I can do to help :) Great! First of all, please post your error message, e.g. here: http://pastebin.com/ thanks for the work, highly appreciated. Your feedback is welcome, too. Please consider to switch your b4 download to releasebranch, then testing of updates is easier: cd some/path/grass7beta4/ svn switch https://svn.osgeo.org/grass/grass/branches/releasebranch_7_0 # now simply svn update to get latest release related updates (there were many in the past few days). Eventually it would be great to update the FreeBSD section here: http://grasswiki.osgeo.org/wiki/Compile_and_Install#FreeBSD_.2F_NetBSD Best Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2518: v.in.ogr
#2518: v.in.ogr ---+ Reporter: baharmon | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: Component: Vector | Version: svn-releasebranch70 Keywords: |Platform: MacOSX Cpu: OSX/Intel | ---+ Changes (by helena): * platform: MSWindows 8 = MacOSX Comment: I can confirm issues with shape file import - I was trying to create a new location using shape file - the shape file was recognized and the location was created but when I answered yes on importing the file I got error stating that the format is not recognized. I am running this with GRASS7.0.0.svn r61585M compiled by Anna on Yosemite (it is really nice). We did not get the sqlite working but I am not sure it is related to the shape import issues. I was able to import the file using v.in.ogr from command line without the table. Perhaps this is something already fixed in 7.1 which needs backporting (or was just backported by Martin?) -- Ticket URL: https://trac.osgeo.org/grass/ticket/2518#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-PSC] RFC4 discussion call
On Mon, Dec 29, 2014 at 6:02 PM, Helena Mitasova hmit...@ncsu.edu wrote: I agree with Maris that no feedback should be interpreted as agreement. A statement : if there are no further comments or feedback for the 7 days, RC1 will be released on XXX date may help in case somebody has some issues and was just delaying posting them. Perhaps that should be added to the text. While doing some other finetuning: http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure?action=diffversion=7old_version=6 I found that a tbd is still there. Also for the PSC, it appears that the release procedure is ready to be voted on? http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure In my view the document is not ready yet (see above). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Heading towards unified dataset
On Sun, Dec 28, 2014 at 2:55 AM, Vaclav Petras wenzesl...@gmail.com wrote: To better coordinate creation of the new sample dataset, I created a page on GRASS Trac wiki: http://trac.osgeo.org/grass/wiki/SampleDataset The lists (I have added some comments) looks very good to me. It is also (now) needed for OSGeoLive8.5 which cannot fit the old 140MB NC dataset. See http://trac.osgeo.org/osgeo/ticket/1446#comment:7 Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Is grass70b4 compiling on FreeBSD ?
Hi, So, I started with a fresh checkout (from the URL you told me to switch to). The full log is on http://pastebin.com/2n9vswif The important part, afaik, is : /usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so: undefined reference to `libiconv' /usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so: undefined reference to `libiconv_close' /usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so: undefined reference to `libiconv_open' So I've tried with --with-iconv on the configure, not that this option exist... Then I manually changed a Makefile, on one of the directories with error. Added -liconv to he LIBES var, then the make worked. My guess would be that configure isn't passing along the -liconv properly in this context... Thanks again, F -=--=-=- Fábio Augusto Salve Dias http://sites.google.com/site/fabiodias/ On Mon, Dec 29, 2014 at 7:50 PM, Markus Neteler nete...@osgeo.org wrote: Hi Fábio, On Mon, Dec 29, 2014 at 10:41 PM, Fábio Dias fabio.d...@gmail.com wrote: Hello all, Is the 'current' beta release version compiling on freebsd? ideally yes. I got the code from the release and I tried with freebsd 10.1 and got some error regarding libiconv, mostly on the new 'temporal' tools. If there's anything I can do to help :) Great! First of all, please post your error message, e.g. here: http://pastebin.com/ thanks for the work, highly appreciated. Your feedback is welcome, too. Please consider to switch your b4 download to releasebranch, then testing of updates is easier: cd some/path/grass7beta4/ svn switch https://svn.osgeo.org/grass/grass/branches/releasebranch_7_0 # now simply svn update to get latest release related updates (there were many in the past few days). Eventually it would be great to update the FreeBSD section here: http://grasswiki.osgeo.org/wiki/Compile_and_Install#FreeBSD_.2F_NetBSD Best Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-PSC] RFC4 discussion call
I agree. Even if we cannot get time to look at it, we can at least check in and say that. 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 Dec 29, 2014, at 10:02 AM, Helena Mitasova hmit...@ncsu.edu wrote: I agree with Maris that no feedback should be interpreted as agreement. A statement : if there are no further comments or feedback for the 7 days, RC1 will be released on XXX date may help in case somebody has some issues and was just delaying posting them. Also for the PSC, it appears that the release procedure is ready to be voted on? http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure Helena On Dec 29, 2014, at 3:11 AM, Maris Nartiss wrote: IMHO lack of answer in a transparent procedure with reasonable response windows just means carry on, everyone agrees. Having a fixed last date for comments might force someone to say something (or used as an argument for STFU later). Just my 0.02, Māris. 2014-12-29 9:50 GMT+02:00 Markus Neteler nete...@osgeo.org: On Mon, Nov 24, 2014 at 2:50 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 24/11/14 14:38, Martin Landa wrote: Dear all, as we are closer and closer to GRASS 7 release I would like to open discussion related to Release procedure - RFC4 [1]. Ideally (I would say) it would make sense to find a way how accept such procedure before we start with GRASS RCs... Thanks for your feedback in advance! Martin [1] http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure Rereading it I found parts that didn't seem clear, so I reordered the sentences slightly to make the meaning clearer. While this is all nice, I am strongly lacking support in the day to day release management. Again the RC1 feedback is actually 0 (zero). The General Procedure in the document is lacking answers to what to do if no or no reasonable feedback occurs. Any ideas? We are in soft freeze for months. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-psc mailing list grass-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r63797 - in grass/trunk: display/d.barscale display/d.colortable display/d.erase display/d.geodesic display/d.grid display/d.histogram display/d.legend display/d.mon displa
On Mon, Dec 29, 2014 at 11:29 AM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2014-12-29 13:26 GMT+01:00 Anna Petrášová kratocha...@gmail.com: I think it's not necessary, it doesn't help with anything, everybody will keep using bgcolor anyway. We already have similar cases (pcurvature, nwalkers) which where already changed and we don't plan to add another underscore there. I meant color-related options. They are named 'color' or 'something_color'. what's special about color options? What about 'background_color' option? Martin I stated my opinion on this earlier: I am against changing options which are easy to understand and people are used to them just because they represent a shortcut, especially when we don't have any good candidate. What would be the advantage of background_color? bg_color or back_ground_color can be at least shorten to bgcolor. However, since you did most of the work recently, I think you have the right to decide it. Anna -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2518: v.in.ogr
#2518: v.in.ogr ---+ Reporter: baharmon | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: Component: Vector | Version: svn-releasebranch70 Keywords: v.in.ogr |Platform: MacOSX Cpu: OSX/Intel | ---+ Changes (by annakrat): * keywords: = v.in.ogr Comment: I tested v.in.ogr when creating new location based on a shapefile and it's working on Ubuntu with the most recent versions of 70 and trunk. It would be good to test it on the newest versions and see if you are describing the same problem and if it depends on shape file data. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2518#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