Thanks for the clarification, I see what you mean now.
So the problem, as I now understand it, is you’re reconstructing
assigned_point_feature two different ways and getting two different results. I had previously thought you were comparing reconstructions of
assigned_point_feature (containing present day geometry) with reconstructions of
point_feature (containing geometry already reconstructed to 130Ma). But that’s not the case here.
In that case, I think the problem is due to plate
926 having a non-zero rotation at present day (relative to anchor plate 0). And since you are explicitly specifying a
rotation_angle = rotation_model.get_rotation(time, pid, 0, 0)
…(ie, the first
0) then the non-zero present day rotation is excluded from the returned rotation. In other words, it’s returning the rotation of plate
926 at 130Ma relative to 0Ma (which excludes the fact that the geometry stored in your feature also undergoes a non-zero rotation just to get to 0Ma).
Instead try using:
rotation_angle = rotation_model.get_rotation(time, pid)
…and see if you now get the same reconstructed results.
The reason for this distinction is explained at the bottom of RotationModel.get_rotation() in the following note:
from_time to zero can give a different result than not specifying
from_time at all if the moving plate (or fixed plate) has a non-zero finite rotation at present day (relative to the anchor plate). However all present-day finite rotations should ideally be zero (identity), so typically there should not be a difference.
…and so it’s probably better to avoid non-zero present day rotations whenever possible as it usually leads to confusing results.
The above note assumes you’re using the latest pyGPlates public release (revision 28) which introduced that distinction to avoid inconsistencies that started appearing whenever there were non-zero present day rotations.