search

DOI-USGS / ale

Abstraction Layer for Ephemerides (ALE)
Other
13 stars 33 forks source link

Define the use of Mars as Sphere #480

Open thareUSGS opened 2 years ago

thareUSGS commented 2 years ago

As described in this RFC, we plan to transition stereo-processing in SOCET SET/GXP to "1. Initialize projects in SOCET SET using the IAU-recommended sphere for Mars (radius = 3396190 meters)" and a couple other updates as described here: https://astrodiscuss.usgs.gov/t/appl-rfc-use-iau-sphere-for-hirise-dtm-projects-in-socet-set/428

BTW, one additional benefit not described in the RFC, is that we will not need to support the various ocentric/ographic jumps to properly support SOCET. Our current workflow, requires ocentric -> ographic -> ocentric transformations during our full stereo workflow as SOCET only recognizes ographic latitudes. Using a sphere, removes this burden (and data resampling).

So as we test ALE-generated metadata (ISDs) for usgscsm (in GXP), the current ISDs for all Mars (HiRISE and CTX) are defined using the default Mars ellipse which is listed as '"radii": {"semimajor": 3396.19, "semiminor": 3376.2, "unit": "km"}'. I assume the defined ellipse may also be impacting the ISD calculations.

For ISIS's spiceinit, I believe a simple update to Mars within pck00009.tpc should help to define Mars as a sphere. For ALE, I am not sure how to override these Mars defaults. Perhaps updating the same file with the NAIF kernels? But if the kernels are within a common area read-only area, can I update the path to the pck file? Or do I need to copy all the kernels and update the kernel path to grab the updated pck file?

I hope this question makes sense? Now, if there is not an easy way to point to an updated pck file (outside the main generally read-only kernel data area), I guess this could be considered as an enhancement request to allow for a pck/radius override.

jessemapel commented 2 years ago

The body radii are pulled in from the PCK or the ISIS cube depending on how you are using it. Making sure that your data sets are consistent is outside the scope of ALE. So, I'm going to say we don't make any changes in ALE and instead recommend some actions for users.

  1. If you want to update an existing ISD just modify the "radii" part of the JSON. Change the "semiminor" value to be the same as the "semimajor" value.
  2. If you are making a new ISD, then either add an extra kernel that redefines Mars as a sphere when you specify the kernel set in loads or in spiceinit before you run loads.
jessemapel commented 2 years ago

Had some more discussion this morning and I still think this is outside of what load should be considering because it's a data issue. So, going with 1 about is recommended. I'm going to put in a small PR to modify the generate_isd script with an optional radius override that users can specify that will do this.