Re: [GRASS-dev] where is GRASS looking for these dependencies?

[Michael Barton]

Thanks. That is reassuring.

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 Jul 22, 2016, at 2:21 PM, Glynn Clements  wrote:
> 
> 
> Michael Barton wrote:
> 
>> Can someone familiar with the GRASS build system tell me where it is
>> looking for the following items in the configure string when
>> compiling?
>> 
>> --with-x
>> --with-cxx
>> --with-opengl=aqua
>> --with-python
>> --with-opencl
> 
> --with-x is built into AC_PATH_XTRA which is a standard autoconf
> macro. The others originate with a LOC_ARG_WITH macro (which is a
> shallow wrapper around AC_ARG_WITH). This sets the variable with_foo
> to "yes" if --with-foo is used with no argument, to "no" if
> --without-foo is used, to the argument if --with-foo is used with an
> argument, and to the default value (the third argument of
> LOC_ARG_WITH, defaulting to "no") if --without-foo isn't used.
> 
>> Thanks. I’m trying to find out if any of these are hardwired to
>> specifically look in /usr/.. for stuff.
> 
> Not by configure.in. AC_PATH_XTRA may have some hardwired defaults,
> some of the other tests use pkgconf by default.
> 
> -- 
> Glynn Clements 

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

Re: [GRASS-dev] where is GRASS looking for these dependencies?

[Glynn Clements]

Michael Barton wrote:

> Can someone familiar with the GRASS build system tell me where it is
> looking for the following items in the configure string when
> compiling?
> 
> --with-x
> --with-cxx
> --with-opengl=aqua
> --with-python
> --with-opencl

--with-x is built into AC_PATH_XTRA which is a standard autoconf
macro. The others originate with a LOC_ARG_WITH macro (which is a
shallow wrapper around AC_ARG_WITH). This sets the variable with_foo
to "yes" if --with-foo is used with no argument, to "no" if
--without-foo is used, to the argument if --with-foo is used with an
argument, and to the default value (the third argument of
LOC_ARG_WITH, defaulting to "no") if --without-foo isn't used.

> Thanks. I’m trying to find out if any of these are hardwired to
> specifically look in /usr/.. for stuff.

Not by configure.in. AC_PATH_XTRA may have some hardwired defaults,
some of the other tests use pkgconf by default.

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

[GRASS-dev] [GRASS GIS] #3105: r.stats.zonal parameter description

[GRASS GIS]

#3105: r.stats.zonal parameter description
-+-
 Reporter:  pvanbosgeo   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.0.5
Component:  Default  |Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 In the manual page of r.stats.zonal, one has to give a base raster map and
 a cover raster map. From these terms alone it may not be clear which map
 should be what without going to the (linked) r.statistics manual page. I
 would like to suggest to:

 1) copy the relevant parts to the description on the r.stats.zonal manual
 page.

 2) describe the parameter base as "Name of base/zonal/category raster
 map". At minimum, use the word 'zonal' (it is part of the name of the
 function for a reason)

 Point 2 applies to the description of the 'base' parameter of r.statistics
 as well.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] GSoC 2016 - PyQt GRASS - Report 9

[Ondřej Pešek]

Hi all!

Here is the ninth report of my GSoC project - PyQt based GUI of GRASS
automatically generated from XML. For screenshots and other stuff see its
wiki: https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI

What did you get done this week?

* New widget: dbtable

* I had finally ordered tabs. Required tab is the first one and Optional
tab the last one. And if widget has defined guisection, it is now prior to
Required.

* I had fixed problems with spinboxes. They now allow you to input number
greater than 100 and also negative numbers.

* Was created first version of sizepolicy. Dialog width and height still
depends on content volume, but now just till some limit. After that, the
tab gets sliders to scroll.
What do you plan on doing next week?

* Finish things with sizepolicy, clear little bit the code, there are still
some widgets which I plan to design better way

Are you blocked on anything?

* I was really blocked on the sizepolicy for a while. I'm talking 'bout it
with my mentor and it seems that it will be okay in a while.

Have a nice weekend,
Ondrej
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Memory use in v.in.lidar for points with attributes

[Moritz Lennert]

On 22/07/16 16:05, Newcomb, Doug wrote:

Hi Folks,
My goal is to import a LiDAR point cloud from an LAS file with 152
million points.  I would like to use v.lidar.mcc to extract bare earth
points from the point cloud for generating a DEM  However, v.lidar.mcc
requires that the point layer have an attribute table


Are you sure ? The example in the v.lidar.mcc man page says:

v.in.lidar -tr input=points.las output=points
v.lidar.mcc points ground=ground_points nonground=non_ground_points

the -t in v.in.lidar means "Do not create attribute table".

> rather than just
> the raw x,y,z points without topography.

Do you mean topology ?

Attribute table and topology are two seperate issues.



So using v.in.lidar, I am importing  the lidar points as normal points,
and the memory usage is steadily climbing.  Less than 1/4 of the points
are imported and memory usage is at 5GB . This on a Windows 7 64 bit
system with GRASS 7.2 svn

I'm suspecting this is not the expected behavior.


I would say that it is expected. YMMMV with different database backends, 
but attribute handling can be memory-heavy.


What does v.in.lidar -t give you ?

If some attribute really need to be conserver, maybe this a good case to 
test Vaclav's additions to v.in.lidar, storing attributes as cat values, 
instead of attributes in a table:


https://lists.osgeo.org/pipermail/grass-dev/2015-September/076490.html
https://trac.osgeo.org/grass/changeset/66343

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

[GRASS-dev] Memory use in v.in.lidar for points with attributes

[Newcomb, Doug]

Hi Folks,
My goal is to import a LiDAR point cloud from an LAS file with 152 million
points.  I would like to use v.lidar.mcc to extract bare earth points from
the point cloud for generating a DEM  However, v.lidar.mcc requires that
the point layer have an attribute table rather than just the raw x,y,z
points without topography.

So using v.in.lidar, I am importing  the lidar points as normal points, and
the memory usage is steadily climbing.  Less than 1/4 of the points are
imported and memory usage is at 5GB . This on a Windows 7 64 bit system
with GRASS 7.2 svn

I'm suspecting this is not the expected behavior.

Doug

-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
As a federal employee, my email may be subject to FOIA request.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev