Re: [GRASS-dev] [GRASS GIS] #1941: wxGUI fails with Japanese locale --> mixed Python installs on Windows

[GRASS GIS]

#1941: wxGUI fails with Japanese locale --> mixed Python installs on Windows
--+-
  Reporter:  venkat   |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  major|   Milestone:  7.0.0
 Component:  wxGUI| Version:  svn-trunk
Resolution:  fixed|Keywords:  wingrass 
  Platform:  MSWindows 7  | Cpu:  x86-32   
--+-
Changes (by annakrat):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 This ticket doesn't make any sense now. Please open a new ticket for the
 current problems if necessary. The original problem seems to be fixed.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2034: GUI crashes on launch for newly compiled binary for Mac OS X

[GRASS GIS]

#2034: GUI crashes on launch for newly compiled binary for Mac OS X
+---
  Reporter:  cmbarton   |   Owner:  grass-dev@… 
  Type:  defect |  Status:  closed  
  Priority:  critical   |   Milestone:  7.0.0   
 Component:  Compiling  | Version:  svn-trunk   
Resolution:  fixed  |Keywords:  wxGUI, Python, toolboxes, ctypes
  Platform:  MacOSX | Cpu:  OSX/Intel   
+---
Changes (by cmbarton):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 AFAICT, this has been fixed in the current versions of both 7.1 and 7.0
 svn. So I can think we can close. Thanks much.

 Closing.

 Michael

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2034: GUI crashes on launch for newly compiled binary for Mac OS X

[GRASS GIS]

#2034: GUI crashes on launch for newly compiled binary for Mac OS X
--+-
 Reporter:  cmbarton  |   Owner:  grass-dev@…   
   
 Type:  defect|  Status:  new   
   
 Priority:  critical  |   Milestone:  7.0.0 
   
Component:  Compiling | Version:  svn-trunk 
   
 Keywords:  wxGUI, Python, toolboxes, ctypes  |Platform:  MacOSX
   
  Cpu:  OSX/Intel |  
--+-

Comment(by annakrat):

 I haven't had problems recently with compilation on Mac, perhaps this
 r60007 fixed that? It is already backported. Can we close this ticket?

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1370: Save display geometry to named region does not support diacritics

[GRASS GIS]

#1370: Save display geometry to named region does not support diacritics
--+-
  Reporter:  MilenaN  |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  Default  | Version:  svn-trunk
Resolution:  fixed|Keywords:  encoding, diacritics 
  Platform:  All  | Cpu:  Unspecified  
--+-
Changes (by annakrat):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Should be fixed in r61307, r61356 and backported in r61357.

-- 
Ticket URL: 
GRASS GIS 

___
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)

[Vaclav Petras]

On Tue, Jul 22, 2014 at 8:14 PM, Glynn Clements 
wrote:

> r61353 changes r.mapcalc so that seeding is performed via seed= or -s.
> The seed (whether specified by seed= or generated for -s) is added to
> the history (for r.mapcalc; r3.mapcalc's create_history() function is
> a stub; do 3D rasters have history?)
>

I added test for r61353 in r61355. Tests are only for r.mapcalc not for
r3.mapcalc.

http://trac.osgeo.org/grass/changeset/61355


>
> As I write this, it has occurred to me that the behaviour of rand()
> may be non-deterministic in the presence of certain forms of
> parallelism, e.g. multiple occurences of rand() in the expression(s)
> in conjunction with pthreads. Ultimately we may need to expand the
> PRNG to support explicit state (as per erand48, nrand48 and jrand48).
>

The tests are not testing any of this (at least not explicitly),
contributions welcome.
___
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)

[Anna Petrášová]

On Tue, Jul 22, 2014 at 8:14 PM, Glynn Clements 
wrote:

>
> Glynn Clements wrote:
>
> > I'm inclined to add both an option (to specify a seed, replacing the
> > environment variable) and a flag (to seed from the system clock or
> > whatever), and having the PRNG generate a fatal error if neither of
> > those are used.
>
> This is now done.
>
> r61350 adds the lrand48/mrand48/drand48 equivalents to lib/gis. Brief
> testing suggests that the results are identical to those generated by
> GNU libc (which should be identical to any other POSIX implementation).
>
> r61352 changes it to generate a fatal error if used prior to seeding.
>
> r61353 changes r.mapcalc so that seeding is performed via seed= or -s.
> The seed (whether specified by seed= or generated for -s) is added to
> the history (for r.mapcalc; r3.mapcalc's create_history() function is
> a stub; do 3D rasters have history?)
>
> Note that GRASS_RND_SEED is no longer supported. That was a hack from
> the time before r.mapcalc used G_parser().
>
> As I write this, it has occurred to me that the behaviour of rand()
> may be non-deterministic in the presence of certain forms of
> parallelism, e.g. multiple occurences of rand() in the expression(s)
> in conjunction with pthreads. Ultimately we may need to expand the
> PRNG to support explicit state (as per erand48, nrand48 and jrand48).
>

