Add Airocean projection (formerly Dymaxion) #4303
Conversation
… and orientation.
plouvart
changed the title
…on (dym). Remove unused constants. Change sqrtl to sqrt.
|
Seems like cppcheck is complaining about some unused variable, despite the fact that it is used next line. |
|
A few typos in the doc reported in https://github.com/OSGeo/PROJ/actions/runs/11632419978/job/32395481110?pr=4303 . For words which are legitimate and must be allowed, you can add them in docs/source/spelling_wordlist.txt |
|
Thanks for the fix for the out of projection domain error |
| accept 5200000 26800000 | ||
| expect 123.33794956763194 6.861286881197438 | ||
| accept 2600000 22300000 | ||
| expect 147.63769509437498 15.818879769693432 |
There was a problem hiding this comment.
@plouvart could you add a test point that triggers the out-of-projection-domain error ?
There was a problem hiding this comment.
Yes. I'll do that in a few minutes
|
|
||
| Original Reference: | ||
| Robert W. Gray (1995) Exact Transformation Equations for | ||
| Fuller's World Map, Vol. 32. Autumn, 1995, pp. 17-25. |
There was a problem hiding this comment.
| Fuller's World Map, Vol. 32. Autumn, 1995, pp. 17-25. | |
| Fuller's World Map. Cartographica, 32(3), 17-25. | |
| https://doi.org/10.3138/1677-3273-Q862-1885 |
|
@mwtoews I saw your comments. Those fixes seem fair. I'll get on those as soon as a I have some free time |
|
a few extra tests to check the behavior of +orient would be nice |
Tests seem to fail in builtins, but I see no error about airocean specifically. What could be the reason? |
Add complete information about available forms for airocean projection Co-authored-by: Mike Taves <[email protected]>
Preserve title case for BibTeX Co-authored-by: Mike Taves <[email protected]>
| // By default the resulting orientation of the projection is vertical | ||
| // the following transforms are used to alter the projection data | ||
| // so that the resulting orientation is horizontal instead | ||
| constexpr double orient_horizontal_trans[4][4] = {{0.0, -1.0, 0.0, 36843762.068421006}, {1.0, 0.0, 0.0, 0.0}, {0.0, 0.0, 1.0, 0.0}, {0.0, 0.0, 0.0, 1.0}}; |
There was a problem hiding this comment.
Isn't the value 36843762.068421006 specific to the use of the GRS80 ellipsoid ?
And I suspect that P->left and P->right shouldn't be overridden, and P->a not used directly, to let the generic code in src/fwd.cpp and src/inv.cpp do the scaling from the unit ellipsoid to the target one.
docs/source/*.rstfor new API