Voxel Grid Rewrite Ideas

A follow-up on the issues raised in https://github.com/PointCloudLibrary/pcl/pull/2171#issuecomment-364926779 .

Ideas

• Start boilerplating on pcl::experimental::VoxelGrid so that we can spread the work over multiple PRs without breaking current functionalities.
• Does it still make sense to call it a grid or even voxel for that matter? VoxelFilter?
• Drop the PointCloud2 support. Use the conversion functions during the deprecation period.

The swappable partitioning strategy seems like something that makes sense at compile time. Since different coordinate systems in the partitioning imply different parameters and therefore the corresponding getters and setters, this immediately invokes templated multiple inheritance in my head. Something along the lines of

class Partition1D
{
    public:

        virtual size_t computeLinearIndex (const float coord) const = 0;
};

class Cartesian1DPartitioning : public Partition1D
{
    public:

        void setMin (const float min) { min_ = min; }

        float getMin () const { return min_; }

        size_t computeLinearIndex (const float coord) const
        {
            // return something meaningful
            return 3.f;
        }

    protected:

        float min_;
        float max_;
        float division_;
};


// Whatever is responsible for receiving the list of points in a voxel and applying some decimation action over it
class SomeVoxelMethod
{

};

template<typename PartitionT, typename VoxelMethodT>
class VoxelFilter : public PartitionT, public VoxelMethodT
{
};

typedef VoxelFilter<Cartesian1DPartitioning, SomeVoxelMethod> VoxelGrid;

See it running here.

Start with the linked PR comment and the proposed pcl::experimental::VoxelGrid design in this issue. Review the existing VoxelGrid and PointCloud2 support before deciding how partitioning and voxel methods should be separated. Done requires an agreed design for the rewrite, deprecation or conversion handling, and a sequence of independently mergeable changes.