thareUSGS
commented
10 months ago Just to ping this issue.
This is an interesting issue which really to me has always been an ISIS implementation quirk. First David is correct that it has always been extremely confusing that setting Mars (which in ISIS defaults as an ellipse) using an ISIS "spherical" projection (like Sinu) that an ellipse is maintained in the label. This has caused us to implement external work-arounds to deal with this quirk in libraries (e.g., GDAL) and exported PDS labels (e.g., HiRISE).
In summary, for this issue, I would be fine that when using a spherical projection, that a sphere is defined in the output cube label.
P.S. -- additional thoughts
- This update is not backward compatible and could be a surprising override for existing users. Thus I'm not sure how to announce any radius override to the user during an ISIS run like cam2map...?
- Like the HiRISE PDS label, which does list a sphere in the output label, ISIS could also do the same. The additional quirk here is that HiRISE uses a spherical equirectangular projection with a local calculated sphere (based on the CenterLatitude -- really called the standard_parallel_1, where the scale of the projection is true). So, if an elliptical Mars is sent to cam2map, internally within the projection, a calculated local spherical radius is used by ISIS. That is fine, but the method to calculate that local sphere is different in ISIS when using planetographic or planetocentric latitude system. Most external applications will assume the "ographic" local radius calculation (if it sees a defined ellipse in the label). Thus for the HiRISE PDS label, which uses an ocentric latitude system, the HiRISE Team explicitly lists the ISIS-calculated local radius as a sphere in the label. Thus for this projection, we can't just assume that the semi-major radius is used, and I guess that calculated radius could be written as a sphere in any output cube.
- In ISIS, many bodies default to a triaxial body (e.g., Io). That is good for initial calculations in ISIS, but not for map projections. Most map projection in ISIS are spherical, a few elliptical, but none use a triaxial map projection. The IAU working group, currently led by B. Archinal, define a best-fit mean sphere for these triaxial bodies. It would be nice to eventually have that option in ISIS to use the IAU-defined best-fit sphere (from the IAU report, https://doi.org/10.1007/s10569-017-9805-5 ). Currently it is left up to the user to understand how to implement that spherical override.
dpmayerUSGS
github-actions[bot]
ISIS version(s) affected: 3.0+
Description
After some discussion with @dpmayerUSGS, it seems like some projections in ISIS that project assuming a spherical body should not be able to project to planetographic latitudes when equatorial radius and the polar radius are not equal.
For example if you look at the math for the sinusoidal projection in ISIS and compare it to the math found in Map Projections- A Working Manual by John Synder (where the sinusoidal information can be found on page 243), the math uses the model for a sphere. There is a model for an ellipsoid but ISIS doesn't support it.
As a result it seems like a user should not be able to define a planetographic latitude option for sinusoidal projection, especially if the equatorial radii and polar radii are different. Fundamentally, if your radii are the same you can specify either, but if they are different you also need to project assuming an ellipsoid rather than a sphere.
How to reproduce
There is no error to reproduce and ISIS accepts the planetographic option for sinusoidal maps, but your latitude will be off given any projection in ISIS that assumes a sphere. It will end up squishing your map based on the polar radii.
Possible Solution
Ideally, for projections that assume a sphere we should either update the radii on the mapping group or enforce the projections that assume as sphere use the planetocentric latitude rather than the planetographic latitude regardless of what the user requested.