Update default Moon shapemodel

[rvwagner]

Description

The current default lunar shapemodel in ISIS is... not even remotely the highest quality that is available these days. It's a 128 px/deg DEM from LOLA data only (from very early in the LRO mission, I believe), and has pretty significant interpolation artifacts everywhere but the poles.

The best shapemodel available for the Moon these days is the 512 px/deg SLDEM, which has almost no interpolation issues, and truly does resolve features at that scale. I'm not suggesting that you include the whole 64GB for a global DEM at 60 m/px, but a downsampled version at 128 px/deg would still be a dramatic improvement over the current DEM, and take up no extra space.

Processing

There are a few complications in actually making this DEM:

• The SLDEM only goes to 60° N/S, so you need to splice in LOLA polar DEMs. Fortunately, the most recent 60m/px LOLA polar DEMs go out to 60° N/S, and have no perceptible artifacts.
• If you're enthusiastic, you can also splice in the Improved LOLA south pole mosaic, which probably won't be detectable at these resolutions.
• The current built-in DEM is reduced in size by storing it as 16-bit with a base and multiplier, and makes it reasonably nice to read outside ISIS by using a base of 1737400 (mean lunar radius) and multiplier of 0.5. This quantizes the DTM a bit more than the 32-bit data type does, but is reasonable at this scale (the smallest multiplier parameter we could use is 0.33 without truncating the highest points on the Moon, and 32-bit floating point at the lunar radius is the same quantization as a multiplier of 0.25). Making that scaling is a bit tricky, but the following suffix does it: +16bit+1721024:1753783.5.

Alternately, if this idea is accepted, I have a merged SLDEM+LOLA poles DEM pre-made at 512 px/deg that I can downsample and convert to 16-bit and post somewhere.

[acpaquette]

@rvwagner Thanks for bringing this up! I think it would be a fairly easy add but I would like @lwellerastro and @blandoplanet for comment on any potentially issues

[lwellerastro]

The question of what lunar DEM should be the ISIS default has been an issue for at least decade now. There have been better versions of the DEM for quite some time, but it has not been updated for seemingly political reasons (I guess).

I have never used the default version for any lunar project I have worked on. It has always been a higher resolution version appropriate for the data (e.g. very high resolution polar LOLA DEMs) or currently a merged version of DEMs (either LOLA-LOLA merge or recently SLDEM-LOLA 60m/pix poles merge). I don't think it is appropriate to put my merged version as is in the base directory for a number of reasons.

I would highly recommend including @thareUSGS and @barchinal in the conversation.

[thareUSGS]

@rvwagner We have various versions of what you created also, but never officially released. What did you do at the overlap of 60/-60 latitude border (the boundary across SLDEM and LOLA)? Did you just overlay them or perhaps blend across the boundary? Using a sub-sampled version will help with that 60/-60 edge. See my example image below (which shows no blending).

Anyway, it would be great to see the SLDEM, LOLA, and LOLA SP merged. Especially if you are offering to do it. ;-). You are correct that releasing as scaled 16bit at 128ppd for the ISIS-data area is probably all we want to support. I guess I don't see any reason not use 0.33 as the scaler. LOLA is released using a scaler of 0.5 (understanding it is really only good at that vertical resolution), but the SLDEM has a higher vertical fidelity. But whatever you think is best. And thanks for the offer.

---

Notes: perhaps future -- ASP has a nice edge-blending capability (as it only blends at the edge). It can nicely blend prioritizing the SLDEM over the LOLA using a non-linear method. As I recall, don't use the ISIS blend routine. It will blend across all pixels (I guess you could crop the LOLA down to only have a tiny bit of overlap to blend across). This would mostly be helpful for any 512ppd version.

So, I would love to eventually see it unscaled 32bit using 256ppd (and even a blended 512ppd). Why? There are plans to move to a cloud-first ISIS data area. The team just implemented the ability to use cloud-optimized formats with compression. Using a cloud-optimize format and a 32bit LERC compression (with a vertical MAX_Z_ERROR=0.1), we will likely see a 4x compression ratio or more. Hard-core users can still house the data locally, but it will quickly become unnecessary for most LROC processing (especially NAC).

---

This shows just an overlay merge (no blend). Not bad, but there is a jump. This snap-shot is at 512ppd, so resampling to a lower-resolution (256ppd or 128ppd would help smooth over that).

[rvwagner]

I haven't done any blending, but I don't think it's a major problem in context; the SLDEM itself has similar elevation jumps all over the place due to layering the LOLA tracks on top of the Kaguya tiles for some inscrutable reason. The 4x reduction to 128 ppd does leave the seam basically imperceptible except in a few places.

Looking at the details of where the seam is most significant, it seems to mostly be at places where a big band of LOLA interpolation at the pole runs into the high-detail SLDEM (like you have pictured), so probably the best approach would be to blend in a way that only alters the LOLA side, and then mask that to only keep the blending where the LOLA count maps show 0 track spots (e.g. interpolated areas). That's future work, though.

Also, half for my own reference, the suffix to get base=1737400 multiplier=0.33 is +16bit+1726591.84:1748213.11. The min/max range in the merged source file I have is 1728269.875 to 1748183.375, which juuuuust squeaks inside those bounds.