I added the support for -s and seed to the r.mapcalc gui in 61354. Testing
is very welcome.

I wonder if there are any modules in core or addons which need to be
updated.

Anna

>
> --
> Glynn Clements 
> ___
> 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] using rand(x,y) in r.mapcalc (grass7)

[Glynn Clements]

Glynn Clements wrote:

> I'm inclined to add both an option (to specify a seed, replacing the
> environment variable) and a flag (to seed from the system clock or
> whatever), and having the PRNG generate a fatal error if neither of
> those are used.

This is now done.

r61350 adds the lrand48/mrand48/drand48 equivalents to lib/gis. Brief
testing suggests that the results are identical to those generated by
GNU libc (which should be identical to any other POSIX implementation).

r61352 changes it to generate a fatal error if used prior to seeding.

r61353 changes r.mapcalc so that seeding is performed via seed= or -s. 
The seed (whether specified by seed= or generated for -s) is added to
the history (for r.mapcalc; r3.mapcalc's create_history() function is
a stub; do 3D rasters have history?)

Note that GRASS_RND_SEED is no longer supported. That was a hack from
the time before r.mapcalc used G_parser().

As I write this, it has occurred to me that the behaviour of rand()
may be non-deterministic in the presence of certain forms of
parallelism, e.g. multiple occurences of rand() in the expression(s)
in conjunction with pthreads. Ultimately we may need to expand the
PRNG to support explicit state (as per erand48, nrand48 and jrand48).

-- 
Glynn Clements 
___
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)

[Glynn Clements]

Vaclav Petras wrote:

> Anyway, the reproducibility would be really nice considering GRASS
> scientific audience, however are you sure that different systems will give
> same random number for the same seed?

They will from now on, because I've replaced the use of the system's
PRNG (either rand or mrand48/drand48) with a portable implementation
of the latter.

> > What about time + process id?

That's what's done now (if -s is used). Although we could probably do
with a better hash (currently, it's just addition) and/or more entropy
sources.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1778: Typing in g.region without parameters does not open a g.region window

[GRASS GIS]

#1778: Typing in g.region without parameters does not open a g.region window
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  normal  |   Milestone:  7.0.0   
 
Component:  Default | Version:  svn-trunk   
 
 Keywords:  g.region, r.colors, r.mask  |Platform:  Linux   
 
  Cpu:  x86-64  |  
+---

Comment(by annakrat):

 Now we can finally solve this ticket thanks to new rules implemented by
 glynn and hcho. We just need to  specify the group of options where at
 least one must be given. In case of g.region, it looks like all options
 and flags should be in this group?

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r60703 - in grass/trunk: display/d.vect general/g.gisenv gui/wxpython/animation lib/python/temporal raster/r.colors raster/r.external raster/r.in.bin raster/r.mapcalc raste

[Michael Barton]

If I understand this correctly, this will be very welcome!

Thanks
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
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
www:http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Jul 22, 2014, at 2:06 PM,  
 wrote:

> From: Glynn Clements 
> Subject: Re: [GRASS-dev] [GRASS-SVN] r60703 - in grass/trunk: display/d.vect 
> general/g.gisenv gui/wxpython/animation lib/python/temporal raster/r.colors 
> raster/r.external raster/r.in.bin raster/r.mapcalc raster/r.neighbors 
> raster/r.out.bin raster/r.quant raster/r.resamp.filter raster/r.series 
> raster/r.series.accumulate raster/r.series.interp raster/r.stats.quantile 
> vector/v.colors vector/v.external.out
> Date: July 22, 2014 at 2:05:31 PM MST
> To: Anna Petrášová 
> Cc: Huidae Cho , GRASS developers list 
> 
> 
> 
> 
> Anna Petrášová wrote:
> 
>> is this new API now stable enough to be actually used in C modules? Should
>> we start to replace the manual checks in modules with these functions?
> 
> I think so.
> 
>> I attached a patch which should fix this ticket [1]: when user doesn't type
>> any command arguments and the module has no explicitly required options
>> (like g.region), it checks if there is any RULE_REQUIRED and if yes, it
>> opens GUI dialog.
> 
> Looks good.
> 
> -- 
> Glynn Clements 

___
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)

[Paulo van Breugel]

On 22-07-14 23:31, Markus Neteler wrote:

On Tue, Jul 22, 2014 at 11:19 PM, Paulo van Breugel wrote:

On 22-07-14 22:58, Glynn Clements wrote:

And when issue of usability doesn't even get considered until a few
years later when the user (or a colleague) gets an email suggesting
the results can't be be reproduced ...?

I'm inclined to add both an option (to specify a seed, replacing the
environment variable) and a flag (to seed from the system clock or
whatever), and having the PRNG generate a fatal error if neither of
those are used.

That way, neither of the likely problems can arise by oversight.


I guess there is a lot to say for both approaches, which is why I think the
suggestion of Markus is a very good one!  +1 from me

It is indeed Glynn's suggestion (which I like, too).


Sorry, never seem to get used to how my email program displays the 
treads... good suggestion by Glynn I mean.. Glynn, it would be really 
great if you could implement it that way.




