Re: [GRASS-dev] [GRASS GIS] #2031: G_legal_filename() cleanup patch for GRASS 6

[GRASS GIS]

#2031: G_legal_filename() cleanup patch for GRASS 6
--+-
  Reporter:  neteler  |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.4
 Component:  LibGIS   | Version:  svn-releasebranch64  
Resolution:  fixed|Keywords:   
  Platform:  All  | Cpu:  All  
--+-

Comment(by glynn):

 Replying to [comment:6 neteler]:

 > IMHO rather than having this test in hundreds of modules it should be
 > done in the respective library function.

 Ideally, G_parser() would perform the checks. But that would require
 either a significant amount of fairly ugly code, or redesigning the option
 descriptions (which has been on the table since roughly forever, but with
 no actual progress).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GUI code dest dir

[Glynn Clements]

Martin Landa wrote:

> >> probably not $GISBASE/lib/python/, as lib/ is for libgis et al. on UNIX
> >> systems.
> >
> > Note that the Python standard library typically goes into
> > /usr/lib/pythonX.Y (where X.Y is the version) on Unix.
> >
> > OTOH, the standard library includes DSOs as well as .py/.pyc files,
> > wheres GRASS' Python libraries are pure Python.
> 
> speaking directly, what you would suggest?
> 
> 1) etc/python -> lib/python
> 2) etc/python -> lib/python2
> 3) etc/python -> python
> 4) etc/python -> python2

Maybe share/python?

If anything needs to move, it's the executables which are currently in
etc (I believe that "libexec" is the standard directory for
executables which aren't supposed to be executed directly by the
user).

> Do we need separated python3 libs later in the future when we support
> Python3? Probably, yes if we support still Python2. Martin

Not necessarily. It's intended to be possible to write code which
works with either 2 or 3, although some features would require 2.7. If
we need to support both 2.6 and 3.x, then we'd probably need two
versions (you can't just use conditionals, because some features
affect the parser).

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

Re: [GRASS-dev] [GRASS GIS] #2272: Improve consistency in random generator usage

[GRASS GIS]

#2272: Improve  consistency in random generator usage
-+--
 Reporter:  neteler  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Default  | Version:  svn-releasebranch70  
 Keywords:  random   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by glynn):

 Replying to [ticket:2272 neteler]:
 > The usage of drand48()/srand48() should be consolitated,
 > perhaps using G_math_rand() which is provided in
 > lib/gmath/rand1.c:

 First, G_math_rand() should be fixed. Currently, it returns a value
 strictly less than 1.0 if drand48 is used, or a value less than or equal
 to 1.0 if rand() is used.

 Also, seeding should be a separate function.

 And we should probably have a portable equivalent to lrand48(), i.e.
 something which returns a non-negative 31-bit integer. The version in
 r.random is broken, as bit 15 will always be zero if RAND_MAX is 32767
 (the minimum value allowed by the ISO C standards).

 My suggestion would be to re-implement the LCG used by lrand48() etc.
 [attachment:lrand48.c Sample implementation]

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] wingrass71: rendering problems with raster layers automatically added by finished modules

[Helmut Kudrnovsky]

Hi,

tested with winGRASS71 by osgeo4w from today.

Rendering is activated in map display.

start e.g. r.slope.aspect in the wxgui, define more than one outputs.

Automatically adding the results to map display is activated.

run r.slope.aspect, after the output results are added to map display,
rendering has problems.

-erase map display erases display, but rendering again raster artefacts are
displayed
- change raster color, raster artefacts are displayed
-only after deleting from and readding result raster in map display,
rendering is correct.

anyone confirms this behavior?



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/wingrass71-rendering-problems-with-raster-layers-automatically-added-by-finished-modules-tp5138427.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] 6.4.4 planning

[Martin Landa]

Hi,

2014-04-29 18:29 GMT+02:00 Markus Neteler :
> now v.buffer has been fixed by Markus Metz (using the GEOS library).
>
> Please test.
>
>> I have updated to some extent the draft release notes (please add more):
>> https://trac.osgeo.org/grass/wiki/Release/6.4.4RC1-News

cool, I would say that it's time for RC1... Martin

-- 
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2276: r.covar: output N (number of cells considered)

[GRASS GIS]

