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

Эта страница является черновиком статьи.

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Последовательность действий при редактировании данных в ГеоМиксере

Заключение

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

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