311 ticket exports used for triage fine-tuning are missing many neighborhood fields, but latitude and longitude are usually present. What should curators do first in data preparation?
Select an answer to reveal the explanation.
Short Explanation
Missing neighborhood tags with good GPS is like a package that has coordinates but no street label—look it up on the city map. Impute from lat/long before you fine-tune the triage LLM.
Full Explanation
When 311 ticket exports used for triage fine-tuning are missing many neighborhood fields but usually include latitude and longitude, curators should first impute neighborhood from lat/long using the city's boundary lookup. That repair uses trustworthy geospatial evidence already in the export to restore a labeling feature triage models need, instead of discarding history or inventing a vague citywide placeholder. Sound municipal data preparation prefers principled imputation from authoritative boundaries when coordinates are present. Deleting the entire 311 history because any missing field invalidates civic ML is extreme and throws away years of otherwise usable triage signal. Filling every blank neighborhood with 'UNKNOWN_CITYWIDE' and skipping coordinates invents a pseudo-class that hides spatial structure and wastes the lat/long that could recover real neighborhoods. Training immediately on raw nulls so the model 'learns to ignore geography' teaches the model that neighborhood is missing noise rather than a recoverable civic feature and degrades geographic triage. Exam caveat: boundary imputation quality depends on accurate GIS layers and point-in-polygon edge cases (borders, water); flag low-confidence imputations rather than silently treating all fills as ground truth. Operational check: join a sample of tickets with missing neighborhoods to the city boundary service, measure fill rate and conflict rate on borders, document the imputation rule in the datasheet, and only then proceed to fine-tuning.