GRASS GIS | 28 Aug 10:46 2015

Re: [GRASS GIS] #2701: Grass 7.0.0 installed from QGIS Repository

#2701: Grass 7.0.0 installed from QGIS Repository
--------------------------+-------------------------
  Reporter:  rjhale1971   |      Owner:  grass-dev <at> …
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  7.0.2
 Component:  Default      |    Version:  7.0.0
Resolution:               |   Keywords:  linux, qgis
       CPU:  Unspecified  |   Platform:  Linux
--------------------------+-------------------------

Comment (by mlennert):

 Replying to [comment:5 neteler]:
 > Replying to [comment:3 martinl]:
 > > Replying to [comment:2 mlennert]:
 > > > Do we really have to depend on svn for g.extension ? AFAIK, trac can
 be configured to allow download of tarballs of specific directories. How
 about enabling this for the addons directory and then just have
 g.extension download these tarballs ?
 > >
 > > Would be nice.
 >
 > For the record: I have configured trac accordingly a month ago.

 And Vaclav has implemented use of the zip archives in r65769, or ?

 I tried:

 apt-get remove subversion

(Continue reading)

GRASS GIS | 28 Aug 10:02 2015

Re: [GRASS GIS] #2701: Grass 7.0.0 installed from QGIS Repository

#2701: Grass 7.0.0 installed from QGIS Repository
--------------------------+-------------------------
  Reporter:  rjhale1971   |      Owner:  grass-dev <at> …
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  7.0.2
 Component:  Default      |    Version:  7.0.0
Resolution:               |   Keywords:  linux, qgis
       CPU:  Unspecified  |   Platform:  Linux
--------------------------+-------------------------

Comment (by neteler):

 Replying to [comment:3 martinl]:
 > Replying to [comment:2 mlennert]:
 > > Do we really have to depend on svn for g.extension ? AFAIK, trac can
 be configured to allow download of tarballs of specific directories. How
 about enabling this for the addons directory and then just have
 g.extension download these tarballs ?
 >
 > Would be nice.

 For the record: I have configured trac accordingly a month ago.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2701#comment:5>
GRASS GIS <https://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
(Continue reading)

GRASS GIS | 28 Aug 09:39 2015

[GRASS GIS] #2731: t.rast.aggregate: ValueError: too many values to unpack

#2731: t.rast.aggregate: ValueError: too many values to unpack
------------------------------+-------------------------
 Reporter:  neteler           |      Owner:  grass-dev <at> …
     Type:  defect            |     Status:  new
 Priority:  normal            |  Milestone:  7.1.0
Component:  Temporal          |    Version:  svn-trunk
 Keywords:  t.rast.aggregate  |        CPU:  Unspecified
 Platform:  Unspecified       |
------------------------------+-------------------------
 The current t.rast.aggregate fails on Windows:

 {{{

 C:\>t.rast.aggregate in=CA_tmean_temporal <at> tmean out=CA_tmean_annual
 basename=yea
 r granularity="1 years" method=average
 Traceback (most recent call last):
   File "C:\OSGeo4W\apps\grass\grass-7.1.svn/scripts/t.rast.aggregate.py",
 line 1
 96, in <module>
     main()
   File "C:\OSGeo4W\apps\grass\grass-7.1.svn/scripts/t.rast.aggregate.py",
 line 1
 73, in main
     overwrite=gcore.overwrite())
   File
 "C:\OSGeo4W\apps\grass\grass-7.1.svn\etc\python\grass\temporal\aggregatio
 n.py", line 308, in aggregate_by_topology
     process_queue.put(mod)
   File
(Continue reading)

Michael Barton | 27 Aug 21:25 2015
Picon

Re: New Mac binaries uploaded

This looks like a very good direction for GRASS in the future from a practical and conceptual standpoint. It
will probably take some rewriting of the existing LiDAR tools of course. This will be much easier if we can
compile it more simply (without Boost). I took a look at the tools on the website. Having a good
‘ground’ module will be very important, since that is one of the proprietary LAS tools now. But I
didn’t see the equivalent of las2las. Are these capabilities included in other tools that I didn’t see?

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 Aug 25, 2015, at 6:50 AM, Howard Butler <howard <at> hobu.co> wrote:
> 
> Doug,
> 
> Thanks for the bump. Here's the case for using PDAL in GRASS:
> 
> 1) It has full LAS 1.4 support (libLAS stops at 1.2) (LASlib has full 1.4 support too)
> 2) It is entirely open source without LAStools'/LASlib's somewhat confusing licensing. It is also BSD if
that matters to you.
> 3) It is developed by a group of developers, and it is developed on github with pull requests and typical
(Continue reading)

