geocode_max_km=40 may be rejecting legitimate MTA locations #6

New Issue

2026-08-19T22:06:53-04:00

logan commented

2026-08-19 22:06:53 -04:00

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.

logan commented

2026-08-20 03:17:47 -04:00

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).

logan referenced this issue

2026-08-20 03:35:14 -04:00

Incident title is re-derived from the newest call, so incidents are named after their last event #25

logan referenced this issue

2026-08-20 03:36:20 -04:00

Incident title is re-derived from the newest call, so incidents are named after their last event #26

logan referenced this issue

2026-08-23 16:16:56 -04:00

Use Maps to verify corrected place names against the talkgroup anchor, and point the induction loop at talkgroups #37

logan referenced this issue

2026-08-23 17:19:58 -04:00

Board 2026-08-23 — Ratify BUSINESS_MODEL.md — COO draft #38

logan referenced this issue

2026-08-23 17:30:49 -04:00

Board 2026-08-23 — Ratify BUSINESS_MODEL.md — FINAL MINUTES #42

logan referenced this issue

2026-08-23 22:15:51 -04:00

Place verification geocodes unit call-signs: "Post 1-2" became a real map pin #52

logan referenced this issue

2026-08-23 23:44:46 -04:00

Board 2026-08-23 — Owner goals — FINAL MINUTES #54

logan referenced this issue

2026-08-24 23:03:42 -04:00

P0: standing correlation-quality evaluation procedure (scheduled AI window) #57

logan referenced this issue

2026-08-26 09:31:44 -04:00

Scene over-splitting: one radio conversation becomes two incidents #5

logan referenced this issue

2026-08-30 02:44:06 -04:00

The primary scene's geocode leaks into every other scene's correlation, fabricating a location match #87

logan commented

2026-09-20 21:56:14 -04:00

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).

logan closed this issue

2026-09-20 21:56:15 -04:00

logan added the area/ai-pipeline area/map

labels 2026-10-05 02:04:15 -04:00

Sign in to join this conversation.