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 <mwtoews@gmail.com>
Preserve title case for BibTeX Co-authored-by: Mike Taves <mwtoews@gmail.com>
| // 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.
There was a problem hiding this comment.
@plouvart gentle ping w.r.t my above question
There was a problem hiding this comment.
Hello @rouault
Sorry for the lack of response over the last few week's. Lots of personal and work related obligations.
I will have time for a closer look at the issue this week end.
There was a problem hiding this comment.
@rouault
I remember that I got the inspiration for the P->right, P->left and P->a lines from the s2 projection file
I didn't know that src/fwd and src/inv does that for us automatically. I can remove those lines.
About the 36843762.068421006 value, it is related to the final scale of the airocean space whose dimensions stays constant whatever ellipsoid model we use (since it all gets normalized to the unit sphere in the end anyway).
Unless I'm mistaken?
There was a problem hiding this comment.
About the 36843762.068421006 value, it is related to the final scale of the airocean space whose dimensions stays constant whatever ellipsoid model we use (since it all gets normalized to the unit sphere in the end anyway).
sounds surprising to me that the extent of the projection is constant and not dependent on the ellipsoid semi-major axis, but I don't know anything about that projection. I guess a could way to check that would be to add round-trip tests with the unit ellipsoid
There was a problem hiding this comment.
I guess a could way to check that would be to add round-trip tests with the unit ellipsoid
That's a good idea. I'll try that
There was a problem hiding this comment.
Round trip tests work when the ellipsoid/no ellipsoid is the same for fwd and inv successively.
Obviously choosing a different ellipsoid model for the fwd and inv model result in a difference.
The dimensions of the Airocean space are determined by the length of the edges of the triangle faces of the icosahedron, which depends on the arbitrary choice of the radius of the sphere it is circumscribed within.
The choice was made to have that scaling factor equals the arithmetic mean radius of the earth, ie. 6,371,008.8 meters.
So it does not mater what ellipsoid model was chosen in the end, because whatever the model chosen, it always gets normalized to a unit sphere as an intermediary step before being scaled to that arbitrary dimension.
There was a problem hiding this comment.
Here's a small sketch I drew to illustrate my point.
blue process is a fwd/inv with +ellps=sphere and red process is fwd/inv with +ellps=GRS80 for instance.
There was a problem hiding this comment.
I still believe there's something wrong related to taking into account ellipsoid characteristics. The value of scale factors compared to other projections seems to be totally off:
$ echo 2 49 | bin/proj +proj=merc -S
222638.98 6242596.00 <1.52134 1.52134 2.31449 0 1.52134 1.52134>
$ echo 2 49 | bin/proj +proj=tmerc -S
146339.48 5431555.61 <1.00026 1.00026 1.00053 0 1.00026 1.00026>
echo 2 49 | bin/proj +proj=s2 -S
0.53 1.05 <0.823654 1.0871 0.895218 15.8914 1.08739 0.823271>
$ echo 2 49 | bin/proj +proj=airocean -S
13269980.92 20976603.56 <5.70685e+06 6.08587e+06 3.46329e+13 5.67366 6.18381e+06 5.60058e+06>
docs/source/*.rstfor new API