# Way to describe a coordinate system without external points of reference?

I'm writing an API for a JavaScript library to let my users offset an object from another.

I have to provide my user with a way to describe a "vertical" and "horizontal" offset.

My problem is that I don't have any point of reference except for the very same position and orientation of the said objects.

In the above example, I have two blocks that face themselves, and the green one is offset from the yellow one by 60 on the Y axis, and 40 on X.

I can't describe this as:

``````{
x: 40,
y: 60,
}
``````

Because if the blocks are rotated together by 90 degrees:

I would have to invert the axes, and my users really just want to express the "distance between them" and the "distance between their bottom edge" (bottom in this example, it may actually be "right" or "left" or "top" if rotated differently).

I need a way to describe the distances so that they don't need to be changed if the boxes rotate.

What's a good way to describe these two distances?

• How are the boxes rotated when the user enters the data? If the orientation is random even then, since they are oriented, you can simultaneously show another view with them rotated to a preferred frame for the purposes of data entry, so that they can enter the x-offset and the y-offset. Internally, just store these as (x, y), and a rotation, and transform the coordinates on the fly when required (e.g., compute a 2D rotation matrix, and multiply; think of it as local space coordinates and world space coordinates, like in games and 3D software). – Filip Milovanović Feb 18 at 9:11
• @FilipMilovanović the user doesn't see anything, it's a software API (via JavaScript), I'll update my question to make that clear. – Fez Vrasta Feb 18 at 17:31
• "I need a way to describe the distances" - do you mean a way to represent them in code (in which case `x, y, rotation` will work), or do you mean you need some alternate words that are more general, to use in the API? And if the latter, given that the users don't see anything, why horizontal/vertical or x/y do not work for you? Specifically, how and when rotation comes into it, and in what way that may cause confusion to the consumers of the API (how is the rotation relevant to them)? – Filip Milovanović Feb 18 at 18:58
• @FilipMilovanović user has no knowledge about the rotation, they know just about the initial rotation they provide. The code then rotates the blocks automatically based on some environment conditions. But if they want to programmatically change the rotation I don't want them to also update the X and Y. So, if one starts with a 90deg rotation, and then moves to 180deg, I don't want the user to think about changing the offsets order – Fez Vrasta Feb 18 at 23:23
• As I've been saying, just store the original offsets (x, y) and also (separately) the original rotation (if you don't consider it to be zero initially or if it cannot be otherwise infered from (x, y)), and then have another variable that stores the current rotation. Never update the original data automatically, just the change the rotation, recalculate (x, y) on each change and pass that to whatever code needs it. Only update the original offsets when the user programmatically changes them (since you've stored the original frame, they (and you) don't have to think about the current state). – Filip Milovanović Feb 18 at 23:37