date:20141229

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

2014-12-29 Thread Glynn Clements


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

2014-12-29 Thread Anna Petrášová

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

2014-12-29 Thread Vaclav Petras

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

2014-12-29 Thread Vaclav Petras

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

2014-12-29 Thread Helena Mitasova

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 ?

2014-12-29 Thread Fábio Dias

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 ?

2014-12-29 Thread Fábio Dias

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á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

2014-12-29 Thread Michael Barton

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

2014-12-29 Thread Anna Petrášová

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