Fast flag update

[emma-nechamkin]

Update tile flags as follows:

• add a flag for whether income has been imputed and adjusted (T/F)
• add a flag for whether the tract is a donut
• update Score N to be donut union Score N

[emma-nechamkin]

Checked that imputation flag is operating as expected.

@vim-usds right now, I've named the flag for tiles IMP_FLG

[emma-nechamkin]

Updating to include donut flags.

Right now, we are sending to tiles the following (@vim-usds):

• the final boolean for score M or not: SM_C
• whether it's a donut community: SM_DON
• whether it's score M without the donuts: SM_NO_DON
  

@vim-usds @KameronKerger -- note that the boolean "is it a donut hole?" can be true even if it's a DAC on its own merit. So, you could imagine a tract that is ALREADY surrounded by other DACs and is already a DAC -- this will show up that it meets the donut hole criterion. I'm happy to change this, but this is most consistent with how we show other indicators. It also lends credence to this approach -- out of 7k donut holes, only around 300 get added. Woo hoo!

PS I am changing these names internally because they super suck.

[emma-nechamkin]

Makes it to the tiles, yay!

[KameronKerger]

@emma-nechamkin does this mean that...

note that the boolean "is it a donut hole?" can be true even if it's a DAC on its own merit.
if DAC by its own merit = UI can treat as a regular DAC
if just DAC by donut hole = UI can treat as donut hole exception
???

[emma-nechamkin]

@emma-nechamkin does this mean that...

note that the boolean "is it a donut hole?" can be true even if it's a DAC on its own merit.
if DAC by its own merit = UI can treat as a regular DAC
if just DAC by donut hole = UI can treat as donut hole exception
???

TY for the speedy reply! So yes! We can think of three types of DACs:

1. a DAC based only on indicators --> indicator DAC boolean yes, donut boolean no
2. a DAC based on indicators AND on donut criteria --> indicator DAC boolean yes, donut boolean yes
3. a DAC only based on donut criteria --> indicator DAC boolean no, donut boolean yes

I can definitely change 2 so that the indicator and the donut booleans are mutually exclusive... but that's kind of confusing in my mind because if a tract is a DAC based on indicators but also entirely surrounded by DACs it meets the adjacency criteria. Wdyt? @KameronKerger

[emma-nechamkin]

I also think that IF we want there to be text ONLY when the tract is a donut hole, we might want to have that be a front end control. My thinking is that it's REALLY confusing for the data user to define this index as only happening in the case when there's no DAC designation already.

However, this is a super simple variable for us to make: ~ dac_indicator & dac_donut

[esfoobar-usds]

🍏

[KameronKerger]

@emma-nechamkin and I agreed that the backend should control the data and the front end should control the user experience on this one...
👍

[github-actions]

** Score Deployed! **
Find it here:

• Score Full usa.csv: https://justice40-data.s3.amazonaws.com/data-pipeline-staging/1844/fa94e0a3724473825b063381f9ebddbd7bc13397/data/score/csv/full/usa.csv
• Download Zip Packet: https://justice40-data.s3.amazonaws.com/data-pipeline-staging/1844/fa94e0a3724473825b063381f9ebddbd7bc13397/data/score/downloadable/Screening_Tool_Data.zip

[github-actions]

** Score Deployed! **
Find it here:

• Score Full usa.csv: https://justice40-data.s3.amazonaws.com/data-pipeline-staging/1844/83437527f7b3ac35c3f1f31e0732be11717f23eb/data/score/csv/full/usa.csv
• Download Zip Packet: https://justice40-data.s3.amazonaws.com/data-pipeline-staging/1844/83437527f7b3ac35c3f1f31e0732be11717f23eb/data/score/downloadable/Screening_Tool_Data.zip

[emma-nechamkin]

Recommitted: #1845