Markus


___
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)

[Markus Neteler]

On Tue, Jul 22, 2014 at 11:19 PM, Paulo van Breugel wrote:
> On 22-07-14 22:58, Glynn Clements wrote:
>> And when issue of usability doesn't even get considered until a few
>> years later when the user (or a colleague) gets an email suggesting
>> the results can't be be reproduced ...?
>>
>> I'm inclined to add both an option (to specify a seed, replacing the
>> environment variable) and a flag (to seed from the system clock or
>> whatever), and having the PRNG generate a fatal error if neither of
>> those are used.
>>
>> That way, neither of the likely problems can arise by oversight.
>>
>
> I guess there is a lot to say for both approaches, which is why I think the
> suggestion of Markus is a very good one!  +1 from me

It is indeed Glynn's suggestion (which I like, too).

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1421: scalability of r.terraflow

[GRASS GIS]

#1421: scalability of r.terraflow
--+-
 Reporter:  dnewcomb  |   Owner:  grass-dev@…  
 Type:  enhancement   |  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Raster| Version:  svn-develbranch6 
 Keywords:  r.terraflow, large grids  |Platform:  Linux
  Cpu:  x86-64|  
--+-

Comment(by neteler):

 Backported to relbr7 in r61340.

 (unrelated:
 dnewcomb, please add you large file calculation timings in
 http://grasswiki.osgeo.org/wiki/GRASS_GIS_Performance )

 Can the ticket be closed?

-- 
Ticket URL: 
GRASS GIS 

___
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)

[Paulo van Breugel]

On 22-07-14 22:58, Glynn Clements wrote:

Markus Neteler wrote:


- if the user needs reproducability, then have a env var to enable that.

And when issue of usability doesn't even get considered until a few
years later when the user (or a colleague) gets an email suggesting
the results can't be be reproduced ...?

I'm inclined to add both an option (to specify a seed, replacing the
environment variable) and a flag (to seed from the system clock or
whatever), and having the PRNG generate a fatal error if neither of
those are used.

That way, neither of the likely problems can arise by oversight.



I guess there is a lot to say for both approaches, which is why I think 
the suggestion of Markus is a very good one!  +1 from me



___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2338: r.horizon rename parameters

[GRASS GIS]

#2338: r.horizon rename parameters
--+-
  Reporter:  zarch|   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  reopened 
  Priority:  critical |   Milestone:  7.0.0
 Component:  Raster   | Version:  svn-trunk
Resolution:   |Keywords:  r.horizon, r.sun 
  Platform:  All  | Cpu:  All  
--+-
Changes (by neteler):

  * keywords:  r.horizon => r.horizon, r.sun
  * status:  closed => reopened
  * resolution:  fixed =>


Comment:

 Reopening as r61098 + r61099 are not yet backported to relbr7 (parameter
 name changes)

-- 
Ticket URL: 
GRASS GIS 

___
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)

[Vaclav Petras]

On Tue, Jul 22, 2014 at 4:58 PM, Glynn Clements 
wrote:

> Markus Neteler wrote:
>
> > - if the user needs reproducability, then have a env var to enable that.
>
> And when issue of usability doesn't even get considered until a few
> years later when the user (or a colleague) gets an email suggesting
> the results can't be be reproduced ...?
>
> I'm inclined to add both an option (to specify a seed, replacing the
> environment variable) and a flag (to seed from the system clock or
> whatever), and having the PRNG generate a fatal error if neither of
> those are used.
>
> That way, neither of the likely problems can arise by oversight.
>

This looks very good at first glance.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r60703 - in grass/trunk: display/d.vect general/g.gisenv gui/wxpython/animation lib/python/temporal raster/r.colors raster/r.external raster/r.in.bin raster/r.mapcalc raste

[Glynn Clements]

Anna Petrášová wrote:

> is this new API now stable enough to be actually used in C modules? Should
> we start to replace the manual checks in modules with these functions?

I think so.

> I attached a patch which should fix this ticket [1]: when user doesn't type
> any command arguments and the module has no explicitly required options
> (like g.region), it checks if there is any RULE_REQUIRED and if yes, it
> opens GUI dialog.

Looks good.

-- 
Glynn Clements 
___
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)

[Vaclav Petras]

On Tue, Jul 22, 2014 at 4:39 PM, Glynn Clements 
wrote:

>
> Paulo van Breugel wrote:
>
> > And it seems to be the default behaviour by python/numpy:
>
> It is, but ...
>
> >  >>> import numpy as np
> >  >>> np.random.random()
> > 0.8351426142559701
> >  >>> np.random.random()
> > 0.4813823441998394
> >  >>> np.random.random()
> > 0.7279314267025369
>
> ... this example doesn't demonstrate that.


Good point, on my computer I get:

>>> import numpy as np
>>> np.random.random()
0.49727844715398417

And in different (also freshly started) Python:

>>> import numpy as np
>>> np.random.random()
0.2457281014919791

