[pdal] GRASS GIS and PDAL: C API?

[Vaclav Petras]

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 at 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 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20150831/f3a21290/attachment.html>