Consider a canonical set of units for methods

[jokva]

So right now, the measured depths can be both meters and feet, and the doglog severity considers some defaults depending on the unit used.

An alternative to this approach is to for the methods always assume that the inputs are in meters or degrees for the computation itself [1] (at least when it matters). Then, since mapping between meters and feet is just a constant anyway, the unit translation can be done external to the methods themselves.

The goal here is simplification of the methods themselves, but it means adding support for other units is external to the methods themselves and pretty cheap.

This may or may not be a good idea, but it's a topic for consideration and discussion.

[1] https://en.wikipedia.org/wiki/Canonical_form

[Zabamund]

Thank you for the issue.

So strictly speaking, right now only one method is dependant on which units are passed, this is mincurve.py as depending which units are passed ('m' or 'ft'), different normalisation is performed on dls, the user can also pass her own norm_opt value.

So for all other methods, which units are passed don't matter, so perhaps rather than changing the code, I could just udpate the docstring to clarify this?

And for mincurve.py, I personnally quite like having both 'm' and 'ft' as default arguments as those are both so common in oilfield and metric units common in drilling. As for the optional argument, I only added that as it's a feature I'd personnally like to have, but it's unlikely to be used much at all as most drillers will want dls/100ft or dls/30m.

So I think this is a good topic of conversation, and I'd suggest to only make changes to the docstrings.

I'll not close this as I'm totally open to diverging opinions.

[jokva]

If it's only the one method that can change, unitless but assumed consistent is a good choice.