Any PRNG returns different
> values for successive calls.
>
> The problem is that user may not see the difference between between two
module calls in GRASS command line and two calls of random() function in
Python. When calling GRASS module in Python the difference is even less
visible.

Anyway, the reproducibility would be really nice considering GRASS
scientific audience, however are you sure that different systems will give
same random number for the same seed? Or do you think about reproducible as
"as reproducible as possible, e.g. using the same system if necessary".

The question is whether the PRNG's initial value should autmatically
> be seeded from some external source of entropy (e.g. the system
> clock), so that the sequence of values differs on different runs.
>
> In turn, that brings up questions about the quality of the entropy
> source. The ANSI C time() function typically only has one second
> granularity (indeed, POSIX requires this, as time_t is defined as
> seconds since the epoch), which is sufficiently course that successive
> runs may get the same seed. Other functions aren't portable, and even
> where available, the granularity isn't guaranteed.
>
> What about time + process id?


> My main objection to automatic seeding is that people will inevitably
> produce non-repeatable results without even realising it.
>
> One possible solution would be to automatically add the seed to the
> history of any map generated by r.mapcalc (or possibly only those
> which use the rand() function). But that would still only help if the
> creator either provides access to the generated maps, or the output
> from r.info. Simply providing the commands used and the end result
> wouldn't help.
>
> --
> Glynn Clements 
> ___
> 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] using rand(x,y) in r.mapcalc (grass7)

[Glynn Clements]

Markus Neteler wrote:

> - if the user needs reproducability, then have a env var to enable that.

And when issue of usability doesn't even get considered until a few
years later when the user (or a colleague) gets an email suggesting
the results can't be be reproduced ...?

I'm inclined to add both an option (to specify a seed, replacing the
environment variable) and a flag (to seed from the system clock or
whatever), and having the PRNG generate a fatal error if neither of
those are used.

That way, neither of the likely problems can arise by oversight.

-- 
Glynn Clements 
___
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)

[Glynn Clements]

Paulo van Breugel wrote:

> And it seems to be the default behaviour by python/numpy:

It is, but ...

>  >>> import numpy as np
>  >>> np.random.random()
> 0.8351426142559701
>  >>> np.random.random()
> 0.4813823441998394
>  >>> np.random.random()
> 0.7279314267025369

... this example doesn't demonstrate that. Any PRNG returns different
values for successive calls.

The question is whether the PRNG's initial value should autmatically
be seeded from some external source of entropy (e.g. the system
clock), so that the sequence of values differs on different runs.

In turn, that brings up questions about the quality of the entropy
source. The ANSI C time() function typically only has one second
granularity (indeed, POSIX requires this, as time_t is defined as
seconds since the epoch), which is sufficiently course that successive
runs may get the same seed. Other functions aren't portable, and even
where available, the granularity isn't guaranteed.

My main objection to automatic seeding is that people will inevitably
produce non-repeatable results without even realising it.

One possible solution would be to automatically add the seed to the
history of any map generated by r.mapcalc (or possibly only those
which use the rand() function). But that would still only help if the
creator either provides access to the generated maps, or the output
from r.info. Simply providing the commands used and the end result
wouldn't help.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7.0beta3 planning

[Markus Neteler]

On Mon, May 26, 2014 at 11:03 AM, Luca Delucchi  wrote:
> On 25 May 2014 23:23, Markus Neteler  wrote:
> > as Martin stated in a recent ticket comment, beta3 should be released asap.
> >
> > I would like to get first the pygrass changes backported (not
> > difficult including the manual improvements).
>
> Today and tomorrow I would like to improve a little bit more the
> pygrass manual, could you wait few days before backport these changes?

all:
I guess we are completely out of sync concerning the PyGRASS docs.
(Un)related to beta3, how should we handle that? Backport it after beta3?

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE

[GRASS GIS]

#2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE
-+--
 Reporter:  neteler  |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  Raster   | Version:  svn-releasebranch70  
 Keywords:   |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by glynn):

 Replying to [comment:3 neteler]:

 > > Aside: if there are still systems out there using the historical limit
 of 4096 bytes of memory for the combination of environment variables and
 arguments (argv), we might want to think about making GRASS less greedy
 with respect to environment variables.
 >
 > You mean the number and/or the length?

 Mainly the number.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r60703 - in grass/trunk: display/d.vect general/g.gisenv gui/wxpython/animation lib/python/temporal raster/r.colors raster/r.external raster/r.in.bin raster/r.mapcalc raste

[Huidae Cho]

Hi,

Well, there are no equivalent functions in python yet. Other than that, I
think this new API is functionally satisfying and r.clump is using it. The
patch looks good to me. BTW, I prefer option= and -f.

Regards,
Huidae



On Tue, Jul 22, 2014 at 1:53 PM, Anna Petrášová 
wrote:

