Я давно занимаюсь не с картами как таковыми, а пространственными данными как инженерным продуктом. Обычно задачи начинаются с разрозненных источников: реестры, api, OSM, кадастры, большие XML, таблицы. А заканчивается нормальным рабочим результатом: адресной базой, spatial dataset, аналитикой или сервисом.

Здесь я буду показывать свои реальные кейсы:
- ГАР/ФИАС и его изменения, возможно даже много;
- пространственные адресные базы;
- иногда OSM и анализ покрытия;
- geospatial data engineering;
- автоматизацию GIS-процессов;
- свои сервисы и data products;
- иногда технические ошибки, ограничения и решения, которые оказались неочевидными

Портфолио:
evgenybelavsky.com
Данные и сервисы:
data.evgenybelavsky.com
Сервис Address Data Service
https://data.evgenybelavsky.com/address-service/

Я регулярно отслеживаю изменения в ГАР/ФИАС, и за первые восемь месяцев 2026 года в обработанных мной обновлениях появилось 2,011,153 новых адресных объекта.

По месяцам динамика выглядит так:
Январь - 84 900
Февраль - 276 747
Март - 302 098
Апрель - 261 200
Май - 300 116
Июнь - 278 365
Июль - 277 671
Август - 230 056

Важное уточнение: речь здесь именно о новых адресных объектах, хотя все изменения включают в себя изменение иерархии, статус, связи и другие параметры. Скоро приведу такой пример, который отнял у меня несколько часов на разбирательство.
Динамика изменений - максимальное значение - март, 302098 новых записей, далее по июль стабильно высокая динамика, а август - минус 17% от июля.

С одной стороны, 2 млн новых адресов могут показаться огромным количеством, но точки зрения крупнейших картографических сервисов, это не такая значительная величина - так как большинство, ну я думаю 70-80% этих адресов уже есть, вопрос только насколько они актуальны, я встречал такие случаи, когда на картографическом сервисе адрес, условно: СНТ "Иванушка" дом 15, а в добавленных в ГАР записях в этом СНТ уже все улицы имеют названия.

#данные

ООН поддержала резолюцию стран Ариканского союза об отказе от Web Mercator, чтобы африканские страны выглядели пропорционально относительно других стран

Сначала они лутали магазины в Париже, а теперь они будут измерять расстояния и азимуты в равновеликой проекции :)
Справедливости ради, Меркатор действительно изменяет визуальное восприятие в зависимости от широты:
на 40° площадь выглядит ~в 1,7 раза больше;
на 50° ~в 2,4 раза;
на 60° ~в 4 раза;
на 70° ~в 8,5 раза.

Хотел еще пошутить, про картографию в африканских странах, но в некоторых из них реально есть крутые национальные картографические сервисы, например, в ЮАР есть nationwide address databases и полноценные routable street datasets.

#Картография

Месяц назад я собрал в единый структурированный набор административно-адресную иерархию Единого адресного реестра Таджикистана ADM1-ADM4 + улицы и провел первое сравнение. Объекты сравниваются по стабильным идентификаторам, причины понятны, но в реестре Таджикистана встречаются и такие особенности, когда один и тот же объект может быть представлен 2 видами записи, например Чамоати/Ҷамоати - для реестра это один и тот же объект, а для строкового diff это два разных значения. поэтому производится нормализация: дехаи/Дехаи/деҳаи. Также, я проверяю id объекта и его родителя, чтобы измененная иерархия объекта попадала в diff.
Первое сравнение показало 0 изменений иерархических объектов. Изменения произошли только в счетчике количества адресов: 196,533 → 142,347 (-54,16 адресов или -27,6%).
Но это агрегированный показатель а не сами данные. Непосредственно за адресов я пока не брался, это будет попозже.
#Данные

Вот реально, в текущем реестре чуть более 4 тыс записей. Но мне кажется, что большая масса данных взята из какого-то старого кадастра и внесена реестр практически без проверок и правок, хотя бОльшу часть ошибок можно исправить автоматически. Примеры:
ADM3 - джамоаты / шаҳрак (и для ADM4 тоже самое)
Одновременно используется: Чамоати - 412, Ҷамоати - 6, чамоати - 2, ҷамоати - 2, ҷамоъати - 1.
Для шаҳрак: шахраки - 51, шаҳраки - 1, плюс шахраки-1, шахраки-2, шаҳри.
Улицы: при стандартной таджикской форме Кӯчаи, в реестре встречаются варианты (а стандартная форма практически отсутствует): Кучаи - 1 642, кучаи - 619, Кучи - 18, КуЧаи - 1, КУчаи - 1, кчаи - 1, Кчаи - 1, кучаиА. - 1
Разный регистр географических названий и в ADM3 и в улицах: Оби Шифо/Оби шифо, 1-Май/1-май - очень много.
Диакритика внутри самих географических названий: Истиклол/Истиқлол, Дехконобод/Деҳқонобод, С.Айни/С.Айнӣ - очень много.
Пробелы: 916 значений с пробелами в начале или конце строки, 742 записей имеют двойные или множественные пробелы
Перевод на английский все четко до ADM2. Кроме одной технической ошибки: Devash­tich District - между словами стоит невидимый символ U+00AD SOFT HYPHEN, который повторяется во всех строках, не наследуется этот район. глазами ошибку Devashtich District/Devash<SOFT HYPHEN>tich District не найти, хотя это разные строки.
#Данные

