Title: Difficulty Inspecting Numerical Data from `/elevation_map` (GridMap) via `ros2 topic echo`

[jj7258]

This is with reference to #1175, When using ros2 topic echo /elevation_map to inspect the grid_map_msgs/msg/GridMap published by RTAB-Map, the output for the data field of the elevation layer often shows a large number of NaN values, particularly at the beginning of the data array. This can be initially confusing for users trying to verify the presence or values of numerical elevation data, as it might seem like no valid data is being published.

While RViz correctly visualizes the map by interpreting these NaNs and rendering cells with valid elevation points, direct numerical inspection of the topic data via ros2 topic echo is challenging for quickly finding actual numerical values. This is particularly relevant for users who intend to consume this elevation data directly for tasks such as analyzing ground surface characteristics, for example, to identify negative obstacles like depressions or indentations in the terrain relative to the robot.

To Reproduce Steps to reproduce the behavior:

1. Run an RTAB-Map session that generates and publishes an elevation map (e.g., with Grid/FromDepth enabled) on the /elevation_map topic.
2. In a terminal, execute ros2 topic echo /elevation_map.
3. Observe the data field within the elevation layer. It will likely display many .nan entries before any numerical values appear, or numerical values might be interspersed with many NaNs.

Expected behavior While NaN values are an expected and correct way to represent unobserved or invalid cells in a GridMap, the user experience for quickly verifying the numerical content of these maps via basic ROS 2 CLI tools could be improved. It would be helpful if:

• There was clearer guidance or a simple utility for users to quickly inspect a sample of actual numerical (non-NaN) data from GridMap topics.
• Users could more easily understand that a large number of NaNs in the topic echo output is normal for this message type and doesn't necessarily indicate an empty map.

Example Log Snippet from ros2 topic echo:

header:
  stamp:
    sec: 1744821000
    # ...
  frame_id: map
info:
  resolution: 0.05
  length_x: 15.2
  length_y: 11.25
  # ...
layers:
- elevation
# ...
data:
- layout:
    dim:
    - label: column_index
      size: 281 # Example value
      stride: 85424 # Example value
    - label: row_index
      size: 304 # Example value
      stride: 304 # Example value
    data_offset: 0
  data:
  - .nan
  - .nan
  - .nan
  # ... many more NaNs ...

Confirmation of Numerical Data (via custom script): A custom Python subscriber was used to confirm that numerical data is indeed present within the same messages:

[INFO] [elevation_viewer]: First 5 non-NaN values found: [-0.317487, -0.30096874, -0.31656173, -0.20199417, -0.31776497]
[INFO] [elevation_viewer]: Their indices in the flat array were: [3284, 3584, 3585, 3587, 3588]

Desktop Environment:

• OS: Ubuntu 22.04
• ROS Distribution: Humble Hawksbill
• RTAB-Map version: 0.21.14

Additional context This issue is not about a bug in the map generation itself (as RViz displays the map correctly) but rather focuses on the usability and ease of direct data inspection for GridMap topics using standard ROS 2 command-line tools. Having straightforward access to the numerical data is crucial for users developing algorithms that directly process these elevation values, such as those for detecting terrain features or ground-level anomalies.

Possible suggestions could include:

• A small utility script provided with rtabmap_ros for pretty-printing a sample of non-NaN data from a specified layer in a GridMap topic.
• Documentation tips on how to effectively inspect numerical data from these topics (e.g., sample Python snippets, RViz cell inspection techniques).

This would help users in debugging, data verification, and better understanding the GridMap message structure for downstream processing.

[matlabbe]

I feel that feature request would be better served in grid_map repo. Maybe by improving the description of the GridMap message, it could already be a step in that direction instead of just "Grid map data."

# Grid map header
GridMapInfo info

# Grid map layer names.
string[] layers

# Grid map basic layer names (optional). The basic layers
# determine which layers from `layers` need to be valid
# in order for a cell of the grid map to be valid.
string[] basic_layers

# Grid map data.
std_msgs/Float32MultiArray[] data

# Row start index (default 0).
uint16 outer_start_index

# Column start index (default 0).
uint16 inner_start_index

We use GridMapRosConverter to convert GridMap internal data to ros topic. Note that when we build the GridMap, we use their API and we don't explicitly set NaN values in the grid, this is handled by their library (I guess it is how they know a cell is valid or not, by checking if it is NaN or not). https://github.com/introlab/rtabmap/blob/105ac3bf9e58776a15cc046da4ae17ee302ce1cc/corelib/src/global_map/GridMap.cpp#L459-L478