Одним из недостатков использования механизма публикации геоданных на основе векторных тайлов является невозможность отображения данных в режиме real-time. Тайловый кэш всегда подготавливаются либо однократно, либо по заданному расписанию. Но очень хочется совместить скорость отображения больших массивов геоданных через MVT и возможность их онлайн-редактирования.

Первая реакция пользователей после внедрения MVT: мы только что нарисовали, где он на общей карте???
Путей решения может быть несколько:
— пытаться вместо тайлового кэша преобразовывать данные в MVT на лету из базы данных. Попробовали. Нагрузка на сервер БД 100% примерно всегда. Не подходит.
— пытаться обновлять кэш при обновлении записей в БД, применяя либо триггеры, либо другие событийные механизмы. Попробовали. Так как кэш мультимасштабный, обновление одного объекта даже самого маленького ведет к пересчету всех тайлов с ним, включая, например, тайл (0, 0, 0). Операции INSERT, UPDATE, DELETE выполняются долго, сервер также загружен на момент обновления. Не подходит.

В итоге остановились на следующем варианте. Рассматриваем ситуацию spatial таблицы в базе данных, которая только дополняется, т.е. записи в таблице никогда не удаляются. К примеру, практически все данные в ГИСОГД идут по такому принципу. Документы не удаляются, а помечаются как недействующие. Земельные участки не удаляются, а меняют статус на «Снят с кадастрового учета». Количество добавленных или измененных данных за день не велико и сильно меньше общего объема данных в таблице.

Источники геоданных публикуются по 2 маршрутам:
/collections/LandPlot/items — OGC API Features, напрямую из БД.
/collections/LandPlot/tiles/{tileMatrix}/{tileRow}/{tileCol} — OGC API Tiles, данные из тайлового кэша.
Особенностью новых стандартов является поддержка «из коробки» мультивременных данных. Это означает, что каждый источник на уровне запросов может поддерживать параметр datetime, определяющий за какой промежуток времени запросить данные. Например, открытый интервал: 2022-10-27T00:00:00Z/..
Таким образом для Features API мы можем запрашивать данные с момента последнего обновления тайлового кэша.

Синхронизируем на клиенте. К примеру, для OpenLayers наследуемся от класса ol/source/VectorTile, перегружаем tileLoadFunction и делаем параллельный запрос к OGC API Features с учетом даты последнего обновления тайлового кэша, объединяем данные по идентификаторам. По итогу с точки зрения клиента слой остается один, стиль отображения также един, но данные берутся из 2 источников.
Поход чем-то близок по духу к Lambda Architecture:
— горячие (Hot) данные по ветке OGC API Tiles. Запрашиваются быстро, часто, регулярно, большой объем.
— холодные (Cold) данные по ветке OGC API Features. Запрашиваются медленнее, содержат полную информацию (как графику, так и семантику объектов).
Ну и фактически подход объединения геоданных разной степени «прожарки» может быть применен для источников не на основе OGC API. Главное – синхронизация по времени.

Если вы осилили дочитать до конца, теперь у нас онлайн-редактор больших объемов данных (несколько миллионов — тестировали, но принципиальных технических ограничения нет и на больший объем) с быстрым отображением. Это крутая техническая фича, позволяет выйти на объемы типа «один редактируемый слой зданий на всю страну» без дебильных ухищрений.

Звоните, пишите, если хотите у себя такой редактор: https://samis.geosamara.ru/