Rainer M Krug | 27 Aug 14:32 2015
Picon

Re: Travis CI

Hi Ivan, Hi Markus,

I have looked at the .travis.yml at
[https://trac.osgeo.org/grass/browser/grass/trunk/.travis.ym]l
and merged it with mine by

1) moving the sections of the .travis.yml fiole into scripts:

   - before_install :: .travis.$TRAVIS_OS_NAME.before_install.sh
   - install        :: .travis.$TRAVIS_OS_NAME.install.sh
   - script         :: .travis.$TRAVIS_OS_NAME.script.sh

2) using a travis multiple OS [http://docs.travis-ci.com/user/multi-os/]
which sets the variable $TRAVIS_OS_NAME to "osx" or "linux" (hopefully
"windows" in the future as well)

So when testing on linux, the scripts with *.linux.*.sh are called, when
testing osx the one=s with *.osx.*.sh get called

3) adding the different compiler to the matrix

So I end up with three separate test scenarios:

,----
| - os: linux
|   language: c
|   compiler: gcc
| 
| - os: linux
|   language: c
(Continue reading)

GRASS GIS | 27 Aug 11:51 2015

[GRASS GIS] #2730: wxGUI: wx.metadata/wx.mwprecip/etc: Unable to fetch interface description for command 'wx.metadata'

#2730: wxGUI: wx.metadata/wx.mwprecip/etc: Unable to fetch interface description
for command 'wx.metadata'
---------------------------------------------+-------------------------
 Reporter:  mlennert                         |      Owner:  grass-dev <at> …
     Type:  defect                           |     Status:  new
 Priority:  normal                           |  Milestone:  7.0.2
Component:  wxGUI                            |    Version:  svn-trunk
 Keywords:  interface-description toolboxes  |        CPU:  Unspecified
 Platform:  Unspecified                      |
---------------------------------------------+-------------------------
 Apparently, at start up, the wxGUI tries to get interface descriptions of
 all addon modules. To do this, it (core/toolboxes.py) uses the name of the
 addon. However, some addons are not modules, but GUI toolboxes that might
 contain modules, and as such they do not provide interface descriptions.
 This is the case, for example, with wx.metadata and wx.mwprecip which lead
 to

 {{{
 WARNING: Some addons failed when loading. Please consider to update your
 addons by running 'g.extension.all -f'.
 }}}

 I don't really understand why this has to be called at all when the user
 does not have any toolboxes defined...

 Verified in trunk and release70.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2730>
GRASS GIS <https://grass.osgeo.org>
(Continue reading)

GRASS GIS | 26 Aug 20:45 2015

Re: [GRASS GIS] #2581: Fix Python ctypes conversion for stat64 struct on GNU/Hurd

#2581: Fix Python ctypes conversion for stat64 struct on GNU/Hurd
----------------------------+---------------------------------
  Reporter:  sebastic       |      Owner:  grass-dev <at> …
      Type:  defect         |     Status:  closed
  Priority:  normal         |  Milestone:  7.0.2
 Component:  Python ctypes  |    Version:  svn-releasebranch70
Resolution:  fixed          |   Keywords:  python
       CPU:  Unspecified    |   Platform:  All
----------------------------+---------------------------------
Changes (by martinl):

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

