Tighten up nomenclature

[paulf81]

Description

In the process of completing #197 , I notice that there's an opportunity to standardize the terms for things in FLASC, especially for functions that were written fairly spaced apart in time.

This also could relate to upcoming work on implementing yaw-change detection (can link as that comes online).

For now just opening this issue to track some things we might focus on. Maybe could ulimately open nomenclature page in documetation and nail this down? Start with a discussion? What do you think @ejsimley @misi9170 ?

turb_id/turb_no/turbid - Should probably just pick one of these
Yaw/yaw_offset/etc.

Related URLs

No response

[misi9170]

Hi Paul,

Sure, shall we start a list here of unclear terms, with a description of the meaning and our preferred name? Although I don't have any examples, we may also have situations where a term is overloaded (same term means two things) that we should similarly try to address (again, I don't know for sure that this exists, but it's possible that we mean by yaw and absolute position in some places in the code and a misalignment in others).

I think there are two separate things here:

1. The labels that FLASC expects in the main dataframe. I don't think there are any inconsistencies here, but it would be good to be clear about exactly what we mean by, say, yaw_002 etc, and add that description to the documentation
2. In-code variables, which I think is what you're mostly talking about in the original post, where inconsistent naming may not lead to bugs but could lead to confusion, especially if they are function keyword arguments

So, perhaps we start a list for each of these? Perhaps both lists can make it into the documentation eventually

[Bartdoekemeijer]

FYI, happy to help populate this list!

[paulf81]

@Bartdoekemeijer and @misi9170 I opened #201 as a place to fill out this list