Collection data sent to ranked abundance do not all have ranges [0, 1]

[d-callan]

From microbiomeComputations created by asizemore: VEuPathDB/microbiomeComputations#24

How do we know what to set for the displayRange? Could set to [0, 1] iff the max value is < 1? Ideally the data would tell us what it's display ranges should be.

A short term option: remove all display ranges from ranked abundance. Not ideal.

[d-callan]

Annotation properties displayRangeMin and displayRangeMax need to be filled out on a per-study basis

[d-callan]

(adding a bit more detail) @danicahelb agreed - on a per-study and per-collection variable basis. Many collection vars are relative abundance values, for example, and do indeed have this [0, 1] range. But the pathway abundance variable is different and could have a much wider range. This is an issue for this microbiomeComputations package because we had been simply setting the displayRanges here since the variables didn't really exist in the same way in the data (in the days of early collection and computed variables).
As you mentioned, step 1 is to annotate the data with the correct range. Step 2 is that in this repository, we need to remove the line of code where we are setting the displayRange. @d-callan may have already done step 2 in her recent refactoring, but highlighting it here just in case.

[d-callan]

I don't remember what I did for ranked abundance during the refactor. But I remember for alpha div setting the display range to 0-1 unless the max value exceeded 1. Then it's set to 0-[max value]. I could do the same for ranked abundance.

(For clarity, this makes step 1 above unnecessary but at the cost of inconsistent ranges across subsets)

Update: I suppose another option is to have the client try to use the 0-1 range we supply in the computed metadata, but expand the range to the dataset max from the study variable metadata if actual values fall outside 0-1.

[d-callan]

^^ is the default. In the client we're already using max(displayRange, dataMax), so from the user's perspective they'd never know the difference. So i'd say it's a pretty low priority ticket. It would only really add clarity to the code.