Механизм редактирования векторных данных в GeoMixer WEB-GIS

Материал из GIS-Lab
Перейти к навигации Перейти к поиску
Эта страница является черновиком статьи.


Техническое описание реализации механизма редактирования векторных данных в GeoMixer WEB-GIS

Введение

Исторически основной задачей Web-GIS была визуализация данных. Широкое распространение интернета позволило решить проблему доступности данных, а стремительное развитие браузеров и расширение возможностей HTTP предоставило новые возможности работы с пространственной информацией.

Самые первые варианты web сервисов доступа к картам просто показывали статические картинки со стрелочками для перемещения в соседние области. Затем появился Google Maps с возможностью таскать карту мышкой и спутниковым покрытием на весь мир.

На следующем шаге браузеры прокачали свои возможности по работе с векторными данными: появились VML и SVG, а позже Canvas и WebGL. Это позволило не просто рендерить картинки на сервере, а передавать клиенту исходные векторные данные для отрисовки в браузере. Интерактивность и анимация географических данных не заставили себя долго ждать…

Логичным продолжением этой тенденции является возможность создавать и модифицировать векторные данные непосредственно в браузере. Хорошим примером развития возможностей редактирования в web является проект OpenStreetMap. Сначала появился редактор, написанный на Java, потом возник проект редактора в браузере, написанный на Flash, который в настоящее время уступает место полностью HTML редактору iD. Редактирование непосредственно в браузере даже такой большой базы данных как OSM сейчас стало реальностью.

В ГеоМиксере так же относительно недавно появилась возможность редактировать данные векторных слоёв. Технические подробности реализации этого функционала и являются основным содержанием данной статьи.

Что нам нужно для счастья

При реализации редактирования векторных объектов мы ставили перед собой следующие задачи:

  • Сразу же после окончания редактирования пользователь видит свои изменения на карте. Никаких перезагрузок страниц, повторной загрузки всех данных и т.п. Для мира десктопных ГИС это естественное требование, но в Web пока что бывают варианты...
  • Пользователи видят обновления данных без перезагрузки карты. Это важный момент для реализации оперативных проектов и для совместного редактирования данных.
  • Механизм редактирования должен одинаково хорошо работать с разными по форме правками: единичные изменения данных, массовые вставки/редактирования, постоянные небольшие изменения отдельных объектов и т.п.
  • Применение механизма редактирования не должно приводить к уменьшению эффективности работы с картой. Не важно, как добавились данные на карту - вручную объект за объектом или сразу всей кучей из файла - всегда система должна работать одинаково быстро.

Пользовательский интерфейс

В GeoMixer’е в данный момент есть несколько способов редактировать объекты:

  • На панели инструментов есть специальный инструмент “Редактирование”. После его включения можно кликнуть на объекте на карте и отредактировать границу и атрибуты объекта.
  • Из контекстного меню слоя можно добавить новый объект в данный слой. При этом геометрию можно выбрать из нарисованных на карте.
  • Из таблицы атрибутов слоя можно редактировать, удалять и добавлять новые объекты.
  • Можно кликнуть правой кнопкой на любой нарисованной геометрии на карте и добавить её в активный слой как новый объект (будет предложено отредактировать таблицу атрибутов)
  • Есть отдельный плагин "AddToMap" для быстрого добавления новых объектов в активный слой. Пользователь кликает на иконке в тулбаре, сразу же рисует геометрию и сохраняет новый объект.

Примеры использования редактирования в ГеоМиксере

Механизм редактирования объектов в GeoMixer’е уже описывался в применении к проекту ГИС-Лаб по созданию слоя геоданных по детским учреждениям Российской Федерации.

Ряд тематических проектов СканЭкс активно используют редактирование векторных данных непосредственно в GeoMixer’е: это и проект по Половодью и по мониторингу свалок в Мурманской области и ряд других. При этом редактирование непосредственно в Геопортале имеет ряд преимуществ: можно легко совмещать разные растровые данные, подгружать названия населённых пунктов, использовать адресный поиск, быстро переместиться в любую точку мира и т.д. Многие из этих операций затруднены в классических десктопных ГИС-системах.

Geomixer editing example.png

Пример оцифрованной в GeoMixer’е области затопления по набору оперативных космических снимков.

Ещё одним примером использования механизма редактирования можно считать карту “Культура Подмосковья” Министерства Культуры Российской Федерации. Сначала данные были подготовлены во внешней программе и импортированы в ГеоМиксер. Далее привязка и атрибутика объектов редактировалась (и продолжает редактироваться) непосредственно на карте без выгрузки в другие программы.

Из интересных примеров использования механизма редактирования можно привести пример одного из охотхозяйств, которые заказали в СканЭксе карту своей территории. Кроме статических данных они хотели сами добавлять данные о местах обитания животных. Этот механизм был реализован на основе Web-интерфейса и успешно используется заказчиками по сей день (к сожалению, проект закрытый, и ссылку дать не получается).

