It’s a fun one!

It seems your two spacecrafts are tightly bound together as if it was a rigid pair. Perhaps they follow each other on the same orbit, one being about 12km in front of the other one?

What we observe here is that the relative velocity of one satellite with respect to the other one *expressed in inertial frame* is exactly compensated by the rotation rate of the local orbital frame. This means that as seen from one satellite, the other one is always in the same position (they form a rigid pair, at least at this time). I doubt this is by chance and guess the pair as been configured as is on purpose.

When we compute the transform from inertial frame to local orbital frame, we take into account the frame position and velocity, the frame orientation, but also the frame rotation rate, so when we convert the coordinates of a moving point that act in fact as if it was a rigid body, we get zero relative velocity.

This is the same thing that we observe when we convert the position-velocity of a perfectly geostationary satellite in Earth frame: despite the satellite has a non-zero velocity in inertial frame, it has zero velocity in Earth frame because it does not move with respect to Earth frame.

The fact that `Transform.transformPVCoordinates()`

applies velocity composition ensures that the result has consistent derivatives, i.e. that the derivative of transformed position is the transformed velocity (which is logical if you consider the geostationary satellite in Earth frame: its position is fixed in Earth frame, so its velocity is zero).

So what is really the velocity you want? There can be several choices, and several ways to achieve them.

If you want the inertial velocity just rotated to project it into local orbital frame but explicitly ignoring all velocity composition (i.e. ignoring both frame velocity and frame rotation rate), then the proper way is to not call `transformPVCoordinates`

but call `transformPosition`

for the position vector and `transformVector`

for the velocity vector as it just applies the rotation part. In this case, you will get the following velocity: (-13.2865009782; -7612.5965756968; -0)

If you want something very special like taking into account the frame velocity but *not* the frame rotation rate, then you could dissect the transform and rebuild it without the rotation rate, as follows:

```
Transform rebuilt = new Transform(transform.getDate(),
new Transform(transform.getDate(),
transform.getCartesian()),
new Transform(transform.getDate(),
new AngularCoordinates(transform.getRotation(),
Vector3D.ZERO)))
```

Then you will get the following velocity: (-13.286500978196113, 0.011594662351892993, -5.773159728050814E-14).

However, I really am not sure about the physical meaning of the second option. Taking just some of the derivatives but not others seems weird to me.

Also note that in both cases, as long as you ignore at least some derivatives in the transforms, the derivative of the transformed position is not the transformed velocity: they are not related anymore.