#2276: r.covar: output N (number of cells considered)
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.4
Component:  Default  | Version:  unspecified  
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Well, such change is really cosmetic...

 * relb70 - only bugfixes and non-invasive changes (including new
 features). Feature freeze will come later with RC1 (I hope later in the
 summer or in the worst case in the autumn). RCs shouldn't take more then
 one/two months. I hope that we will have defined release policy in the
 near future, so it will be more clear.

 * relb64 - we are close to RC, so feature freeze (well the change reported
 by you is really minor changes, so no big deal).

 Go ahead with backport if you feel that is useful.

 Martin

-- 
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] #2277: graphically set up region bounds

[GRASS GIS]

#2277: graphically set up region bounds
-+--
 Reporter:  vincent  |   Owner:  martinl
 Type:  enhancement  |  Status:  assigned   
 Priority:  normal   |   Milestone:  7.0.0  
Component:  wxGUI| Version:  unspecified
 Keywords:  region   |Platform:  Unspecified
  Cpu:  Unspecified  |  
-+--

Comment(by wenzeslaus):

 Replying to [comment:9 martinl]:
 > Replying to [comment:6 vincent]:
 > > > Replying to [comment:3 martinl]:
 > > >
 > > > right, please try out r60055 (trunk, GRASS 7.1). Later I can
 backported to relbr70.
 > >
 > > Do you plan to backport this to 6.4 relbr too ?
 >
 > not really, the code is different, it would require extra work. Moreover
 we are very close to RC1. Feature freeze time.

 And this is the problem of backporting features. Will we also backport to
 6.5 (or even to 6.3)? And then fix the bugs in all branches (there are
 always some at least minor, such as [changeset:60059 typos]) and also
 backport improvements (e.g. printing of the region to console to get some
 feedback) for the new features once they are in place in all branches.

-- 
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] #2277: graphically set up region bounds

[GRASS GIS]

#2277: graphically set up region bounds
-+--
 Reporter:  vincent  |   Owner:  martinl
 Type:  enhancement  |  Status:  assigned   
 Priority:  normal   |   Milestone:  7.0.0  
Component:  wxGUI| Version:  unspecified
 Keywords:  region   |Platform:  Unspecified
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Replying to [comment:6 vincent]:
 > Do you plan to backport this to 6.4 relbr too ?

 not really, the code is different, it would require extra work. Moreover
 we are very close to RC1. Feature freeze time.

-- 
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] #2277: graphically set up region bounds

[GRASS GIS]

#2277: graphically set up region bounds
-+--
 Reporter:  vincent  |   Owner:  martinl
 Type:  enhancement  |  Status:  assigned   
 Priority:  normal   |   Milestone:  7.0.0  
Component:  wxGUI| Version:  unspecified
 Keywords:  region   |Platform:  Unspecified
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Replying to [comment:7 vincent]:
 > Replying to [comment:4 martinl]:
 > > Replying to [comment:3 martinl]:
 > >
 > > > right, please try out r60055 (trunk, GRASS 7.1). Later I can
 backported to relbr70.
 > >
 > > `Various zoom options -> Set computation region extent interactively`
 > Oops, line 1257 in grass/trunk/gui/wxpython/mapdisp/frame.py:
 > [[BR]]
 > `s/iteractively/interactively/`

 ops, fixed in r60059. Thanks for testing.

-- 
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] #2277: graphically set up region bounds

[GRASS GIS]

#2277: graphically set up region bounds
-+--
 Reporter:  vincent  |   Owner:  martinl
 Type:  enhancement  |  Status:  assigned   
 Priority:  normal   |   Milestone:  7.0.0  
Component:  wxGUI| Version:  unspecified
 Keywords:  region   |Platform:  Unspecified
  Cpu:  Unspecified  |  
-+--

Comment(by vincent):

 Replying to [comment:4 martinl]:
 > Replying to [comment:3 martinl]:
 >
 > > right, please try out r60055 (trunk, GRASS 7.1). Later I can
 backported to relbr70.
 >
 > `Various zoom options -> Set computation region extent interactively`
 Oops, line 1257 in grass/trunk/gui/wxpython/mapdisp/frame.py:
 [[BR]]
 `s/iteractively/interactively/`

-- 
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] #2277: graphically set up region bounds

[GRASS GIS]

