[pdal] lazperf requirement for PDAL 2.4+

[Howard Butler]

> On Oct 4, 2021, at 8:17 AM, Sebastiaan Couwenberg <sebastic at xs4all.nl> wrote:
> 
> Much more time was spent to get laszip into Debian, which will now only
> be used in the bullseye stable release. It was definitely not worth that
> much effort.

At least the licensing story of lazperf is exactly the same as laszip, so it won't have to run over that particular hurdle again.

> How much effort will be required to maintain lazperf is impossible to
> predict. If the SONAME changes often, you'll need to coordinate
> transitions often. If it doesn't, you'll mostly need to keep up with
> bugreports and new upstream releases.

I would predict one or two bug fix releases per year going forward after we release lazperf 2.2.0. 

> As someone who actually uses lazperf you're much better suited to help
> maintain the package than someone like me who doesn't. I encourage you
> to package laszip and maintain it with in the Debian GIS Team. Refer to
> the team policy for the workflow documentation:
> 
> https://debian-gis-team.pages.debian.net/policy/

We're not purposefully trying to be difficult. With Martin Isenburg's recent death, his profound expertise with the LASzip library goes with it. We haven't had a LASzip release in almost two years, and there have not really been any new features in the LASzip library in 5+ years after the LAZ 1.4 encoder/decoder was released. The LASzip code is hard to follow, contains significant sections of duplication, and has a funky API. 

laz-perf adds tests, the ability to reuse the library in web assembly scenarios, and a cleaner programming API. The encoder/decoder is binary compatible with LASzip and laz-rs (great care has been taken by us and Thomas Montaigu of laz-rs to preserve this due to there being no LAZ specification beyond the LASzip code). The refactoring of the EPT and LAZ codebase to add support for COPC in PDAL provides the opportunity to move forward without dual LAZ library support.

Howard