grid_map_demos appears to use filters directly without declaring it in package.xml

[Plumezz]

Summary

While reviewing ROS 2 package dependency metadata, I noticed that grid_map_demos appears to use filters directly, but filters does not seem to be declared in grid_map_demos/package.xml in humble branch.

The package declares higher-level grid map packages such as grid_map_filters, which appear to make filters available transitively.

Evidence

Direct usage

grid_map_demos directly includes filters headers:

• include/grid_map_demos/FiltersDemo.hpp:15: #include <filters/filter_chain.hpp>
• src/normal_filter_comparison_node.cpp:7: #include <filters/filter_chain.hpp>

The implementation uses filters::FilterChain<grid_map::GridMap> for filter-chain demos.

Current package.xml

I could not find a direct declaration of filters in grid_map_demos/package.xml. The package declares grid_map_filters, which likely provides filters transitively:

<depend>grid_map_filters</depend>

Observed during build/test

During build tracing, files from filters were accessed, for example:

• share/filters/cmake/filtersConfig.cmake
• share/filters/cmake/ament_cmake_export_include_directories-extras.cmake
• share/filters/cmake/ament_cmake_export_targets-extras.cmake
• share/ament_index/resource_index/package_run_dependencies/filters

Transitive path

The dependency appears to be reachable transitively through paths such as:

grid_map_demos -> grid_map_filters -> filters
grid_map_demos -> grid_map_cv -> filters

Suggested fix

If filters::FilterChain is a direct dependency of the demos package, would it make sense to add:

<depend>filters</depend>

Notes

This issue is not claiming that the package currently fails to build. The concern is that the package directly uses filters while relying on a transitive dependency path to make it available. The observation is based on package metadata, source usage, dependency closure analysis, and build/test file-access tracing.

Could you please confirm whether this dependency is intentionally left implicit through the transitive dependency path shown above, or whether adding an explicit dependency to package.xml would be appropriate?

I would be happy to open a small PR adding the dependency if that matches the intended package metadata.