Closed busstoptaktik closed 1 year ago
I would expect a basic API like
for coord in mygeom {
let (x, y) = transformer.transform((coord.0, coord.1));
// ...
}
which returns transformed coordinates as a copy. Would the trait API be more efficient in transforming a list of coordinates, or is the goal to support transforming geometry coordinates in-place?
The latter case would probably look like
transformer.transform_all_coords(mygeom);
Fore me personally, the single coord API would be good enough.
Time to reconsider this, given https://github.com/georust/geo/issues/901 and https://github.com/georust/geo/issues/898
Closed with the merging of CoordinateSet #40
Problem
Currently, Rust Geodesy forces input data to be in the form of a slice of
CoordinateTuple
s, which really is forcing the coordinate representation conventions of the library on to the application code calling it.In PROJ, I eliminated this unfortunate characteristic in 2017, by introducing the
proj_trans_generic(...)
function in the 4D API (cf https://github.com/OSGeo/PROJ/pull/530).With Rust having much better support for generic programming than C, one would think that it would be possible to do something better in the case of Rust Geodesy. I believe the demo code below shows that this is actually the case.
Solution
Essentially, we do four things:
Coord
, formerly known asCoordinateTuple
:CoordinateTuple
trait, describing anything that can be both constructed from aCoord
, turned into aCoord
, and copied:CoordinateSet
trait, describing a set of any kind ofCoordinateTuple
s. HereCoordinateSet
refers to the ISO19100 concept of coordinatesets, i.e. a collection ofCoordinateTuple
s, all of the same base type.CoordinateSet
s, rather than slices ofCoordinateTuple
sConclusion
With this done, users of Rust geodesy may implement the two tiny traits above, for their particular data type, and RG will automagically support that type.
The code below includes two examples:
I believe the demo suggests that this will make Rust Geodesy much more generally useful.
Demo