За последнее время я собралл в один сервис несколько операций, которые раньше делал вручную. Задача есть территория → нужны актуальные адреса ГАР/ФИАС в координатах (сам ГАР это просто текстовые записи).
Обычно последовательности такая: НСПД → ЗУ+ОКС → кадастровый номер → ГАР/ФИАС → матчинг → QGIS. Это достаточно затратно по времени, при чем на всех этапах, поэтому я сначала для себя, а потом и для коллег по цеху создал облачный сервис.

Что он делает:
1. Пользователь подтверждает что он не бот (полноценная регистрация пользователя не нужна, первичная регистрация и вход объединены в один passwordless flow: пользователь указывает email, получает magic link и после перехода автоматически создаётся/активируется его сессия)
2. Пользователь рисует область на карте (веб-карта реализована на Leaflet: обзорная CARTO Positron и стандартный OSM + геокодер Nominatim) и запускает процесс.
3. Сервис сам собирает данные, проводит сопоставления с НСПД и ФИАС, и формирует геопекадж с двумя слоями. Почему два слоя – ниже.
4. Пользователь скачивает результат, который сразу, без танцев с бубном готов к работе.

Особенности готового геопекаджа:
- сохранена полная структура ГАР/ФИАС (я оставил только один идентификатор FIAS ID, чтобы можно было проверить адрес прямо на сайте ФИАСа, иначе в файле более 100 полей)
- содержит одно созданное поле, которое не является структурой ФИАСа: address_number. Почему такая реализация: в исходных XML—таблицах номера домов для объектов капитального строительства и земельных участков разнесены по разным полям (и в готовом геопекадже также) + номера корпуса, строения находятся в отдельном столбце – именно поэтому для удобства address_number содержит полный номер адреса
- 2 слоя: точечный и площадной: точечный слой адресов содержит две сущности: адрес строения и адрес земельного участка. Со строением все понятно – точка попадает на центр домика на снимке. А адрес земельного участка – это центроид непосредственно земельного участка. При большом объеме данных бывает трудно сориентироваться на какой домик сдвигать точку, а когда есть граница ЗУ – «область поиска» необходимого строения сразу ограничена. Ну и я хочу вообще поручить эту задачу (сдвиг точки на строение) не человеку, а нейросети, поэтому и нужны границы участка. Адресная точка ЗУ и границы ЗУ связаны одинаковым ID.

Сейчас, пока тестовый период и пока работает только один воркер, есть ограничения: площадь обработки: 1 на 1 км, 10 кредитов с одной почты (и да, почтовые алиасы с гугловой почты уже не работают 😜).

Ссылка на сервис: https://data.evgenybelavsky.com/address-service/

#ГАР #АдресныеДанные #Инструменты

Вот кстати, интересный кейс: два ОКС с одинаковым адресом: респ. Башкортостан, м.р-н Уфимский, с.п. Жуковский сельсовет, СНТ Озон, д.54. Но для ГАР это два разных объекта: дом и строение.

#ГАР #АдресныеДанные #Инструменты

Как работает pipeline Address Data Service
В интерфейсе всё выглядит довольно просто: нарисовал AOI, нажал Start, получил GeoPackage. Но внутри сам процесс разбит на несколько этапов:
- обращение к НСПД и поиск объектов по AOI;
- обращение к ГАР/ФИАС и поиск соответствий;
- нормализация;
- пространственная сборка;
- формирование GeoPackage.

