config.py sets geocode_max_km: float = 40.0, rejecting any geocode result farther than 40km from the node.
MTA police talkgroups routinely reference locations beyond that radius — Fordham, Grand Central, Stamford. If those are being discarded, the affected incidents silently lose both their map pin and their location-proximity correlation signal, and the loss looks identical to "no location was extracted".
Untested. Confirm by grepping c2-core logs for the exceeds geocode_max_km rejection line and looking at what is actually being dropped. Do not just raise the number: it trades false negatives for false positives, and a wrong pin is worse than no pin.
`config.py` sets `geocode_max_km: float = 40.0`, rejecting any geocode result farther than 40km from the node.
MTA police talkgroups routinely reference locations beyond that radius — Fordham, Grand Central, Stamford. If those are being discarded, the affected incidents silently lose both their map pin and their location-proximity correlation signal, and the loss looks identical to "no location was extracted".
**Untested.** Confirm by grepping c2-core logs for the `exceeds geocode_max_km` rejection line and looking at what is actually being dropped. Do not just raise the number: it trades false negatives for false positives, and a wrong pin is worse than no pin.
Measured against the 2026-08-19 dump: the 40km radius is not the main cause. Geocode success is 6.8%, and 17 of 26 location strings never geocode at all — because the strings themselves are ASR garbage, not because they were rejected for distance.
Representative: "northbound ramp to the conics" — that is the Taconic. Whisper mangled the road name, so nothing was ever going to geocode it, at any radius.
So the fix is upstream of the radius: a vocabulary/biasing pass on local road, town and landmark names before the geocode attempt. vocabulary_learning_enabled already exists as a feature flag — worth checking whether it is doing anything for place names specifically.
Raising geocode_max_km on its own would trade a small number of false negatives for a larger number of confidently-wrong pins, and per server-26#23 a wrong pin is worse than no pin. Leaving this open but re-pointed at ASR quality.
Full analysis: CORRELATION_REVIEW_0820.md (project root, not in git).
Measured against the 2026-08-19 dump: **the 40km radius is not the main cause.** Geocode success is 6.8%, and 17 of 26 location strings never geocode at all — because the strings themselves are ASR garbage, not because they were rejected for distance.
Representative: `"northbound ramp to the conics"` — that is the **Taconic**. Whisper mangled the road name, so nothing was ever going to geocode it, at any radius.
So the fix is upstream of the radius: a vocabulary/biasing pass on local road, town and landmark names before the geocode attempt. `vocabulary_learning_enabled` already exists as a feature flag — worth checking whether it is doing anything for place names specifically.
Raising `geocode_max_km` on its own would trade a small number of false negatives for a larger number of confidently-wrong pins, and per server-26#23 a wrong pin is worse than no pin. Leaving this open but re-pointed at ASR quality.
Full analysis: `CORRELATION_REVIEW_0820.md` (project root, not in git).
Confirmed and fixed as part of #159 (commit 66bbf5b), which independently found and traced the exact mechanism this issue flagged as untested. Concrete case: node-002 sits in Westchester but relays "New York City - NYPD Citywide 2 Patch" — real addresses on it are routinely 40-70km away, past geocode_max_km, and were being rejected every time (confirmed in prod: location_coords was null on every incident on that talkgroup). _geocode_location now skips the node-distance check specifically when the query already names its own region (operator-set area_context, or a municipality parsed from the talkgroup's own name) — the exact MTA-far-talkgroup case this issue described. Closing as fixed; see #159 for the full trace and #160 for the parallel gap in place_verifier.py (not fixed, tracked separately).
Confirmed and fixed as part of #159 (commit 66bbf5b), which independently found and traced the exact mechanism this issue flagged as untested. Concrete case: node-002 sits in Westchester but relays "New York City - NYPD Citywide 2 Patch" — real addresses on it are routinely 40-70km away, past `geocode_max_km`, and were being rejected every time (confirmed in prod: `location_coords` was null on every incident on that talkgroup). `_geocode_location` now skips the node-distance check specifically when the query already names its own region (operator-set area_context, or a municipality parsed from the talkgroup's own name) — the exact MTA-far-talkgroup case this issue described. Closing as fixed; see #159 for the full trace and #160 for the parallel gap in place_verifier.py (not fixed, tracked separately).
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.
config.pysetsgeocode_max_km: float = 40.0, rejecting any geocode result farther than 40km from the node.MTA police talkgroups routinely reference locations beyond that radius — Fordham, Grand Central, Stamford. If those are being discarded, the affected incidents silently lose both their map pin and their location-proximity correlation signal, and the loss looks identical to "no location was extracted".
Untested. Confirm by grepping c2-core logs for the
exceeds geocode_max_kmrejection line and looking at what is actually being dropped. Do not just raise the number: it trades false negatives for false positives, and a wrong pin is worse than no pin.Measured against the 2026-08-19 dump: the 40km radius is not the main cause. Geocode success is 6.8%, and 17 of 26 location strings never geocode at all — because the strings themselves are ASR garbage, not because they were rejected for distance.
Representative:
"northbound ramp to the conics"— that is the Taconic. Whisper mangled the road name, so nothing was ever going to geocode it, at any radius.So the fix is upstream of the radius: a vocabulary/biasing pass on local road, town and landmark names before the geocode attempt.
vocabulary_learning_enabledalready exists as a feature flag — worth checking whether it is doing anything for place names specifically.Raising
geocode_max_kmon its own would trade a small number of false negatives for a larger number of confidently-wrong pins, and per server-26#23 a wrong pin is worse than no pin. Leaving this open but re-pointed at ASR quality.Full analysis:
CORRELATION_REVIEW_0820.md(project root, not in git).Confirmed and fixed as part of #159 (commit
66bbf5b), which independently found and traced the exact mechanism this issue flagged as untested. Concrete case: node-002 sits in Westchester but relays "New York City - NYPD Citywide 2 Patch" — real addresses on it are routinely 40-70km away, pastgeocode_max_km, and were being rejected every time (confirmed in prod:location_coordswas null on every incident on that talkgroup)._geocode_locationnow skips the node-distance check specifically when the query already names its own region (operator-set area_context, or a municipality parsed from the talkgroup's own name) — the exact MTA-far-talkgroup case this issue described. Closing as fixed; see #159 for the full trace and #160 for the parallel gap in place_verifier.py (not fixed, tracked separately).