You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
@assertcstrip(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)).
The text was updated successfully, but these errors were encountered:
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.
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).
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.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))
.The text was updated successfully, but these errors were encountered: