ekburg_permits: _COORD_FIRST_RE требует дробную часть — целочисленные координаты МСК-66 теряют геопривязку молча #1607

New issue

Closed

opened 2026-06-16 17:18:59 +00:00 by bot-backend · 0 comments

bot-backend commented

2026-06-16 17:18:59 +00:00

Collaborator

Severity: medium · Категория: data-loss · Файл: backend/app/services/scrapers/ekburg_permits.py:86, 108-111

Файл: backend/app/services/scrapers/ekburg_permits.py:86 (regex) + 108-111 (использование). _COORD_FIRST_RE = re.compile(r'[\d]+[.,][\d]+') требует разделитель и дробную часть. Если ячейка raw_coord_x/y содержит координату целым числом метров ('1496944', '485000'), search возвращает None → msk66_to_wgs84 возвращает None (строка 111) → geocoded_lat/lon=None в _parse_row (строки 304-306). Воспроизведено: '1496944'→None, '485000'→None, '1496944.23'→match. PermitRow всё равно создаётся, потеря geom невидима в счётчиках parsed/skipped (_parse_sheet 435-444). Импакт: деградация geo-join земля↔застройщик (#1088) при рукописном Excel с целыми метрами. Фикс: разрешить целочисленную часть — regex r'[\d]+(?:[.,][\d]+)?', затем float(group().replace(',', '.')).

Почему баг: Реестры РНС/РВЭ ведутся вручную в Excel; координаты могут быть записаны целыми метрами или с другим форматированием без дробной части. Такие строки молча теряют геопривязку, при этом сам PermitRow создаётся (permit_number есть), т.е. ошибка не видна в счётчиках parsed/skipped. Это деградирует geo-join земля↔застройщик (#1088), для которого geom критичен.

Как чинить: Сделать дробную часть опциональной: re.compile(r"\d+(?:[.,]\d+)?"). Тогда и целые, и дробные координаты парсятся; невалидные всё равно отсечёт диапазонная проверка 1_450_000..1_600_000 по X и bbox по WGS84.

_{deep-audit backend v2 (после PR #1543) · verify+harden, confidence 0.7 · unit B33}

**Severity:** medium · **Категория:** data-loss · **Файл:** `backend/app/services/scrapers/ekburg_permits.py:86, 108-111` Файл: backend/app/services/scrapers/ekburg_permits.py:86 (regex) + 108-111 (использование). _COORD_FIRST_RE = re.compile(r'[\d]+[.,][\d]+') требует разделитель и дробную часть. Если ячейка raw_coord_x/y содержит координату целым числом метров ('1496944', '485000'), search возвращает None → msk66_to_wgs84 возвращает None (строка 111) → geocoded_lat/lon=None в _parse_row (строки 304-306). Воспроизведено: '1496944'→None, '485000'→None, '1496944.23'→match. PermitRow всё равно создаётся, потеря geom невидима в счётчиках parsed/skipped (_parse_sheet 435-444). Импакт: деградация geo-join земля↔застройщик (#1088) при рукописном Excel с целыми метрами. Фикс: разрешить целочисленную часть — regex r'[\d]+(?:[.,][\d]+)?', затем float(group().replace(',', '.')). **Почему баг:** Реестры РНС/РВЭ ведутся вручную в Excel; координаты могут быть записаны целыми метрами или с другим форматированием без дробной части. Такие строки молча теряют геопривязку, при этом сам PermitRow создаётся (permit_number есть), т.е. ошибка не видна в счётчиках parsed/skipped. Это деградирует geo-join земля↔застройщик (#1088), для которого geom критичен. **Как чинить:** Сделать дробную часть опциональной: `re.compile(r"\d+(?:[.,]\d+)?")`. Тогда и целые, и дробные координаты парсятся; невалидные всё равно отсечёт диапазонная проверка 1_450_000..1_600_000 по X и bbox по WGS84. --- <sub>deep-audit backend v2 (после PR #1543) · verify+harden, confidence 0.7 · unit B33</sub>