Технический раздел

Клац-клац-клац

Первое, что необходимо при редактировании - собственно пользовательский интерфейс изменения и создания геометрии в бразуере. Когда Yandex или Google предлагают Вам нарисовать схему прохода к офису, скорость работы этого механизма не сильно важна (лишь бы было людям удобно). Но если вы вдруг решите подредактирвоать какую-нибудь границу Москвы из нескольких тысяч точек, то эффективность используемого подхода станет критичным.

В ГеоМиксере используется довольно простая схема из трёх SVG элементов: линия для отображения на экране, линия для взаимодействия с пользователем (она невидима, но более толстая, чтобы было удобней хватать мышью) и геометрия типа “мультиточка” для рисования вершин ломанных. Пересечение ломанных с курсором мыши высчитывает браузер, а всё остальные - уже сам ГеоМиксер.

Сравнить производительность инструментов редактирования можно на специально подготовленной страничке (замечания и улучшения к исходному репозиторию приветствуются!)

Тайлы, диффы и другая серверная жуть

Требование обновлять данные в клиенте “на лету” вызывает сразу несколько проблем: как понять, какая версия данных есть у конкретного клиента, как эффективно передать ему обновления, как не загрузить сервер при регулярных вставках объектов и т.п.

Сначала пару слов про форматы данных. На сервере все объекты векторных слоёв хранятся в двух видах: как записи в таблице БД и в виде векторных тайлов, готовых для отдачи клиенту. БД выступает в роли надёжного транзакционного хранилища и обеспечивает эффективный поиск данных, а тайлы используются для передачи в бразуер и оптимизированы для визуализации на клиенте. Создание тайлов (тайлинг) - довольно ресурсоёмкая и в общем случае нелокальная операция (может затронуть большое количество тайлов при небольших изменениях).

Geomixer editing naive sequence.png

Последовательность действий при простейшей реализации редактирования

Тайлинг нужно учитывать при изменении данных на сервере. Давайте рассмотрим самый простой и естественный вариант: клиент передаёт изменения на сервер, где они заносятся в БД и сразу же тайлятся (см. схему выше). После окончания тайлинга клиент получает ответ типа “всё ок”.

Такая схема порождает проблемы двух видов:

  • Рассинхронизация данных между клиентом и сервером. У клиента уже новые данные, а сервер может отдавать только старые тайлы. Стоит перезагрузить страницу до окончания процесса тайлинга - и пользователь не увидит своих последних изменений. Обычно такое развитие событий огорчает людей.
  • Проблема "синхронного тайлинга". В описанной схеме серверу нужно перетайлить всё как можно быстрее, а начинать тайлинг нужно немедленно после получения обновления. Что делать, если в процессе тайлинга пришли новые данные? Как быть с регулярно обновляемыми слоями?

Для решения этих проблем мы внесли в схему ряд улучшений (см схему ниже).

Таблица необработанных данных и асинхронный тайлинг

На сервере заводится специальная таблица, содержащая изменённые, но ещё не натайленные данные (diffs). Отдельные потоки (threads) тайлинга отслеживают изменения в этой таблице и при необходимости запускают новый процесс. В тайлах меняются только обновившиеся объекты, без полного переформирования.

Временные изменения

Данные слоя в ГеоМиксере состоят теперь из друх частей: списка тайлов с данными и временных обновлений (diffs), которые ещё не успели натайлиться. Когда пользователь внёс изменения в слой, эти изменения сразу же попадают в список временных обновлений. Этот список передаётся на клиент каждый раз вместе с остальной информацией о слое. Клиент просто игнорирует данные из тайлов по объектам этого списка. Каждый тайл имеет версию, и когда сервер обработает очередную порцию изменений, клиенту поступит новое описание слоя без временных изменений, но с новыми версиями тайлов. Таким образом поддерживается постоянная согласованность данных между клиентом и сервером вне зависимости от длительности процесса тайлинга.

Благодаря передачи на клиент ненатайленных изменений появляется много возможностей по управлению и оптимизации процесса тайлинга. Например, можно накапливать изменения в отдельных слоях (10 изменений натайлить за один раз быстрее, чем 10 раз по одному изменению), выставлять приоритеты для разных типов данных и т.п.

Geomixer editing sequence.png

Последовательность действий при редактировании в GeoMixer

Заключение

Web-GIS постоянно совершенствуются, реализуя всё больше возможностей, которые раньше были доступны только в десктопных приложениях. Возможность изменять исходные геоданные - естественный шаг на этом пути.

В GeoMixer’е мы не просто реализовали формальную возможность отсылать изменения на сервер, мы постарались сделать удобный механизм для совместной работы над векторными данными. Для этого пришлось реализовать ряд нововведений: поддержка версий слоёв и отдельных векторных тайлов, отдельная таблица с необработанными изменениями на сервере, передача временных изменений на клиент. Всё это существенно улучшило стабильность и удобство редактирования пространственных данных в web-клиенте.