Re: [GRASS GIS] #1525: r.mask cannot use float maps

#1525: r.mask cannot use float maps
----------------------+-----------------------------------------------------
 Reporter:  pertusus  |       Owner:  grass-dev <at> …              
     Type:  defect    |      Status:  new                      
 Priority:  minor     |   Milestone:  7.0.0                    
Component:  Raster    |     Version:  svn-trunk                
 Keywords:            |    Platform:  Linux                    
      Cpu:  x86-64    |  
----------------------+-----------------------------------------------------

Comment(by glynn):

 Replying to [comment:6 pertusus]:
 > It does not solve my issue.  I have printed the options, and indeed
 maskcats is not null, but *:
 Oops; try r50019.

 AFAICT, 6.x will have the same issue.

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1525#comment:8>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS GIS] #1527: vector projection over wrapping boundary is split

#1527: vector projection over wrapping boundary is split
-----------------------+----------------------------------------------------
  Reporter:  pertusus  |       Owner:  grass-dev <at> …              
      Type:  defect    |      Status:  reopened                 
  Priority:  normal    |   Milestone:  6.4.2                    
 Component:  Vector    |     Version:  svn-releasebranch64      
Resolution:            |    Keywords:                           
  Platform:  Linux     |         Cpu:  x86-64                   
-----------------------+----------------------------------------------------

Comment(by mmetz):

 Please try trunk r50023. There is a new option to disable longitude
 wrapping directly in the proj4 library

 Disabling longitude wrapping could (should?) be the default since usually
 there is no difference, and if errors occur, the default wrapping needs to
 be disabled in proj4 in order to preserve vector topology.

 Markus M

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1527#comment:8>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org

Re: [GRASS GIS] #1525: r.mask cannot use float maps

#1525: r.mask cannot use float maps
----------------------+-----------------------------------------------------
 Reporter:  pertusus  |       Owner:  grass-dev <at> …              
     Type:  defect    |      Status:  new                      
 Priority:  minor     |   Milestone:  6.4.2                    
Component:  Raster    |     Version:  svn-trunk                
 Keywords:            |    Platform:  Linux                    
      Cpu:  x86-64    |  
----------------------+-----------------------------------------------------
Changes (by neteler):

  * milestone:  7.0.0 => 6.4.2

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1525#comment:9>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: multithreading v.surf.bspline and others with OpenMP

Hi,

2011/12/18 Hamish <hamish_b <at> yahoo.com>:
> Sören wrote:
>>> The GRASS ATLAS wrapper is and example for such
>>> an approach. ATLAS can be used, but in case it
>>> is not installed, the default GRASS implementation
>>> is used.
> Hamish:
>> > Oh, I did not know that was there. We can work on
>> > adding it to trunk's ./configure next.
> Sören:
>> We can do, but the IMHO the ATLAS wrapper is not in
>> use by any module, except the library test module.
>
> the question is: if we had support for it would it
> be used? since we already have BLAS for low-level
> stuff and LAPACK for mid-level stuff, and the gmath
> and gpde libraries, and the ccmath library built in,
> it starts to feel a little crowded.  But if it is
> the right tool for the right job I would not want
> to deny someone to easily use it.
>
> what advantage does ATLAS bring to the table?

ATLAS is the C-Implementation of BLAS and parts of LAPACK.[1]

The advantages of ATLAS over the BLAS/LAPACK Fortran wrapper in GRASS
is that its supports
the C-style matrix layout used by the gmath library and that no

grass toolboxes idea continued (g.extension)

Hi,

I have added (r50024) very initial support of "toolboxes idea" (see
[1] for detailed information) to `g.extension` (see notes at wiki
[2]). Any feedback, support, improvements welcomed.

Martin

[1] http://grass.osgeo.org/wiki/Toolboxes
[2] http://grass.osgeo.org/wiki/Toolboxes#Managing_toolboxes

--

-- 
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Re: Re: multithreading v.surf.bspline and others with OpenMP

2012/1/2 Sören Gebbert <soerengebbert <at> googlemail.com>:

...
> ATLAS is the C-Implementation of BLAS and parts of LAPACK.[1]
>
> The advantages of ATLAS over the BLAS/LAPACK Fortran wrapper in GRASS
> is that its supports
> the C-style matrix layout used by the gmath library and that no
> Fortran to C conversion is needed.

This sounds very good.

> As far as i know the BLAS/LAPACK wrapper is not used in GRASS and IMHO
> with the presents of ATLAS and ccmath obsolete.

It was originally introduced to support the i.spec.unmix command which
is sitting since 1999 in the GRASS Addons :) Of course it would be
better to also update i.spec.unmix at this point to completely use
gmath which then calls ATLAS.

Markus

Re: grass toolboxes idea continued (g.extension)

Hello,
I'm not in the mood to digg deeply into this concept. It looks similar
to R packages, right? Can we borrow most of (design) from R to not
reinvent the wheel and to learn from their mistakes/success?

Also, if we have an option to start a new, why limit ourselves to
single or double letter as toolbox prefix? I assume, all modules in a
toolbox should have a common prefix, like hy.flow, right?

Just drinking morning tea,
Maris.

2012/1/2 Martin Landa <landa.martin <at> gmail.com>:
> Hi,
>
> I have added (r50024) very initial support of "toolboxes idea" (see
> [1] for detailed information) to `g.extension` (see notes at wiki
> [2]). Any feedback, support, improvements welcomed.
>
> Martin
>
> [1] http://grass.osgeo.org/wiki/Toolboxes
> [2] http://grass.osgeo.org/wiki/Toolboxes#Managing_toolboxes
>
> --
> Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
> _______________________________________________
> grass-dev mailing list
> grass-dev <at> lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS GIS] #1526: "Diplay/update attributes" can freeze GUI

#1526: "Diplay/update attributes" can freeze GUI
----------------------+-----------------------------------------------------
 Reporter:  artegion  |       Owner:  martinl     
     Type:  defect    |      Status:  new         
 Priority:  blocker   |   Milestone:  6.4.2       
Component:  wxGUI     |     Version:  6.4.2 RCs   
 Keywords:            |    Platform:  MSWindows XP
      Cpu:  x86-64    |  
----------------------+-----------------------------------------------------

Comment(by artegion):

 Yes, with 6.5 it works.

 (defect with multiple layer ( Ticket #1522 ) remains but it is another
 thread...)


 Replying to [comment:1 martinl]:
 > Could you try GRASS 6.5 from (1) - this bug has been probably fixed in
 r50007?
 >
 > [1] http://wingrass.fsv.cvut.cz/grass65/

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1526#comment:4>
GRASS GIS <http://grass.osgeo.org>

Re: grass toolboxes idea continued (g.extension)

Hi,

On Tue, Jan 3, 2012 at 8:31 AM, Maris Nartiss <maris.gis <at> gmail.com> wrote:
> Hello,
> I'm not in the mood to digg deeply into this concept. It looks similar
> to R packages, right? Can we borrow most of (design) from R to not
> reinvent the wheel and to learn from their mistakes/success?

Why not use a modified version of pip [0] (a tool for installing and
managing Python packages)?

with Pip you can add/change repository, compile C/Fortran module,
manage dependencies, install from some version control system (use
URLs like hg+http://domain/repo -- or prefix git+, svn+ etc), and
using virtualenv [1].

my 2 cents.

Pietro

[0] http://pypi.python.org/pypi/pip - https://github.com/pypa/pip
[1] http://pypi.python.org/pypi/virtualenv

Re: [GRASS GIS] #1527: vector projection over wrapping boundary is split

#1527: vector projection over wrapping boundary is split
-----------------------+----------------------------------------------------
  Reporter:  pertusus  |       Owner:  grass-dev <at> …              
      Type:  defect    |      Status:  reopened                 
  Priority:  normal    |   Milestone:  6.4.2                    
 Component:  Vector    |     Version:  svn-releasebranch64      
Resolution:            |    Keywords:                           
  Platform:  Linux     |         Cpu:  x86-64                   
-----------------------+----------------------------------------------------

Comment(by pertusus):

 The projection indeed seems to do the same than with the previous patch.
 The other issues are still there, though...

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1527#comment:9>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev