MAP2MAP with Tracking Layer Doesn't Work Properly

[astrostu]

ISIS version(s) affected: 6.0.0-

Description
After map-projecting a mosaic that has an additional _tracking.cub file, the _tracking.cub will not itself map-project to the new projection and QVIEW will not properly map back to it.

How to reproduce
I was examining a mid-latitude mosaic that I had constructed with AUTOMOS with track=true. Mid-latitudes in equirectangular projection have some significant distortions that make it hard to tell sometimes if the control was good. I used MAP2MAP to convert my image mosaic to a Lambert Azimuthal with a local central lat/lon, which works much better for looking for anomalies. I then tried to project the _tracking.cub layer with MAP2MAP but got an error that it couldn't be projected ("ERROR Unable to find PVL group [Mapping] in file [MC04_PDS202106_50mpp_tracking.cub]."). Meanwhile, loading the image mosaic in QVIEW, it seemed like it still knew where things were, but as I would move from one image that was part of the mosaic to another, it did not update properly. I would move off the mosaic in the Lambert projection and it would still say I was on an input cube, leading me to realize that it was not doing some dynamic, on-the-fly projection of the tracking cube.

Possible Solution
See next section.

Additional context
With that all said, I don't know if this is a bug per se or simply a missing feature? Perhaps there is a bug that the _tracking.cub should include a mapping group in the header but it's not, so it's a problem with AUTOMOS? Or perhaps the feature request is that it be included so MAP2MAP works on it? Or perhaps the bug or feature is that QVIEW be able to dynamically search for lat/lon from the image cube and map that onto the tracking cube rather than do a line/sample lookup?

[astrostu]

With the above context in mind, I think I have successfully "hacked" a fix for this: I used COPYLABEL to copy the mapping group from the image cube into the tracking cube, and then I MAP2MAP'd the tracking cube. Backup the original files to something like .bak.cub, rename the map-projected files to the original names, and it seems to work. The renaming is needed unless (I assume— I didn't check) one goes into the header and changes the name link to the tracking cube.

That said, it's not perfect, there are still some offsets and issues at the ~pixel-level, so use at your own risk.

So ... if y'all opt to not include this as a feature (or bug fix) in a future ISIS release, hopefully someone doing an internet search will see this as a work-around.

[AustinSanders]

It looks like this issue slipped through the cracks so far, but I'm now tracking this issue and will attempt to replicate soon. Thanks for your patience and the proposed workaround! I'll update the issue with more info as I dig my way through.

[github-actions]

Thank you for your contribution!

Unfortunately, this issue hasn't received much attention lately, so it is labeled as 'stale.'

If no additional action is taken, this issue will be automatically closed in 180 days.

[astrostu]

bump