At Kraken Robotics, we take a similar approach to what @rolker described. We define the following frames in an attempt to comply with both REP103, REP105 and SNAME conventions.
The frames suffixed by _ned are pretty self-explanatory and are connected by static transforms from ENU to NED in the above image. As for the base_link_app, the static transform from base_link to base_link_app is defined in the robot’s URDF along with all the other static and dynamic transforms (robot_state_publisher and joint_state_publisher can be used to keep such body-attached transforms updated in the TF tree)
The _app suffix stands for application since this frame is supposed to be the main target for the nodes of a given application case, ours being underwater robotics and, consequently, following the SNAME convention (forward-starboard-down).
If the relevant GNC (guidance, navigation, and control) nodes have expected frame_ids as parameters, one could both transform incoming data (if needed) and automatically compute intermediate transforms to broadcast and update the TF tree. For instance, broadcasting the intermediate odom->base_link knowing actually odom_ned->base_link_app (odometry component) and/or broadcasting map->odom knowing actually map_ned->base_link_app (localization component).
Regarding earth->map, there is an interesting open thread that is more general (not maritime-related) but from which this discussion may leverage, it also contains a nice proposal from Polymath Robotics.