Comment:

 Replying to [comment:6 martinl]:
 > done in r65968. If no objection I will backport it to relbr70.

 backported in r66031. Closing the ticket.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2581#comment:7>
GRASS GIS <https://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Radim Blazek | 26 Aug 19:37 2015
Picon

Vect_new_map_struct

Hi,

I have created new issue https://trac.osgeo.org/grass/ticket/2729
requesting to add Vect_new_map_struct, patch is supplied.

Radim
GRASS GIS | 26 Aug 19:31 2015

[GRASS GIS] #2729: Missing Vect_new_map_struct

#2729: Missing Vect_new_map_struct
-------------------------+-------------------------
 Reporter:  rblazek      |      Owner:  grass-dev <at> …
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:
Component:  Vector       |    Version:  svn-trunk
 Keywords:               |        CPU:  Unspecified
 Platform:  All          |
-------------------------+-------------------------
 There is no function to allocate Map_info. If GRASS library is used in
 another application (QGIS for example) which is compiled by a compiller
 with different ABI, calls to Vect_ functions using Map_info structure
 allocated by the other application may result in crash. The problem was
 discussed here:
 http://lists.osgeo.org/pipermail/grass-dev/2015-June/075539.html

 A patch against trunk r66029 introducing Vect_new_map_struct and
 Vect_destroy_map_struct is attached. I am not sure what should be a policy
 for releasing Map_info members.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2729>
GRASS GIS <https://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 26 Aug 14:58 2015

[GRASS GIS] #2728: g.gui.animation (wx3): TypeError : in method 'new_SpinCtrl', expected argument 9 of type 'int'

#2728: g.gui.animation (wx3):  TypeError : in method 'new_SpinCtrl', expected
argument 9 of type 'int'
---------------------------+-------------------------
 Reporter:  mlennert       |      Owner:  grass-dev <at> …
     Type:  defect         |     Status:  new
 Priority:  normal         |  Milestone:  7.0.2
Component:  wxGUI          |    Version:  svn-trunk
 Keywords:  g.gui.animate  |        CPU:  Unspecified
 Platform:  Unspecified    |
---------------------------+-------------------------
 Using freshly checked out trunk, and trying to enter the settings dialog
 of g.gui.animation, I get:

 {{{
 Settings: unable to get value 'animation:nprocs:value'
 Settings: unable to get value 'animation:nprocs:value'
 Traceback (most recent call last):
   File
 "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64
 -unknown-linux-gnu/gui/wxpython/animation/frame.py", line
 297, in OnPreferences

 dlg = PreferencesDialog(parent=self, giface=self._giface)
   File
 "/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64
 -unknown-linux-gnu/gui/wxpython/animation/dialogs.py", line
 1479, in __init__

 self._createGeneralPage(self.notebook)
   File
(Continue reading)

GRASS GIS | 26 Aug 14:55 2015

Re: [GRASS GIS] #2558: The 'Profile Surfae Map' tool does not function.

#2558: The 'Profile Surfae Map' tool does not function.
--------------------------+-------------------------
  Reporter:  humu2015     |      Owner:  grass-dev <at> …
      Type:  defect       |     Status:  new
  Priority:  critical     |  Milestone:  6.4.6
 Component:  wxGUI        |    Version:  unspecified
Resolution:               |   Keywords:
       CPU:  Unspecified  |   Platform:  Linux
--------------------------+-------------------------

Comment (by mlennert):

 Replying to [comment:2 annakrat]:
 > I am not sure if we can do anything about this:
 > http://trac.wxwidgets.org/ticket/16767

 This is still and issue (including on grass7). The wx issues seem to have
 been fixed [1], but in until these are released in a new version 3.0.3 the
 histogram tool is completely unusable ! Is there really no temporary
 workaround ?

 [1] https://github.com/wxWidgets/wxPython/commits/master/wx/lib/plot.py

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2558#comment:5>
GRASS GIS <https://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
(Continue reading)


Gmane