Open whitefractal opened 1 year ago
Yeah, we should definitely support 3-4D transforms, it's just a question of API design.
I agree but I don't have time, so (and I mean this in the most constructive way) if you want it, you'll almost certainly have to write it.
I have a fork that I adapted for 3D coordinate conversion, specifically, because I needed to reproject to ECEF @whitefractal .
Here is the proj.rs fork. Here is an example how I use it.
In my adaptation, I did the minimum necessary for my use case. However, because the current Coord is 2D only, I'm not sure if adding additional members (eg z
), would break anything downstream. What do you think @lnicola @urschrei ?
But if you don't see big hurdles in the API, I'll implement the 3D across proj and send a PR.
Proj::convert
assumes 2D coordinates, and passesz: 0.0
intoproj_sys
(which handles 3D just fine).This is insufficient for conversions to/from (e.g.) ECEF coordinates, where the z coordinate is critical even for locations on the ground.
Then need to access the private
c_proj
makes it impossible to define a trait with a minimally-modifiedconvert
method which takes a 3D point, passes all three values in/out of proj_sys, and returns a 3D point.Some provision for 3D coords within this crate would be extremely helpful please :-)