lekss361/gendesign

Fork 0

Кадастр: bulk NSPD grid-walk структурно теряет дома (покрытие МКД ~25-30%) — нужен анализ + денсер-сетка #1785

New issue

Closed

opened 2026-06-19 14:00:34 +00:00 by lekss361 · 6 comments

lekss361 commented

2026-06-19 14:00:34 +00:00

Owner

Антон (@Light1YT), посмотри/проанализируй — нашёл потолок текущего метода наполнения кадастра, влияет на trade-in геокодинг.

Контекст

Trade-in падал на части адресов (address_not_geocoded, 15 за 60 дней у praktika/kopylov/user2): автокомплит резолвит адрес, но /estimate геокодил строку заново через cad_buildings, а там дыры. Чинибельный primary-фикс — Variant A (передаём координаты из автокомплита, PR #1782/#1783). Но параллельно проверил полноту самой базы кадастра.

Что сделал

Пере-запустил ekb_full харвест (job #23, 2026-06-19): 2408/2408 кварталов, 585k запросов, 0 WAF, 0 ошибок, ~2ч10м. Прирост: 38,114 → 48,509 зданий (+10,395), МКД 4,019 → 4,775 (+756).

Проблема (главное)

Прирост есть, но конкретные дома он не берёт — bulk grid-walk структурно лоссовый:

4 тест-адреса (Космонавтов 7б, Космонавтов 26а, Фрунзе 75, Педагогическая 15) — 0/4 даже после полного харвеста. Их кварталы обработаны, в них десятки зданий, но именно эти дома отсутствуют.
Пример: квартал 66:41:0205009 (Космонавтов 7б) = 1784 × 1612 м (~2.9 км²). Grid-walk сетка 7×7 = 49 точек, шаг ~255 м. WMS GetFeatureInfo отдаёт фичи только под сэмплированным пикселем → всё между точками сетки теряется. Дом 7 есть в квартале (соседи 5б, 11б), но между точками — пропущен.
МКД 4,775 vs реальные ~15-20k по ЕКБ → покрытие жилых МКД ~25-30%.
Харвестится 2408 из 11048 кварталов cad_quarters_geom.

Гипотезы для анализа

Денсер grid-walk: grid_n сейчас хардкод 7 (bulk_harvest.py GRID_WALK_CATS, get_features_in_bbox_grid). Шаг 255м → при grid_n=13-15 шаг ~120-135м, ловит кратно больше. Цена — ×3-4 запросов на квартал. Стоит ли делать adaptive grid_n по размеру/плотности квартала?
grid_n не выставляется через admin API (CreateCadastreJobRequest: scope/quarters/limit/rate_ms). Добавить параметр?
NSPD snapshot жёстко 20 объектов/категория без пагинации — это фундамент проблемы для плотных кварталов.
Альтернатива bulk: есть ли у НСПД массовый дамп зданий по кадастр-кварталу (objects-list по objdocId уже частично есть — list_objects_in_building)?

Связанное

PR #1780 (кадастр-матчер геокодера — резолв из своей базы по улица+дом, 60% упавших), #1782/#1783 (Variant A координаты).
Vault: research/Cadastral_Matching_Scoping_Jun18, code/modules/NSPD_Bulk_Client, domains/cadastre/Cad_Buildings_Schema_v2.

Прямо сейчас тестирую денсер-сетку (grid_n=15) по кварталу Космонавтова — приложу результат в коммент. Твой взгляд по 1-4 нужен.

Антон (@Light1YT), посмотри/проанализируй — нашёл потолок текущего метода наполнения кадастра, влияет на trade-in геокодинг. ## Контекст Trade-in падал на части адресов (`address_not_geocoded`, 15 за 60 дней у praktika/kopylov/user2): автокомплит резолвит адрес, но `/estimate` геокодил строку заново через cad_buildings, а там дыры. Чинибельный primary-фикс — Variant A (передаём координаты из автокомплита, PR #1782/#1783). Но параллельно проверил полноту самой базы кадастра. ## Что сделал Пере-запустил `ekb_full` харвест (job #23, 2026-06-19): 2408/2408 кварталов, 585k запросов, **0 WAF, 0 ошибок, ~2ч10м**. Прирост: **38,114 → 48,509 зданий (+10,395)**, МКД **4,019 → 4,775 (+756)**. ## Проблема (главное) Прирост есть, но **конкретные дома он не берёт** — bulk grid-walk структурно лоссовый: - 4 тест-адреса (Космонавтов 7б, Космонавтов 26а, Фрунзе 75, Педагогическая 15) — **0/4 даже после полного харвеста**. Их кварталы обработаны, в них десятки зданий, но именно эти дома отсутствуют. - Пример: квартал `66:41:0205009` (Космонавтов 7б) = **1784 × 1612 м (~2.9 км²)**. Grid-walk сетка **7×7 = 49 точек, шаг ~255 м**. WMS GetFeatureInfo отдаёт фичи только под сэмплированным пикселем → всё между точками сетки теряется. Дом 7 есть в квартале (соседи 5б, 11б), но между точками — пропущен. - МКД 4,775 vs реальные ~15-20k по ЕКБ → покрытие жилых МКД **~25-30%**. - Харвестится **2408 из 11048** кварталов `cad_quarters_geom`. ## Гипотезы для анализа 1. **Денсер grid-walk**: `grid_n` сейчас хардкод 7 (`bulk_harvest.py` GRID_WALK_CATS, `get_features_in_bbox_grid`). Шаг 255м → при grid_n=13-15 шаг ~120-135м, ловит кратно больше. Цена — ×3-4 запросов на квартал. Стоит ли делать adaptive grid_n по размеру/плотности квартала? 2. **`grid_n` не выставляется через admin API** (`CreateCadastreJobRequest`: scope/quarters/limit/rate_ms). Добавить параметр? 3. NSPD snapshot жёстко 20 объектов/категория без пагинации — это фундамент проблемы для плотных кварталов. 4. Альтернатива bulk: есть ли у НСПД массовый дамп зданий по кадастр-кварталу (objects-list по objdocId уже частично есть — `list_objects_in_building`)? ## Связанное - PR #1780 (кадастр-матчер геокодера — резолв из своей базы по улица+дом, 60% упавших), #1782/#1783 (Variant A координаты). - Vault: `research/Cadastral_Matching_Scoping_Jun18`, `code/modules/NSPD_Bulk_Client`, `domains/cadastre/Cad_Buildings_Schema_v2`. Прямо сейчас тестирую денсер-сетку (grid_n=15) по кварталу Космонавтова — приложу результат в коммент. Твой взгляд по 1-4 нужен.

lekss361 commented

2026-06-19 14:06:37 +00:00

Author

Owner

КЛЮЧЕВАЯ находка (live-проба сейчас) — дело не в плотности сетки, WMS grid-walk СЛОМАН на стороне НСПД

Прогнал прямой тест по кварталу 66:41:0205009 (Космонавтов) через NSPDBulkClient в проде:

1. Snapshot работает и показывает реальный масштаб дыры:

search_by_quarter("66:41:0205009").meta_counts:
  36369 (Здания) = 754      ← НСПД знает про 754 здания в квартале
  37163 (Помещения) = 15126
  36368 (ЗУ) = 95
per-cat snapshot 36369 вернул: 143 features

→ В квартале 754 здания, snapshot отдаёт 143 (~19%), у нас в базе 34.

2. Grid-walk (механизм добора сверх snapshot) — HTTP 500 на КАЖДОЙ ячейке:

wms_feature_info(layer_id=36369, ...) для 5 ячеек сетки 7×7:
  cell 0/12/24/36/48 → 500 ServiceException (InternalServerError)
GET https://nspd.gov.ru/api/aeggis/v4/36369/wms?REQUEST=GetFeatureInfo&...
  → <ServiceExceptionReport><ServiceException code="InternalServerError">

Стабильно, не транзиент (snapshot тем же клиентом в той же сессии — ОК). Это ровно layer_..._failed: true, что светилось в phase_state job #23.

3. Следствие: денсер grid_n (7→15) бесполезен — каждая ячейка всё равно 500. job #23 сделал 585k запросов, но grid-walk почти ничего не добрал; +10k зданий пришли из snapshot'ов, не из сетки. Поэтому МКД застряли на ~25-30%, а конкретные дома (Космонавтов 7б и т.д.) не попали.

Вопрос к тебе (Антон) сместился

Не «увеличить grid_n», а найти рабочий способ enumeration зданий по кварталу вместо мёртвого WMS GetFeatureInfo:

WMS aeggis/v4/{layer}/wms отдаёт 500 — это поменялось у НСПД (раньше работало, см. NSPD_Bulk_Client от 05-17), или нужен другой param/endpoint?
Есть ли пагинация у search/geoportal (snapshot сейчас cap 143/754)?
list_objects_in_building(objdocId) даёт помещения по зданию — можно ли симметрично получить список зданий по objdocId квартала (37163=15126 помещений → обратный путь к зданиям)?
HAR-аудит НСПД 2026-06: как карта nspd.gov.ru сейчас грузит здания в квартале (через playwright)?

754 здания в одном квартале vs 34 у нас — потенциал огромный, но текущий механизм добора не работает. Это блокер дозалива.

## КЛЮЧЕВАЯ находка (live-проба сейчас) — дело не в плотности сетки, WMS grid-walk СЛОМАН на стороне НСПД Прогнал прямой тест по кварталу `66:41:0205009` (Космонавтов) через `NSPDBulkClient` в проде: **1. Snapshot работает и показывает реальный масштаб дыры:** ``` search_by_quarter("66:41:0205009").meta_counts: 36369 (Здания) = 754 ← НСПД знает про 754 здания в квартале 37163 (Помещения) = 15126 36368 (ЗУ) = 95 per-cat snapshot 36369 вернул: 143 features ``` → В квартале **754 здания, snapshot отдаёт 143 (~19%), у нас в базе 34.** **2. Grid-walk (механизм добора сверх snapshot) — HTTP 500 на КАЖДОЙ ячейке:** ``` wms_feature_info(layer_id=36369, ...) для 5 ячеек сетки 7×7: cell 0/12/24/36/48 → 500 ServiceException (InternalServerError) GET https://nspd.gov.ru/api/aeggis/v4/36369/wms?REQUEST=GetFeatureInfo&... → <ServiceExceptionReport><ServiceException code="InternalServerError"> ``` Стабильно, не транзиент (snapshot тем же клиентом в той же сессии — ОК). Это ровно `layer_..._failed: true`, что светилось в `phase_state` job #23. **3. Следствие:** денсер grid_n (7→15) бесполезен — каждая ячейка всё равно 500. job #23 сделал 585k запросов, но grid-walk почти ничего не добрал; **+10k зданий пришли из snapshot'ов, не из сетки**. Поэтому МКД застряли на ~25-30%, а конкретные дома (Космонавтов 7б и т.д.) не попали. ## Вопрос к тебе (Антон) сместился Не «увеличить grid_n», а **найти рабочий способ enumeration зданий по кварталу вместо мёртвого WMS GetFeatureInfo**: - WMS `aeggis/v4/{layer}/wms` отдаёт 500 — это поменялось у НСПД (раньше работало, см. `NSPD_Bulk_Client` от 05-17), или нужен другой param/endpoint? - Есть ли пагинация у `search/geoportal` (snapshot сейчас cap 143/754)? - `list_objects_in_building(objdocId)` даёт помещения по зданию — можно ли симметрично получить **список зданий по objdocId квартала** (37163=15126 помещений → обратный путь к зданиям)? - HAR-аудит НСПД 2026-06: как карта nspd.gov.ru сейчас грузит здания в квартале (через playwright)? 754 здания в одном квартале vs 34 у нас — потенциал огромный, но текущий механизм добора не работает. Это блокер дозалива.

lekss361 commented

2026-06-19 14:11:19 +00:00

Author

Owner

IP/VPN-гипотезу исключил — WMS-эндпоинт мёртв серверно, не rate-limit

Прогнал тот же WMS-запрос с локальной машины (другой IP, не прод) через curl -k:

Запрос	Прод-IP	Локальный IP
`GET /api/aeggis/v4/36369/wms?REQUEST=GetFeatureInfo&...`	500	500 (тот же ServiceException InternalServerError, 0.36s)
`GET /api/geoportal/v2/search/geoportal?thematic=1&query=66:41:0205009`	200	200 (FeatureCollection)

→ 500 идентичный с любого IP → НСПД задеприкейтил/сломал сам эндпоинт aeggis/v4/{layer}/wms?GetFeatureInfo, это не блок нашего IP. VPN/ротация прокси НЕ поможет. search работает отовсюду, но cap ~143/754.

Что это значит для дозалива

Grid-walk через WMS GetFeatureInfo (наш текущий механизм добора сверх snapshot, см. NSPD_Bulk_Client 05-17) больше не существует на стороне НСПД. Нужен новый рабочий endpoint enumeration зданий по кварталу.

Браузер-дебаг карты НСПД (чтобы увидеть, чем карта сейчас грузит здания) отсюда не снять — у nspd.gov.ru российский CA-серт (ERR_CERT_AUTHORITY_INVALID), мой Playwright-MCP не игнорит cert. Антон — нужен HAR-аудит nspd.gov.ru/map в твоём окружении (playwright с ignoreHTTPSErrors=true или браузер с РФ-CA): посмотреть, какой запрос карта шлёт при загрузке зданий в видимом квартале — это и будет замена мёртвому WMS.

Кандидаты, что карта могла переехать на: vector tiles (/mvt), geoportal/v2/search/geoportal_item, geoportal/v1/intersects по полигону квартала. Нужен твой HAR чтобы подтвердить.

## IP/VPN-гипотезу исключил — WMS-эндпоинт мёртв серверно, не rate-limit Прогнал тот же WMS-запрос **с локальной машины (другой IP, не прод)** через `curl -k`: | Запрос | Прод-IP | Локальный IP | |---|---|---| | `GET /api/aeggis/v4/36369/wms?REQUEST=GetFeatureInfo&...` | 500 | **500** (тот же ServiceException InternalServerError, 0.36s) | | `GET /api/geoportal/v2/search/geoportal?thematic=1&query=66:41:0205009` | 200 | **200** (FeatureCollection) | → **500 идентичный с любого IP → НСПД задеприкейтил/сломал сам эндпоинт `aeggis/v4/{layer}/wms?GetFeatureInfo`, это не блок нашего IP. VPN/ротация прокси НЕ поможет.** `search` работает отовсюду, но cap ~143/754. ## Что это значит для дозалива Grid-walk через WMS GetFeatureInfo (наш текущий механизм добора сверх snapshot, см. `NSPD_Bulk_Client` 05-17) **больше не существует на стороне НСПД**. Нужен новый рабочий endpoint enumeration зданий по кварталу. **Браузер-дебаг карты НСПД** (чтобы увидеть, чем карта сейчас грузит здания) **отсюда не снять** — у nspd.gov.ru российский CA-серт (`ERR_CERT_AUTHORITY_INVALID`), мой Playwright-MCP не игнорит cert. Антон — нужен HAR-аудит nspd.gov.ru/map в твоём окружении (playwright с `ignoreHTTPSErrors=true` или браузер с РФ-CA): посмотреть, какой запрос карта шлёт при загрузке зданий в видимом квартале — это и будет замена мёртвому WMS. Кандидаты, что карта могла переехать на: vector tiles (`/mvt`), `geoportal/v2/search/geoportal_item`, `geoportal/v1/intersects` по полигону квартала. Нужен твой HAR чтобы подтвердить.

lekss361 commented

2026-06-19 14:18:50 +00:00

Author

Owner

✅ РЕШЕНО через debug-браузер: НСПД мигрировал ID слоёв. Это НЕ IP/VPN и НЕ просто плотность — корень в мёртвом layer id.

Снял HAR карты nspd.gov.ru/map (через реальный браузер с РФ-CA). Карта использует active_layers=36049,36071 и layers-theme-tree?themeId=1. Достал дерево слоёв:

layers-theme-tree (themeId=1):
  36048 = "Земельные участки из ЕГРН"   ← был 36368
  36049 = "Здания"                       ← был 36369

Проба WMS GetFeatureInfo по новому слою (квартал Космонавтова 66:41:0205009):

Слой	Результат
36369 (старый «Здания»)	500 InternalServerError (мёртв)
36049 (новый «Здания»)	200 OK, FeatureCollection ✅

Grid-walk на 36049, рост по плотности:

grid_n	ячеек	зданий	дом 7?
7	49	6	нет
15	225	17	нет
25	625	34	✅ «пр-кт Космонавтов, дом 7б / 7в / 7а»

0 ошибок на всех ячейках 36049. Дом 7б — тот, на котором падал trade-in — захватывается при layer=36049 + grid_n=25.

Фикс (предлагаю PR, нужен твой sanity-check по нюансу)

backend/app/services/cadastre/bulk_harvest.py:

Grid-walk WMS layer: 36368 → 36048, 36369 → 36049.
ВАЖНЫЙ нюанс — разошлись id-пространства: search_by_quarter (snapshot) в meta_counts всё ещё отдаёт старые категории (видел live: {..., 36368: 95, 36369: 754, ...}), а WMS-слой теперь новый (36048/36049). Т.е. overflow-детекция по snapshot читает 36369, а grid-walk должен бить в 36049. Нужен явный маппинг search_category → wms_layer (36369→36049, 36368→36048), а не глобальная замена константы. Иначе meta_counts.get(CAT_BUILDING) сломается.
grid_n adaptive: сейчас хардкод 7 (шаг ~255м на квартале 1.8км). Поднять до ~25 (шаг ~70м) или делать adaptive по размеру bbox квартала. Цена: 625 vs 49 запросов/квартал × 2408 ≈ 1.5M запросов на full (vs 590k). Прогон #23 прошёл 0 WAF, так что выдержит, но дольше (~5-6ч).

Антон — подтверди подход (особенно п.2 маппинг) и нет ли у НСПД bulk-feature эндпоинта получше grid-walk'а (слой 36071 в active_layers отдал 772КБ одним запросом — что это за слой и нет ли «все здания в bbox» одним вызовом?). Дальше оформлю PR в bulk_harvest.py.

## ✅ РЕШЕНО через debug-браузер: НСПД мигрировал ID слоёв. Это НЕ IP/VPN и НЕ просто плотность — корень в мёртвом layer id. Снял HAR карты nspd.gov.ru/map (через реальный браузер с РФ-CA). Карта использует `active_layers=36049,36071` и `layers-theme-tree?themeId=1`. Достал дерево слоёв: ``` layers-theme-tree (themeId=1): 36048 = "Земельные участки из ЕГРН" ← был 36368 36049 = "Здания" ← был 36369 ``` ### Проба WMS GetFeatureInfo по новому слою (квартал Космонавтова 66:41:0205009): | Слой | Результат | |---|---| | 36369 (старый «Здания») | **500 InternalServerError** (мёртв) | | **36049 (новый «Здания»)** | **200 OK, FeatureCollection** ✅ | ### Grid-walk на 36049, рост по плотности: | grid_n | ячеек | зданий | дом 7? | |---|---|---|---| | 7 | 49 | 6 | нет | | 15 | 225 | 17 | нет | | **25** | **625** | **34** | **✅ «пр-кт Космонавтов, дом 7б / 7в / 7а»** | 0 ошибок на всех ячейках 36049. **Дом 7б — тот, на котором падал trade-in — захватывается при layer=36049 + grid_n=25.** ## Фикс (предлагаю PR, нужен твой sanity-check по нюансу) `backend/app/services/cadastre/bulk_harvest.py`: 1. **Grid-walk WMS layer**: `36368 → 36048`, `36369 → 36049`. 2. **ВАЖНЫЙ нюанс — разошлись id-пространства**: `search_by_quarter` (snapshot) в `meta_counts` всё ещё отдаёт **старые** категории (видел live: `{..., 36368: 95, 36369: 754, ...}`), а **WMS-слой теперь новый** (36048/36049). Т.е. overflow-детекция по snapshot читает 36369, а grid-walk должен бить в 36049. Нужен явный маппинг `search_category → wms_layer` (36369→36049, 36368→36048), а не глобальная замена константы. Иначе `meta_counts.get(CAT_BUILDING)` сломается. 3. **grid_n adaptive**: сейчас хардкод 7 (шаг ~255м на квартале 1.8км). Поднять до ~25 (шаг ~70м) или делать adaptive по размеру bbox квартала. Цена: 625 vs 49 запросов/квартал × 2408 ≈ 1.5M запросов на full (vs 590k). Прогон #23 прошёл 0 WAF, так что выдержит, но дольше (~5-6ч). Антон — подтверди подход (особенно п.2 маппинг) и нет ли у НСПД bulk-feature эндпоинта получше grid-walk'а (слой 36071 в active_layers отдал 772КБ одним запросом — что это за слой и нет ли «все здания в bbox» одним вызовом?). Дальше оформлю PR в `bulk_harvest.py`.

lekss361 commented

2026-06-19 14:27:56 +00:00

Author

Owner

✅✅ РЕШЕНИЕ дозалива: НЕ НСПД, а геопортал Екатеринбурга (open WFS, bulk, полнее НСПД)

По наводке владельца проверил геопортал.екатеринбург.рф (= punycode xn--80afgznagjs...). Vault это уже разведал 2026-06-06 (research/EKB_Geoportal_WFS_Construction_Intel_Jun06, EKB_Geoportal_PZZ_Content_API_Jun06): открытый GeoServer WFS, 1149 слоёв, без авторизации, нормальный TLS, OWS /api/gis/ows/3/portal/{wfs|wms|wmts}.

Live-проба сейчас (с локальной машины):

WFS GetFeature bulk по bbox работает — GET /api/gis/ows/3/portal/wfs?...&typeNames=portal:portal_geo_adr_capital_build&CQL_FILTER=BBOX(geoloc,60.600,56.855,60.620,56.872)&count=10000 → 200, 406 КБ, 103 здания одним запросом (vs NSPD grid-walk 34 точечно). Поля богатые: g_street_2, g_house_2, adr_material, adr_building_type, adr_purpose, adr_fire_resist, ....
Здание, которое НСПД пропустил — ЕСТЬ. POST /api/gis/spatialObject/searchByGeom {geoJsonGeometries:[POINT(60.611164 56.863409)], layerKeys:[10221]} (Космонавтов 7б) → вернул TopoBuild key=1000010816536809, точный MultiPolygon-контур на координатах. Слой «500_ЗДАНИЯ, СТРОЕНИЯ / Здания, строения и их части», dataset обновлён 2025-08-11.
Карточка: GET /api/card/portal/TopoBuild/{key} → Улица / Номер дома / Материал / Этажность / Тип здания (пример: «Ленина, 39, Камень»).

Ключевые building-слои (из GetCapabilities):

portal_geo_adr_capital_build — адресные капитальные (street/house в полях, 103/bbox)
portal_geo_adr_point_all_build / _active_build — адресные точки (вернули 0 на geoloc-BBOX → другое geom-поле, проверить)
TopoBuild (layerKey 10221) — топографические контуры зданий, полное покрытие + свежее (2025-08), geometry-rich (адрес — через карточку/join с adr-слоями)
portal_geo_gkn_oks / gkn_oksall_glv_arch — ОКС ЕГРН

Trade-in импакт закрыт через геопортал (#1786), 2026-06-20

Параллельный маршрут — реестр зданий городского геопортала ЕКБ (ekb_geoportal_buildings, отдельный geocoder-tier ДО cad_buildings, #1786) — докачан полностью: 34735 зданий, полное покрытие bbox ЕКБ (8484/8484 тайлов WFS).

4 контрольных адреса из этого issue (были 0/4 в NSPD grid-walk) теперь резолвятся 4/4 — проверено end-to-end через geocode() in-container (tradein-backend):

Адрес	lat/lon	conf
Космонавтов 7б	56.86315 / 60.60758	exact
Космонавтов 26а	56.88311 / 60.62028	exact
Фрунзе 75	56.81197 / 60.59784	exact
Педагогическая 15	56.83529 / 60.65583	exact

Геопортал-tier (_geoportal_house_match, exact street_norm+house_norm) полнее NSPD (~70% зданий ЕКБ отсутствуют в NSPD) и закрывает trade-in симптом address_not_geocoded без зависимости от densing NSPD-сетки.

Структурный вопрос densing grid-walk NSPD (grid_n, adaptive сетка, пагинация snapshot) — остаётся за тобой, @Light1YT, как отдельный анализ полноты кадастровой базы (она нужна не только для геокода). Этот issue можно держать открытым под NSPD-анализ либо закрыть, если геопортал принимается как итоговое решение для геокода — на твоё/Антона усмотрение.

## Trade-in импакт закрыт через геопортал (#1786), 2026-06-20 Параллельный маршрут — реестр зданий **городского геопортала ЕКБ** (`ekb_geoportal_buildings`, отдельный geocoder-tier ДО cad_buildings, #1786) — докачан полностью: **34735 зданий**, полное покрытие bbox ЕКБ (8484/8484 тайлов WFS). **4 контрольных адреса из этого issue (были 0/4 в NSPD grid-walk) теперь резолвятся 4/4** — проверено end-to-end через `geocode()` in-container (`tradein-backend`): | Адрес | lat/lon | conf | |---|---|---| | Космонавтов 7б | 56.86315 / 60.60758 | exact | | Космонавтов 26а | 56.88311 / 60.62028 | exact | | Фрунзе 75 | 56.81197 / 60.59784 | exact | | Педагогическая 15 | 56.83529 / 60.65583 | exact | Геопортал-tier (`_geoportal_house_match`, exact street_norm+house_norm) полнее NSPD (~70% зданий ЕКБ отсутствуют в NSPD) и закрывает trade-in симптом `address_not_geocoded` без зависимости от densing NSPD-сетки. **Структурный вопрос densing grid-walk NSPD (grid_n, adaptive сетка, пагинация snapshot)** — остаётся за тобой, @Light1YT, как отдельный анализ полноты кадастровой базы (она нужна не только для геокода). Этот issue можно держать открытым под NSPD-анализ либо закрыть, если геопортал принимается как итоговое решение для геокода — на твоё/Антона усмотрение.

lekss361 commented

2026-06-20 05:58:59 +00:00

Author

Owner

Закрываю — актуальность отпала. NSPD grid-walk densing не нужен: геокод house-level для trade-in полностью закрыт реестром городского геопортала ЕКБ (ekb_geoportal_buildings, 34735 зданий, #1786) как отдельным geocoder-tier'ом до cad_buildings. 4/4 контрольных адреса резолвятся (см. коммент выше). Если кадастровая полнота NSPD понадобится под другую задачу (не геокод) — завести отдельный issue.

Закрываю — актуальность отпала. NSPD grid-walk densing не нужен: геокод house-level для trade-in полностью закрыт реестром городского геопортала ЕКБ (`ekb_geoportal_buildings`, 34735 зданий, #1786) как отдельным geocoder-tier'ом до cad_buildings. 4/4 контрольных адреса резолвятся (см. коммент выше). Если кадастровая полнота NSPD понадобится под другую задачу (не геокод) — завести отдельный issue.

lekss361 closed this issue

2026-06-20 05:59:00 +00:00