ctxcal now uses cam

[Kelvinrr]

Description

Part of making calibration apps work without local spice, ctxcal attempts to use the camera before using kernels.

Related Issue

#4303

Motivation and Context

How Has This Been Tested?

Tested locally, both camera and local spice return the same result. Should we consider adding tests as original tests do not use spice inited cubes?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Documentation change (update to the documentation; no code change)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have read and agree to abide by the Code of Conduct
• I have read the CONTRIBUTING document.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have added myself to the .zenodo.json document.
• I have added any user impacting changes to the CHANGELOG.md document.

Licensing

This project is mostly composed of free and unencumbered software released into the public domain, and we are unlikely to accept contributions that are not also released into the public domain. Somewhere near the top of each file should have these words:

This work is free and unencumbered software released into the public domain. In jurisdictions that recognize copyright laws, the author or authors of this software dedicate any and all copyright interest in the software to the public domain.

• I dedicate any and all copyright interest in this software to the public domain. I make this dedication for the benefit of the public at large and to the detriment of my heirs and successors. I intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this software under copyright law.

[kberryUSGS]

This looks good to me! I think your idea to add a test (or tests) that use spiceinited cubes, so that this updated code is tested, is a good idea.

[Kelvinrr]

@kberryUSGS So the question is: Should I just update the tests to use spiceinit-ed cubes (easy, done today), or, should I make a GTest for the case instead (requires converting the app, would add a lot of time to development). I am kinda fine with either, it's more if you think we can still get though all of them if we also covert the apps as I imagine we will have to test all of these.

[kberryUSGS]

@Kelvinrr I'm honestly fine with either, too. It's tricky because that's technically beyond the scope of this project, but also it feels like adding technical debt to add new tests in the old testing framework.

Could you go ahead and convert just ctxcal and its tests and see how long it takes? Then, we can use that as a rough estimate to see if it's even feasible to convert the rest of the calibration apps while we're in here or not.

My preference is to have the conversion come in as a separate PR anyway, since it's hard to see the diffs if the code changes and the conversion are in the same PR, so I'd lean toward merging this PR if CI passes (and you're confident in the local tests you ran,) and then you could put up a new PR for just the conversion and new test(s) when that's ready.

[kberryUSGS]

👍