db-pluto QA: 26a CoY Fields Preview

[github-actions]

This version is not intended to be published, but rather to allow us to QA the new fields. The build is here:

There are seven new fields in total in total:

• 4 MIH Options
• Transit Zone (TrnstZone)
• Far values: AffResFAR, ManuFAR

MIH Options

Below are the options:

mihopt1​
mihopt2​
mihopt3 (includes both existing opt3 and deep affordability)​
mihopt4 ​ (workforce)

Here's the assignment strategy (from our docs)

-- Assignment Strategy:
-- Unlike transit zones where each lot gets assigned to exactly one zone, MIH areas can have
-- multiple overlapping affordability options that ALL apply to a single lot. A lot is assigned 
-- to a MIH option if either:
--   1. ≥10% of the lot area is covered by the MIH area, OR
--   2. ≥50% of the MIH area is covered by the lot
--
-- Multiple Options Per Lot:
-- A single lot can legitimately have multiple MIH options (e.g., Option 1, Option 2, Deep Affordability).
-- These are not competing assignments but rather cumulative policy options that apply to development
-- on that lot. The final output pivots these into binary flags (mih_opt1, mih_opt2, etc.).

Transit Zones

These are much more complicated. This is the outcome of conversations with Transit and Housing. Below is the logic:

-- ASSIGNMENT LOGIC:
-- We assign transit zones using a two-tier strategy:
--
-- 1. BLOCK-LEVEL ASSIGNMENT (when unambiguous):
--    - For tax blocks where a single transit zone clearly dominates (no competing zones >10% coverage),
--      assign all lots in that block to the dominant zone.
--    - This captures cases where a transit zone boundary might cut through individual lots within
--      a block, but we want those lots assigned consistently with their parent block.
--
-- 2. LOT-LEVEL ASSIGNMENT (when ambiguous):
--    - This is a fallback for when we can't determine a clear block-level assignment.
--    - For example, when a rail line cuts straight through a "block", creating ambiguity about
--      which transit zone the block belongs to. In such cases, we calculate coverage for each
--      individual lot and assign based on the lot's specific overlap.
--    - Special rule: If a lot has significant coverage in ANY zone AND "Beyond the Greater Transit Zone",
--      we always default to the non-Beyond zone.
--    - Note: We're not doing any complicated geometry splitting here, just falling back to
--      lot-by-lot calculation when block-level assignment would be misleading.

TLDR: We try to assign a full block to a transit zone, because there are cases like this:

or this:

Where the transit zone slices the tax lot in half. In such a case, we try to keep the tax lot with it's "block" (scare quotes, because there's not a real concept of a block)

When the block is ambiguous, as this "block" is:

Then we dissolve the block and just assign the tax lot to it's best transit zone match EXCEPT when a competing match is the outermost TZ (beyond the greater transit zone). So if a block is split between that tz and any other, we assign to the other TZ

FAR values

These are applied exactly like all the other FAR values.