Каждый этап сохраняет промежуточный результат. С одной стороны, это увеличивает объём промежуточных данных, с другой сильно упрощает диагностику, когда что-то пошло не так. В результат попадают только актуальные записи. Актуальность, если коротко, определяется группой признаков
ISACTUAL=1 означает, что это последняя версия записи по объекту, но сама запись при этом ещё не обязательно действующая. Поэтому отдельно проверяется:
ISACTUAL = 1
ISACTIVE = 1
Затем выбирается текущий кадастровый параметр:
TYPEID = 8
CHANGEIDEND = 0
После этого адрес собирается по актуальной административной или муниципальной иерархии.
То есть простое совпадение кадастрового номера с записью в XML ещё не означает, что найден актуальный адрес.

Если совсем коротко, логика выглядит так:
CURRENT GAR OBJECT =
ISACTUAL = 1
AND ISACTIVE = 1

CURRENT CADASTRAL LINK =
TYPEID = 8
AND CHANGEIDEND = 0
 
CURRENT ADDRESS =
current object
+ current cadastral link
+ current hierarchy

Чтобы получить из множества XML-таблиц актуальный на момент работы сервиса адрес, при подготовке текущей модели ГАР обрабатываются 7 основных семейств XML-таблиц (в полном архиве это 672 целевых XML-файла) + 7 справочников типов объектов.

Пользователю отдаётся результат только с идентификатором FIAS ID, чтобы можно было проверить наличие и актуальность записи прямо на стороне ФИАС (Я уже встречал случай, когда в течение трёх месяцев адрес сначала был создан, затем изменился номер здания, а в СНТ всем проездам присвоили названия улиц. Все эти изменения потом вылезли в дельтах). При этом в базе сохраняется полная версия с полным набором идентификаторов.

Скорость обработки сейчас — около 2–3 минут для получения 1,5–2 тыс. адресов.
То есть пользовательский запрос уже не работает напрямую с полной исторической массой ГАР. Он работает с подготовленной актуальной моделью, а вся тяжёлая логика по фильтрации, сопоставлению и проверке актуальности остаётся внутри pipeline.

Дальнейшие планы: автоматизация обработки дельт, чтобы не скачивать ежемесячно полный файл ГАР и не пересобирать с нуля материализованные витрины, которые использует pipeline.

#ГАР #АдресныеДанные #Инструменты

Разобрал картографический веб-сервис одного из OSINT-проектов.
Что показывает этот сервис: закрытие российских аэропортов в связи с беспилотной опасностью.
Чем зацепила глаз карта: я заметил что Калининград находится примерно на тех же широтах что и Мурманск. При более детальном взгляде на регионы РФ - регионы имеют поворот.

Спойлер: все в порядке, просто на фронте используется равновеликая коническая проекция Albers Equal-Area Conic

Все остальные данные - границы и аэропорты - обычные JSONы с координатами в EPSG 4326, которые в браузере пересчитываются в коническую библиотекой Apache ECharts.

Почему использована такая проекция - могу предположить, чтобы не "рвалась" Чукотка при отображении всей территории РФ в Меркаторе. и чтобы сильно вытянутая по долготе территория РФ отображалась более компактно. Какие данные используются:
Регионы РФ: проект Click That 'Hood, репозиторий https://github.com/codeforgermany/click_that_hood, 2013 года, при этом данные были модифицированы - добавлен как минимум один объект, который не отображается на веб ресурсе, а таблица метаданных пустая. То есть это уже не исходный а модифицированный файл.

Аэропорты:
Данные отсюда: https://ourairports.com/ (это открытые данные, можно скачать отсюда: https://davidmegginson.github.io/ourairports-data/airports.csv)
Полный набор данных включает чуть более 86 тыс объектов, объектов на территории РФ - 219, на OSINT-ресурсе - 213. Из 219 объектов по РФ исключены 6 объектов, которые имеют признак Air Base, а именно: Kubinka Air Base - UUMB, Krechevitsy Air Base - ULLK, Kamenny Ruchey Naval Air Base - UHKG, Sredniy Island Air Base - UODS, Migalovo Air Base - UUEM, Chkalovskiy Air Base - UUMU. То есть фильтрация была примерно такая:
iso_country == "RU"
AND icao_code IS NOT NULL
AND type IN ("small_airport", "medium_airport", "large_airport")
AND name NOT LIKE "%Air Base%"

Идентификатор ourairports_ident, координаты и другие параметры объектов в JSONе OSINT-проекта и в данных ourairports.com совпадают.
К аэропортам подгружается динамическая информация о статусе и событиях.

Сервис безусловно сделан красиво. Кстати, анализ этого сайта подтолкнул меня к мысли, что пора сделать автоматизацию: браузерную утилиту, которая сама найдет JSON/GeoJSON-ресурсы страницы, покажет их структуру, определит CRC поля с координатами и скачает одной кнопкой данные виде нормального GeoJSON или GPKG для дальнейшего анализа.