>
>
> On Wed, Jun 25, 2014 at 2:09 AM, Huidae Cho  wrote:
>
>> We also need to add option_rules or something to g.parser so that python
>> scripts can have access to these functions. Something like:
>>
>> #%option_rules
>> #% exclusive: -a, -b
>> #% requires_all: opt1, opt2, -a
>> #%end
>>
>>
>>
>>
>> On Fri, Jun 20, 2014 at 9:59 PM, Huidae Cho  wrote:
>>
>>> G_option_excludes() works for me.
>>>
>>>
>>> On Fri, Jun 20, 2014 at 7:58 PM, Glynn Clements <
>>> gl...@gclements.plus.com> wrote:
>>>

 Huidae Cho wrote:

 > I assume G__check_option_rules() is supposed to be called by
 G_parser().
 > Then, instead of calling G_fatal_error, it should append errors to
 > st->errors.

 Okay; I presume that the intent is so that it will report all errors,
 not just the first.

 > If so... for g.mlist we can define two different versions of
 > rules:
 >
 > This version prints more correct errors because only present
 options/flags
 > will be displayed in errors, but too much typing.
 > G_option_exclusive(flag.regex, flag.extended, NULL);
 > G_option_exclusive(flag.pretty, flag.full, NULL);
 > G_option_exclusive(flag.pretty, opt.output, NULL);
 > G_option_exclusive(flag.pretty, flag.mapset, NULL);
 > G_option_exclusive(flag.pretty, flag.type, NULL);
 > G_option_exclusive(flag.full, opt.output, NULL);
 > G_option_exclusive(flag.full, flag.mapset, NULL);
 > G_option_exclusive(flag.full, flag.type, NULL);
 >
 > This version is shorter, but -p -f will print three errors including
 > options/flags not present.
 > G_option_exclusive(flag.regex, flag.extended, NULL);
 > G_option_exclusive(flag.pretty, flag.full, opt.output, NULL);
 > G_option_exclusive(flag.pretty, flag.full, flag.mapset, NULL);
 > G_option_exclusive(flag.pretty, flag.full, flag.type, NULL);
 >
 > Can we implement something like
 > G_option_exclusive(pretty, full, G_option_or(output, mapset, type))
 > ?

 I'd rather stick to "flat" rules rather than heading in the direction
 of generalised boolean expressions.

 Not because it's hard to implement, but because it makes it harder to
 utilise the information.

 The next logical step is to include the rules in the
 --interface-description output so that the GUI can convey the
 relationships to the user. E.g. mutually-exclusive options might use
 radio buttons, or greying-out excluded options. Options which are
 required by another option could be marked as "required" when a value
 is given for the first option. And so on.

 Realistically, that requires that the rules belong to a finite set of
 patterns.

 > pretty, full, and any of output, mapset, and type are mutually
 exclusive,
 > but output, mapset, and type are not exclusive.

 How about another rule type:

 > G_option_excludes(flag.pretty, opt.output, flag.mapset,
 flag.type, NULL);
 > G_option_excludes(flag.full,   opt.output, flag.mapset,
 flag.type, NULL);

 where the first option excludes all remaining options.

 This is essentially the negation of G_option_requires().

 --
 Glynn Clements 

>>>
>>>
>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
>
> Hi,
>
> is this new API now stable enough to be actually used in C modules? Should
> we start to replace the manual checks in modules with these functions? BTW,
> documentation is still missing.
>
>  I attached a patch which should fix this ticket [1]: when user doesn't
> type any command arguments and the module has no explicitly required
> options (like g.region), it checks if there is any RULE_REQUIRED and if
> yes, it opens GUI dialog.
>
> Also I would consider a little bit better error message, the name of the
> option is not very visible in the sentence. Perhaps using quotes or <>
> around the option would help. Also, "Option myoption1 requires at least one
> of myoption2" sounds weird, perhaps there should be special handling of
> cases when there is just one option required. These are just details.
>
> Thanks,
> Anna
>
>
> [1]http://trac.osgeo.org/grass/ticket/1778
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1262: r.proj broken in all dev versions

[GRASS GIS]

#1262: r.proj broken in all dev versions
---+
  Reporter:  cmbarton  |   Owner:  grass-dev@…  
  Type:  defect|  Status:  closed   
  Priority:  critical  |   Milestone:  6.4.1
 Component:  Raster| Version:  unspecified  
Resolution:  fixed |Keywords:  r.proj, reprojection 
  Platform:  MacOSX| Cpu:  OSX/Intel
---+

Comment(by annakrat):

 r.proj was still crashing on Windows in GRASS7, fortunately just after the
 raster was reprojected. Fixed in r61327, r61328.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r60703 - in grass/trunk: display/d.vect general/g.gisenv gui/wxpython/animation lib/python/temporal raster/r.colors raster/r.external raster/r.in.bin raster/r.mapcalc raste

[Anna Petrášová]

On Wed, Jun 25, 2014 at 2:09 AM, Huidae Cho  wrote:

