As far as I know (if this is not correct, please someone point it out), the navsat_transform_node needs an IMU topic since with the GPS you are not able to provide a proper estimation of your orientation. If you take a look in rviz at the odometry provided by a GPS, if you are static, the orientation is just plotted with a directed arrow with random orientation, this is due to the fact that the orientation is calculated taking into account the current GPS position and a random close position. With the IMU you can provide a high precisse orientation information, allowing the localization process to be more accurate.
However, since the nav_msgs/Odometry input messages come usually from EFK or UKF nodes, you can activate the use_odometry_yaw flag to avoid using an IMU topic as input for the navsat_transform_node. Nonetheless, you will have to take into account that this last fussion needs to contain a proper orientation information. As I see, either your odometry contains a good orientation somehow, or you are forced to use the IMU data, either in the fussion process of UKF/EFK or directly as input in the navsat_transform_node.