The point of navsat_transform_node is to convert GPS data into world-frame coordinates in a nav_msgs/Odometry message. The sensor you are describing is not actually a GPS, and already provides the (X, Y) position of your robot, so just use that data directly as an input to the EKF (i.e., don't bother running navsat_transform_node).
Also, I don't recommend feeding the output of (1) into (2). Just fuse the same inputs that (1) has, and add the input for the indoor GPS sensor.
Remember that you don't want to have more than one EKF input measuring the same pose variable (X, Y, Z, roll, pitch, or yaw).
EDIT 1 to clarify previous answer:
Sure, you can run two state estimation nodes. You can do something like this:
- EKF (odom): fuse wheel encoder odometry (velocities) and IMU
- EKF (map): fuse wheel encoder odometry (velocities), IMU, and the nav_msgs/Odometry message that is being spit out by your indoor "GPS."
My point is that if you had a real GPS unit, the role of navsat_transform_node would be to convert latitude and longitude into a pose that you can fuse into the second EKF. Since you already have the indoor beacons spitting out pose data in a message type that the EKF can take in directly, you don't need navsat_transform_node.
