[sensor_msgs] Proposal: Add Altitude.msg (scalar vertical position + variance)

Description

Add a new scalar message to sensor_msgs named Altitude.msg, containing a timestamped vertical position z in meters (positive up), with an optional uncertainty. This fills the gap between existing messages that either (a) embed altitude together with latitude/longitude (NavSatFix) or (b) represent barometric pressure or generic ranges rather than altitude itself. The proposed definition mirrors existing scalar messages (e.g., Temperature, Illuminance) that carry a variance field.

Motivation

Many robotics applications need a standardized, timestamped scalar for vertical position (z) that is independent of latitude/longitude. The most common sources are barometric altimeters (converting absolute air pressure to altitude using a reference such as QNH or a locally defined “home” level), radar/laser/ultrasonic altimeters that directly measure height above ground along a downward beam (AGL), and underwater pressure sensors that map hydrostatic pressure to depth; DVLs and single‑beam echosounders also report altitude above the seabed as a single range.
Today these signals are typically published as FluidPressure, NavSatFix, or Range (or as community‑specific messages), which forces consumers to infer semantics, perform conversions, or carry unrelated fields. A minimal Altitude.msg, Header + altitude [m] (positive up, negative for depth) + variance [m²], would let drivers and estimators exchange vertical‑only observations with unambiguous units, frames, and uncertainty, reducing boilerplate conversions and improving interoperability in state‑estimation pipelines.

Why not Range? Range denotes along-beam distance from an active ranger and has different semantics/fields (min/max, FOV, radiation type). Many altitude sources are not active rangers (e.g., barometers), and even when they are (radar altimeters), the semantic intent is “vertical position”, not raw range.

Design / Implementation Considerations

Units & Sign (REP-103): meters, +Z up; negative altitude = depth (explicit in docstring). This keeps consistency with ROS axis conventions.

Uncertainty: follow scalar pattern → variance (float64, m²), where 0.0 = unknown, as in Temperature/FluidPressure/Illuminance.

Frame semantics (REP-105): header.frame_id declares the measurement frame (e.g., base_link, imu_link, map, or earth).

Additional Information

I’m opening this issue to quickly gauge community feedback on adding a minimal, source‑agnostic vertical position message to sensor_msgs; if there is support, I volunteer to author the PR (message and docs)

Start by reviewing the existing sensor_msgs scalar messages named in the proposal, especially Temperature, Illuminance, FluidPressure, NavSatFix, and Range, along with the stated REP-103 and REP-105 considerations. Confirm the proposed fields and semantics with the community; done means agreement on the interface followed by the message and documentation changes described in the issue.