Follow-up to #159 (fixed in intelligence.py's _geocode_location/_location_query_parts via trust_named_region). Deliberately not fixed in the same pass — different file, and #159 was scoped to the confirmed production symptom (duplicate incidents from a dead location_proximity signal). Logged so it doesn't get lost; see DEFERRED.md's place_verifier.py section for the paired entry.
place_verifier.py:200-202:
anchor=area_context.anchor_for(system_area,tg_area)ifnotanchor:returnNone,None# load-bearing: no anchor means skip, never accept
This is the exact same gap #159 found in intelligence.py: a citywide/patched system with no operator-configured Local Area (e.g. New York City - NYPD Citywide 2 Patch, confirmed empty in prod) never gets an anchor, so verify() bails out immediately — transcript place-name correction (sound-alike substitution against Maps/local_knowledge) never runs for that entire talkgroup, forever. Same root cause as #159, different consequence: there it silently killed location_coords (and thus location_proximity correlation); here it silently kills transcript quality (a mis-transcribed street name never gets corrected before it reaches extraction, the correlator, or the summarizer).
Not proposing a fix here, just flagging the parallel. Possible direction: reuse whatever trust_named_region-equivalent signal #159 introduced (a municipality parsed from the talkgroup's own name counts as "described" even without a resolved numeric anchor) to let verify() attempt geocoding for sound-alike checks scoped to that derived place instead of skipping outright.
Follow-up to #159 (fixed in intelligence.py's `_geocode_location`/`_location_query_parts` via `trust_named_region`). Deliberately not fixed in the same pass — different file, and #159 was scoped to the confirmed production symptom (duplicate incidents from a dead `location_proximity` signal). Logged so it doesn't get lost; see DEFERRED.md's place_verifier.py section for the paired entry.
`place_verifier.py:200-202`:
```python
anchor = area_context.anchor_for(system_area, tg_area)
if not anchor:
return None, None # load-bearing: no anchor means skip, never accept
```
This is the exact same gap #159 found in `intelligence.py`: a citywide/patched system with no operator-configured Local Area (e.g. `New York City - NYPD Citywide 2 Patch`, confirmed empty in prod) never gets an anchor, so `verify()` bails out immediately — transcript place-name correction (sound-alike substitution against Maps/local_knowledge) never runs for that entire talkgroup, forever. Same root cause as #159, different consequence: there it silently killed `location_coords` (and thus `location_proximity` correlation); here it silently kills transcript quality (a mis-transcribed street name never gets corrected before it reaches extraction, the correlator, or the summarizer).
Not proposing a fix here, just flagging the parallel. Possible direction: reuse whatever `trust_named_region`-equivalent signal #159 introduced (a municipality parsed from the talkgroup's own name counts as "described" even without a resolved numeric anchor) to let `verify()` attempt geocoding for sound-alike checks scoped to that derived place instead of skipping outright.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Follow-up to #159 (fixed in intelligence.py's
_geocode_location/_location_query_partsviatrust_named_region). Deliberately not fixed in the same pass — different file, and #159 was scoped to the confirmed production symptom (duplicate incidents from a deadlocation_proximitysignal). Logged so it doesn't get lost; see DEFERRED.md's place_verifier.py section for the paired entry.place_verifier.py:200-202:This is the exact same gap #159 found in
intelligence.py: a citywide/patched system with no operator-configured Local Area (e.g.New York City - NYPD Citywide 2 Patch, confirmed empty in prod) never gets an anchor, soverify()bails out immediately — transcript place-name correction (sound-alike substitution against Maps/local_knowledge) never runs for that entire talkgroup, forever. Same root cause as #159, different consequence: there it silently killedlocation_coords(and thuslocation_proximitycorrelation); here it silently kills transcript quality (a mis-transcribed street name never gets corrected before it reaches extraction, the correlator, or the summarizer).Not proposing a fix here, just flagging the parallel. Possible direction: reuse whatever
trust_named_region-equivalent signal #159 introduced (a municipality parsed from the talkgroup's own name counts as "described" even without a resolved numeric anchor) to letverify()attempt geocoding for sound-alike checks scoped to that derived place instead of skipping outright.