[octree] OctreePointCloudSearch<>::getNeightborsWithinRadiusRecursive() requires member that is not apart of OctreeContainerBase

[S1ink]

Describe the bug

pcl::octree::OctreePointCloudSearch<>::getNeightborsWithinRadiusRecursive() was changed in this commit to directly reference the internal vector provided by pcl::octree::OctreeContainerPointIndices using pcl::octree::OctreeContainerPointIndices::getPointIndicesVector(). However, this method is specific to pcl::octree::OctreeContainerPointIndices and not apart of the pcl::octree::OctreeContainerBase interface, therefore other pcl-provided and user-implemented leaf container classes that only implement the pcl::octree::OctreeContainerBase interface are no longer guaranteed to work here.

Context

Using pcl::octree::OctreeContainerPointIndex as leaf container for pcl::octree::OctreePointCloudSearch<>, updating codebase from PCL 1.14 to PCL 1.15.1.

Expected behavior

All pcl::octree::OctreeContainerBase-compliant classes should work with all octree methods, or edge cases should be asserted at compile time.

Current Behavior

Compile error when any octree container that doesn't have const pcl::Indices& getPointIndicesVector() member is used with pcl::octree::OctreePointCloudSearch<> and calling pcl::octree::OctreePointCloudSearch<>::getNeighborsWithinRadiusRecursive() (used in radiusSearch()).

To Reproduce

Instantiate pcl::octree::OctreePointCloudSearch<> with pcl::octree::OctreeContainerPointIndex as LeafContainerT template parameter and call pcl::octree::OctreePointCloudSearch<>::radiusSearch().

Screenshots/Code snippets

In file included from /usr/include/pcl-1.15/pcl/octree/octree_search.h:657,
                 from /mnt/data2/code/lance-ws/src/cardinal-perception/include/modules/map_octree.hpp:53,
                 from /mnt/data2/code/lance-ws/src/cardinal-perception/include/modules/kfc_map.hpp:52,
                 from /mnt/data2/code/lance-ws/src/cardinal-perception/src/core/modules/kfc_map.cpp:9:
/usr/include/pcl-1.15/pcl/octree/impl/octree_search.hpp: In instantiation of ‘void pcl::octree::OctreePointCloudSearch<PointT, LeafContainerT, BranchContainerT>::getNeighborsWithinRadiusRecursive(const PointT&, double, const BranchNode*, const pcl::octree::OctreeKey&, pcl::uindex_t, pcl::Indices&, std::vector<float>&, pcl::uindex_t) const [with PointT = pcl::PointXYZ; LeafContainerT = pcl::octree::OctreeContainerPointIndex; BranchContainerT = pcl::octree::OctreeContainerEmpty; BranchNode = pcl::octree::OctreeBranchNode<pcl::octree::OctreeContainerEmpty>; pcl::uindex_t = unsigned int; pcl::Indices = std::vector<int>]’:
/usr/include/pcl-1.15/pcl/octree/impl/octree_search.hpp:178:3:   required from ‘pcl::uindex_t pcl::octree::OctreePointCloudSearch<PointT, LeafContainerT, BranchContainerT>::radiusSearch(const PointT&, double, pcl::Indices&, std::vector<float>&, pcl::uindex_t) const [with PointT = pcl::PointXYZ; LeafContainerT = pcl::octree::OctreeContainerPointIndex; BranchContainerT = pcl::octree::OctreeContainerEmpty; pcl::uindex_t = unsigned int; pcl::Indices = std::vector<int>]’
  178 |   getNeighborsWithinRadiusRecursive(p_q,
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/mnt/data2/code/lance-ws/src/cardinal-perception/include/modules/impl/kfc_map_impl.hpp:119:60:   required from ‘csm::perception::KFCMap<Point_T, Map_T>::UpdateResult csm::perception::KFCMap<Point_T, Map_T>::updateMap(const Vec3f&, const PointCloudT&, const std::vector<RayDirT>*, const pcl::Indices*) [with int CollisionModel = 5; RayDirT = pcl::Axis; Point_T = pcl::PointXYZ; Map_T = csm::perception::MapOctree<pcl::PointXYZ, 2>; Vec3f = Eigen::Matrix<float, 3, 1>; PointCloudT = pcl::PointCloud<pcl::PointXYZ>; pcl::Indices = std::vector<int>]’
  119 |     results.points_searched = this->map_octree.radiusSearch(
      |                               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
  120 |         lp,
      |         ~~~                                                 
  121 |         this->delete_max_range,
      |         ~~~~~~~~~~~~~~~~~~~~~~~                             
  122 |         tmp_indices,
      |         ~~~~~~~~~~~~                                        
  123 |         tmp_dists);
      |         ~~~~~~~~~~                                          
/mnt/data2/code/lance-ws/src/cardinal-perception/src/core/modules/kfc_map.cpp:26:1:   required from here
  255 |                 const pcl::Indices*);
      |                                    ^
/usr/include/pcl-1.15/pcl/octree/impl/octree_search.hpp:403:49: error: ‘const class pcl::octree::OctreeContainerPointIndex’ has no member named ‘getPointIndicesVector’; did you mean ‘getPointIndices’?
  403 |         for (const auto& index : (*child_leaf)->getPointIndicesVector()) {
      |                                  ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
      |                                  getPointIndices

Environment:

• OS: Ubuntu 26.04
• Compiler: GCC 15.2.0
• PCL Version 1.15.1

Possible Solution

Change should be reverted or OctreeContainerBase interface should be updated to require/support this access method.

[mvieth]

Thanks for the report! Maybe something like the following would work, then we have the best of both:

namespace detail {
  const pcl::Indices& getPointIndices(const OctreeContainerPointIndices& leaf)
  {
    return leaf.getPointIndicesVector();
  }

  template<class T>
  pcl::Indices getPointIndices(const T& leaf)
  {
    pcl::Indices decoded_point_vector;
    leaf.getPointIndices(decoded_point_vector);
    return decoded_point_vector;
  }
}
...
for (const auto& index : detail::getPointIndices(*(*child_leaf))) {

[S1ink]

Yeah that looks like it would work.

As a patch in my usecase I just made a wrapper that returns an std::array with one element for the single-index case, since the problematic segment just needs anything that can be iterated on. It'd be a little more work but if you add another method or few methods to the base container that provide an "iterable" interface then everything would be contained there and not require external adapters. Idk its up to you.

[mvieth]

I opened a pull request with the fix - feel free to take a look. I made the fix slightly more general but did not add an iterable interface to the base container so far (that would require more time to fully think through than I can spend right now, but could still be done in the future).