Dear all,
when dealing with Earth coordinates Astropy uses liberfa, in particular using the standard spheroids defined in src/eform.c.
As a starting point for an implementation of planetary body-fixed coordinate frames in astropy, I would like to make a list of historical and current planetary spheroids so they can be added in erfa. I’m only considering rocky bodies for which an acceptable spheroidal description has been used until now.
I’m planning to use the SPICE kernel file pck00011.tpc for the last version of the spheroids (2015 right?)
I would be grateful if someone here could be able to confirm / complete the additional spheroids used for planetary imagery projection.
Mercury : IAU_2009
Venus : Magellan data are reprojected on a sphere of radius 6051.0 Km, while the current standard is 6051.8Km. Is the Magellan datum corresponding to a previous IAU standard?
Mars : if I understand correctly current values are still the IAU_2000 values? Is it worth it to add previous spheroids / spheres for historical reasons?
Moon : it looks like the sphere of radius 1737.4Km is the only datum used for projections?
Satellites and small bodies (only non-triaxial ones), I guess it could be enough to define their datums as IAU_2015?
In general, the best references for historical datums will be the IAU WGGCRE Reports. I think I have PDFs of all of the reports going back to 1980 if you can’t find them online. The most recent report is Archinal et al., 2018. Non-paywalled link.
See Tables 4 and 5 for the current IAU-reccommended radii for the planets and their satellites.
PCKs from NAIF don’t always contain values from the most recent IAU reports. Also, sometimes the radii change in the reports, but not the pole position/rotation terms, sometimes the opposite is true, sometimes both radii and pole position/rotation terms change for a body. It just depends. It’s inadvisable to to mix a pole position from one report with radii from another.
The mnemonics that are sometimes used for the datums (“IAU_2009”, “IAU_2015”, etc.) confuse me. @thare can explain those better than I can. If you’re working with SPICE kernels, what matters are the numerical values.
Venus: Yes, most map-projected Magellan products were created using the then-standard radius. The recommended radius value has been updated since then.
Mars: Yes, the radius values have remained unchanged since Seidelman et al. (2002). These are unlikely to change until we send another laser altimiter to Mars.
Moon: The first few IAU working group reports specified 1738 km for the moon, but the recommended value was refined to 1737.4 km in Davies et al. (1989) and has remained unchanged since then.
I agree with David here. We are suppose to all follow the IAU reports (including NAIF and their updates to SPICE *.tpc kernels). Unfortunately, there is no easily parsed table or data file generated along with IAU report. I would love to see this changed in the future (meaning along with the report publication, also support an updated table housed somewhere which could be used for your purposes).
The IAU_date has definitely been a point of confusion. My intent was that the date is based on the title of the IAU report (not the actual publication date!). So for the IAU_2000 values were to be based on:
P. K. Seidelmann (Chair), V. K. Abalakin, M. Bursa, M. E. Davies, C. De Bergh, J. H. Lieske, J. Oberst, J. L. Simon, E. M Standish, P. Stooke, and P. C. Thomas (2002). “Report of the IAU/IAG Working Group on Cartographic Coordinates and Rotation Elements of the Planets and Satellites: 2000,” Celestial Mechanics and Dynamical Astronomy, 82, pp. 83-110. Available from Springer Link. ADS Services.
And the IAU_2015 values based on:
B. A. Archinal (Chair), C. H. Acton, M. F. A’Hearn, A. Conrad (Acting Vice Chair), G. J. Consolmagno, T. Duxbury, D. Hestroffer, J. L. Hilton, R. Kirk, S. A. Klioner, D. McCarthy, K. Meech, J. Oberst, J. Ping, P. K. Seidelmann, D. J. Tholen, P. C. Thomas, and I.P. Williams (2018). “Report of the IAU Working Group on Cartographic Coordinates and Rotational Elements: 2015,” Celestial Mechanics and Dynamical Astronomy, 130:22, doi: 10.1007/s10569-017-9805-5. Available from Springer Link., ADS Services., Astropedia
Note all the IAU reports are currently summarized from this IAU page.
So there is one other “major” issue that we tried to tackle from a cartographic (mapping) perspective. I am referring to the small subset of IAU coded values for OGC web-services and as implemented in PROJ (thus GDAL/QGIS). Paper is forthcoming, but all we have is this abstract for now (note the listed codes wrongly set the “version” to 2018). Feedback is always welcome for any of this.
Problem: While the *.tpc SPICE kernels correctly list the full definition for the defined body (many times a triaxial definition), current SPICE kernels (or even cartographic/mapping applications like ISIS) do NOT list the IAU-defined best-fit mean sphere.
Summary introduction – for a triaxial body, the IAU defines a best-fit mean sphere which is recommended for producing map-based products (image mosaics, DEMs, geologic maps). This is not always a static equation which can be simply generated from the 3 axes. Using a sphere (for a triaxial body) is essentially required for interoperability for map projected data. I’m not saying the triaxial definition can’t be used for initial calculations, but when a derived, map projected, product is released, it should be set to the IAU-defined mean radius. Mars is unfortunately a special (historical) case as alluded to in the original post.
One attempted solution: First, share a machine-readable table/file with the community which lists the IAU original triaxial and the best-fit mean sphere. This table is currently housed (just for the IAU 2015 report) here on GitHub and in the PROJ repo. When the IAU releases a new report, add to a known site with a new table, and implement a new version of codes. With time, it would be great to have all the previous IAU reports as a table like this for historical uses. Second, map the most used projections (for web services) to a subset of “IAU projection codes” following other coded systems like EPSG. I have always disliked these coded systems, but passing large WKT-projection strings for web services has always been frowned upon. The GMAP Team has a good summary page for references.
Overall summary. Unless we update SPICE kernels with the IAU-defined mean radius, I don’t think we can use those kernels alone (at least for some mapping purposes). It might need to be a mix of the *.tpc and GitHub table which does have the IAU-defined mean-radius listed. Again, even ISIS doesn’t list that mean radius value anywhere. Unfortunately, the GitHub table doesn’t have everything one might need either as available in the kernels (e.g. W0). Others have attempted to tackle this issue, but perhaps a new set of machine-friendly tables can be maintained under something like PlanetaryPy which lists everything reported by the IAU publications.
Keeping in mind that the final goal is to directly read via astropy the [ABC]_RADIUS keywords defined here, I think a good path forward is to make a selection of the most used ellipsoid for now, thanks to your references (by the way this is what is done for the Earth in liberfa, not all the ellipsoids are available).
If you don’t mind I will link this discussion when offering the pull request.
Thanks!
The IAU values are not up to date, so I wouldn’t use them for science (but of course you should be able to access the them in any database, and these values might be needed for historical image projections). Also, for most terrestrial planets, the reference ellipsoid is a sphere, and you really only need the mean planetary radius. For the slowly rotating objects, the natural topographic variations are greater than any expected hydrostatic flattening.
The best values for the reference shapes of Mercury, Venus, Mars and the Moon can probably be found in Wieczorek (2015, Gravity and topography of the terrestrial planets, Treatise on Geophysics, second edition, vol. 10, 10.1016/B978-0-444-53802-4.00169-X). In these, I have either constructed new spherical harmonic models of these bodies using the latest topographic datasets, or used previously published models if they didn’t need to be updated. The “degree 0” term of a spherical harmonic expansion is simply the mean planetary radius.
Here are some numbers
Mercury: 2439.372 km
Venus: 6051.878 km
Mars: 3389.500 km
The Moon: 1737.151 km
Mars is the only flattened object, and there is a paper that made a reference ellipsoid that minimized deviations with respect to the geoid: Ardalan A. A, R. Karimi, and E. W. Grafarend (2010). A new reference equipotential surface, and reference ellipsoid for the planet Mars. Earth, Moon, and Planets, 106, 1-13, doi:10.1007/s11038-009-9342-7.
They give:
flattening, f : 0.005227617843759314
a: 3395.4280
b: 3377.678
Them are fighting words and not a very productive suggestion (please mind the young readers). Cartography is often based on comparing your results with previous knowledge and a lot of science can be done by putting new measurements into maps using the same old wrong value that was used for maps in wide distribution. One just needs to keep in mind how to apply these maps.
That DOI doesn’t resolve at doi.org? Some kind of “CORS error” at Springer.
Good answer :-). But seriously, I almost dipped my toe into other known issues with updated size definitions that are found/used in the community but not yet approved by the IAU (or updated in SPICE kernels). Along with your new updates, there are plenty of other recent examples for needed body updates born from global network solutions (Mercury, Europa) to updates derived by activate missions. Better data, better models, will often result in better size definitions. This issue here is the delay in pushing this into the IAU report and then SPICE kernels (which we sort-of just need to accept or deal with). When a map/data is released using the latest and greatest whatever, it is critical to make sure the end-user knows (e.g. metadata, labels, docs, paper, all of the above).
The IAU working group relies on the community for updates (which are reviewed by the working group before acceptance and publication). The goal is for a new IAU publication is ~3 years but often that time-frame can easily double. Note that many on the working group volunteer their time.
Thus, if you have solid research that updates the size or other aspects of a body definition, that should be widely used by community members, that information needs to be sent to the IAU WGCCRE for review and potential adoption.
Lastly, there is a strong case (for interoperability) to maintaining and using an approved and standardized body size for mapped/projected data that is widely used across the community (even if not the latest and greatest).
@mark-wieczorek I hear you!
However, liberfa is a library derived from SOFA explicitly implementing IAU standards. Adding non standard models to their headers is not an option.
Also those standards are useful when using archived data.
That said, having the three radius explicitly described in metadata (like PDS does) with custom values and being able to process the data accordingly should be the goal… this will take a bit more time…
The last IAU report Archinal et al., 2018 states:
“The distinction of a reference radius for a body (here, the Moon and Titan) is made between cartographic uses, and for orthoprojection and geophysical uses.”
A step in your direction?
The numbers that the IAU are using aren’t too different from those based on the most recent datasets and analyses
Archinal et al. (2018)
Mercury: 2439.4 ± 0.1 km
Venus: 6051.8 ± 1 km
Mars: 3389.50 ± 0.2 km
The Moon: 1737.4 km (no uncertainty)
Values computed or tabulated in the Wieczorek (2015) review
Mercury: 2439.372 km
Venus: 6051.878 km
Mars: 3389.500 km
The Moon: 1737.151 km
The biggest difference is for the Moon, and this has been known since the Clementine mission.
In any case, assigning error bars to these numbers is complicated. We have tons of measurements, so the uncertainty in the laser/radar shot should go towards zero, but there are data gaps and uneven sampling that are more difficult to quantify.
I’ll contact Brent Archinal about this, because the Moon value has been bothering me for some time!
Struggling in manually parsing the openly available standard papers right now…
I’m wondering if the Strasbourg astronomical Data Center would be able to provide a service connecting a csv to each report containing the standard parameters for each body.
They already have the infrastructure, as they provide catalogs related to publications.
Is someone from CDS on this forum?
If it helps, several EPN-TAP services provide such information : Planets, and the brand new MoonsProp service for natural satellites. All declared in the IVOA registry, and accessible via the VESPA portal https://vespa.obspm.fr/
Planets may be a bit behind. We welcome contributions to the content.
