Restore stage uncertainty import (CSV) as 2 st dev, not 1

[JeromeLeCoz]

The change made in version 3.2 is confusing, so I propose to restore the previous convention (as described in the doc and consistently with other displays and data imports, especially gaugings uncertainty).

[IvanHeriver]

Indeed, there was a change made with this commit 50ca015 where it was decided (probably for consistency with the rest of the app) that the the stage uncertainty should be displayed as 2*std (i.e. extended uncertainty), before, it was expressed as standard deviation. In this commit, the stage uncertainties are now mutliplied by 2 since all uncertainties are stored as std in BaRatinAGE.

However, I see that the table headers do not reflect this since it is still written Stage_non_sys_err_std [m] instead of simply Stage_non_sys_err [m] (assuming extended uncertainty by default). If I am not mistaken, this is the first issue I identify.

The second issue I see is how BaRatinAGE expects the uncertainty to be expressed in the limnigraph import dialog. The user interface is ambiguous and we should indeed expect extended uncertainty. As you pointed out, the documentation says so (https://baratin-tools.github.io/en/doc/baratinage/stage-series/). However, I am wondering, should it be relative (in %) or absolute (m) uncertainty? Absolute makes more sense to me and although documentation is ambiguous, test data provide uncertainties in meters. If absolute extended uncertainty is what is expected, imported uncertainties should be devide by 2 so it is stored as a std whithin BaRatinAGE (as I expect all uncertainties to be) and then it would display properly in the uncertainty table.

To sum up, two issues need to be addressed:

• table headers should fixed
• imported stage uncertainties should be treated as (absolute?) extended uncertainties

[JeromeLeCoz]

Yes Ivan, I agree. In brief: all the displayed stage uncertainties displayed to the user (CSV import file+headers, table headers, plots, etc.) should be absolute (in meters), expanded (not "extended") uncertainties, even though single std (standard uncertainties) are stored and used in the computations.

(Relative stage uncertainties do not make sense since stage is relative to an arbitrary datum, hence it can take any range of postivie or negative values depending on that arbitrary reference; that's also why we never offer log scale option for stages).

[IvanHeriver]

Oups for the typo for the expanded uncertainties and yes, indeed, absolute uncertainties makes no sens for stage errors...

I've made a commit that should fix this. If you have no objection, I'll release the 3.3.1 version of BaRatinAGE this week.