Механизм редактирования векторных данных в GeoMixer WEB-GIS
Техническое описание реализации механизма редактирования векторных данных в 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’е области затопления по набору оперативных космических снимков.
Ещё одним примером использования механизма редактирования можно считать карту “Культура Подмосковья” Министерства Культуры Российской Федерации. Сначала данные были подготовлены во внешней программе и импортированы в ГеоМиксер. Далее привязка и атрибутика объектов редактировалась (и продолжает редактироваться) непосредственно на карте без выгрузки в другие программы.
Из интересных примеров использования механизма редактирования можно привести пример одного из охотхозяйств, которые заказали в СканЭксе карту своей территории. Кроме статических данных они хотели сами добавлять данные о местах обитания животных. Этот механизм был реализован на основе Web-интерфейса и успешно используется заказчиками по сей день (к сожалению, проект закрытый, и ссылку дать не получается).
Технический раздел
Клац-клац-клац
Первое, что необходимо при редактировании - собственно пользовательский интерфейс изменения и создания геометрии в бразуере. Когда Yandex или Google предлагают Вам нарисовать схему прохода к офису, скорость работы этого механизма не сильно важна (лишь бы было людям удобно). Но если вы вдруг решите подредактирвоать какую-нибудь границу Москвы из нескольких тысяч точек, то эффективность используемого подхода станет критичным.
В ГеоМиксере используется довольно простая схема из трёх SVG элементов: линия для отображения на экране, линия для взаимодействия с пользователем (она невидима, но более толстая, чтобы было удобней хватать мышью) и геометрия типа “мультиточка” для рисования вершин ломанных. Пересечение ломанных с курсором мыши высчитывает браузер, а всё остальные - уже сам ГеоМиксер.
Сравнить производительность инструментов редактирования можно на специально подготовленной страничке (замечания и улучшения к исходному репозиторию приветствуются!)
Тайлы, диффы и другая серверная жуть
Требование обновлять данные в клиенте “на лету” вызывает сразу несколько проблем: как понять, какая версия данных есть у конкретного клиента, как эффективно передать ему обновления, как не загрузить сервер при регулярных вставках объектов и т.п.
Сначала пару слов про форматы данных. На сервере все объекты векторных слоёв хранятся в двух видах: как записи в таблице БД и в виде векторных тайлов, готовых для отдачи клиенту. БД выступает в роли надёжного транзакционного хранилища и обеспечивает эффективный поиск данных, а тайлы используются для передачи в бразуер и оптимизированы для визуализации на клиенте. Создание тайлов (тайлинг) - довольно ресурсоёмкая и в общем случае нелокальная операция (может затронуть большое количество тайлов при небольших изменениях).
Последовательность действий при простейшей реализации редактирования
Тайлинг нужно учитывать при изменении данных на сервере. Давайте рассмотрим самый простой и естественный вариант: клиент передаёт изменения на сервер, где они заносятся в БД и сразу же тайлятся (см. схему выше). После окончания тайлинга клиент получает ответ типа “всё ок”.
Такая схема порождает проблемы двух видов:
- Рассинхронизация данных между клиентом и сервером. У клиента уже новые данные, а сервер может отдавать только старые тайлы. Стоит перезагрузить страницу до окончания процесса тайлинга - и пользователь не увидит своих последних изменений. Обычно такое развитие событий огорчает людей.
- Проблема "синхронного тайлинга". В описанной схеме серверу нужно перетайлить всё как можно быстрее, а начинать тайлинг нужно немедленно после получения обновления. Что делать, если в процессе тайлинга пришли новые данные? Как быть с регулярно обновляемыми слоями?
Для решения этих проблем мы внесли в схему ряд улучшений (см схему ниже).
Таблица необработанных данных и асинхронный тайлинг
На сервере заводится специальная таблица, содержащая изменённые, но ещё не натайленные данные (diffs). Отдельные потоки (threads) тайлинга отслеживают изменения в этой таблице и при необходимости запускают новый процесс. В тайлах меняются только обновившиеся объекты, без полного переформирования.
Временные изменения
Данные слоя в ГеоМиксере состоят теперь из друх частей: списка тайлов с данными и временных обновлений (diffs), которые ещё не успели натайлиться. Когда пользователь внёс изменения в слой, эти изменения сразу же попадают в список временных обновлений. Этот список передаётся на клиент каждый раз вместе с остальной информацией о слое. Клиент просто игнорирует данные из тайлов по объектам этого списка. Каждый тайл имеет версию, и когда сервер обработает очередную порцию изменений, клиенту поступит новое описание слоя без временных изменений, но с новыми версиями тайлов. Таким образом поддерживается постоянная согласованность данных между клиентом и сервером вне зависимости от длительности процесса тайлинга.
Благодаря передачи на клиент ненатайленных изменений появляется много возможностей по управлению и оптимизации процесса тайлинга. Например, можно накапливать изменения в отдельных слоях (10 изменений натайлить за один раз быстрее, чем 10 раз по одному изменению), выставлять приоритеты для разных типов данных и т.п.
Последовательность действий при редактировании в GeoMixer
Заключение
Web-GIS постоянно совершенствуются, реализуя всё больше возможностей, которые раньше были доступны только в десктопных приложениях. Возможность изменять исходные геоданные - естественный шаг на этом пути.
В GeoMixer’е мы не просто реализовали формальную возможность отсылать изменения на сервер, мы постарались сделать удобный механизм для совместной работы над векторными данными. Для этого пришлось реализовать ряд нововведений: поддержка версий слоёв и отдельных векторных тайлов, отдельная таблица с необработанными изменениями на сервере, передача временных изменений на клиент. Всё это существенно улучшило стабильность и удобство редактирования пространственных данных в web-клиенте.