Dear all,
first, thanks Howard for detailed answer in the original thread "New Mac
binaries uploaded". The listed points are really encouraging. (I'm creating
a new thread to keep it organized; cross posting grass-dev and pdal.)
Removing the Boost dependency and an actual release with packages sounds
great, however I realized that there is no C API. Is that right? GRASS GIS
now actually somehow lives with Boost dependency of libLAS but it is using
its C API. I don't have much experience in that matter but I know that many
people consider C API much better since it better holds ABI (AFAIU). Is
there any ongoing or planned work on C API for PDAL?
Thanks,
Vaclav
On Thu, Aug 27, 2015 at 3:25 PM, Michael Barton <Michael.Barton@asu.edu>
wrote:
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
> On Aug 25, 2015, at 6:50 AM, Howard Butler <howard@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 open source methodology. If you have
changes to make, you can start having impact right away.
> 4) It's GDAL for point clouds and supports reading at least 16 different
point cloud formats and writing at least 14
> 5) It is composeable. Using its VRT-like Pipeline syntax, you can stack
together reader, filter, and writer operations into a data flow that can be
executed via simple command line tools or embedded into applications
> 6) It supports extension with Python. Using the predicate [1] and
programmable [2] filters, you can write software that interacts with the
points without having to develop C/C++. This is very useful for rapid
prototyping of algorithms (you have the full expressiveness of numpy
available to you).
> 7) It supports PCL integration. Advanced exploitive techniques [3]
developed in that environment are available to utilize in processing
pipelines via simple JSON configuration.
> 8) It has full coordinate system support through GeoTIFF/GDAL/proj.4.
This is a big missing feature of LASlib.
>
> With regard to PDAL's boost dependency, we are working to remove that.
It's not gone at the moment, but it is really close. We recognize that
Boost is a pain for many folks, and the C++11 standard added most of the
features from boost PDAL was depending upon anyway. The most significant
boost reliance at the moment is PDAL's use of program_options, but we are
working around it.
>
> PDAL will be having its 1.0.0 release before FOSS4G 2015 in September.
If you will be attending FOSS4G 2015, make sure to attend Michael Smith's
presentation at 14:40 on Thursday where he will give examples and
background on how to use PDAL for point cloud data processing and
management.
>
> We have PDAL packages for OSGeo4W64 and OSGeo4Mac. These are maintained
by the developers of the software. We recognize that without packages, many
folks cannot use the code, and we will be maintaining these packages as
best we can going forward. We will leave the Linux packaging to the
experts, however, and the official release will be the signal to those
folks to bring it off the lab bench.
>
> Hope this helps,
>
> Howard
>
>
> [1] http://www.pdal.io/stages/filters.predicate.html
> [2] http://www.pdal.io/stages/filters.programmable.html
> [3] http://www.pdal.io/stages/filters.pclblock.html#implemented-filters