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

Вчера сделал первое обновление сервиса. Обновил данные - при первом запуске данные были от 01 сентября, теперь от 11 сентября. И стало работать на минуту быстрее. Был план (и он остается) - делать автоматические обновления прямо по дельтам - но не вывез. Поэтому обновление прошло по полному файлу ГАР и это хорошо - я фактически откатал полный пайплан от скачки 54ГБ файла до до подготовки витрин АДМ и МУН деления, откуда и формируется полный адрес ГАР. 54ГБ превращаются 7-8ГБ только актуальных записей без исторических, без машиномест, помещений и других ненужных данных. И в целом план такой: 2-4 месяца сервис обновляется дельтами, а потом полным файлом. Почему: дельты маленькие, но очень много таблиц, но все обновится за минуты: 300 тыс записей против 34 млн строения+24 млн ЗУ актуальных записей полного файла ГАР. Подготовка полного файла ГАР в АДМ/МУН витрины занимает около 8 часов. Но я пока опасаюсь, что обновления по дельтам могут копить ошибки, поэтому периодически планирую обновлять по полному файлу ГАР.
Ссылка на сервис: https://data.evgenybelavsky.com/address-service/

#Геосервисы #SpatialDataEngineering

Искусство заголовка :)
Здесь скорее речь идет о внутреннем (+ для клиентов СДЭКа) картографическом сервисе. Сейчас он сидит на Яндекс-картах и наверное хочет соскочить - стоимость геокодера, тайлового сервиса и поиска очень негуманная. Для крупной компании издержки могут составлять миллионы и сейчас уже возможно, десятки миллионов рублей в год. А У СДЭК как минимум 2 публичных сервиса на Я-картах + логистика на этих же картах. Могу предположить, что это будет картографический сервис аналогичный WB-картам, но под свои задачи. Кстати, есть что сказать про WB-карты

Как устроены карты WB: и карта ПВЗ (https://map.wb.ru), и сама карта (https://wb-maps.wb.ru) устроены одинаково – это тайлы MVT (Mapbox Vector Tiles), структура талов соответствует распространённой схеме представления OSM-данных в MVT. Структура атрибутики тоже характерна для данных ОСМ. Внешний вид определяется JSON-стилем, всего есть 372 правила оформления:
Линейные правила (line): 269
Площадные правила (fill): 44
Символы и подписи (symbol): 54
Маркеры (circle): 2
3D правила (fill-extrusion): 2
Фон (background): 1
Архитектурно, тайлы имеют 3 источника: planet, geodata и poi. При этом разделение проходит не строго по типам объектов: дороги и POI встречаются сразу в нескольких источниках. По видимому, это сделано для того, чтобы картографическое подразделение могло детализировать отдельные слои и объекты.

Принципиально, практически все исходные данные (хотя я не смотрел много, только Москву, область и Донецкую область) – это OSM, не только структура и содержание, но и идентификаторы конкретных объектов: в тайлах карты WB совпадают с идентификаторами тех же объектов в ОСМ. Можно было предположить, что это сделано для того, чтобы обновлять WB карты при изменении ОСМ, но на момент проверки фрагмента Мск в ОСМ точек подъезда (входы в здания) было больше, чем в данных WB карт, так же, диапазоны квартир для конкретных подъездов в ОСМ заполнено больше, чем в WB картах.
MVT тайлы WB-карт можно подключить прямо в QGIS и поиграться с ними, и даже сделать стили отображения условно близкое к web представлению. В целом, в WB-картах я не нашел каких-то значительных отличий от ОСМ (на проверяемых участках) со всем косяками ОСМ на просмотренных участках. Вероятно картографические подразделения в РФ, Узбекистане делают что-то что пока не видно стороннему наблюдателю. Может быть нацелены на картографию для именно такси и доставки на территории Белоруссии или Узбекистана.

#Геосервисы #SpatialDataEngineering

ЗD объекты (отдельные детализированные архитектурные объекты) на WB-картах реализованы через отдельные геопривязанные 3D-модели в формате glTF 2.0. Они загружаются HTTP-запросами из инфраструктуры статических ресурсов WB независимо от MVT-тайлов как отдельная пространственная сущность. Они имеют трёхмерную геометрию, материалы и текстуры. В исследованных файлах встречается THREE.GLTFExporter - инструмент экспорта из экосистемы Three.js.
Вокруг московского кремля я выловил 49 уникальных ЗD моделей (но это не 49 зданий, а именно моделей – т.к. конкретные здания могут состоять из нескольких моделей, например: Собор Василия Блаженного - 4 модели, стены кремля - несколько самостоятельных участков).
Я откуда все это знаю? Я ходил к ним собесы (несколько), изучал их продукт. Но не подошел, наверное квалификации не хватило хе-хе.

#Геосервисы #SpatialDataEngineering

Пару постов выше выше я упоминал про браузерную утилиту, которая облегчает жизнь инженера, когда лень долго копаться в сайтах, чтобы найти нужные геоданные. Дошли руки, сделал Spatial Data Hunter - сразу покажет, где геоданные или списки с цифрами, похожими на координаты, даст ссылку, сделает и скачает геоджсон. В целом - работает, иногда корявенько, но в текущих задачах справляется отлично. сейчас она зацепляет и векторные тайлы - надо будет это устранить, векторные тайлы - это отдельная задача, т.к. их нужно сажать в правильные СК и координаты, это исправлю в следующий раз, когда руки дойдут

Хотел сделать утилиту, которая превращала бы GeoPackage, наборы SHP или GeoJson в красивые GIS-видео.
В чем классность идеи - в том, что можно делать красвые видео на реальных данных и на реальном местоположении, отображая координаты, объемы, количество объектов, связи между ними, ареалы распространения во времени и т.д. И это все на реальных, проверяемых данных.
В целом, задача казалась выполнимой. Но только для небольшх и нескольких однотипных анимаций. Проблема возникла тогда, когда захотелось уйти от одинаковых видео или изменить сценарий. Если для 2-3 слоев еще реально вручную задать время и место анимации, то для бОльшего количества, где уже нужно приблизить камеру, потом показать отдельный счётчик, затем изменить масштаб, добавить подпись, задержать кадр и плюсом синхронизировать всё это между собой - это уже придется делать собственный видеоредактор.
Но зато теперь понятно как делать простейшие анимациии
Что использовалось: Python - логика сценария и последовательность появления объектов, на входе GeoPackage с 3 слоями библиотека Pillow, для создания и отрисовки отдельных кадров и FFmpeg для сборки и экспорта в MP4.

#ГИСИнструменты