Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add local coordinates #48

Open
ettersi opened this issue Mar 26, 2024 · 2 comments
Open

Add local coordinates #48

ettersi opened this issue Mar 26, 2024 · 2 comments
Labels
enhancement New feature or request feature

Comments

@ettersi
Copy link
Contributor

ettersi commented Mar 26, 2024

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
Copy link
Member

juliohm commented Mar 26, 2024

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
Copy link
Contributor Author

ettersi commented Mar 27, 2024

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request feature
Projects
None yet
Development

No branches or pull requests

2 participants