Add local coordinates

[ettersi]

It would be great if CoordRefSystems could implement the East North Up local coordinate system.

A major design issue when it comes to local coordinates is whether such coordinates should remember their origin. I would like to propose that in CoordRefSystems local coordinates should remember their origin but the cstrip() function (see #47) should return only the offset, i.e.

x = Cartesian(1,0,0)
y = Cartesian(1,1,0)
@assert cstrip(ENU(x), y) == SVector(1,0,0) # y is one unit to the east of x

This would allow local coordinates to represent a unique point in space just like their global counterparts, and at the same time it would allow the user to easily "relocate" a local coordinate using cwrap(ENU(y), cstrip(ENU(x), local_coord)).

[juliohm]

I remember seeing this nice idea in MapMaths.jl, where you can add angular coordinates to local coordinates in meters to shift a point over a wrapped segment over the sphere.

We plan to add an operation for this instead:

CRS + ENU ---> CRS

It doesn't need to be the + function, it can be a specific name such as shift or move. We will see which properties this operation satisfies before we commit to a particular name/design.

Would that address your original issue?

[ettersi]

Addition would work well this way. How would you handle subtraction or convex combinations? I think defining e.g. CRS - CRS -> ENU is problematic, because some people might instead want CRS - CRS -> WrappingENU or CRS - CRS -> Cartesian (i.e. the difference in an ECEF coordinate system).

[disberd]

I also believe it would be nice to be able to represents different Cartesian CRSs, which are just identified as a rotation and translation w.r.t to a default CRS (which can be simply the Cartesian we have now).

This is something that can be very useful in many applications, and the ENU CRS would be just one possible realizations of this generic "TrasformedCartesian".

It is definitely something I need in my domain as we need to define visibility angles between different targes, each of which has its own diffrent transformed cartesian CRS.

Having a specific CRS with its own translation/rotation associated would greatly simplify ensuring that operations like addition and subtractions are done in the correct reference frame (or automatically applying the transformation embedded in the CRS for operations between different transformed CRSs).

I do understand that this is something that might not be as relevant in geospatial context where most of the time you are just interested in things related to ECEF, but is indeed very relevant when you deal with antennas as usually antenn properties are easily defined with respect to their local CRS which can be arbitrarily rotated/transformed depending on the antenna position and orientation.

I also understand that implementing this in the "right" way is not trivial, especially if the transformation has to be somehow embedded in the type domain (the rotation associated to the ENU CRS depends on the latitude/longitude so you'd have to at least encode that in the type domain for fully typed implementation, which will probably be extreme)

Given the above I also understand if this is considered too much out of scope for this project, but I'd like to keep this discussion open here as well even if just for exchanging opinions and ideas for potential separate implementation I might have to do to accomodate for this :D