all new R11 and R12 zoning districts values should be mapped to Other in GFT. and since Other overrides all other districts on a lot (see diagram below), those lots should end up as Other

but since all lots with these districts have a zonedist1 like M1-8A/R12, the lots would end up as Commercial or Manufacturing because we currently ignore the second half of district values split by a forward slash (relevant query)

@jackrosacker noted that the "first half of the forward slash wins" behavior is now undesired because the Other mapping for the new districts should win no matter what's in front of the forward slash. previously, all values after the forward slash were high residential, so the lot's GFT zoning would be end up being Commercial or Manufacturing anyway. that's no longer the case

a good approach may be to explode the forward slashed values so that we map both components of them instead of just the first half

data notes

there are 592 relevant lots (zonedist1 like '%/R11' or zonedist1 like '%/R12' from PLUTO). they're all in midtown and these are the counts:

all lots where the zonedist1 has a forward slash have a residential district of five or greater after the slash (and when there's a zondist2 3 or 4, it also doesn't have a R district under five).

so the current logic, which ignores the values after the forward slash in a zondist value, isn't missing any potential R1-R4 with C or M determinations. so it seems safe to explode values with forward slashes to two rows during int__zoning_districts and this won't inadvertently change the outputs for non R11/R12 lots

GFT lot zoning logic

After generalizing each zonedist value for a lot, this logic determines the GFT zoning for the lot