What's going on here is the Y and X coordinates of the observation are stacked together and then transformed to model coordinates. This should probably be better done with two different arrays, one with the 2D coordinates of the Y-axis and one the X-axis, instead of using the diagonal, which is what triggers the error.
This issue is here to document to problem. We could allow for non-square frame in the non-rotated case, but we must assert that the observations are square in the rotated case.
Follow up from #276
The immediately offending line is https://github.com/pmelchior/scarlet/blob/5b0b5e078b8bc183aaa1453255b73f6baa95cef0/scarlet/renderer.py#L274-L275
What's going on here is the Y and X coordinates of the observation are stacked together and then transformed to model coordinates. This should probably be better done with two different arrays, one with the 2D coordinates of the Y-axis and one the X-axis, instead of using the diagonal, which is what triggers the error.
But doing that doesn't solve the problem when the frames are rotated. To go from the rotated to the unrotated coordinates is done here: https://github.com/pmelchior/scarlet/blob/5b0b5e078b8bc183aaa1453255b73f6baa95cef0/scarlet/renderer.py#L322-L329 This requires that both coordinates in
coord_hrhave the same length, i.e. that their frames are square. That's consistent with eq 20 in Remy's paper, where X and Y coordinates also have to be of same length.This issue is here to document to problem. We could allow for non-square frame in the non-rotated case, but we must assert that the observations are square in the rotated case.