> We also need to add option_rules or something to g.parser so that python
> scripts can have access to these functions. Something like:
>
> #%option_rules
> #% exclusive: -a, -b
> #% requires_all: opt1, opt2, -a
> #%end
>
>
>
>
> On Fri, Jun 20, 2014 at 9:59 PM, Huidae Cho  wrote:
>
>> G_option_excludes() works for me.
>>
>>
>> On Fri, Jun 20, 2014 at 7:58 PM, Glynn Clements > > wrote:
>>
>>>
>>> Huidae Cho wrote:
>>>
>>> > I assume G__check_option_rules() is supposed to be called by
>>> G_parser().
>>> > Then, instead of calling G_fatal_error, it should append errors to
>>> > st->errors.
>>>
>>> Okay; I presume that the intent is so that it will report all errors,
>>> not just the first.
>>>
>>> > If so... for g.mlist we can define two different versions of
>>> > rules:
>>> >
>>> > This version prints more correct errors because only present
>>> options/flags
>>> > will be displayed in errors, but too much typing.
>>> > G_option_exclusive(flag.regex, flag.extended, NULL);
>>> > G_option_exclusive(flag.pretty, flag.full, NULL);
>>> > G_option_exclusive(flag.pretty, opt.output, NULL);
>>> > G_option_exclusive(flag.pretty, flag.mapset, NULL);
>>> > G_option_exclusive(flag.pretty, flag.type, NULL);
>>> > G_option_exclusive(flag.full, opt.output, NULL);
>>> > G_option_exclusive(flag.full, flag.mapset, NULL);
>>> > G_option_exclusive(flag.full, flag.type, NULL);
>>> >
>>> > This version is shorter, but -p -f will print three errors including
>>> > options/flags not present.
>>> > G_option_exclusive(flag.regex, flag.extended, NULL);
>>> > G_option_exclusive(flag.pretty, flag.full, opt.output, NULL);
>>> > G_option_exclusive(flag.pretty, flag.full, flag.mapset, NULL);
>>> > G_option_exclusive(flag.pretty, flag.full, flag.type, NULL);
>>> >
>>> > Can we implement something like
>>> > G_option_exclusive(pretty, full, G_option_or(output, mapset, type))
>>> > ?
>>>
>>> I'd rather stick to "flat" rules rather than heading in the direction
>>> of generalised boolean expressions.
>>>
>>> Not because it's hard to implement, but because it makes it harder to
>>> utilise the information.
>>>
>>> The next logical step is to include the rules in the
>>> --interface-description output so that the GUI can convey the
>>> relationships to the user. E.g. mutually-exclusive options might use
>>> radio buttons, or greying-out excluded options. Options which are
>>> required by another option could be marked as "required" when a value
>>> is given for the first option. And so on.
>>>
>>> Realistically, that requires that the rules belong to a finite set of
>>> patterns.
>>>
>>> > pretty, full, and any of output, mapset, and type are mutually
>>> exclusive,
>>> > but output, mapset, and type are not exclusive.
>>>
>>> How about another rule type:
>>>
>>> > G_option_excludes(flag.pretty, opt.output, flag.mapset, flag.type,
>>> NULL);
>>> > G_option_excludes(flag.full,   opt.output, flag.mapset, flag.type,
>>> NULL);
>>>
>>> where the first option excludes all remaining options.
>>>
>>> This is essentially the negation of G_option_requires().
>>>
>>> --
>>> Glynn Clements 
>>>
>>
>>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>


Hi,

is this new API now stable enough to be actually used in C modules? Should
we start to replace the manual checks in modules with these functions? BTW,
documentation is still missing.

I attached a patch which should fix this ticket [1]: when user doesn't type
any command arguments and the module has no explicitly required options
(like g.region), it checks if there is any RULE_REQUIRED and if yes, it
opens GUI dialog.

Also I would consider a little bit better error message, the name of the
option is not very visible in the sentence. Perhaps using quotes or <>
around the option would help. Also, "Option myoption1 requires at least one
of myoption2" sounds weird, perhaps there should be special handling of
cases when there is just one option required. These are just details.

Thanks,
Anna


[1]http://trac.osgeo.org/grass/ticket/1778
Index: lib/gis/parser.c
===
--- lib/gis/parser.c(revision 61322)
+++ lib/gis/parser.c(working copy)
@@ -419,7 +419,8 @@
 
 /* If there are NO arguments, go interactive */
 
-if (argc < 2 && st->has_required && !st->no_interactive && isatty(0)) {
+if (argc < 2 && (st->has_required || G__has_required_rule())
+&& !st->no_interactive && isatty(0)) {
module_gui_wx();
return -1;
 }
Index: lib/gis/parser_local_proto.h
===
--- lib/gis/parser_local_proto.h(revision 61322)
+++ lib/gis/parser_local_proto.h(working copy)
@@ -56,6 +56,7 @@
 
 void G__check_option_rules(void);
 void G

Re: [GRASS-dev] [GRASS GIS] #2147: db.databases not working in GRASS 7

[GRASS GIS]

#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 cmbarton):

 I just checked and the behavior is the same as I originally reported. I've
 run this from a mapset in my nc_spm_08 location that has a functioning
 SQLITE database. That is, this mapset has vectors connected to an SQLITE
 database that is working correctly. Yet I still get:

 {{{

 db.databases location=nc_spm_08nc_spm_08
 dbmi: db_list_databases() not implemented
 dbmi: db_list_databases() not implemented
 ERROR: Unable to list databases. Try to define correct connection settings
by db.login.

 }}}

 The manual defines "location" as follows:

 "Default location for SQLite driver is the full path for the current
 mapset. For PostgreSQL driver it's empty connection string. "

 This is NOT standard usage of the word "location" in GRASS. Nonetheless,
 it doesn't seem to work when I put in the proper pathname either.

 {{{

 db.databases location=$GISDBASE/$LOCATION_NAME/$MAPSET
 dbmi: db_list_databases() not implemented
 dbmi: db_list_databases() not implemented
 ERROR: Unable to list databases. Try to define correct connection settings
by db.login.

 }}}

 Same thing happens if I specify the path to the SQLite database itself:

 {{{

 db.databases location=$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db
 dbmi: db_list_databases() not implemented
 dbmi: db_list_databases() not implemented
 ERROR: Unable to list databases. Try to define correct connection settings
by db.login.

 }}}

 Maybe the command is no longer relevant. If it doesn't work, maybe it
 should be dropped from the distribution.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7.0beta3 planning

[Helmut Kudrnovsky]

Anna Petrášová wrote
>>
>> g.gui.rlisetup is working now; but an g.gui.rlisetup-entry in the main
>> GUI
>> is missing.
>>
> 
> Isn't it the 'Set up sampling and analysis framework? '  in Raster ->
> Landscape patch analysis?
> 
> 
> Anna

ah, yes, you're right, sorry for the noise.



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/GRASS-7-0beta3-planning-tp5142434p5152495.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] GRASS 7.0beta3 planning

[Anna Petrášová]

On Tue, Jul 22, 2014 at 5:57 AM, Helmut Kudrnovsky  wrote:

> Markus Neteler wrote
> > On Fri, Jul 18, 2014 at 8:39 AM, Helmut Kudrnovsky <
>
> > hellik@
>
> > > 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@.osgeo
>
> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>
> tested with:
>
> GRASS Version: 7.0.0svn
> GRASS SVN Revision: 61304
> Erstellungsdatum: 2014-07-22
> 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)
>
> g.gui.rlisetup is working now; but an g.gui.rlisetup-entry in the main GUI
> is missing.
>

Isn't it the 'Set up sampling and analysis framework? '  in Raster ->
Landscape patch analysis?


Anna

>
>
>
>
> -
> best regards
> Helmut
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/GRASS-7-0beta3-planning-tp5142434p5152402.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] pygrass vs grass python scripting library

[Pietro]

Hi Paulo,

On Tue, Jul 22, 2014 at 8:55 AM, Paulo van Breugel
 wrote:
> I am trying to familiarize myself a bit with python scripting in GRASS. I am
> a bit confused about the different approaches that seem possible. More
> specifically, there is the pygrass
> (http://grasswiki.osgeo.org/wiki/Python/pygrass) and grass python scripting
> library (
> http://grasswiki.osgeo.org/wiki/GRASS_Python_Scripting_Library). Is there
> somewhere a concise description explaining the difference between the two.

I tried to explain the different approach in the following article:

Zambelli, P., Gebbert, S., Ciolli, M., 2013. Pygrass: An Object
Oriented Python Application Programming Interface (API) for Geographic
Resources Analysis Support System (GRASS) Geographic Information
System (GIS). ISPRS International Journal of Geo-Information 2,
201–219.
http://dx.doi.org/10.3390/ijgi2010201
http://www.mdpi.com/2220-9964/2/1/201/pdf


> And for writing python scripts (addons), which of these two are a better
> option to use (for somebody fairly familiar with GRASS, with some experience
> in writing shell or R scripts for GRASS, but with no experience at all with
> python).

pygrass has been written to be as much pythonic as possible, therefore
for people knowing python should be easier to work with pygrass.
In general I think that the grass.script API is more tested and stable
and more important it is working for both GRASS6 and GRASS7.

pygrass.Module has been devloped to interact with a module as an
object, setting the module parameters, check if the parameters are
valid or not, and execute the module. The Module class has been used
to apply a GRASS module over the current region, splitting the region
in several tiles, create a mapset for each tile, execute the module
and then patch the results and remove the temporary mapset
(GridModule), or in ParallelModuleQueue to handle a queue of modules.

If combine with shortcuts can Improve the python syntax:

from:

run_command("r.slope.aspect", elevation="elevation", slope="slope",
overwrite=True)

to:

r.slope_aspect(elevation="elevation", slope="slope", overwrite=True)

that is closer to the BASH syntax.

But what is particularly interesting of pygrass is the ability to use
and call the C API of GRASS through the ctypes , all the functions in
the grass.script modules are calling and parsing the results of some
GRASS modules.

With pygrass we are using directly the C API of GRASS, like for
example you can write a function that work row by row or pixel by
pixel to do some analysis on a raster map, or line by line in a vector
map, and user don't have to know C or the C API of GRASS.

I hope that the difference is clearer now, otherwise please ask me! :-)

Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2375: t.rast.import: add memory parameter

[GRASS GIS]

#2375: t.rast.import: add memory parameter
---+
 Reporter:  neteler|   Owner:  grass-dev@…  
 Type:  enhancement|  Status:  new  
 Priority:  normal |   Milestone:  7.0.0
Component:  Temporal   | Version:  svn-releasebranch70  
 Keywords:  t.rast.import  |Platform:  All  
  Cpu:  All|  
---+
 t.rast.import might become faster for larger datasets when
 using a bigger GDAL cache since it calls r.in.gdal (which allows
 for a larger cache size).

 Effectively it might be the best to propagate the "memory"
 parameter of r.in.gdal (called in lib/python/temporal/stds_import.py) to
 the user interface of t.rast.import.

 Sidenote:

 Potentially the call of GDALSetCacheMax() in r.in.gdal/main.c
 should be changed to GDALSetCacheMax64(), not sure if conditionalized, to
 overcome the 2GB cache limit.
 See
 http://www.gdal.org/gdal_8h.html#adfb1e95703ee577f012935869852d96c

-- 
Ticket URL: 
GRASS GIS 

___
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)

