Splitting HALO specific and generic parts of the project

[hgloeckner]

Hello everyone,

I went through the docs again today (and started to run the python code). Doing so, I realized that the 'operation' part of the website is very HALO-specific while the python package is generic to the platform. This was a bit confusing, so we thought it might make sense to split this up into different repos

• pydropsonde, which is the generic python package for dropsonde data analysis
• halodrop, which is the specific HALO-operation how-to [names are up for discussion]

This could go hand in hand with the idea of an organisation as in Issue 25 and would enable other platforms to add their operation guidelines. Like this it might be clearer that the package itself is not HALO-specific

[Geet-George]

Hi Helene, great point! This is exactly something we were discussing during the workshop last year. See Discussions here. Thanks for opening this issue. :)

I agree absolutely with what you say. One idea could be to simply keep the operations part out of the Python package. It is better to keep the handbook for operations separate. It can play into the reorganization being discussed in issue #109. I am now more and more leaning towards what @tmieslinger said in issue #25 about having this as an organization with one repo for Post-ASPEN data, one for ASPEN CLI and maybe we can add individual repos that cover the operations for whichever platforms want it. HALO will have its own, for example.

All that said, separating the repos could also be a thing-for-later issue, as there are more pressing things that are needed by the time ORCESTRA starts.

[tmieslinger]

Hi @Geet-George, we sat together this morning and quickly opened an organisation that we can potentially use. It's called atmdrops. I'd first work out #109 before any splitting. But I think that splitting the documentation of HALO-specific operations and the generic data processing helps the reusability of the processing part and is a good way to go.