A bit of a clunker of a PR, but I believe it gets the job done. The crux of debugging this issue lied in pursuing a deeper exploration of translate_state_activity_code. In the cases of AZ, MT, and WA, passing the value of activity.name as the activity_name argument is important; for those states, activity.name will correspond to one of the keys in AZ_KEY, MT_KEY, and WA_KEY, respectively (for certain Shapefiles). For WI, however, we need to pass the value of appendage_col_value, since translation of state codes occurs on this secondary column.
In short, I think a huge source of the issues in this area of the codebase is that WI performs the translation on the values in the appendage column, not the primary activity column. In fact, it's the only state satisfying both of the following criteria:
Has configs with use_name_ as_activity=True and non-Noneactivity_name_appendage_col.
Has a lookup table for translating state codes.
WI's persistent problems also probably made it easier for us to think the problem was fixed once WI's values looked correct. With this change, we start to see positive signs of correction:
Problematic TX parcels with activities like "Producing – Producing" now read "Oil and gas lease – Producing"
Problematic WI parcels with activities like "DNR Easement - 1222.0" now read "DNR Easement - Open to passive use only"
I also verified the AZ and MT lookups are appearing as expected.
A bit of a clunker of a PR, but I believe it gets the job done. The crux of debugging this issue lied in pursuing a deeper exploration of
translate_state_activity_code
. In the cases of AZ, MT, and WA, passing the value ofactivity.name
as theactivity_name
argument is important; for those states,activity.name
will correspond to one of the keys inAZ_KEY
,MT_KEY
, andWA_KEY
, respectively (for certain Shapefiles). For WI, however, we need to pass the value ofappendage_col_value
, since translation of state codes occurs on this secondary column.In short, I think a huge source of the issues in this area of the codebase is that WI performs the translation on the values in the appendage column, not the primary activity column. In fact, it's the only state satisfying both of the following criteria:
use_name_ as_activity=True
and non-None
activity_name_appendage_col
.WI's persistent problems also probably made it easier for us to think the problem was fixed once WI's values looked correct. With this change, we start to see positive signs of correction:
I also verified the AZ and MT lookups are appearing as expected.