Spatial transformations

[roaldarbol]

From the meeting with Sofia and Niko, we got a good common understanding of which spatial features are important. Long story short, we use the right-hand rule. We also spoke of the different coordinate systems we might use, the Cartesian systems which can vary by where the origin is and which direction is positive (e.g. computer vision, y has its origin in the top-left, and Y increases downwards).

Coordinate system

We really only have two coordinate systems at the moment; Cartesian (2D/3D) and polar/spherical (2D/3D). So here there should two functions, one for transforming each way between the two (useful link for transformations). There are more types of coordinate systems, but I think they are more esoteric and we can look at such transformations should the need arise. We settled on using right-handed coordinate systems, which I guess is irrespective of which type of coordinate system we use.(?)

Here it's a question whether to keep x and y for polar coordinates + a field in the metadata to know it's polar; or change to r and theta (and phi for azimuth in 3D). I'm not completely set on this yet...

• set_coord_radial(data)
• set_coord_cartesian(data)

Orientation of coordinate system (?)

When we talked about top-left, bottom-left, etc. is there a term for what that is? Is it the orientation of the coordinate system? It's not just the origin, since positive rotation (following the right-hand rule) went in opposite directions for those two - if I remember correctly? So operations in this space would be really be two rotating "the hand", does that sound right?

• set_coord_orientation(data, orientation)

Origin of coordinate system

Luckily, there's also simple stuff. Having a transformation that simply changes the origin would be great.

• set_origin_cartesian(data, x, y, z=NULL)
• set_origin_radial(data, r, theta, phi=NULL)
• set_origin(data, x, y, z, r, theta, phi)
  • Maybe a wrapper function that can contain both of the above.

Egocentric and allocentric (real-world) coordinates

Relevant discussion here: neuroinformatics-unit/movement#239

• set_egocentric_origin(data, keypoints)
  • Question here is whether the user should compute e.g. centroid, or center between two points? I think it would be best for the function to do it automatically. If given 1 point, use that; if given 2 points, use the middle point between them; if given 3 or more points, use their centroid.
• set_egocentric_orientation(data, keypoints)
  • What should the rules be here? A minimum of two points are needed; and when given, we'll need to know whether they are the direction (so direction of the vector formed of the two points should be kept at zero), or perpendicular (so the perpendicular angle is kept at zero).

There's an additional curiosity I've realised: What do we do if there are multiple animals? Then each point will has to have a position on both their own egocentric coordinate system, but they will also exist in the egocentric coordinate system of other individuals. So then the coordinate systemneeds to be included as a data field too. For data with many individuals, this may get unwieldly... needs to be thought through. We can also include individual as an optional field (since I've now made it an obligatory column), so you can restrict yourself to make everything relative to that individual only (and setting e.g. individual="all" would create the unwieldly data; set_egocentric_origin(data, keypoints, individual=NULL)). Maybe this should be restricted to data frames with only a single individual for now?

[roaldarbol]

We got it down to just two functions (!!!):

• translate_coordinates
• rotate_coordinates

They can take a few different input types. rotate_coordinates still need to be implemented.

[roaldarbol]

Alright, now I've also got rotate_coordinates working. I need to figure out whether it needs extra parameters and then it also needs proper testing. I've also made the combined function transform_to_egocentric.