[pdal] filters.icp transformation

[Jim Klassen]

On 3/6/20 2:40 PM, Jed Frechette wrote:
> On Fri, 6 Mar 2020 11:51:55 -0500 Bradley Chambers wrote:
>
>> See my latest comment in the PR. I think the way to go is to remove the
>> centering step altogether. It doesn't address the ease of use, but that's
>> really a separate issue anyway.
> As a user this would be my preference as well.
>
> A lot of our workflows involve using 4x4 matrices to move
> transformation information around. The results of something like an
> ICP alignment might be applied to the original data, or some other
> derivative data object in a completely different application. A
> transform history might also be stored as a series of 4x4 matrices.
>
> Even if filters.icp was using floats and precision was a concern for
> large numbers I would prefer to handle the centering myself as a
> pretransform rather than have the ICP filter calculate separate
> centering values. Typically if we're working on something in a large
> number coordinate system, but need to use software without the
> required coordinate precision we'll choose a standard global
> translation to use for the asset throughout it's lifetime. Unless it
> is completely hidden from the user, having filters.icp calculate it's
> own translation just adds more bookkeeping we need to keep track of.
>
> In short, all I would want to get out of filters.icp or filters.cpd is
> a single transform matrix that can be applied directly with
> filters.transformation. For our use case, even getting the transformed
> points isn't really needed. More often than not we're applying the
> transform to a modified version of the original points so we would
> just discard the points output by filters.icp anyway.
>
> Best wishes,
>
You make a very good point.