[BUG] LUDU Overrides Table 2016-2019

[GregorSchroeder]

Describe the bug

The LUDU Overrides table developed by SANDAG to apply post-hoc corrections to prior LUDU releases operates via the [LCKey] identifier, the granular identifier of records in SANDAG's Land Use and Dwelling Unit layer. Unfortunately, from 2016-2019 the identifier was removed and replaced with [subParcel] as a unique identifier. This means we are unable to apply LUDU overrides to the 2016-2019 LUDUs when developing intercensal 2010-2019 Estimates.

To Reproduce

Review the available fields in the 2016-2019 LUDU and LUDU Points tables. There is no [LCKey] field. The only mapping currently available in the LUDU Overrides table is built on [LCKey].

Expected behavior

The LUDU Overrides table needs to be able to be applied to the 2016-2019 LUDUs both now and into the future as more overrides are added to the table.

Potential resolution

There are two potential resolutions

1. The GIS team recreates [LCKey]s for 2016-2019 that are consistent with the [LCKey]s from 2010-2015 and 2020-2024 such that the LUDU Overrides table can be applied correctly.
2. The GIS and E&F teams add [subParcel] to the LUDU Overrides table for current entries and all future overrides that apply to 2016-2019.

[gracechung]

E&F and GIS Team Meeting Notes, October 10, 2025

• GIS team proposed a workflow to recreate [LCKey]s for 2016-2019 that are consistent with the [LCKey]s from 2010-2015 and 2020-2024 such that the LUDU Overrides table can be applied correctly.
• The steps include (copied from the GIS team’s PowerPoint slide; contact Blake for details).
  _1. If 2015 = 2020 LCKeys and subPID is the same 2016-2019, means no change, assign LCKey values and query out.

2. Look for year-over-year Δ in PID, apn8. Start with 2015 and 2016…

• A) For new/Δ records, see if 2016 attributes match 2017-2020. If so, assign 2020 LCKey that Hofmockel added to 2016-2019. If not, see B)
  Reiterate check for new/Δ records that match 2020 for 2017, 2018, and 2019. This should connect all “new” LCKeys from 2020 to previous years.
• B) If 2016 records do NOT match/exist in 2020, this means the LCKey we create will disappear before 2020. Create new LCKey value that does not exist in 2024. Assign LCKey for all valid years and add value to a table so that PIPPy will not reuse the LCKey in 2025.

3. Reiterate process year-over-year btw 2016 to 2019.

• For cases where an LCKey disappears and a new LCKey is created, but will disappear before 2020, repeat the 2024 check and add the LCKey to the table for PIPPy to read.
• The table for PIPPy to read will only be pertinent in 2025. The highest value will move beyond what we’re assigning in 2026. Alternatively, we could use a special combination of numbers for these cases, so the override is not necessary (e.g., 00001, 00002, etc.)_
  -Both E&F and GIS team agreed that the approach is sound, and the GIS team will proceed with the work.
  -The only concern is that if the GIS team starts working on this task, it will push 2025 LUDU back.

Oct 14, 2025

• Gregor clarified that we don't need 2025 LUDU until May 2026.
• GIS team confirmed that it is not a problem and will start the work this week, before initiating the 2025 Land Inventory Update.