Internalize ussa1976 codebase

[leroyvn]

The ussa1976 package is no longer maintained. To keep functionality as it is, I am internalizing its codebase with minimal changes. The ussa1976.compute() function (main entry point) is now accessed as joseki.profiles.ussa_1976.compute().

[K20shores]

@leroyvn is there a reason ussa1976 is no longer maintained? I would welcome doing the maintenance and deployment work for the ussa1976 project if given the chance.

[leroyvn]

Hi @K20shores, when our colleague responsible for the maintenance of ussa1976 left us, the project was left unattended. The reason is that this atmospheric model is not used in the scientific field where Rayference operates — it is rather targeting aviation.

The tooling on the ussa1976 package needed a big upgrade, and I didn't feel like doing all that work for something that's not used for our applications. But I also didn't want to retire the functionality it offered for compatibility reasons.

I am now working on evolving Joseki, upgrading its tooling (that's the ongoing update, to be released as v2.7.0), and, in the medium term, redesigning certain parts to generate profiles suitable for advanced atmospheric spectroscopy (e.g. dimer concentrations). Since Joseki is now in a reasonably healthy state, I figured it would be easier to simply merge ussa1976's functionality with Joseki's. Actually, Joseki replicates a lot of ussa1976's features, so maintaining both separately didn't make so much sense. Joseki's scope doesn't expand much with the addition of the ussa1976 codebase.

All of ussa1976's features are still here, under a FOSS license. I just need to add a few lines of documentation to cover the bits that are specific to that model in the Joseki docs.

So I'd say: unless you absolutely want the USSA 1976 atmospheric model bundled by itself, I don't see a reason to spend time on maintaining it as a separate project.

[K20shores]

@leroyvn I'm interested in using the output of the standard atmosphere. I'm indifferent about continuing the package, but another option is available.

I've talked with the maintainer of metpy (I work at the same organization as they do) and asked if including the US Standard Atmosphere calculations in their package would be appropriate. He has told me that they would welcome a contribution that provides for these calculations.

So, my preferred approach would be to integrate all the code from ussa1976 into metpy and make it accessible there. It would be up to you then if you wanted to include metpy as a dependency or keep using that code internally.

Do you have any objections or thoughts about that? I would, of course, be doing the work to include it into metpy.

[leroyvn]

Ok, I see. Of course, feel free to proceed with the integration of the ussa1976 codebase in MetPy (the code is MIT-licensed so that shouldn't give you any trouble). In the end, it's about deciding on which solution results in the lowest amount of technical debt on your side.

That said, it might still be appropriate to try and maintain a common codebase, if relevant, to minimize the amount of duplicate effort. I'll reach out privately to continue the discussion.