From a recent email, I tried to explain our current GDAL/PROJ implementation (and workarounds) for supporting “geocentric” latitude systems in commonly used mapping applications. Why – in general, many applications still assume a more typical “geographic” latitude system.
History: More than 20 years ago, Mars data sets started to be released using geocentric (aka planetocentric, aerocentric, or just ocentric) latitude systems. Unfortunately, this continues to be confusing on what are the best practices for ocentric latitudes. Below I try to summarize how GDAL manipulates map projection definitions for ISIS2/3, PDS4, and VICAR formatted files. This topic is being raised again as our ability to define different latitude systems inside newer map projection definitions are starting to be available.
Goal: Dropping multiple data sets into a mapping application will correctly overlay (as released by different facilities or from online streaming services). Really, the hope is that you don’t need to worry about what is described here. This doesn’t resolve any inherit pointing offsets if the data sets have not been controlled to each other or a common base.
RECOMMENDATON: To really help with data interoperability for mapping applications, I still highly recommend the use of the IAU mean/best-fit sphere. The use of a sphere in a Cartesian 2D/2.5D map projection can help all these issues go away. For best-fit spheres, see: IAU Publication (paywall, PDF), IAU codes (LPSC 2025 abstract, registry)
Current GDAL implementation (for better or worse). Again, this is really meant for ISIS3, VICAR, and PDS map projected files:
-
Because ISIS uses a spherical equation for the below list, we force GDAL to use the semi-major radius as a sphere. Actually, lots of mapping applications default to a sphere for these projections. Note that I didn’t implement the VICAR driver in GDAL, but I think it follows the same rules.
- if SIMPLE_CYLINDRICAL, EQUIDISTANT, ORTHOGRAPHIC, STEREOGRAPHIC (not at the pole), or SINUSOIDAL, then set the semi-major radius as a sphere.
-
For Equirectangular, ISIS also uses a spherical equation BUT using a calculated local radius based on the standard_parallel (aka scaling latitude). This seems to be calculated differently than other applications, so we calculate this local radius in GDAL and force a sphere.
-
If stereographic (at the poles 90/-90) or polar stereographic
- if ographic, use ellipse (pass-thru semi-major and semi-minor radii)
- if ocentric, set semi-minor radius as sphere
-
For everything else in ISIS (Mercator, Transverse Mercator, Lambert Conformal, etc.)
- if ographic, use ellipse (pass-thru semi-major and semi-minor radii).
- if ocentric, then set the semi-major radius as a sphere.
Summary: There could be some unknown issues using the settings above (even though this was implemented almost 20 years ago for ISIS2 and then ~15 years ago for ISIS3). I am fine hearing about any issues or concerns so we can update for future uses and applications.
Lastly, to help interoperability – besides recommending a spherical body, I also shy away from using elliptical-enabled map projections like Transverse Mercator and Lambert Conformal opting for more simple projections like Simple Cylindrical, Sinusoidal, and Orthographic. Equirectangular has its own special issues, but we commonly use that projection. To minimize distortions for a local area, a centered Orthographic or a centered Equirectangular can be used. Other projections like Azimuthal Equidistant can also be used, but many of those projections are not available in ISIS3. To see what map projections are available in ISIS3 see.