fix(ptica): шумовой скорер перестаёт считать водоёмы источниками шума (#2464-G) #2931

Merged

bot-backend merged 1 commit from fix/2464g-noise-source-type-filter into main

2026-08-19 12:42:00 +00:00

bot-backend commented

2026-08-19 12:21:42 +00:00

Collaborator

Что не так

Запрос шумовых источников брал из osm_noise_sources_ekb все типы. В таблице лежат и нешумовые слои — их отдельно читает блок гидрологии (9c) ниже в том же файле:

highway     5 616   есть в NOISE_L_BASE
railway     1 994   есть в NOISE_L_BASE
industrial    585   есть в NOISE_L_BASE
utility     1 487   -> дефолт 50 дБ
water         870   -> дефолт 50 дБ

Ключа в NOISE_L_BASE у них нет, поэтому .get(key, 50.0) выдавал им ровно 50 дБ — значение, совпадающее с порогом попадания в список источников. На origin/main тест печатает дефект буквально:

AssertionError: нешумовой слой попал в источники шума:
  [{'source_type': 'water', 'name': 'Пруд', 'distance_m': 10, 'estimated_db': 50.0}]

Второе, менее заметное: LIMIT 30 берётся по близости, поэтому вода вытесняла настоящие источники.

Замер (прод, 19.08, 1 000 участков, детерминированная выборка по cad_num)

занятых слотов LIMIT 30              19 755
  из них вода и коммуникации          8 797   (44.5%)
участков, теряющих хотя бы 1 источник   562
участков, теряющих ВИДИМЫЙ источник       0   из 729
участков, где меняется максимум дБ         0

Честно про масштаб: видимого эффекта у вытеснения нет — все вытесненные источники оказались тише порога 50 дБ, максимум дБ не меняется ни у одного участка. Видимый дефект — только водоём ближе 10 м. Правка убирает не столько видимую поломку, сколько скрытый потолок: почти половина бюджета LIMIT уходила на строки, которые скорер не умеет оценивать.

Ловушка, из-за которой правка не в одну строку

Очевидный вариант — добавить фильтр и оставить noise_sources_count=len(noise_rows) — сломал бы треть участков.

_compute_confidence спрашивает «загружена ли шумовая карта» и при нуле пишет «Шумовая карта не загружена — noise score = stub». А у 345 участков из 1 000 в радиусе 2 км нет ни одного шумового источника при наличии воды. После наивной правки они получили бы это утверждение — неверное: карта загружена, просто рядом тихо.

До правки верный ответ там выходил по случайности — ровно потому, что в счёт шли нешумовые строки. Поэтому покрытие карты считается отдельным дешёвым COUNT(*) (таблица целиком — 10.5 тыс. строк), а параметр переименован в noise_map_rows_nearby, чтобы смысл не приходилось угадывать.

Проверка

тест	`origin/main`	с правкой	наивный вариант фикса
`test_water_not_reported_as_noise_source`	красный (`'water' in {'water'}`)	зелёный	зелёный
`test_no_false_map_not_loaded_caveat...`	зелёный	зелёный	красный

Второй тест — контроль: он зелёный по обе стороны от правки, но краснеет, если считать покрытие по отфильтрованному списку. Проверено подстановкой наивного варианта, не рассуждением.

pytest tests/api/v1 на уже перебазированном дереве (то есть на том коде, что уйдёт в мерж): 348 passed, 1 skipped, rc=0, сторож пропусков молчит.

Побочно: мок parcel_meta переведён на сигнатуры

test_analyze_parcel_meta.py раздавал ответы db.execute по порядковому номеру вызова. Добавление любого запроса выше по коду ломало его — следы в истории самого файла (#29 G2, затем #2464 cluster B), и мой запрос покрытия сломал бы снова. Такое падение говорит не о parcel_meta, ради которого написан файл, а о том, что кто-то добавил блок выше.

Переведён на матчинг по сигнатуре SQL — приём уже применён в соседнем test_analyze_market_price.py, где эта хрупкость описана в докстринге. Проверено, что мок не потерял зубы: со специально сломанной сигнатурой тест краснеет. И что миграция сама по себе ничего не меняет: на origin/main он тоже зелёный.

Refs #2464

## Что не так Запрос шумовых источников брал из `osm_noise_sources_ekb` **все** типы. В таблице лежат и нешумовые слои — их отдельно читает блок гидрологии (9c) ниже в том же файле: ``` highway 5 616 есть в NOISE_L_BASE railway 1 994 есть в NOISE_L_BASE industrial 585 есть в NOISE_L_BASE utility 1 487 -> дефолт 50 дБ water 870 -> дефолт 50 дБ ``` Ключа в `NOISE_L_BASE` у них нет, поэтому `.get(key, 50.0)` выдавал им ровно **50 дБ** — значение, совпадающее с порогом попадания в список источников. На `origin/main` тест печатает дефект буквально: ``` AssertionError: нешумовой слой попал в источники шума: [{'source_type': 'water', 'name': 'Пруд', 'distance_m': 10, 'estimated_db': 50.0}] ``` Второе, менее заметное: `LIMIT 30` берётся **по близости**, поэтому вода вытесняла настоящие источники. ## Замер (прод, 19.08, 1 000 участков, детерминированная выборка по cad_num) ``` занятых слотов LIMIT 30 19 755 из них вода и коммуникации 8 797 (44.5%) участков, теряющих хотя бы 1 источник 562 участков, теряющих ВИДИМЫЙ источник 0 из 729 участков, где меняется максимум дБ 0 ``` **Честно про масштаб:** видимого эффекта у вытеснения нет — все вытесненные источники оказались тише порога 50 дБ, максимум дБ не меняется ни у одного участка. Видимый дефект — только водоём ближе 10 м. Правка убирает не столько видимую поломку, сколько скрытый потолок: почти половина бюджета `LIMIT` уходила на строки, которые скорер не умеет оценивать. ## Ловушка, из-за которой правка не в одну строку Очевидный вариант — добавить фильтр и оставить `noise_sources_count=len(noise_rows)` — **сломал бы треть участков**. `_compute_confidence` спрашивает «загружена ли шумовая карта» и при нуле пишет «Шумовая карта не загружена — noise score = stub». А у **345 участков из 1 000** в радиусе 2 км нет ни одного шумового источника при наличии воды. После наивной правки они получили бы это утверждение — неверное: карта загружена, просто рядом тихо. До правки верный ответ там выходил **по случайности** — ровно потому, что в счёт шли нешумовые строки. Поэтому покрытие карты считается отдельным дешёвым `COUNT(*)` (таблица целиком — 10.5 тыс. строк), а параметр переименован в `noise_map_rows_nearby`, чтобы смысл не приходилось угадывать. ## Проверка | тест | `origin/main` | с правкой | наивный вариант фикса | |---|---|---|---| | `test_water_not_reported_as_noise_source` | **красный** (`'water' in {'water'}`) | зелёный | зелёный | | `test_no_false_map_not_loaded_caveat...` | зелёный | зелёный | **красный** | Второй тест — контроль: он зелёный по обе стороны от правки, но краснеет, если считать покрытие по отфильтрованному списку. Проверено подстановкой наивного варианта, не рассуждением. `pytest tests/api/v1` на **уже перебазированном** дереве (то есть на том коде, что уйдёт в мерж): **348 passed, 1 skipped, rc=0**, сторож пропусков молчит. ## Побочно: мок parcel_meta переведён на сигнатуры `test_analyze_parcel_meta.py` раздавал ответы `db.execute` по **порядковому номеру вызова**. Добавление любого запроса выше по коду ломало его — следы в истории самого файла (#29 G2, затем #2464 cluster B), и мой запрос покрытия сломал бы снова. Такое падение говорит не о `parcel_meta`, ради которого написан файл, а о том, что кто-то добавил блок выше. Переведён на матчинг по сигнатуре SQL — приём уже применён в соседнем `test_analyze_market_price.py`, где эта хрупкость описана в докстринге. Проверено, что мок не потерял зубы: со специально сломанной сигнатурой тест краснеет. И что миграция сама по себе ничего не меняет: на `origin/main` он тоже зелёный. Refs #2464

bot-backend added 1 commit 2026-08-19 12:21:42 +00:00

fix(ptica): шумовой скорер перестаёт считать водоёмы источниками шума (#2464-G)

CI Trade-In / changes (pull_request) Successful in 8s

Details

CI / changes (pull_request) Successful in 9s

Details

CI Trade-In / backend-tests (pull_request) Has been skipped

Details

CI Trade-In / browser-tests (pull_request) Has been skipped

Details

CI Trade-In / frontend-checks (pull_request) Has been skipped

Details

CI / frontend-tests (pull_request) Has been skipped

Details

CI / openapi-codegen-check (pull_request) Successful in 2m4s

Details

CI / backend-tests (pull_request) Successful in 16m57s

Details

959246a6ec

Запрос шума брал из osm_noise_sources_ekb ВСЕ типы. В таблице лежат и нешумовые
слои — water (870 строк) и utility (1487), их отдельно читает блок гидрологии.
Для скорера они мусор: ключа в NOISE_L_BASE нет, поэтому .get(key, 50.0) выдавал
им ровно 50 дБ — значение, совпадающее с порогом попадания в список источников.

Замер 19.08 на 1000 участков (детерминированная выборка по cad_num): 19755
занятых слотов LIMIT 30, из них 8797 (44.5%) — вода и коммуникации; 562 участка
теряли из-за этого хотя бы один настоящий источник.

Честно про эффект: сегодня пользователь этого почти не видит. Все вытесненные
источники оказались тише порога 50 дБ (участков, теряющих ВИДИМЫЙ источник: 0 из
729), максимум дБ не меняется ни у одного. Видимый дефект — только водоём ближе
10 м, попадающий в список как источник на 50 дБ. Правка убирает не столько
видимую поломку, сколько скрытый потолок: почти половина бюджета LIMIT уходила
на строки, которые скорер не умеет оценивать.

Отдельный запрос на покрытие шумовой карты — не педантизм, а условие
корректности. _compute_confidence спрашивает «загружена ли карта» (при нуле пишет
«Шумовая карта не загружена — noise score = stub»), а у 345 участков из 1000 в
радиусе 2 км нет НИ ОДНОГО шумового источника при наличии воды. Наивный вариант
фикса (фильтр + len(noise_rows)) соврал бы этой трети. До правки верный ответ там
получался случайно — ровно потому, что в счёт шли нешумовые строки. Параметр
переименован в noise_map_rows_nearby, чтобы смысл не приходилось угадывать.

Тест на эту ловушку зелёный по обе стороны, но краснеет на наивном варианте —
проверено подстановкой.

Мок в test_analyze_parcel_meta.py переведён с позиционной нумерации db.execute на
матчинг по сигнатуре SQL: добавление любого запроса выше по коду ломало его
(следы в истории — #29 G2, #2464 cluster B), давая красный CI без отношения к
предмету теста. Тот же приём уже применён в test_analyze_market_price.py.

Переформатирование assert-сообщения — от pre-commit ruff 0.7.4 (#2864), не моё.