[GRASS GIS]

#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|  
--+-

Comment(by hellik):

 Replying to [comment:11 hellik]:
 > Replying to [comment:10 wenzeslaus]:
 > > Possible duplicate of #1983. Please continue discussion here.
 >
 > around line [https://trac.osgeo.org/grass/browser/grass/trunk/mswindows
 /GRASS-Installer.nsi.tmpl#L894 L894] may be following should be added:

 and the [http://nsis.sourceforge.net/AccessControl_plug-in plugin] has to
 be added to nsis on the build server.

-- 
Ticket URL: 
GRASS GIS 

___
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)

[GRASS GIS]

#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|  
--+-

Comment(by hellik):

 Replying to [comment:10 wenzeslaus]:
 > Possible duplicate of #1983. Please continue discussion here.

 around line [https://trac.osgeo.org/grass/browser/grass/trunk/mswindows
 /GRASS-Installer.nsi.tmpl#L894 L894] may be following should be added:

 {{{
 AccessControl::SetOnFile
 "$INSTDIR\etc\grass@GRASS_VERSION_MAJOR@@GRASS_VERSION_MINOR@.py" "(BU)"
 "Execute"
 }}}

 not sure to whom ''execute'' should be granted ( BU is builtin/users:
 [http://ss64.com/nt/syntax-security_groups.html builtin/users]

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2305: i.atcorr landsat8 support

[GRASS GIS]

#2305: i.atcorr landsat8 support
--+-
  Reporter:  vesnikos |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  Imagery  | Version:  svn-trunk
Resolution:  fixed|Keywords:  Landsat, i.atcorr
  Platform:  Linux| Cpu:  x86-64   
--+-
Changes (by neteler):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Backported to relbr7 in r61314.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7.0beta3 planning

[Helmut Kudrnovsky]

Markus Neteler wrote
> On Fri, Jul 18, 2014 at 8:39 AM, Helmut Kudrnovsky <

> hellik@

> > 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@.osgeo

> http://lists.osgeo.org/mailman/listinfo/grass-dev

tested with:

GRASS Version: 7.0.0svn 
GRASS SVN Revision: 61304   
Erstellungsdatum: 2014-07-22
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)

g.gui.rlisetup is working now; but an g.gui.rlisetup-entry in the main GUI
is missing.




-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/GRASS-7-0beta3-planning-tp5142434p5152402.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] [GRASS GIS] #2354: cruft in release tarball

[GRASS GIS]

#2354: cruft in release tarball
---+
  Reporter:  hamish|   Owner:  grass-dev@…  
  Type:  defect|  Status:  closed   
  Priority:  normal|   Milestone:  6.4.5
 Component:  Installation  | Version:  6.4.4
Resolution:  fixed |Keywords:   
  Platform:  All   | Cpu:  All  
---+
Changes (by neteler):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Added in r61309 and r61310. Closing.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2374: Vector digitizer does not show scalebar

[GRASS GIS]

#2374: Vector digitizer does not show scalebar
--+-
 Reporter:  neteler   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-releasebranch70  
 Keywords:  digitizer,vector  |Platform:  Linux
  Cpu:  Unspecified   |  
--+-
 How to reproduce:

 Enter the digitizer mode, switch on the barscale: it is not shown.

 But when leaving the digitizer mode, then it is there. Looks like a
 refresh problem.

-- 
Ticket URL: 
GRASS GIS 

___
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

[Markus Neteler]

On Mon, Jul 21, 2014 at 4:08 PM, Martin Landa  wrote:
> Hi,
>
> 2014-07-21 15:46 GMT+02:00 Markus Neteler :
>
>> If no objections, I'll backport r61296 to relbr70.
>
> +1 for backport. Martin

Done in relbr7 in r61308.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev