[pdal] lazperf requirement for PDAL 2.4+

[Andrew Bell]

Perhaps unfortunately, lazperf has slipped from being a tool to compress
data according to the LAZ algorithm into something that can read and write
complete LAS/LAZ files. This additional functionality originally existed
only for testing purposes. I think that if the encoding/decoding bits were
separate, it would be totally stable. I don't know if this matters to
people, but I thought I would mention it.

On Mon, Oct 4, 2021 at 9:17 AM Sebastiaan Couwenberg <sebastic at xs4all.nl>
wrote:

> On 10/4/21 2:29 PM, James Klassen wrote:
> > It seems important for the other GIS packages to have pdal packaged
> (especially with the upcoming QGIS point cloud work). It also seems like it
> is important to have it packaged for OSGeo Live.
>
> Very true.
>
> I initially packaged pdal because grass needed an alternative for
> liblas, I was more willing to maintain packages I don't actually use
> back then.
>
> 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.
>
> > However, while I mostly run Debian stable, I build/install multiple
> versions of pdal, lazperf, gdal, QGIS, CloudCompare, et al. from source
> because the packaged versions usually aren’t up to date with what I need
> (and I like building from source because it helps when I need to
> debug/modify code).
>
> Libraries with rdepds like pdal, and specifically ones with many like
> gdal, are not very suited for backports. So if you need something newer
> than what's in Debian stable, you either need to maintain backport for
> bunch of packages or build them all from source.
>
> > I haven’t packaged anything for Debian before.  I have built some of my
> own DEBs, but I just did the bare minimum to get something that would
> install. I haven’t gone through any of the community process, nor cared if
> the packages pass lint.  Lazperf itself seems like a pretty easy place to
> start (few dependencies, well behaved cmake, etc).  How much ongoing effort
> would be required to maintain a package such as lazperf?
>
> Packaging for Debian differs from packaging for personal repos mostly in
> that the copyright file needs to be properly maintained, tooling like
> licensecheck helps greatly with that.
>
> 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.
>
> 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/
>
> Kind Regards,
>
> Bas
>
> --
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pdal
>


-- 
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20211004/66405a9a/attachment-0001.html>