Closed Rennzie closed 10 months ago
I decided skipping the "anything allowed" approach of PROJ in favor of the (I believe) "only a and rf" dogma of EPSG, since "if it does not appear in practice, no reason to support it" - or at least that was my bad excuse. Really I just had to shoehorn and cut down to be able to get to a 80% solution in 0.1% of the time.
The workaround is to use the "a,rf" syntax for ellps, i.e. ellps=6378249.145,293.46
in your case. This is handled by Ellipsoid::named()
.
The all-encompassing solution would probably either be rather intrusive, probably starting somewhere like here, or be based on additional pattern recognition in the parse_proj()
function, scanning for all valid PROJ ellipsoid definition tokens, and translating them into a ellps=a,rf
pair.
Note, however, that PROJ's interpretation of redundant ellipsoid specifiers may be surprising - e.g. the combination ellps=GRS80 a=1
results in the instantiation of an ellipsoid the shape of GRS80 but with a size of unity. If you decide to give it a try, also consider doing a bit of work documenting known (and potentially unknown) differences: parse_proj
is horribly underdocumented (totally my fault)
Ok thanks for the guidance @busstoptaktik. I'll have a think and give it a whirl as time permits.
While testing various output from
projinfo
I've come across an example where the ellipse is described in terms ofrf
anda
parameters instead ofellps=<name>
. For example a transformation between EPSG:2001 and EPSG:3857 looks like:When converting the same coordinate with PROJ and RG I get differences in the order of 10's of meters. The
a=6378249.145 rf=293.465
parameters describe theclrk80
ellipse, so if I update both pipelines to useellps=clrk80
instead of usinga
andrf
the results are the same.The question is, should RG be able to handle ellipse input via the
rf
anda
parameters? If yes, I'm happy to attempt a PR with some guidance on where to do this and what else needs to be covered.