Closed BethMattern closed 2 years ago
The data is ~0.897. so when we determine whether that is >=90th percentile, it is NOT and so it is NOT included. But when we round the number for the UI, it looks like 90.
This will affect ALL percentile fields for all values between .895 and .8999999999.
I think we need a steer from design/product (@BethMattern @glennettec @KameronKerger ) on how they want this to look.
Some options:
Force all values between .895 and .8999999 to actually round down to .89 to make the visuals appear better.
Round up .895 to .90 before percentile cutoff (I don't think we want this, that's a major effect on the definition).
Add an explanatory note or asterisk.
Another option: if we're going to essentially use "floors" for our percentile cutoffs where .89999999 is not above the threshold but .90 is, then perhaps we should no longer round numbers anywhere, and instead always floor them (e.g., .899999 goes to .89, and so does, e.g., .7363459342 to .73). This would be consistent and also make the thresholds match. It's also a fairly trivial backend change.
We will do that.
This is where we round -- we use Pandas.round: https://github.com/usds/justice40-tool/blob/main/data/data-pipeline/data_pipeline/etl/score/etl_score_post.py#L216
@saran-ahluwalia is this the rounding thing you talked about in standup today?
Yes @BethMattern, I believe that this is the main issue associated with the current task.
@esfoobar-usds @BethMattern Is there any other QA and/or additional client-side validation that needs to occur before this is closed?
Your round PR should take care of this, but we'll double check shortly.
The building value field should be blue in the side panel for census tract 31075956300 https://d29zfl8cj7y1zf.cloudfront.net/en/cejst#10.17/41.9023/-101.7773