#2277: graphically set up region bounds
-+--
 Reporter:  vincent  |   Owner:  martinl
 Type:  enhancement  |  Status:  assigned   
 Priority:  normal   |   Milestone:  7.0.0  
Component:  wxGUI| Version:  unspecified
 Keywords:  region   |Platform:  Unspecified
  Cpu:  Unspecified  |  
-+--

Comment(by vincent):

 Replying to [comment:4 martinl]:
 > Replying to [comment:3 martinl]:
 >
 > > right, please try out r60055 (trunk, GRASS 7.1). Later I can
 backported to relbr70.
 >
 > `Various zoom options -> Set computation region extent interactively`

 Great, Martin !
 it works like a charm...
 Do you plan to backport this to 6.4 relbr too ?

 Thank you

-- 
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] #2277: graphically set up region bounds

[GRASS GIS]

#2277: graphically set up region bounds
-+--
 Reporter:  vincent  |   Owner:  martinl
 Type:  enhancement  |  Status:  assigned   
 Priority:  normal   |   Milestone:  7.0.0  
Component:  wxGUI| Version:  unspecified
 Keywords:  region   |Platform:  Unspecified
  Cpu:  Unspecified  |  
-+--
Changes (by martinl):

 * cc: grass-dev@… (added)
  * owner:  grass-dev@… => martinl
  * status:  new => assigned


-- 
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] #2277: graphically set up region bounds

[GRASS GIS]

#2277: graphically set up region bounds
-+--
 Reporter:  vincent  |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  unspecified  
 Keywords:  region   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Replying to [comment:3 martinl]:

 > right, please try out r60055 (trunk, GRASS 7.1). Later I can backported
 to relbr70.

 `Various zoom options -> Set computation region extent interactively`

-- 
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] #2277: graphically set up region bounds

[GRASS GIS]

#2277: graphically set up region bounds
-+--
 Reporter:  vincent  |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  unspecified  
 Keywords:  region   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by martinl):

 Replying to [comment:2 vincent]:
 > Replying to [comment:1 martinl]:
 > > Slightly related, it's possible to set region extent from display, see
 `Various zoom options -> Set computational region from display extent`.
 >
 > Yes I use that, but proceeding this way may not be very handy : you have
 to resize the map display frame if you need to define e.g. an especially
 narrow region.

 right, please try out r60055 (trunk, GRASS 7.1). Later I can backported to
 relbr70.

-- 
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] #2017: osgf compilation error (was: osgf compilation error (fixed?))

[GRASS GIS]

#2017: osgf compilation error
---+
 Reporter:  martinl|   Owner:  grass-dev@…  

 Type:  defect |  Status:  new  

 Priority:  critical   |   Milestone:  7.0.0

Component:  Compiling  | Version:  svn-trunk

 Keywords:  libc, osgf, libavutil, ffmpeg  |Platform:  Linux

  Cpu:  x86-64 |  
---+
Changes (by wenzeslaus):

  * keywords:  libc, osgf, libavutil => libc, osgf, libavutil, ffmpeg


Comment:

 So, current state is that GRASS has to be compiled without `ffmpeg`
 (`avutil`):
 {{{
 --with-ffmpeg=no
 }}}
 This probably applies to all GRASS branches and most of the platforms.

 ''Removing status from the ticket title. Please keep discussion about
 ticket status in ticket comments.''

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] discussion: spectral libraries and GRASS

[Yann Chemin]

Hi, I would like to start a discussion about supporting spectral
libraries in GRASS.

known formats:

ASTER speclibv2.0 has each signature in a plain text file with 27
lines of headers and the rest in 2 columns Tab-separated
(1=wavelength, 2=reflectance)

Speclab.lib06 (http://speclab.cr.usgs.gov/spectral.lib06/) is in text
format, seems a bit more complex than speclibv2.0 and I have not been
able to compile their reading code yet, I might just skip it and make
directly a reader.

ENVI .sli seems to be a hyperspectral image cube with an augmented
header file to fit the attributes handling.

Questions:

1 - anybody worked with spectral libraries in GRASS before? If yes,
which approach you used?
2 - any (un/less)known modules waiting to be resurrected about that?
3 - If nothing is there, anybody has a strong feeling about the way to
go for GRASS to: a) import b) store such libraries?
4 - A last note: each signature has significant amount of metadata,
this might be a challenge.

(I am willing to code the necessary to import and store)

Yann
-- 

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