[GRASS-dev] grass 7.2 planning

GRASS GIS GRASS GIS developer
1

If we could get wxPython 3.x working for the GUI, we could switch all Mac compiling to 64bit. That would make LAS libraries MUCH easier to compile and bundle with GRASS. I’ve posted a 64bit version of GRASS 7.1 with wxPython 3.0.2.0 for people to test and report bugs. It mostly works fine. So it may not be a big deal to fix the few remaining issues.

Related to this, is there a plan to replace liblas with the new Python alternative (the name escapes me at the moment)? This would further simplify making robust LiDAR tools available in GRASS

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 Apr 30, 2016, at 5:59 AM, grass-dev-request@lists.osgeo.org wrote:

From: Vaclav Petras <wenzeslaus@gmail.com>

Subject: Re: [GRASS-dev] grass 7.2 planning

Date: April 30, 2016 at 5:59:27 AM MST

To: Martin Landa <landa.martin@gmail.com>

Cc: GRASS developers list <grass-dev@lists.osgeo.org>

On Sat, Apr 30, 2016 at 8:09 AM, Martin Landa <landa.martin@gmail.com> wrote:

2016-04-29 15:09 GMT+02:00 Vaclav Petras <wenzeslaus@gmail.com>:

I have some things in lidar modules which would be good to do before the
branching, namely changing the layer options to flag(s) and removal of
vector output from r.in.lidar. Ideally, some code should go from modules to
the library but that might not be feasible in the given time frame (from my
side). The first week of May I can’t promise any commits since I’m at FOSS4G
NA [1]

we can wait one week or so if you wish.

Thanks. This would give at least some chance to get things straight.

From things I remember, there is the prototype of Simple Python Editor which
needs a review but you (Martin) already did some, so I guess that’s fine.

Yes, I used the editor in lessons. Nice tool!

Thanks. It took me some time to discover that this is exactly what users want.

I had only one problem,
sometimes run button was not working (I discovered why after lesson)

I focused on getting the basics working but the executing is just tricky. Will try to look at it as well to see if some substantial changes are needed.

2

The LiDAR tools I was thinking of is PDAL.

http://www.pdal.io

I guess it’s C++. But it’s open source without some of the legal and compiling issues of LAStools.

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 Apr 30, 2016, at 9:28 AM, Michael Barton <michael.barton@asu.edu> wrote:

If we could get wxPython 3.x working for the GUI, we could switch all Mac compiling to 64bit. That would make LAS libraries MUCH easier to compile and bundle with GRASS. I’ve posted a 64bit version of GRASS 7.1 with wxPython 3.0.2.0 for people to test and report bugs. It mostly works fine. So it may not be a big deal to fix the few remaining issues.

Related to this, is there a plan to replace liblas with the new Python alternative (the name escapes me at the moment)? This would further simplify making robust LiDAR tools available in GRASS

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 Apr 30, 2016, at 5:59 AM, grass-dev-request@lists.osgeo.org wrote:

From: Vaclav Petras <wenzeslaus@gmail.com>

Subject: Re: [GRASS-dev] grass 7.2 planning

Date: April 30, 2016 at 5:59:27 AM MST

To: Martin Landa <landa.martin@gmail.com>

Cc: GRASS developers list <grass-dev@lists.osgeo.org>

On Sat, Apr 30, 2016 at 8:09 AM, Martin Landa <landa.martin@gmail.com> wrote:

2016-04-29 15:09 GMT+02:00 Vaclav Petras <wenzeslaus@gmail.com>:

I have some things in lidar modules which would be good to do before the
branching, namely changing the layer options to flag(s) and removal of
vector output from r.in.lidar. Ideally, some code should go from modules to
the library but that might not be feasible in the given time frame (from my
side). The first week of May I can’t promise any commits since I’m at FOSS4G
NA [1]

we can wait one week or so if you wish.

Thanks. This would give at least some chance to get things straight.

From things I remember, there is the prototype of Simple Python Editor which
needs a review but you (Martin) already did some, so I guess that’s fine.

Yes, I used the editor in lessons. Nice tool!

Thanks. It took me some time to discover that this is exactly what users want.

I had only one problem,
sometimes run button was not working (I discovered why after lesson)

I focused on getting the basics working but the executing is just tricky. Will try to look at it as well to see if some substantial changes are needed.

3

Hi Michael,

I'm currently looking at the lidar-related functionality, so here is some
info.

On Sat, Apr 30, 2016 at 12:28 PM, Michael Barton <Michael.Barton@asu.edu>
wrote:

Related to this, is there a plan to replace liblas with the new Python
alternative (the name escapes me at the moment)? This would further
simplify making robust LiDAR tools available in GRASS

On Sat, Apr 30, 2016 at 12:36 PM, Michael Barton <Michael.Barton@asu.edu>
wrote:

The LiDAR tools I was thinking of is PDAL.

http://www.pdal.io

You can try compile GRASS with PDAL right now. Just note that PDAL is not a
drop-in replacement for libLAS and so far the PDAL functionality is
available only through special module v.in.pdal. See #2732 [1] for details.

I guess it's C++.

Yes, it's C++ not C or Python and it currently does not have C API, so it
might be even harder to connect in general. The basic functionality newly
(since release 1.2) does not depend on Boost but the new C++ (I think
C++11) is needed. It is important to note that most of the fancy
functionality (like ground detection) is provided through another
dependency, PCL (http://pointclouds.org/), which is a large point cloud
processing library which depends on Boost (if I recall correctly).

But it's open source without some of the legal and compiling issues of

LAStools.

With the current GRASS source code we are able to use only libLAS (
http://www.liblas.org/), not LAStools (https://rapidlasso.com/lastools/)
[2].

Best,
Vaclav

[1] https://trac.osgeo.org/grass/ticket/2732
[2] https://lists.osgeo.org/pipermail/grass-dev/2015-September/076318.html

4

Vaclav,

I agree with all of your points. There was a little discussion about recoding GRASS LiDAR tools to use PDAL instead of libLAS. I am just wondering if that has gone anywhere or not.

libLAS is missing some of the most sophisticated filtering routines found in the non-open-source LAStools. PDAL seems to have them according to the web site but I admit that I have not yet tried them. I might have time to do so in the coming weeks.

Michael

···

Hi Michael,

I’m currently looking at the lidar-related functionality, so here is some info.

On Sat, Apr 30, 2016 at 12:28 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

Related to this, is there a plan to replace liblas with the new Python alternative (the name escapes me at the moment)? This would further simplify making robust LiDAR tools available in GRASS

On Sat, Apr 30, 2016 at 12:36 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

The LiDAR tools I was thinking of is PDAL.

http://www.pdal.io

You can try compile GRASS with PDAL right now. Just note that PDAL is not a drop-in replacement for libLAS and so far the PDAL functionality is available only through special module v.in.pdal. See #2732 [1] for details.

I guess it’s C++.

Yes, it’s C++ not C or Python and it currently does not have C API, so it might be even harder to connect in general. The basic functionality newly (since release 1.2) does not depend on Boost but the new C++ (I think C++11) is needed. It is important to note that most of the fancy functionality (like ground detection) is provided through another dependency, PCL (http://pointclouds.org/), which is a large point cloud processing library which depends on Boost (if I recall correctly).

But it’s open source without some of the legal and compiling issues of LAStools.

With the current GRASS source code we are able to use only libLAS (http://www.liblas.org/), not LAStools (https://rapidlasso.com/lastools/) [2].

Best,

Vaclav

[1] https://trac.osgeo.org/grass/ticket/2732
[2] https://lists.osgeo.org/pipermail/grass-dev/2015-September/076318.html

5

On Sat, Apr 30, 2016 at 6:36 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

The LiDAR tools I was thinking of is PDAL.

http://www.pdal.io

I guess it's C++. But it's open source without some of the legal and
compiling issues of LAStools.

There is already a ticket:
#2732: Read lidar data as vector points using PDAL

Note that PDAL needs tons of extra packages including gl2ps, hexer,
jsoncpp, laszip, netcdf-cxx, nitro, openni, pcl, points2grid, qhull,
tinyxml, vtk, boost-date-time, boost-system.

:slight_smile:

Markus

6

On 04/30/2016 11:22 PM, Markus Neteler wrote:

Note that PDAL needs tons of extra packages including gl2ps, hexer,
jsoncpp, laszip, netcdf-cxx, nitro, openni, pcl, points2grid, qhull,
tinyxml, vtk, boost-date-time, boost-system.

You only need all those dependencies if need all the PDAL plugins, core
PDAL only requires GDAL, the other dependencies are optional.

The pdal Debian package only enables the plugins for which the
dependencies are available (greyhound, icebridge, python & sqlite). The
PCL plugin pulls in the enormous and problematic VTK dependency chain
and has been disabled in the Debian package despite the dependencies
being available.

Kind Regards,

Bas

--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1

7

Yes. This is a problem. I've only run it in a docker container so far. So I don't know how hard it will be to compile it--probably difficult.

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 Apr 30, 2016, at 2:22 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Sat, Apr 30, 2016 at 6:36 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

The LiDAR tools I was thinking of is PDAL.

http://www.pdal.io

I guess it's C++. But it's open source without some of the legal and
compiling issues of LAStools.

There is already a ticket:
#2732: Read lidar data as vector points using PDAL

Note that PDAL needs tons of extra packages including gl2ps, hexer,
jsoncpp, laszip, netcdf-cxx, nitro, openni, pcl, points2grid, qhull,
tinyxml, vtk, boost-date-time, boost-system.

:slight_smile:

Markus