GIS-Lab - Вклад [ru]

GISConf - служба помощи

2015-11-11T16:02:44Z

Parshin:

На конференции Открытые ГИС планируется создать "Службу помощи" - отдельную стойку или стол, где каждый сможет подойти и задать свои вопросы одному из экспертов.

==Как работает==
В этой секции работает группа умудренных экспертов, каждый из которых готов потратить от 30 до 60 минут своего времени на ответы по ГИС и около тематики.
Предполагается помещение на 5-7 человек для консультаций. На экране ноутбука (идеально - компьютер с двумя мониторами) эксперт может показать какие-то наглядные вещи.
Данный формат общения будет работать как минимум один день конференции.

Компетенция эксперта может быть как технологической, так и тематической (например, GeoServer или Геомаркетинг). Для каждого эксперта можно определить круг компетенций (основная, второстепенные, "где-то что-то слышал").

==Эксперты==
Имя и Фамилия. День, в который готов выступить. Время, которое готов потратить. '''Основные компетенции'''. Второстепенные компетенции. ''Ориентируюсь''.

{| class="wikitable"
|-
! Имя
! Даты
! Время, ч
! Компетенции (основные)
! Компетенции (второстепенные)
|-
|Андрей Жуков
|21-22
|2
|GeoServer, картографические стили
|QGIS, Python
|-
|Максим Дубинин
|21-22
|0.5-1
|Развертывание, лицензирование
|
|-
|Дмитрий Колесов
|21-22
|1
|GRASS GIS, обработка данных
|
|-
|Александр Мурый
|21-22
|1-2
|GRASS GIS, GDAL, QGIS, shell+Python, Linux, OSGeo-Live, обработка ЦМР
|3D (Paraview, Meshlab), SAGA, другое СПО
|-
|Владислав Филиппов
|21-22
|1
|GeoServer, GeoServer+GeoWebCache
|QGIS, Python, OpenLayers
|-
|Александр Клешнин
|21-22
|1
|QGIS, PostGIS, GeoServer, web-картографические приложения на базе Leaflet, получение данных из OpenStreetMap
|
|-
|Никита Лаврентьев
|21
|1-2
|QGIS, общие вопросы
| Ubuntu и работа в СПО целом, веб-картография, ДДЗ
( космическая съемка, аэрофотосъемка с БПЛА)
|-
|Александр Паршин
|21-22
|1
|Leaflet и приложения на её основе
|
|-
|}

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

2014-05-21T14:39:35Z

Parshin:

{{Статья|Черновик}}

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

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

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

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

Логичным продолжением этой тенденции является возможность создавать и модифицировать векторные данные непосредственно в браузере. Хорошим примером развития возможностей редактирования в web является проект OpenStreetMap. Сначала появился [http://josm.openstreetmap.de/ редактор], написанный на Java, потом возник проект [http://wiki.openstreetmap.org/wiki/Potlatch_2 редактора в браузере], написанный на Flash, который в настоящее время уступает место полностью HTML редактору [http://ideditor.com/ iD]. Редактирование непосредственно в браузере даже такой большой базы данных как OSM сейчас стало реальностью.

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

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

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

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

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

Механизм редактирования объектов в ГеоМиксере [http://gis-lab.info/qa/geomixer-editing.html уже описывался] в применении к [http://gis-lab.info/qa/geodetdom.html проекту ГИС-Лаб] по созданию слоя геоданных по детским учреждениям Российской Федерации.

В ряде тематических проектов СканЭкс активно используется редактирование векторных данных непосредственно в ГеоМиксере: это и [http://press.scanex.ru/index.php/ru/massmedia/item/3894-t-comm проект по Половодью] и по мониторингу свалок в Мурманской области и ряд других. При этом редактирование в Геопортале имеет ряд преимуществ: можно легко совмещать разные растровые данные, подгружать названия населённых пунктов, использовать адресный поиск, быстро переместиться в любую точку мира и т.д. Многие из этих операций затруднены в классических десктопных ГИС-системах.

[[Файл:Geomixer_editing_example.png|700px|center]]
''Пример оцифрованной в ГеоМиксере области затопления по набору оперативных космических снимков.''

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

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

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

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

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

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

Сравнить производительность инструментов редактирования можно на специально подготовленной [http://aparshin.github.io/editing-tools-testing/ страничке] (замечания и улучшения к [https://github.com/aparshin/editing-tools-testing исходному репозиторию] приветствуются!)

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

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

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

[[Файл:Geomixer_editing_naive_sequence.png|700px|center]]
''Последовательность действий при простейшей реализации редактирования''

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

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

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

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

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

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

[[Файл:Geomixer_editing_sequence.png|700px|center]]
''Последовательность действий при редактировании данных в ГеоМиксере''

== Заключение ==

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

В ГеоМиксере мы не просто реализовали формальную возможность отсылать изменения на сервер, мы постарались сделать удобный механизм для совместной работы над векторными данными. Для этого пришлось реализовать ряд нововведений: поддержка версий слоёв и отдельных векторных тайлов, отдельная таблица с необработанными изменениями на сервере, передача временных изменений на клиент. Всё это существенно улучшило стабильность и удобство редактирования пространственных данных в web-клиенте.
==Ссылки==
* [http://gis-lab.info/qa/geomixer.html Краткий обзор GeoMixer WEB-GIS]
* [http://geomixer.ru/ Сайт Geomixer.ru]
* [http://gis-lab.info/qa/geomixer-multitemporal-layers.html Мультивременные слои в GeoMixer WEB-GIS]
* [http://gis-lab.info/qa/geomixer-editing.html Редактирование векторных слоев с помощью GeoMixer на примере геоданных по детским учреждениям]

Редактирование векторных данных в GeoMixer WEB-GIS

2014-05-21T14:18:05Z

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

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

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

2014-05-21T14:18:05Z

{{Статья|Черновик}}

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

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

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

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

Логичным продолжением этой тенденции является возможность создавать и модифицировать векторные данные непосредственно в браузере. Хорошим примером развития возможностей редактирования в web является проект OpenStreetMap. Сначала появился [http://josm.openstreetmap.de/ редактор], написанный на Java, потом возник проект [http://wiki.openstreetmap.org/wiki/Potlatch_2 редактора в браузере], написанный на Flash, который в настоящее время уступает место полностью HTML редактору [http://ideditor.com/ iD]. Редактирование непосредственно в браузере даже такой большой базы данных как OSM сейчас стало реальностью.

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

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

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

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

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

Механизм редактирования объектов в ГеоМиксере [http://gis-lab.info/qa/geomixer-editing.html уже описывался] в применении к [http://gis-lab.info/qa/geodetdom.html проекту ГИС-Лаб] по созданию слоя геоданных по детским учреждениям Российской Федерации.

Ряд тематических проектов СканЭкс активно используют редактирование векторных данных непосредственно в ГеоМиксере: это и [http://press.scanex.ru/index.php/ru/massmedia/item/3894-t-comm проект по Половодью] и по мониторингу свалок в Мурманской области и ряд других. При этом редактирование непосредственно в Геопортале имеет ряд преимуществ: можно легко совмещать разные растровые данные, подгружать названия населённых пунктов, использовать адресный поиск, быстро переместиться в любую точку мира и т.д. Многие из этих операций затруднены в классических десктопных ГИС-системах.

[[Файл:Geomixer_editing_example.png|700px|center]]
''Пример оцифрованной в ГеоМиксере области затопления по набору оперативных космических снимков.''

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

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

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

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

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

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

Сравнить производительность инструментов редактирования можно на специально подготовленной [http://aparshin.github.io/editing-tools-testing/ страничке] (замечания и улучшения к [https://github.com/aparshin/editing-tools-testing исходному репозиторию] приветствуются!)

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

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

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

[[Файл:Geomixer_editing_naive_sequence.png|700px|center]]
''Последовательность действий при простейшей реализации редактирования''

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

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

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

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

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

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

[[Файл:Geomixer_editing_sequence.png|700px|center]]
''Последовательность действий при редактировании данных в ГеоМиксере''

== Заключение ==

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

В ГеоМиксере мы не просто реализовали формальную возможность отсылать изменения на сервер, мы постарались сделать удобный механизм для совместной работы над векторными данными. Для этого пришлось реализовать ряд нововведений: поддержка версий слоёв и отдельных векторных тайлов, отдельная таблица с необработанными изменениями на сервере, передача временных изменений на клиент. Всё это существенно улучшило стабильность и удобство редактирования пространственных данных в web-клиенте.
==Ссылки==
* [http://gis-lab.info/qa/geomixer-editing.html Редактирование векторных слоев с помощью Geomixer]
* [http://gis-lab.info/qa/geomixer.html Краткий обзор GeoMixer WEB-GIS]
* [http://geomixer.ru/ Сайт Geomixer.ru]
* [http://maps.kosmosnimki.ru/api/index.html Онлайн версия Geomixer]
* [http://kosmosnimki.ru/ Сайт Kosmosnimki.ru]

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

2014-05-20T15:29:44Z

Parshin: Вычитал

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

2014-05-20T15:15:35Z

Parshin: Добавил картинки

{{Статья|Черновик}}

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

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

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

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

Логичным продолжением этой тенденции является возможность создавать и модифицировать векторные данные непосредственно в браузере. Хорошим примером развития возможностей редактирования в web является проект OpenStreetMap. Сначала появился [http://josm.openstreetmap.de/ редактор], написанный на Java, потом возник проект [http://wiki.openstreetmap.org/wiki/Potlatch_2 редактора в браузере], написанный на Flash, который в настоящее время уступает место полностью HTML редактору [http://ideditor.com/ iD]. Редактирование непосредственно в браузере даже такой большой базы данных как OSM сейчас стало реальностью.

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

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

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

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

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

Механизм редактирования объектов в GeoMixer’е [http://gis-lab.info/qa/geomixer-editing.html уже описывался] в применении к [http://gis-lab.info/qa/geodetdom.html проекту ГИС-Лаб] по созданию слоя геоданных по детским учреждениям Российской Федерации.

Ряд тематических проектов СканЭкс активно используют редактирование векторных данных непосредственно в GeoMixer’е: это и [http://press.scanex.ru/index.php/ru/massmedia/item/3894-t-comm проект по Половодью] и по мониторингу свалок в Мурманской области и ряд других. При этом редактирование непосредственно в Геопортале имеет ряд преимуществ: можно легко совмещать разные растровые данные, подгружать названия населённых пунктов, использовать адресный поиск, быстро переместиться в любую точку мира и т.д. Многие из этих операций затруднены в классических десктопных ГИС-системах.

[[Файл:Geomixer_editing_example.png|700px|center]]
''Пример оцифрованной в GeoMixer’е области затопления по набору оперативных космических снимков.''

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

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

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

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

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

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

Сравнить производительность инструментов редактирования можно на специально подготовленной [http://aparshin.github.io/editing-tools-testing/ страничке] (замечания и улучшения к [https://github.com/aparshin/editing-tools-testing исходному репозиторию] приветствуются!)

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

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

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

[[Файл:Geomixer_editing_naive_sequence.png|700px|center]]
''Последовательность действий при простейшей реализации редактирования''

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

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

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

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

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

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

[[Файл:Geomixer_editing_sequence.png|700px|center]]
''Последовательность действий при редактировании в GeoMixer''

== Заключение ==

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

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

Файл:Geomixer editing naive sequence.png

2014-05-20T15:09:48Z

Parshin:

Файл:Geomixer editing example.png

2014-05-20T15:06:02Z

Parshin:

Файл:Geomixer editing sequence.png

2014-05-20T15:05:12Z

Parshin:

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

2014-05-20T14:01:34Z

Parshin: Добавил ссылки

{{Статья|Черновик}}

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

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

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

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

Логичным продолжением этой тенденции является возможность создавать и модифицировать векторные данные непосредственно в браузере. Хорошим примером развития возможностей редактирования в web является проект OpenStreetMap. Сначала появился [http://josm.openstreetmap.de/ редактор], написанный на Java, потом возник проект [http://wiki.openstreetmap.org/wiki/Potlatch_2 редактора в браузере], написанный на Flash, который в настоящее время уступает место полностью HTML редактору [http://ideditor.com/ iD]. Редактирование непосредственно в браузере даже такой большой базы данных как OSM сейчас стало реальностью.

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

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

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

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

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

Механизм редактирования объектов в GeoMixer’е [http://gis-lab.info/qa/geomixer-editing.html уже описывался] в применении к [http://gis-lab.info/qa/geodetdom.html проекту ГИС-Лаб] по созданию слоя геоданных по детским учреждениям Российской Федерации.

Ряд тематических проектов СканЭкс активно используют редактирование векторных данных непосредственно в GeoMixer’е: это и [http://press.scanex.ru/index.php/ru/massmedia/item/3894-t-comm проект по Половодью] и по мониторингу свалок в Мурманской области и ряд других. При этом редактирование непосредственно в Геопортале имеет ряд преимуществ: можно легко совмещать разные растровые данные, подгружать названия населённых пунктов, использовать адресный поиск, быстро переместиться в любую точку мира и т.д. Многие из этих операций затруднены в классических десктопных ГИС-системах.

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

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

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

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

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

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

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

Сравнить производительность инструментов редактирования можно на специально подготовленной [http://aparshin.github.io/editing-tools-testing/ страничке] (замечания и улучшения к [https://github.com/aparshin/editing-tools-testing исходному репозиторию] приветствуются!)

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

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

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

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

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

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

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

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

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

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

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

== Заключение ==

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

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

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

2014-05-16T07:39:48Z

Parshin: Новая страница: «{{Статья|Черновик}} Техническое описание реализации механизма редактирования векторных…»

{{Статья|Черновик}}

Техническое описание реализации механизма редактирования векторных данных в 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-клиенте.

Мультивременные слои в GeoMixer WEB-GIS

2013-12-05T21:15:59Z

Parshin: /* Как оно работает (скучный технический раздел :) */

{{Статья|Черновик}}
{{Аннотация|Общий обзор и детали реализации механизма работы с временны́ми архивами данных в GeoMixer Web-GIS}}

== Философское введение ==

Иногда данных бывает много, очень много. Как правило, пытаться отобразить их все — плохая идея. И дело тут даже не в технических сложностях и ограничениях, а в возможностях человека. Сложно представить себе ситуацию, когда пользователю одновременно нужно увидеть несколько десятков тысяч отдельных объектов.

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

В нашей практике реализации проектов на основе платформы [http://gis-lab.info/qa/geomixer.html GeoMixer] часто встречался особенный вид данных — объекты, накапливающиеся с течением времени. Это могут быть данные о погоде (температура, давление, сила и направление ветра), пожары, результаты мониторинга (рубки, нефтяные слики, и т.д.) и множество других примеров. Так же временной аспект могут иметь и сами снимки ДЗЗ (например, при регулярной съёмке одной и той же территории).

Изначально мы использовали стандартные механизмы работы с наборами данных: разбивали данные на отдельные слои по дате; объединяли всё в один слой, а потом фильтровали объекты слоя по временному атрибуту; делали специализированные интерфейсы под конкретные проекты. Однако все эти варианты имеют ряд технических сложностей, трудны в поддержке и не всегда адекватно выглядят для пользователей.

Со временем пришло понимание, что для подобных данных нужно отдельное решение — мультивременные слои. Мультивременной слой в ГеоМиксере — это векторный слой, объекты которого могут быть отображены за какой-то определённый промежуток времени. При этом не просто происходит фильтрация данных в момент визуализации, но и оптимизация передачи данных с сервера. Таким образом, становится возможным создавать слои практически с неограниченным количеством данных при условии, что при просмотре данных будет выбрана разумная пространственно-временная область.

== Как использовать в ГеоМиксере ==

Мультивременной слой в ГеоМиксере является частным случаем векторного слоя (из меню: Слой -> Создать векторный слой). Можно использовать готовый источник данных (например, shp файл) или создать пустой слой с заданием атрибутивных полей вручную. При этом среди атрибутов слоя должны быть поля временнóго типа.

После сохранения карты и перезагрузки страницы слева над деревом слоёв появится календарик для выбора периода отображения. Его можно использовать для просмотра данных за определённый период. Стоит иметь в виду, что календарик по умолчанию действует на все слои в карте.

Для работы с мультивременными слоями через GeoMixer API в класс [http://geomixer.ru/api_reference/#класс_layer Layer] добавлен метод <code>setDateInterval()</code>:
<pre>
function setDateInterval(dateBegin, dateEnd)
dateBegin: Date – начальная дата периода отображения
dateEnd: Date – конечная дата периода отображения
</pre>

Функция позволяет отображать данные векторного слоя за период с <code>dateBegin</code> до <code>dateEnd</code>.

При этом через API для разных слоёв можно задавать разные периоды отображения.

== Примеры ==

[[Файл:Geomixer_temporal_hotspots.png|700px|center]]

Наш [http://maps.kosmosnimki.ru/api/index.html?6F8B9 любимый векторный слой] — точки с температурными аномалиями (пожарами), полученными со спутников [http://en.wikipedia.org/wiki/Terra_(satellite) TERRA] и [http://en.wikipedia.org/wiki/Aqua_(satellite) AQUA].

В слое 6.6 млн. точек с августа 2012 по текущий момент. На календарике сверху слева можно выбрать любой день и посмотреть пожары по всему миру за эту дату.

Более того, реализация мультивременных слоёв в ГеоМиксере позволяет не только просматривать данные за один день, но и увидеть данные на локальную территорию за большой промежуток времени (лишь бы общий объём данных в этой пространственно-временной области был разумным). Вот пример такой выборки — [http://maps.kosmosnimki.ru/api/index.html?permalink=KDHV2&KRZ89 пожары за весь прошлый год на Московскую область].

[[Файл:geomixer_temporal_landsat8.jpg|700px|center]]

Ещё пример — данные [http://en.wikipedia.org/wiki/Landsat_8 Landsat 8]. Данные открытые, мы скачиваем безоблачные сцены на территорию России и храним их в ГеоМиксере в виде мультивременного слоя. Например, вот [http://maps.kosmosnimki.ru/api/index.html?permalink=PR7PO&6F8B9 съёмка за одну неделю в ноябре] (каждый прямоугольник — это одна снятая спутником сцена). Кстати, если приблизиться, будут видны и сами снимки в полном разрешении (30м/пиксель)!

При помощи такого мультивременного слоя можно искать съёмку на конкретный район — нужно зазумиться в нужное место, выбрать период побольше и переключать слои кликами по ним. Вот [http://maps.kosmosnimki.ru/api/index.html?permalink=5U7YK&6F8B9 доступная съёмка Landsat 8 на Северобайкальск c апреля этого года] (кликайте для переключения снимков).

Так же мы экспериментируем с различными дополнительными элементами управления для анализа временно́й компоненты данных. [http://www.youtube.com/watch?v=VaPJFivbN7c Вот пример] работы с одним из таких инструментов - "таймлайном". Этот инструмент упрощает понимание того, как данные из некоторой пространственной области распределены во времени.

[[Файл:Geomixer_temporal_ais.png|700px|center]]

Следующий пример — мониторинг объектов. У нас ведётся несколько мониторинговых проектов, данные по которым хранятся именно в форме мультивременных рядов.

На скриншоте выше показан пример визуализации данных мониторинга судов за один день в Баренцевом море (к сожалению, лицензия на данные не позволяет нам использовать их в публичных проектах). Каждый треугольник — зафиксированное положение корабля. Направление иконки соответствует направлению движения, а цвет — типу судна. В этом слое на данный момент 3.7 млн. объектов (положений кораблей). Использование мультивременного слоя позволяет быстро просматривать данные за произвольный временной период.

== Как оно работает (скучный технический раздел :) ==

Основная проблема, которую нам пришлось решить — передача на клиент только нужных данных без существенной загрузки сервера. Можно было бы настроить в БД нужные индексы, при каждом запросе делать выборки, результаты конвертировать в понятный клиенту формат и отгружать в браузер. Но нам это показалось недостаточно эффективным решением. Кроме того, у нас есть хорошо себя показавшие векторные тайлы, которые хотелось применить и для мультивременных слоёв. Но всё оказалось не так просто…

[[Файл:Geomixer_temporal_vector_tiles.png|center|400px|]]
''Пример разбиения пространства на тайлы разного размера. Размер тайла определяется количеством попавших в него данных.''

Сначала пару слов про наши векторные тайлы. Для передачи на клиент векторных данных мы разбиваем их на квадратные кусочки (тайлы), сразу же преобразуем эти кусочки в GeoJSON-подобный формат и сохраняем на сервере. Клиенту просто отдаём статические файлы. Степень разбиения определяется размером данных — если в тайле оказывается слишком много объектов, он разбивается на 4 подтайла. Такой подход сохраняет баланс между количеством запросов на сервер и загрузкой лишних (не видимых в данный момент) данных.

Алгоритм построения тайлов для набора векторных объектов выглядит примерно так. Сначала вычисляется общий размер данных для всего набора. Если он меньше определённого порога, то всё записывается в один тайл, и процесс завершается. Если размер данных слишком большой, данные делятся на 4 части в соответствии со своим положением в пространстве. Для каждой части процесс повторяется.

Однако при применении этой схемы к мультивременным слоям мы столкнулись с проблемой формы пространственно-временной области, которая может быть запрошена.

[[Файл:Geomixer_temporal_temporal_tiles1.png|center|700px]]
''Мультивременные тайлы по дням. Дополнительно показана структура тайлов за один конкретный день. Каждый прямоугольник на графике слева — тайлы для данных за один конкретный день.''

Всё дело в том, что квадратные тайлы (векторные или растровые — не важно) хорошо подходят для передачи на клиент только при условии, что область просмотра (экран монитора) тоже примерно квадратная. Но представьте на минутку, что пользователь захочет отрисовать картинку размером 1×100000 или 100000×1 пикселей! Стандартные квадратные тайлы 256×256 тут не подойдут — вам придётся передать ровно в 256 раз больше данных, чем нужно клиенту!

Именно такая ситуация возникает в случае с пространственно-временными данными — пользователи хотят смотреть и данные на весь мир за один день (аналог запроса 10000×1) и данные за 10 лет на деревню бабушки (1×10000). Если есть тайлы только за отдельные дни, во втором случае придётся сделать минимум 3650 запросов; если в каждом тайле есть данные сразу за 10 лет, при просмотре всего мира за любой день мы загрузим весь архив (точнее говоря, попробуем загрузить…).

[[Файл:Geomixer_temporal_temporal_tiles2.png|center|500px]]
''Наборы тайлов с разным разрешением по времени. Показаны характерные запросы от пользователей, которые обрабатываются этими наборами. Каждый тайл содержит примерно одинаковое количество данных, так что при увеличении протяжённости во времени размер тайла в пространстве уменьшается.''

Решаем мы эту проблему хранением сразу нескольких наборов тайлов различной формы. Условно говоря, есть тайлы за каждый отдельный день, тайлы за неделю, за месяц и за год. Список тайлов передаётся на клиент. Когда пользователь выбирает определённый период в календарике, наш API решает, какой набор данных лучше использовать и грузит нужные тайлы.

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

На клиенте при показе на карте мультивременного слоя API вычисляет временны́е рамки запроса и выбирает подмножество тайлов, которые нужно запросить с сервера. Пример: пусть на сервере хранятся тайлы длительностью день и неделя, а пользователь выбрал период в 10 дней. У нас есть вариант запросить тайлы за 10 дней по отдельности, за неделю и отдельно за 3 оставшихся дня, или за две недели. Последний вариант может оказаться предпочтительнее, если общее количество данных мало (из-за меньшего числа запросов на сервер).

Поскольку все тайлы имеют примерно одинаковый размер, основным критерием выбора в ГеоМиксере является общее количество запросов на сервер для получения всех нужных данных. Если протяжённости во времени всех тайлов кратны друг другу (скажем, 1, 4, 16, 64 дня), минимизировать эту величину можно за один проход по списку тайлов(например, при помощи какой-нибудь древовидной структуры).

Описанное решение позволяет крайне эффективно с точки зрения сервера выбирать данные для запросов разной формы (фактически, раздаётся статика). Из минусов можно отметить увеличение объёма данных на сервере для хранения векторных тайлов (хотя для нас это всё-равно копейки по сравнению с размером наших растровых данных) и сложность обновления (каждое изменение нужно отразить сразу в нескольких тайлах).

== Банальное заключение ==

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

== (Бес)полезные ссылки ==
* [http://gis-lab.info/qa/geomixer.html Краткий обзор GeoMixer WEB-GIS]
* [http://docs.geomixer.ru/doku.php?id=geomixer:documentation:user_manual:geomixer_web_gis Пользовательская документация GeoMixer]
* [http://geomixer.ru/api_reference GeoMixer API Reference]

Мультивременные слои в GeoMixer WEB-GIS

2013-12-04T08:28:30Z

Parshin: /* Как оно работает (скучный технический раздел :) */

{{Статья|Черновик}}
{{Аннотация|Общий обзор и детали реализации механизма работы с временны́ми архивами данных в GeoMixer Web-GIS}}

== Философское введение ==

Иногда данных бывает много, очень много. Как правило, пытаться отобразить их все — плохая идея. И дело тут даже не в технических сложностях и ограничениях, а в возможностях человека. Сложно представить себе ситуацию, когда пользователю одновременно нужно увидеть несколько десятков тысяч отдельных объектов.

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

В нашей практике реализации проектов на основе платформы [http://gis-lab.info/qa/geomixer.html GeoMixer] часто встречался особенный вид данных — объекты, накапливающиеся с течением времени. Это могут быть данные о погоде (температура, давление, сила и направление ветра), пожары, результаты мониторинга (рубки, нефтяные слики, и т.д.) и множество других примеров. Так же временной аспект могут иметь и сами снимки ДЗЗ (например, при регулярной съёмке одной и той же территории).

Изначально мы использовали стандартные механизмы работы с наборами данных: разбивали данные на отдельные слои по дате; объединяли всё в один слой, а потом фильтровали объекты слоя по временному атрибуту; делали специализированные интерфейсы под конкретные проекты. Однако все эти варианты имеют ряд технических сложностей, трудны в поддержке и не всегда адекватно выглядят для пользователей.

Со временем пришло понимание, что для подобных данных нужно отдельное решение — мультивременные слои. Мультивременной слой в ГеоМиксере — это векторный слой, объекты которого могут быть отображены за какой-то определённый промежуток времени. При этом не просто происходит фильтрация данных в момент визуализации, но и оптимизация передачи данных с сервера. Таким образом, становится возможным создавать слои практически с неограниченным количеством данных при условии, что при просмотре данных будет выбрана разумная пространственно-временная область.

== Как использовать в ГеоМиксере ==

Мультивременной слой в ГеоМиксере является частным случаем векторного слоя (из меню: Слой -> Создать векторный слой). Можно использовать готовый источник данных (например, shp файл) или создать пустой слой с заданием атрибутивных полей вручную. При этом среди атрибутов слоя должны быть поля временнóго типа.

После сохранения карты и перезагрузки страницы слева над деревом слоёв появится календарик для выбора периода отображения. Его можно использовать для просмотра данных за определённый период. Стоит иметь в виду, что календарик по умолчанию действует на все слои в карте.

Для работы с мультивременными слоями через GeoMixer API в класс [http://geomixer.ru/api_reference/#класс_layer Layer] добавлен метод <code>setDateInterval()</code>:
<pre>
function setDateInterval(dateBegin, dateEnd)
dateBegin: Date – начальная дата периода отображения
dateEnd: Date – конечная дата периода отображения
</pre>

Функция позволяет отображать данные векторного слоя за период с <code>dateBegin</code> до <code>dateEnd</code>.

При этом через API для разных слоёв можно задавать разные периоды отображения.

== Примеры ==

[[Файл:Geomixer_temporal_hotspots.png|700px|center]]

Наш [http://maps.kosmosnimki.ru/api/index.html?6F8B9 любимый векторный слой] — точки с температурными аномалиями (пожарами), полученными со спутников [http://en.wikipedia.org/wiki/Terra_(satellite) TERRA] и [http://en.wikipedia.org/wiki/Aqua_(satellite) AQUA].

В слое 6.6 млн. точек с августа 2012 по текущий момент. На календарике сверху слева можно выбрать любой день и посмотреть пожары по всему миру за эту дату.

Более того, реализация мультивременных слоёв в ГеоМиксере позволяет не только просматривать данные за один день, но и увидеть данные на локальную территорию за большой промежуток времени (лишь бы общий объём данных в этой пространственно-временной области был разумным). Вот пример такой выборки — [http://maps.kosmosnimki.ru/api/index.html?permalink=KDHV2&KRZ89 пожары за весь прошлый год на Московскую область].

[[Файл:geomixer_temporal_landsat8.jpg|700px|center]]

Ещё пример — данные [http://en.wikipedia.org/wiki/Landsat_8 Landsat 8]. Данные открытые, мы скачиваем безоблачные сцены на территорию России и храним их в ГеоМиксере в виде мультивременного слоя. Например, вот [http://maps.kosmosnimki.ru/api/index.html?permalink=PR7PO&6F8B9 съёмка за одну неделю в ноябре] (каждый прямоугольник — это одна снятая спутником сцена). Кстати, если приблизиться, будут видны и сами снимки в полном разрешении (30м/пиксель)!

При помощи такого мультивременного слоя можно искать съёмку на конкретный район — нужно зазумиться в нужное место, выбрать период побольше и переключать слои кликами по ним. Вот [http://maps.kosmosnimki.ru/api/index.html?permalink=5U7YK&6F8B9 доступная съёмка Landsat 8 на Северобайкальск c апреля этого года] (кликайте для переключения снимков).

Так же мы экспериментируем с различными дополнительными элементами управления для анализа временно́й компоненты данных. [http://www.youtube.com/watch?v=VaPJFivbN7c Вот пример] работы с одним из таких инструментов - "таймлайном". Этот инструмент упрощает понимание того, как данные из некоторой пространственной области распределены во времени.

[[Файл:Geomixer_temporal_ais.png|700px|center]]

Следующий пример — мониторинг объектов. У нас ведётся несколько мониторинговых проектов, данные по которым хранятся именно в форме мультивременных рядов.

На скриншоте выше показан пример визуализации данных мониторинга судов за один день в Баренцевом море (к сожалению, лицензия на данные не позволяет нам использовать их в публичных проектах). Каждый треугольник — зафиксированное положение корабля. Направление иконки соответствует направлению движения, а цвет — типу судна. В этом слое на данный момент 3.7 млн. объектов (положений кораблей). Использование мультивременного слоя позволяет быстро просматривать данные за произвольный временной период.

== Как оно работает (скучный технический раздел :) ==

Основная проблема, которую нам пришлось решить — передача на клиент только нужных данных без существенной загрузки сервера. Можно было бы настроить в БД нужные индексы, при каждом запросе делать выборки, результаты конвертировать в понятный клиенту формат и отгружать в браузер. Но нам это показалось недостаточно эффективным решением. Кроме того, у нас есть хорошо себя показавшие векторные тайлы, которые хотелось применить и для мультивременных слоёв. Но всё оказалось не так просто…

[[Файл:Geomixer_temporal_vector_tiles.png|center|400px|]]
''Пример разбиения пространства на тайлы разного размера. Размер тайла определяется количеством попавших в него данных.''

Сначала пару слов про наши векторные тайлы. Для передачи на клиент векторных данных мы разбиваем их на квадратные кусочки (тайлы), сразу же преобразуем эти кусочки в GeoJSON-подобный формат и сохраняем на сервере. Клиенту просто отдаём статические файлы. Степень разбиения определяется размером данных — если в тайле оказывается слишком много объектов, он разбивается на 4 подтайла. Такой подход сохраняет баланс между количеством запросов на сервер и загрузкой лишних (не видимых в данный момент) данных.

Алгоритм построения тайлов для набора векторных объектов выглядит примерно так. Сначала вычисляется общий размер данных для всего набора. Если он меньше определённого порога, то всё записывается в один тайл, и процесс завершается. Если размер данных слишком большой, данные делятся на 4 части в соответствии со своим положением в пространстве. Для каждой части процесс повторяется.

Однако при применении этой схемы к мультивременным слоям мы столкнулись с проблемой формы пространственно-временной области, которая может быть запрошена.

[[Файл:Geomixer_temporal_temporal_tiles1.png|center|700px]]
''Мультивременные тайлы по дням. Дополнительно показана структура тайлов за один конкретный день. Каждый прямоугольник на графике слева — тайлы для данных за один конкретный день.''

Всё дело в том, что квадратные тайлы (векторные или растровые — не важно) хорошо подходят для передачи на клиент только при условии, что область просмотра (экран монитора) тоже примерно квадратная. Но представьте на минутку, что пользователь захочет отрисовать картинку размером 1×100000 или 100000×1 пикселей! Стандартные квадратные тайлы 256×256 тут не подойдут — вам придётся передать ровно в 256 раз больше данных, чем нужно клиенту!

Именно такая ситуация возникает в случае с пространственно-временными данными — пользователи хотят смотреть и данные на весь мир за один день (аналог запроса 10000×1) и данные за 10 лет на деревню бабушки (1×10000). Если есть тайлы только за отдельные дни, во втором случае придётся сделать минимум 3650 запросов; если в каждом тайле есть данные сразу за 10 лет, при просмотре всего мира за любой день мы загрузим весь архив (точнее говоря, попробуем загрузить…).

[[Файл:Geomixer_temporal_temporal_tiles2.png|center|500px]]
''Наборы тайлов с разным разрешением по времени. Показаны характерные запросы от пользователей, которые обрабатываются этими наборами. Каждый тайл содержит примерно одинаковое количество данных, так что при увеличении протяжённости во времени размер тайла в пространстве уменьшается.''

Решаем мы эту проблему хранением сразу нескольких наборов тайлов различной формы. Условно говоря, есть тайлы за каждый отдельный день, тайлы за неделю, за месяц и за год. Список тайлов передаётся на клиент. Когда пользователь выбирает определённый период в календарике, наш API решает, какой набор данных лучше использовать и грузит нужные тайлы (кстати, определение этого набора тоже интересная задачка, которая может быть решена разными способами).

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

Такой подход позволяет крайне эффективно с точки зрения сервера выбирать данные для запросов разной формы (фактически, раздаётся статика). Из минусов можно отметить увеличение объёма данных на сервере для хранения векторных тайлов (хотя для нас это всё-равно копейки по сравнению с размером наших растровых данных) и сложность обновления (каждое изменение нужно отразить сразу в нескольких тайлах).

== Банальное заключение ==

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

== (Бес)полезные ссылки ==
* [http://gis-lab.info/qa/geomixer.html Краткий обзор GeoMixer WEB-GIS]
* [http://docs.geomixer.ru/doku.php?id=geomixer:documentation:user_manual:geomixer_web_gis Пользовательская документация GeoMixer]
* [http://geomixer.ru/api_reference GeoMixer API Reference]

Файл:Geomixer temporal temporal tiles1.png

2013-12-04T08:20:06Z

Parshin: загружена новая версия «Файл:Geomixer temporal temporal tiles1.png»

Файл:Geomixer temporal vector tiles.png

2013-12-04T08:18:59Z

Parshin: загружена новая версия «Файл:Geomixer temporal vector tiles.png»

Мультивременные слои в GeoMixer WEB-GIS

2013-12-04T08:13:56Z

Parshin: /* Как оно работает (скучный технический раздел :) */

{{Статья|Черновик}}
{{Аннотация|Общий обзор и детали реализации механизма работы с временны́ми архивами данных в GeoMixer Web-GIS}}

== Философское введение ==

Иногда данных бывает много, очень много. Как правило, пытаться отобразить их все — плохая идея. И дело тут даже не в технических сложностях и ограничениях, а в возможностях человека. Сложно представить себе ситуацию, когда пользователю одновременно нужно увидеть несколько десятков тысяч отдельных объектов.

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

В нашей практике реализации проектов на основе платформы [http://gis-lab.info/qa/geomixer.html GeoMixer] часто встречался особенный вид данных — объекты, накапливающиеся с течением времени. Это могут быть данные о погоде (температура, давление, сила и направление ветра), пожары, результаты мониторинга (рубки, нефтяные слики, и т.д.) и множество других примеров. Так же временной аспект могут иметь и сами снимки ДЗЗ (например, при регулярной съёмке одной и той же территории).

Изначально мы использовали стандартные механизмы работы с наборами данных: разбивали данные на отдельные слои по дате; объединяли всё в один слой, а потом фильтровали объекты слоя по временному атрибуту; делали специализированные интерфейсы под конкретные проекты. Однако все эти варианты имеют ряд технических сложностей, трудны в поддержке и не всегда адекватно выглядят для пользователей.

Со временем пришло понимание, что для подобных данных нужно отдельное решение — мультивременные слои. Мультивременной слой в ГеоМиксере — это векторный слой, объекты которого могут быть отображены за какой-то определённый промежуток времени. При этом не просто происходит фильтрация данных в момент визуализации, но и оптимизация передачи данных с сервера. Таким образом, становится возможным создавать слои практически с неограниченным количеством данных при условии, что при просмотре данных будет выбрана разумная пространственно-временная область.

== Как использовать в ГеоМиксере ==

Мультивременной слой в ГеоМиксере является частным случаем векторного слоя (из меню: Слой -> Создать векторный слой). Можно использовать готовый источник данных (например, shp файл) или создать пустой слой с заданием атрибутивных полей вручную. При этом среди атрибутов слоя должны быть поля временнóго типа.

После сохранения карты и перезагрузки страницы слева над деревом слоёв появится календарик для выбора периода отображения. Его можно использовать для просмотра данных за определённый период. Стоит иметь в виду, что календарик по умолчанию действует на все слои в карте.

Для работы с мультивременными слоями через GeoMixer API в класс [http://geomixer.ru/api_reference/#класс_layer Layer] добавлен метод <code>setDateInterval()</code>:
<pre>
function setDateInterval(dateBegin, dateEnd)
dateBegin: Date – начальная дата периода отображения
dateEnd: Date – конечная дата периода отображения
</pre>

Функция позволяет отображать данные векторного слоя за период с <code>dateBegin</code> до <code>dateEnd</code>.

При этом через API для разных слоёв можно задавать разные периоды отображения.

== Примеры ==

[[Файл:Geomixer_temporal_hotspots.png|700px|center]]

Наш [http://maps.kosmosnimki.ru/api/index.html?6F8B9 любимый векторный слой] — точки с температурными аномалиями (пожарами), полученными со спутников [http://en.wikipedia.org/wiki/Terra_(satellite) TERRA] и [http://en.wikipedia.org/wiki/Aqua_(satellite) AQUA].

В слое 6.6 млн. точек с августа 2012 по текущий момент. На календарике сверху слева можно выбрать любой день и посмотреть пожары по всему миру за эту дату.

Более того, реализация мультивременных слоёв в ГеоМиксере позволяет не только просматривать данные за один день, но и увидеть данные на локальную территорию за большой промежуток времени (лишь бы общий объём данных в этой пространственно-временной области был разумным). Вот пример такой выборки — [http://maps.kosmosnimki.ru/api/index.html?permalink=KDHV2&KRZ89 пожары за весь прошлый год на Московскую область].

[[Файл:geomixer_temporal_landsat8.jpg|700px|center]]

Ещё пример — данные [http://en.wikipedia.org/wiki/Landsat_8 Landsat 8]. Данные открытые, мы скачиваем безоблачные сцены на территорию России и храним их в ГеоМиксере в виде мультивременного слоя. Например, вот [http://maps.kosmosnimki.ru/api/index.html?permalink=PR7PO&6F8B9 съёмка за одну неделю в ноябре] (каждый прямоугольник — это одна снятая спутником сцена). Кстати, если приблизиться, будут видны и сами снимки в полном разрешении (30м/пиксель)!

При помощи такого мультивременного слоя можно искать съёмку на конкретный район — нужно зазумиться в нужное место, выбрать период побольше и переключать слои кликами по ним. Вот [http://maps.kosmosnimki.ru/api/index.html?permalink=5U7YK&6F8B9 доступная съёмка Landsat 8 на Северобайкальск c апреля этого года] (кликайте для переключения снимков).

Так же мы экспериментируем с различными дополнительными элементами управления для анализа временно́й компоненты данных. [http://www.youtube.com/watch?v=VaPJFivbN7c Вот пример] работы с одним из таких инструментов - "таймлайном". Этот инструмент упрощает понимание того, как данные из некоторой пространственной области распределены во времени.

[[Файл:Geomixer_temporal_ais.png|700px|center]]

Следующий пример — мониторинг объектов. У нас ведётся несколько мониторинговых проектов, данные по которым хранятся именно в форме мультивременных рядов.

На скриншоте выше показан пример визуализации данных мониторинга судов за один день в Баренцевом море (к сожалению, лицензия на данные не позволяет нам использовать их в публичных проектах). Каждый треугольник — зафиксированное положение корабля. Направление иконки соответствует направлению движения, а цвет — типу судна. В этом слое на данный момент 3.7 млн. объектов (положений кораблей). Использование мультивременного слоя позволяет быстро просматривать данные за произвольный временной период.

== Как оно работает (скучный технический раздел :) ==

Основная проблема, которую нам пришлось решить — передача на клиент только нужных данных без существенной загрузки сервера. Можно было бы настроить в БД нужные индексы, при каждом запросе делать выборки, результаты конвертировать в понятный клиенту формат и отгружать в браузер. Но нам это показалось недостаточно эффективным решением. Кроме того, у нас есть хорошо себя показавшие векторные тайлы, которые хотелось применить и для мультивременных слоёв. Но всё оказалось не так просто…

[[Файл:Geomixer_temporal_vector_tiles.png|center|400px|]]
''Пример разбиения пространства на тайлы разного размера. Размер тайла определяется количеством попавших в него данных.''

Сначала пару слов про наши векторные тайлы. Для передачи на клиент векторных данных мы разбиваем их на квадратные кусочки (тайлы), сразу же преобразуем эти кусочки в GeoJSON-подобный формат и сохраняем на сервере. Клиенту просто отдаём статические файлы. Степень разбиения определяется размером данных — если в тайле оказывается слишком много объектов, он разбивается на 4 подтайла. Такой подход сохраняет баланс между количеством запросов на сервер и загрузкой лишних (не видимых в данный момент) данных.

Алгоритм построения тайлов для набора векторных объектов выглядит примерно так. Сначала вычисляется общий размер данных для всего набора. Если он меньше определённого порога, то всё записывается в один тайл, и процесс завершается. Если размер данных слишком большой, данные делятся на 4 части в соответствии со своим положением в пространстве. Для каждой части процесс повторяется.

Однако при применении этой схемы к мультивременным слоям мы столкнулись с проблемой формы пространственно-временной области, которая может быть запрошена.

[[Файл:Geomixer_temporal_temporal_tiles1.png|center|700px]]
''Мультивременные тайлы по дням. Дополнительно показана структура тайлов за один конкретный день. Каждый прямоугольник на графике слева — тайлы для данных за один конкретный день.''

Всё дело в том, что квадратные тайлы (векторные или растровые — не важно) хорошо подходят для передачи на клиент только при условии, что область просмотра (экран монитора) тоже примерно квадратная. Но представьте на минутку, что пользователь захочет отрисовать картинку размером 1×100000 или 100000×1 пикселей! Стандартные квадратные тайлы 256×256 тут не подойдут — вам придётся передать ровно в 256 раз больше данных, чем нужно клиенту!

Именно такая ситуация возникает в случае с пространственно-временными данными — пользователи хотят смотреть и данные на весь мир за один день (аналог запроса 10000×1) и данные за 10 лет на деревню бабушки (1×10000). Если есть тайлы только за отдельные дни, во втором случае придётся сделать минимум 3650 запросов; если в каждом тайле есть данные сразу за 10 лет, при просмотре всего мира за любой день мы загрузим весь архив (точнее говоря, попробуем загрузить…).

[[Файл:Geomixer_temporal_temporal_tiles2.png|center|500px]]
''Наборы тайлов с разным разрешением по времени. Показаны характерные запросы от пользователей, которые обрабатываются этими наборами. Каждый тайл имеет примерно одинаковый размер данных, так что при увеличении протяжённости во времени размер в пространстве уменьшается.''

Решаем мы эту проблему хранением сразу нескольких наборов тайлов различной формы. Условно говоря, есть тайлы за каждый отдельный день, тайлы за неделю, за месяц и за год. Список тайлов передаётся на клиент. Когда пользователь выбирает определённый период в календарике, наш API решает, какой набор данных лучше использовать и грузит нужные тайлы (кстати, определение этого набора тоже интересная задачка, которая может быть решена разными способами).

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

Такой подход позволяет крайне эффективно с точки зрения сервера выбирать данные для запросов разной формы (фактически, раздаётся статика). Из минусов можно отметить увеличение объёма данных на сервере для хранения векторных тайлов (хотя для нас это всё-равно копейки по сравнению с размером наших растровых данных) и сложность обновления (каждое изменение нужно отразить сразу в нескольких тайлах).

== Банальное заключение ==

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

== (Бес)полезные ссылки ==
* [http://gis-lab.info/qa/geomixer.html Краткий обзор GeoMixer WEB-GIS]
* [http://docs.geomixer.ru/doku.php?id=geomixer:documentation:user_manual:geomixer_web_gis Пользовательская документация GeoMixer]
* [http://geomixer.ru/api_reference GeoMixer API Reference]

Файл:Geomixer temporal vector tiles.png

2013-12-04T07:53:43Z

Parshin: загружена новая версия «Файл:Geomixer temporal vector tiles.png»

Мультивременные слои в GeoMixer WEB-GIS

2013-12-04T07:01:15Z

Parshin: /* Как оно работает (скучный технический раздел :) */

{{Статья|Черновик}}
{{Аннотация|Общий обзор и детали реализации механизма работы с временны́ми архивами данных в GeoMixer Web-GIS}}

== Философское введение ==

Иногда данных бывает много, очень много. Как правило, пытаться отобразить их все — плохая идея. И дело тут даже не в технических сложностях и ограничениях, а в возможностях человека. Сложно представить себе ситуацию, когда пользователю одновременно нужно увидеть несколько десятков тысяч отдельных объектов.

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

В нашей практике реализации проектов на основе платформы [http://gis-lab.info/qa/geomixer.html GeoMixer] часто встречался особенный вид данных — объекты, накапливающиеся с течением времени. Это могут быть данные о погоде (температура, давление, сила и направление ветра), пожары, результаты мониторинга (рубки, нефтяные слики, и т.д.) и множество других примеров. Так же временной аспект могут иметь и сами снимки ДЗЗ (например, при регулярной съёмке одной и той же территории).

Изначально мы использовали стандартные механизмы работы с наборами данных: разбивали данные на отдельные слои по дате; объединяли всё в один слой, а потом фильтровали объекты слоя по временному атрибуту; делали специализированные интерфейсы под конкретные проекты. Однако все эти варианты имеют ряд технических сложностей, трудны в поддержке и не всегда адекватно выглядят для пользователей.

Со временем пришло понимание, что для подобных данных нужно отдельное решение — мультивременные слои. Мультивременной слой в ГеоМиксере — это векторный слой, объекты которого могут быть отображены за какой-то определённый промежуток времени. При этом не просто происходит фильтрация данных в момент визуализации, но и оптимизация передачи данных с сервера. Таким образом, становится возможным создавать слои практически с неограниченным количеством данных при условии, что при просмотре данных будет выбрана разумная пространственно-временная область.

== Как использовать в ГеоМиксере ==

Мультивременной слой в ГеоМиксере является частным случаем векторного слоя (из меню: Слой -> Создать векторный слой). Можно использовать готовый источник данных (например, shp файл) или создать пустой слой с заданием атрибутивных полей вручную. При этом среди атрибутов слоя должны быть поля временнóго типа.

После сохранения карты и перезагрузки страницы слева над деревом слоёв появится календарик для выбора периода отображения. Его можно использовать для просмотра данных за определённый период. Стоит иметь в виду, что календарик по умолчанию действует на все слои в карте.

Для работы с мультивременными слоями через GeoMixer API в класс [http://geomixer.ru/api_reference/#класс_layer Layer] добавлен метод <code>setDateInterval()</code>:
<pre>
function setDateInterval(dateBegin, dateEnd)
dateBegin: Date – начальная дата периода отображения
dateEnd: Date – конечная дата периода отображения
</pre>

Функция позволяет отображать данные векторного слоя за период с <code>dateBegin</code> до <code>dateEnd</code>.

При этом через API для разных слоёв можно задавать разные периоды отображения.

== Примеры ==

[[Файл:Geomixer_temporal_hotspots.png|700px|center]]

Наш [http://maps.kosmosnimki.ru/api/index.html?6F8B9 любимый векторный слой] — точки с температурными аномалиями (пожарами), полученными со спутников [http://en.wikipedia.org/wiki/Terra_(satellite) TERRA] и [http://en.wikipedia.org/wiki/Aqua_(satellite) AQUA].

В слое 6.6 млн. точек с августа 2012 по текущий момент. На календарике сверху слева можно выбрать любой день и посмотреть пожары по всему миру за эту дату.

Более того, реализация мультивременных слоёв в ГеоМиксере позволяет не только просматривать данные за один день, но и увидеть данные на локальную территорию за большой промежуток времени (лишь бы общий объём данных в этой пространственно-временной области был разумным). Вот пример такой выборки — [http://maps.kosmosnimki.ru/api/index.html?permalink=KDHV2&KRZ89 пожары за весь прошлый год на Московскую область].

[[Файл:geomixer_temporal_landsat8.jpg|700px|center]]

Ещё пример — данные [http://en.wikipedia.org/wiki/Landsat_8 Landsat 8]. Данные открытые, мы скачиваем безоблачные сцены на территорию России и храним их в ГеоМиксере в виде мультивременного слоя. Например, вот [http://maps.kosmosnimki.ru/api/index.html?permalink=PR7PO&6F8B9 съёмка за одну неделю в ноябре] (каждый прямоугольник — это одна снятая спутником сцена). Кстати, если приблизиться, будут видны и сами снимки в полном разрешении (30м/пиксель)!

При помощи такого мультивременного слоя можно искать съёмку на конкретный район — нужно зазумиться в нужное место, выбрать период побольше и переключать слои кликами по ним. Вот [http://maps.kosmosnimki.ru/api/index.html?permalink=5U7YK&6F8B9 доступная съёмка Landsat 8 на Северобайкальск c апреля этого года] (кликайте для переключения снимков).

Так же мы экспериментируем с различными дополнительными элементами управления для анализа временно́й компоненты данных. [http://www.youtube.com/watch?v=VaPJFivbN7c Вот пример] работы с одним из таких инструментов - "таймлайном". Этот инструмент упрощает понимание того, как данные из некоторой пространственной области распределены во времени.

[[Файл:Geomixer_temporal_ais.png|700px|center]]

Следующий пример — мониторинг объектов. У нас ведётся несколько мониторинговых проектов, данные по которым хранятся именно в форме мультивременных рядов.

На скриншоте выше показан пример визуализации данных мониторинга судов за один день в Баренцевом море (к сожалению, лицензия на данные не позволяет нам использовать их в публичных проектах). Каждый треугольник — зафиксированное положение корабля. Направление иконки соответствует направлению движения, а цвет — типу судна. В этом слое на данный момент 3.7 млн. объектов (положений кораблей). Использование мультивременного слоя позволяет быстро просматривать данные за произвольный временной период.

== Как оно работает (скучный технический раздел :) ==

Основная проблема, которую нам пришлось решить — передача на клиент только нужных данных без существенной загрузки сервера. Можно было бы настроить в БД нужные индексы, при каждом запросе делать выборки, результаты конвертировать в понятный клиенту формат и отгружать в браузер. Но нам это показалось недостаточно эффективным решением. Кроме того, у нас есть хорошо себя показавшие векторные тайлы, которые хотелось применить и для мультивременных слоёв. Но всё оказалось не так просто…

[[Файл:Geomixer_temporal_vector_tiles.png|center|400px|]]
''Пример разбиения пространства на тайлы разного размера. Размер тайла определяется количеством попавших в него данных.''

Сначала пару слов про наши векторные тайлы. Для передачи на клиент векторных данных мы разбиваем их на квадратные кусочки (тайлы), сразу же преобразуем эти кусочки в GeoJSON-подобный формат и сохраняем на сервере. Клиенту просто отдаём статические файлы. Степень разбиения определяется размером данных — если в тайле оказывается слишком много объектов, он разбивается на 4 подтайла. Такой подход сохраняет баланс между количеством запросов на сервер и загрузкой лишних (не видимых в данный момент) данных.

Алгоритм построения тайлов для набора векторных объектов выглядит примерно так. Сначала вычисляется общий размер данных для всего набора. Если он меньше определённого порога, то всё записывается в один тайл, и процесс завершается. Если размер данных слишком большой, данные делятся на 4 части в соответствии со своим положением в пространстве. Для каждой части процесс повторяется.

Однако при применении этой схемы к мультивременным слоям мы столкнулись с проблемой формы пространственно-временной области, которая может быть запрошена.

[[Файл:Geomixer_temporal_temporal_tiles1.png|center|700px]]
''Мультивременные тайлы по дням. Дополнительно показана структура тайлов за один конкретный день. Каждый квадратик — отдельный тайл с данными. По горизонтальной оси условно показан размер тайла в пространстве, а по вертикальной — его протяжённость по времени.''

Всё дело в том, что квадратные тайлы (векторные или растровые — не важно) хорошо подходят для передачи на клиент только при условии, что область просмотра (экран монитора) тоже примерно квадратная. Но представьте на минутку, что пользователь захочет отрисовать картинку размером 1×100000 или 100000×1 пикселей! Стандартные квадратные тайлы 256×256 тут не подойдут — вам придётся передать ровно в 256 раз больше данных, чем нужно клиенту!

Именно такая ситуация возникает в случае с пространственно-временными данными — пользователи хотят смотреть и данные на весь мир за один день (аналог запроса 10000×1) и данные за 10 лет на деревню бабушки (1×10000). Если есть тайлы только за отдельные дни, во втором случае придётся сделать минимум 3650 запросов; если в каждом тайле есть данные сразу за 10 лет, при просмотре всего мира за любой день мы загрузим весь архив (точнее говоря, попробуем загрузить…).

[[Файл:Geomixer_temporal_temporal_tiles2.png|center|500px]]
''Наборы тайлов с разным разрешением по времени. Показаны характерные запросы от пользователей, которые обрабатываются этими наборами. Каждый тайл имеет примерно одинаковый размер данных, так что при увеличении протяжённости во времени размер в пространстве уменьшается.''

Решаем мы эту проблему хранением сразу нескольких наборов тайлов различной формы. Условно говоря, есть тайлы за каждый отдельный день, тайлы за неделю, за месяц и за год. Список тайлов передаётся на клиент. Когда пользователь выбирает определённый период в календарике, наш API решает, какой набор данных лучше использовать и грузит нужные тайлы (кстати, определение этого набора тоже интересная задачка, которая может быть решена разными способами).

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

Такой подход позволяет крайне эффективно с точки зрения сервера выбирать данные для запросов разной формы (фактически, раздаётся статика). Из минусов можно отметить увеличение объёма данных на сервере для хранения векторных тайлов (хотя для нас это всё-равно копейки по сравнению с размером наших растровых данных) и сложность обновления (каждое изменение нужно отразить сразу в нескольких тайлах).

== Банальное заключение ==

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

== (Бес)полезные ссылки ==
* [http://gis-lab.info/qa/geomixer.html Краткий обзор GeoMixer WEB-GIS]
* [http://docs.geomixer.ru/doku.php?id=geomixer:documentation:user_manual:geomixer_web_gis Пользовательская документация GeoMixer]
* [http://geomixer.ru/api_reference GeoMixer API Reference]

Мультивременные слои в GeoMixer WEB-GIS

2013-12-01T14:41:05Z

Parshin: /* Примеры */

{{Статья|Черновик}}
{{Аннотация|Общий обзор и детали реализации механизма работы с временны́ми архивами данных в GeoMixer Web-GIS}}

== Философское введение ==

Иногда данных бывает много, очень много. Как правило, пытаться отобразить их все — плохая идея. И дело тут даже не в технических сложностях и ограничениях, а в возможностях человека. Сложно представить себе ситуацию, когда пользователю одновременно нужно увидеть несколько десятков тысяч отдельных объектов.

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

В нашей практике реализации проектов на основе платформы [http://gis-lab.info/qa/geomixer.html GeoMixer] часто встречался особенный вид данных — объекты, накапливающиеся с течением времени. Это могут быть данные о погоде (температура, давление, сила и направление ветра), пожары, результаты мониторинга (рубки, нефтяные слики, и т.д.) и множество других примеров. Так же временной аспект могут иметь и сами снимки ДЗЗ (например, при регулярной съёмке одной и той же территории).

Изначально мы использовали стандартные механизмы работы с наборами данных: разбивали данные на отдельные слои по дате; объединяли всё в один слой, а потом фильтровали объекты слоя по временному атрибуту; делали специализированные интерфейсы под конкретные проекты. Однако все эти варианты имеют ряд технических сложностей, трудны в поддержке и не всегда адекватно выглядят для пользователей.

Со временем пришло понимание, что для подобных данных нужно отдельное решение — мультивременные слои. Мультивременной слой в ГеоМиксере — это векторный слой, объекты которого могут быть отображены за какой-то определённый промежуток времени. При этом не просто происходит фильтрация данных в момент визуализации, но и оптимизация передачи данных с сервера. Таким образом, становится возможным создавать слои практически с неограниченным количеством данных при условии, что при просмотре данных будет выбрана разумная пространственно-временная область.

== Как использовать в ГеоМиксере ==

Мультивременной слой в ГеоМиксере является частным случаем векторного слоя (из меню: Слой -> Создать векторный слой). Можно использовать готовый источник данных (например, shp файл) или создать пустой слой с заданием атрибутивных полей вручную. При этом среди атрибутов слоя должны быть поля временнóго типа.

После сохранения карты и перезагрузки страницы слева над деревом слоёв появится календарик для выбора периода отображения. Его можно использовать для просмотра данных за определённый период. Стоит иметь в виду, что календарик по умолчанию действует на все слои в карте.

Для работы с мультивременными слоями через GeoMixer API в класс [http://geomixer.ru/api_reference/#класс_layer Layer] добавлен метод <code>setDateInterval()</code>:
<pre>
function setDateInterval(dateBegin, dateEnd)
dateBegin: Date – начальная дата периода отображения
dateEnd: Date – конечная дата периода отображения
</pre>

Функция позволяет отображать данные векторного слоя за период с <code>dateBegin</code> до <code>dateEnd</code>.

При этом через API для разных слоёв можно задавать разные периоды отображения.

== Примеры ==

[[Файл:Geomixer_temporal_hotspots.png|700px|center]]

Наш [http://maps.kosmosnimki.ru/api/index.html?6F8B9 любимый векторный слой] — точки с температурными аномалиями (пожарами), полученными со спутников [http://en.wikipedia.org/wiki/Terra_(satellite) TERRA] и [http://en.wikipedia.org/wiki/Aqua_(satellite) AQUA].

В слое 6.6 млн. точек с августа 2012 по текущий момент. На календарике сверху слева можно выбрать любой день и посмотреть пожары по всему миру за эту дату.

Более того, реализация мультивременных слоёв в ГеоМиксере позволяет не только просматривать данные за один день, но и увидеть данные на локальную территорию за большой промежуток времени (лишь бы общий объём данных в этой пространственно-временной области был разумным). Вот пример такой выборки — [http://maps.kosmosnimki.ru/api/index.html?permalink=KDHV2&KRZ89 пожары за весь прошлый год на Московскую область].

[[Файл:geomixer_temporal_landsat8.jpg|700px|center]]

Ещё пример — данные [http://en.wikipedia.org/wiki/Landsat_8 Landsat 8]. Данные открытые, мы скачиваем безоблачные сцены на территорию России и храним их в ГеоМиксере в виде мультивременного слоя. Например, вот [http://maps.kosmosnimki.ru/api/index.html?permalink=PR7PO&6F8B9 съёмка за одну неделю в ноябре] (каждый прямоугольник — это одна снятая спутником сцена). Кстати, если приблизиться, будут видны и сами снимки в полном разрешении (30м/пиксель)!

При помощи такого мультивременного слоя можно искать съёмку на конкретный район — нужно зазумиться в нужное место, выбрать период побольше и переключать слои кликами по ним. Вот [http://maps.kosmosnimki.ru/api/index.html?permalink=5U7YK&6F8B9 доступная съёмка Landsat 8 на Северобайкальск c апреля этого года] (кликайте для переключения снимков).

Так же мы экспериментируем с различными дополнительными элементами управления для анализа временно́й компоненты данных. [http://www.youtube.com/watch?v=VaPJFivbN7c Вот пример] работы с одним из таких инструментов - "таймлайном". Этот инструмент упрощает понимание того, как данные из некоторой пространственной области распределены во времени.

[[Файл:Geomixer_temporal_ais.png|700px|center]]

Следующий пример — мониторинг объектов. У нас ведётся несколько мониторинговых проектов, данные по которым хранятся именно в форме мультивременных рядов.

На скриншоте выше показан пример визуализации данных мониторинга судов за один день в Баренцевом море (к сожалению, лицензия на данные не позволяет нам использовать их в публичных проектах). Каждый треугольник — зафиксированное положение корабля. Направление иконки соответствует направлению движения, а цвет — типу судна. В этом слое на данный момент 3.7 млн. объектов (положений кораблей). Использование мультивременного слоя позволяет быстро просматривать данные за произвольный временной период.

== Как оно работает (скучный технический раздел :) ==

Основная проблема, которую нам пришлось решить — передача на клиент только нужных данных без существенной загрузки сервера. Можно было бы настроить в БД нужные индексы, при каждом запросе делать выборки, результаты конвертировать в понятный клиенту формат и отгружать в браузер. Но нам это показалось недостаточно эффективным решением. Кроме того, у нас есть хорошо себя показавшие векторные тайлы, которые хотелось применить и для мультивременных слоёв. Но всё оказалось не так просто…

[[Файл:Geomixer_temporal_vector_tiles.png|center|400px|]]
''Пример разбиения пространства на тайлы разного размера. Размер тайла определяется количеством попавших в него данных.''

Сначала пару слов про наши векторные тайлы. Для передачи на клиент векторных данных мы разбиваем них на квадратные кусочки (тайлы), сразу же преобразуем эти кусочки в GeoJSON-подобный формат и сохраняем на диск. Клиенту просто отдаём статические файлы. Степень разбиения контролируется размером данных — если в тайле оказывается слишком много объектов, он разбивается на 4 подтайла. Такой подход сохраняет баланс между количеством запросов на сервер и загрузкой лишних (не видимых в данный момент) данных.

Однако при применении этой схемы к мультивременным слоям мы столкнулись с проблемой формы пространственно-временной области, которая может быть запрошена.

[[Файл:Geomixer_temporal_temporal_tiles1.png|center|700px]]
''Мультивременные тайлы по дням. Дополнительно показана структура тайлов за один конкретный день. Каждый квадратик — отдельный тайл с данными. По горизонтальной оси условно показан размер тайла в пространстве, а по вертикальной — его протяжённость по времени.''

Всё дело в том, что квадратные тайлы (векторные или растровые — не важно) хорошо подходят для передачи на клиент только при условии, что область просмотра (экран монитора) тоже примерно квадратная. Но представьте на минутку, что пользователь захочет отрисовать картинку размером 1×100000 или 100000×1 пикселей! Стандартные квадратные тайлы 256×256 тут не подойдут — вам придётся передать ровно в 256 раз больше данных, чем нужно клиенту!

Именно такая ситуация возникает в случае с пространственно-временными данными — пользователи хотят смотреть и данные на весь мир за один день (аналог запроса 10000×1) и данные за 10 лет на деревню бабушки (1×10000). Если есть тайлы только за отдельные дни, во втором случае придётся сделать минимум 3650 запросов; если в каждом тайле есть данные сразу за 10 лет, при просмотре всего мира за любой день мы загрузим весь архив (точнее говоря, попробуем загрузить…).

[[Файл:Geomixer_temporal_temporal_tiles2.png|center|500px]]
''Наборы тайлов с разным разрешением по времени. Показаны характерные запросы от пользователей, которые обрабатываются этими наборами. Каждый тайл имеет примерно одинаковый размер данных, так что при увеличении протяжённости во времени размер в пространстве уменьшается.''

Решаем мы эту проблему хранением сразу нескольких наборов тайлов различной формы. Условно говоря, есть тайлы за каждый отдельный день, тайлы за неделю, за месяц и за год. Список тайлов передаётся на клиент. Когда пользователь выбирает определённый период в календарике, наш API решает, какой набор данных лучше использовать и грузит нужные тайлы (кстати, определение этого набора тоже интересная задачка, которая может быть решена разными способами).

Такой подход позволяет крайне эффективно с точки зрения сервера выбирать данные для запросов разной формы (фактически, раздаётся статика). Из минусов можно отметить увеличение объёма данных на сервере для хранения векторных тайлов (хотя для нас это всё-равно копейки по сравнению с размером наших растровых данных) и сложность обновления (каждое изменение нужно отразить сразу в нескольких наборах).

== Банальное заключение ==

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

== (Бес)полезные ссылки ==
* [http://gis-lab.info/qa/geomixer.html Краткий обзор GeoMixer WEB-GIS]
* [http://docs.geomixer.ru/doku.php?id=geomixer:documentation:user_manual:geomixer_web_gis Пользовательская документация GeoMixer]
* [http://geomixer.ru/api_reference GeoMixer API Reference]

Мультивременные слои в GeoMixer WEB-GIS

2013-11-29T12:40:17Z

Parshin:

{{Статья|Черновик}}
{{Аннотация|Общий обзор и детали реализации механизма работы с временны́ми архивами данных в GeoMixer Web-GIS}}

== Философское введение ==

Иногда данных бывает много, очень много. Как правило, пытаться отобразить их все — плохая идея. И дело тут даже не в технических сложностях и ограничениях, а в возможностях человека. Сложно представить себе ситуацию, когда пользователю одновременно нужно увидеть несколько десятков тысяч отдельных объектов.

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

В нашей практике реализации проектов на основе платформы [http://gis-lab.info/qa/geomixer.html GeoMixer] часто встречался особенный вид данных — объекты, накапливающиеся с течением времени. Это могут быть данные о погоде (температура, давление, сила и направление ветра), пожары, результаты мониторинга (рубки, нефтяные слики, и т.д.) и множество других примеров. Так же временной аспект могут иметь и сами снимки ДЗЗ (например, при регулярной съёмке одной и той же территории).

Изначально мы использовали стандартные механизмы работы с наборами данных: разбивали данные на отдельные слои по дате; объединяли всё в один слой, а потом фильтровали объекты слоя по временному атрибуту; делали специализированные интерфейсы под конкретные проекты. Однако все эти варианты имеют ряд технических сложностей, трудны в поддержке и не всегда адекватно выглядят для пользователей.

Со временем пришло понимание, что для подобных данных нужно отдельное решение — мультивременные слои. Мультивременной слой в ГеоМиксере — это векторный слой, объекты которого могут быть отображены за какой-то определённый промежуток времени. При этом не просто происходит фильтрация данных в момент визуализации, но и оптимизация передачи данных с сервера. Таким образом, становится возможным создавать слои практически с неограниченным количеством данных при условии, что при просмотре данных будет выбрана разумная пространственно-временная область.

== Как использовать в ГеоМиксере ==

Мультивременной слой в ГеоМиксере является частным случаем векторного слоя (из меню: Слой -> Создать векторный слой). Можно использовать готовый источник данных (например, shp файл) или создать пустой слой с заданием атрибутивных полей вручную. При этом среди атрибутов слоя должны быть поля временнóго типа.

После сохранения карты и перезагрузки страницы слева над деревом слоёв появится календарик для выбора периода отображения. Его можно использовать для просмотра данных за определённый период. Стоит иметь в виду, что календарик по умолчанию действует на все слои в карте.

Для работы с мультивременными слоями через GeoMixer API в класс [http://geomixer.ru/api_reference/#класс_layer Layer] добавлен метод <code>setDateInterval()</code>:
<pre>
function setDateInterval(dateBegin, dateEnd)
dateBegin: Date – начальная дата периода отображения
dateEnd: Date – конечная дата периода отображения
</pre>

Функция позволяет отображать данные векторного слоя за период с <code>dateBegin</code> до <code>dateEnd</code>.

При этом через API для разных слоёв можно задавать разные периоды отображения.

== Примеры ==

[[Файл:Geomixer_temporal_hotspots.png|700px|center]]

Наш [http://maps.kosmosnimki.ru/api/index.html?6F8B9| любимый векторный слой] — точки с температурными аномалиями (пожарами), полученными со спутников [http://en.wikipedia.org/wiki/Terra_(satellite) TERRA] и [http://en.wikipedia.org/wiki/Aqua_(satellite) AQUA].

В слое 6.6 млн. точек с августа 2012 по текущий момент. На календарике сверху слева можно выбрать любой день и посмотреть пожары по всему миру за эту дату.

Более того, реализация мультивременных слоёв в ГеоМиксере позволяет не только просматривать данные за один день, но и увидеть данные на локальную территорию за большой промежуток времени (лишь бы общий объём данных в этой пространственно-временной области был разумным). Вот пример такой выборки — [http://maps.kosmosnimki.ru/api/index.html?permalink=KDHV2&KRZ89| пожары за весь прошлый год на Московскую область].

[[Файл:geomixer_temporal_landsat8.jpg|700px|center]]

Ещё пример — данные [http://en.wikipedia.org/wiki/Landsat_8| Landsat 8]. Данные открытые, мы скачиваем безоблачные сцены на территорию России и храним их в ГеоМиксере в виде мультивременного слоя. Например, вот [http://maps.kosmosnimki.ru/api/index.html?permalink=PR7PO&6F8B9| съёмка за одну неделю в ноябре] (каждый прямоугольник — это одна снятая спутником сцена). Кстати, если приблизиться, будут видны и сами снимки в полном разрешении (30м/пиксель)!

При помощи такого мультивременного слоя можно искать съёмку на конкретный район — нужно зазумиться в нужное место, выбрать период побольше и переключать слои кликами по ним. Вот [http://maps.kosmosnimki.ru/api/index.html?permalink=5U7YK&6F8B9| доступная съёмка Landsat 8 на Северобайкальск c апреля этого года] (кликайте для переключения снимков).

[[Файл:Geomixer_temporal_ais.png|700px|center]]

Следующий пример — мониторинг объектов. У нас ведётся несколько мониторинговых проектов, данные по которым хранятся именно в форме мультивременных рядов.

На скриншоте выше показан пример визуализации данных мониторинга судов за один день в Баренцевом море (к сожалению, лицензия на данные не позволяет нам использовать их в публичных проектах). Каждый треугольник — зафиксированное положение корабля. Направление иконки соответствует направлению движения, а цвет — типу судна. В этом слое на данный момент 3.7 млн. объектов (положений кораблей). Использование мультивременного слоя позволяет быстро просматривать данные за произвольный временной период.

== Как оно работает (скучный технический раздел :) ==

Основная проблема, которую нам пришлось решить — передача на клиент только нужных данных без существенной загрузки сервера. Можно было бы настроить в БД нужные индексы, при каждом запросе делать выборки, результаты конвертировать в понятный клиенту формат и отгружать в браузер. Но нам это показалось недостаточно эффективным решением. Кроме того, у нас есть хорошо себя показавшие векторные тайлы, которые хотелось применить и для мультивременных слоёв. Но всё оказалось не так просто…

[[Файл:Geomixer_temporal_vector_tiles.png|center|400px|]]
''Пример разбиения пространства на тайлы разного размера. Размер тайла определяется количеством попавших в него данных.''

Сначала пару слов про наши векторные тайлы. Для передачи на клиент векторных данных мы разбиваем них на квадратные кусочки (тайлы), сразу же преобразуем эти кусочки в GeoJSON-подобный формат и сохраняем на диск. Клиенту просто отдаём статические файлы. Степень разбиения контролируется размером данных — если в тайле оказывается слишком много объектов, он разбивается на 4 подтайла. Такой подход сохраняет баланс между количеством запросов на сервер и загрузкой лишних (не видимых в данный момент) данных.

Однако при применении этой схемы к мультивременным слоям мы столкнулись с проблемой формы пространственно-временной области, которая может быть запрошена.

[[Файл:Geomixer_temporal_temporal_tiles1.png|center|700px]]
''Мультивременные тайлы по дням. Дополнительно показана структура тайлов за один конкретный день. Каждый квадратик — отдельный тайл с данными. По горизонтальной оси условно показан размер тайла в пространстве, а по вертикальной — его протяжённость по времени.''

Всё дело в том, что квадратные тайлы (векторные или растровые — не важно) хорошо подходят для передачи на клиент только при условии, что область просмотра (экран монитора) тоже примерно квадратная. Но представьте на минутку, что пользователь захочет отрисовать картинку размером 1×100000 или 100000×1 пикселей! Стандартные квадратные тайлы 256×256 тут не подойдут — вам придётся передать ровно в 256 раз больше данных, чем нужно клиенту!

Именно такая ситуация возникает в случае с пространственно-временными данными — пользователи хотят смотреть и данные на весь мир за один день (аналог запроса 10000×1) и данные за 10 лет на деревню бабушки (1×10000). Если есть тайлы только за отдельные дни, во втором случае придётся сделать минимум 3650 запросов; если в каждом тайле есть данные сразу за 10 лет, при просмотре всего мира за любой день мы загрузим весь архив (точнее говоря, попробуем загрузить…).

[[Файл:Geomixer_temporal_temporal_tiles2.png|center|500px]]
''Наборы тайлов с разным разрешением по времени. Показаны характерные запросы от пользователей, которые обрабатываются этими наборами. Каждый тайл имеет примерно одинаковый размер данных, так что при увеличении протяжённости во времени размер в пространстве уменьшается.''

Решаем мы эту проблему хранением сразу нескольких наборов тайлов различной формы. Условно говоря, есть тайлы за каждый отдельный день, тайлы за неделю, за месяц и за год. Список тайлов передаётся на клиент. Когда пользователь выбирает определённый период в календарике, наш API решает, какой набор данных лучше использовать и грузит нужные тайлы (кстати, определение этого набора тоже интересная задачка, которая может быть решена разными способами).

Такой подход позволяет крайне эффективно с точки зрения сервера выбирать данные для запросов разной формы (фактически, раздаётся статика). Из минусов можно отметить увеличение объёма данных на сервере для хранения векторных тайлов (хотя для нас это всё-равно копейки по сравнению с размером наших растровых данных) и сложность обновления (каждое изменение нужно отразить сразу в нескольких наборах).

== Банальное заключение ==

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

== (Бес)полезные ссылки ==
* [http://gis-lab.info/qa/geomixer.html Краткий обзор GeoMixer WEB-GIS]
* [http://docs.geomixer.ru/doku.php?id=geomixer:documentation:user_manual:geomixer_web_gis Пользовательская документация GeoMixer]
* [http://geomixer.ru/api_reference GeoMixer API Reference]

Мультивременные слои в GeoMixer WEB-GIS

2013-11-28T14:31:59Z

Parshin:

{{Статья|Черновик}}
{{Аннотация|Общий обзор и детали реализации механизма работы с временны́ми архивами данных в GeoMixer Web-GIS}}

== Философское введение ==

Иногда данных бывает много, очень много. Как правило, пытаться отобразить их все — плохая идея. И дело тут даже не в технических сложностях и ограничениях, а в возможностях человека. Сложно представить себе ситуацию, когда пользователю одновременно нужно увидеть несколько десятков тысяч отдельных объектов.

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

В нашей практике реализации проектов на основе платформы [http://gis-lab.info/qa/geomixer.html GeoMixer] часто встречался особенный вид данных — объекты, накапливающиеся с течением времени. Это могут быть данные о погоде (температура, давление, сила и направление ветра), пожары, результаты мониторинга (рубки, нефтяные слики, и т.д.) и множество других примеров. Так же временной аспект могут иметь и сами снимки ДЗЗ (например, при регулярной съёмке одной и той же территории).

Изначально мы использовали стандартные механизмы работы с наборами данных: разбивали данные на отдельные слои по дате; объединяли всё в один слой, а потом фильтровали объекты слоя по временному атрибуту; делали специализированные интерфейсы под конкретные проекты. Однако все эти варианты имеют ряд технических сложностей, трудны в поддержке и не всегда адекватно выглядят для пользователей.

Со временем пришло понимание, что для подобных данных нужно отдельное решение — мультивременные слои. Мультивременной слой в ГеоМиксере — это векторный слой, объекты которого могут быть отображены за какой-то определённый промежуток времени. При этом не просто происходит фильтрация данных в момент визуализации, но и оптимизация передачи данных с сервера. Таким образом, становится возможным создавать слои практически с неограниченным количеством данных при условии, что при просмотре данных будет выбрана разумная пространственно-временная область.

== Как использовать в ГеоМиксере ==

Мультивременной слой в ГеоМиксере является частным случаем векторного слоя (из меню: Слой -> Создать векторный слой). Можно использовать готовый источник данных (например, shp файл) или создать пустой слой с заданием атрибутивных полей вручную. При этом среди атрибутов слоя должны быть поля временнóго типа.

После сохранения карты и перезагрузки страницы слева над деревом слоёв появится календарик для выбора периода отображения. Его можно использовать для просмотра данных за определённый период. Стоит иметь в виду, что календарик по умолчанию действует на все слои в карте.

Для работы с мультивременными слоями через GeoMixer API в класс [http://geomixer.ru/api_reference/#класс_layer Layer] добавлен метод <code>setDateInterval()</code>:
<pre>
function setDateInterval(dateBegin, dateEnd)
dateBegin: Date – начальная дата периода отображения
dateEnd: Date – конечная дата периода отображения
</pre>

Функция позволяет отображать данные векторного слоя за период с <code>dateBegin</code> до <code>dateEnd</code>.

При этом через API для разных слоёв можно задавать разные периоды отображения.

== Примеры ==

[[Файл:Geomixer_temporal_hotspots.png|700px|center]]

Наш [http://maps.kosmosnimki.ru/api/index.html?6F8B9| любимый векторный слой] — точки с температурными аномалиями (пожарами), полученными со спутников [http://en.wikipedia.org/wiki/Terra_(satellite) TERRA] и [http://en.wikipedia.org/wiki/Aqua_(satellite) AQUA].

В слое 6.6 млн. точек с августа 2012 по текущий момент. На календарике сверху слева можно выбрать любой день и посмотреть пожары по всему миру за эту дату.

Более того, реализация мультивременных слоёв в ГеоМиксере позволяет не только просматривать данные за один день, но и увидеть данные на локальную территорию за большой промежуток времени (лишь бы общий объём данных в этой пространственно-временной области был разумным). Вот пример такой выборки — [http://maps.kosmosnimki.ru/api/index.html?permalink=KDHV2&KRZ89| пожары за весь прошлый год на Московскую область].

[[Файл:geomixer_temporal_landsat8.jpg|700px|center]]

Ещё пример — данные [http://en.wikipedia.org/wiki/Landsat_8| Landsat 8]. Данные открытые, мы скачиваем безоблачные сцены на территорию России и храним их в ГеоМиксере в виде мультивременного слоя. Например, вот [http://maps.kosmosnimki.ru/api/index.html?permalink=PR7PO&6F8B9| съёмка за одну неделю в ноябре] (каждый прямоугольник — это одна снятая спутником сцена). Кстати, если приблизиться, будут видны и сами снимки в полном разрешении (30м/пиксель)!

При помощи такого мультивременного слоя можно искать съёмку на конкретный район — нужно зазумиться в нужное место, выбрать период побольше и переключать слои кликами по ним. Вот [http://maps.kosmosnimki.ru/api/index.html?permalink=5U7YK&6F8B9| доступная съёмка Landsat 8 на Северобайкальск c апреля этого года] (кликайте для переключения снимков).

[[Файл:Geomixer_temporal_ais.png|700px|center]]

Следующий пример — мониторинг объектов. У нас ведётся несколько мониторинговых проектов, данные по которым хранятся именно в форме мультивременных рядов.

На скриншоте выше показан пример визуализации данных мониторинга судов за один день в Баренцевом море (к сожалению, лицензия на данные не позволяет нам использовать их в публичных проектах). Каждый треугольник — зафиксированное положение корабля. Направление иконки соответствует направлению движения, а цвет — типу судна. В этом слое на данный момент 3.7 млн. объектов (положений кораблей). Использование мультивременного слоя позволяет быстро просматривать данные за произвольный временной период.

== Как оно работает (скучный технический раздел :) ==

Основная проблема, которую нам пришлось решить — передача на клиент только нужных данных без существенной загрузки сервера. Можно было бы настроить в БД нужные индексы, при каждом запросе делать выборки, результаты конвертировать в понятный клиенту формат и отгружать в браузер. Но нам это показалось недостаточно эффективным решением. Кроме того, у нас есть хорошо себя показавшие векторные тайлы, которые хотелось применить и для мультивременных слоёв. Но всё оказалось не так просто…

[[Файл:Geomixer_temporal_vector_tiles.png|center|400px|]]
''Пример разбиения пространства на тайлы разного размера. Размер тайла определяется количеством попавших в него данных.''

Сначала пару слов про наши векторные тайлы. Для передачи на клиент векторных данных мы разбиваем них на квадратные кусочки (тайлы), сразу же преобразуем эти кусочки в GeoJSON-подобный формат и сохраняем на диск. Клиенту просто отдаём статические файлы. Степень разбиения контролируется размером данных — если в тайле оказывается слишком много объектов, он разбивается на 4 подтайла. Такой подход сохраняет баланс между количеством запросов на сервер и загрузкой лишних (не видимых в данный момент) данных.

Однако при применении этой схемы к мультивременным слоям мы столкнулись с проблемой формы пространственно-временной области, которая может быть запрошена.

[[Файл:Geomixer_temporal_temporal_tiles1.png|center|700px]]
''Мультивременные тайлы по дням. Дополнительно показана структура тайлов за один конкретный день. Каждый квадратик — отдельный тайл с данными. По горизонтальной оси условно показан размер тайла в пространстве, а по вертикальной — его протяжённость по времени.''

Всё дело в том, что квадратные тайлы (векторные или растровые — не важно) хорошо подходят для передачи на клиент только при условии, что область просмотра (экран монитора) тоже примерно квадратная. Но представьте на минутку, что пользователь захочет отрисовать картинку размером 1×100000 или 100000×1 пикселей! Стандартные квадратные тайлы 256×256 тут не подойдут — вам придётся передать ровно в 256 раз больше данных, чем нужно клиенту!

Именно такая ситуация возникает в случае с пространственно-временными данными — пользователи хотят смотреть и данные на весь мир за один день (аналог запроса 10000×1) и данные за 10 лет на деревню бабушки (1×10000). Если есть тайлы только за отдельные дни, во втором случае придётся сделать минимум 3650 запросов; если в каждом тайле есть данные сразу за 10 лет, при просмотре всего мира за любой день мы загрузим весь архив (точнее говоря, попробуем загрузить…).

[[Файл:Geomixer_temporal_temporal_tiles2.png|center|500px]]
''Наборы тайлов с разным разрешением по времени. Показаны характерные запросы от пользователей, которые обрабатываются этими наборами. Каждый тайл имеет примерно одинаковый размер данных, так что при увеличении протяжённости во времени размер в пространстве уменьшается.''

Решаем мы эту проблему хранением сразу нескольких наборов тайлов различной формы. Условно говоря, есть тайлы за каждый отдельный день, тайлы за неделю, за месяц и за год. Список тайлов передаётся на клиент. Когда пользователь выбирает определённый период в календарике, наш API решает, какой набор данных лучше использовать и грузит нужные тайлы (кстати, определение этого набора тоже интересная задачка, которая может быть решена разными способами).

Такой подход позволяет крайне эффективно с точки зрения сервера выбирать данные для запросов разной формы (фактически, раздаётся статика). Из минусов можно отметить увеличение объёма данных на сервере для хранения векторных тайлов (хотя для нас это всё-равно копейки по сравнению с размером наших растровых данных) и сложность обновления (каждое изменение нужно отразить сразу в нескольких наборах).

== Банальное заключение ==

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

== (Бес)полезные ссылки ==
* [http://gis-lab.info/qa/geomixer.html| Краткий обзор GeoMixer WEB-GIS]
* [http://docs.geomixer.ru/doku.php?id=geomixer:documentation:user_manual:geomixer_web_gis| Пользовательская документация GeoMixer]
* [http://geomixer.ru/api_reference| GeoMixer API Reference]

Мультивременные слои в GeoMixer WEB-GIS

2013-11-28T08:03:52Z

Parshin: Новая страница: «{{Статья|Черновик}} == Философское введение == Иногда данных бывает много, очень много. Как…»

{{Статья|Черновик}}

== Философское введение ==

Иногда данных бывает много, очень много. Как правило, пытаться отобразить их все — плохая идея. И дело тут даже не в технических сложностях и ограничениях, а в возможностях человека. Сложно представить себе ситуацию, когда пользователю одновременно нужно увидеть несколько десятков тысяч отдельных объектов.

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

В нашей практике часто встречался особенный вид данных — объекты, накапливающиеся с течением времени. Это могут быть данные о погоде (температура, давление, сила и направление ветра), пожары, результаты мониторинга (рубки, нефтяные слики, и т.д.) и множество других примеров. Так же временной аспект могут иметь и сами снимки ДЗЗ (например, при регулярной съёмке одной и той же территории).

Изначально мы использовали стандартные механизмы работы с наборами данных: разбивали данные на отдельные слои по дате; объединяли всё в один слой, а потом фильтровали объекты слоя по временному атрибуту; делали специализированные интерфейсы под конкретные проекты. Однако все эти варианты имеют ряд технических сложностей, трудны в поддержке и не всегда адекватно выглядят для пользователей.

Со временем пришло понимание, что для подобных данных нужно отдельное решение — мультивременные слои. Мультивременной слой в ГеоМиксере — это векторный слой, объекты которого могут быть отображены за какой-то определённый промежуток времени. При этом не просто происходит фильтрация данных в момент визуализации, но и оптимизация передачи данных с сервера. Таким образом, становится возможным создавать слои практически с неограниченным количеством данных при условии, что при просмотре данных будет выбрана разумная пространственно-временная область.

== Как использовать в ГеоМиксере ==

Мультивременной слой в ГеоМиксере является частным случаем векторного слоя (из меню: Слой -> Создать векторный слой). Можно использовать готовый источник данных (например, shp файл) или создать пустой слой с заданием атрибутивных полей вручную. При этом среди атрибутов слоя должны быть поля временнóго типа.

После сохранения карты и перезагрузки страницы слева над деревом слоёв появится календарик для выбора периода отображения. Его можно использовать для просмотра данных за определённый период. Стоит иметь в виду, что календарик по умолчанию действует на все слои в карте.

Для работы с мультивременными слоями через GeoMixer API в класс [http://geomixer.ru/api_reference/#класс_layer Layer] добавлен метод <code>setDateInterval()</code>:
<pre>
function setDateInterval(dateBegin, dateEnd)
dateBegin: Date – начальная дата периода отображения
dateEnd: Date – конечная дата периода отображения
</pre>

Функция позволяет отображать данные векторного слоя за период с <code>dateBegin</code> до <code>dateEnd</code>.

При этом через API для разных слоёв можно задавать разные периоды отображения.

== Примеры ==

[[Файл:Geomixer_temporal_hotspots.png|700px]]

Наш [http://maps.kosmosnimki.ru/api/index.html?6F8B9| любимый векторный слой] — точки с температурными аномалиями (пожарами), полученными со спутников [http://en.wikipedia.org/wiki/Terra_(satellite) TERRA] и [http://en.wikipedia.org/wiki/Aqua_(satellite) AQUA].

В слое 6.6 млн. точек с августа 2012 по текущий момент. На календарике сверху слева можно выбрать любой день и посмотреть пожары по всему миру за эту дату.

Более того, реализация мультивременных слоёв в ГеоМиксере позволяет не только просматривать данные за один день, но и увидеть данные на локальную территорию за большой промежуток времени (лишь бы общий объём данных в этой пространственно-временной области был разумным). Вот пример такой выборки — [http://maps.kosmosnimki.ru/api/index.html?permalink=KDHV2&KRZ89| пожары за весь прошлый год на Московскую область].

[[Файл:geomixer_temporal_landsat8.jpg|700px]]

Ещё пример — данные [http://en.wikipedia.org/wiki/Landsat_8| Landsat 8]. Данные открытые, мы скачиваем безоблачные сцены на территорию России и храним их в ГеоМиксере в виде мультивременного слоя. Например, вот [http://maps.kosmosnimki.ru/api/index.html?permalink=PR7PO&6F8B9| съёмка за одну неделю в ноябре] (каждый прямоугольник — это одна снятая спутником сцена). Кстати, если приблизиться, будут видны и сами снимки в полном разрешении (30м/пиксель)!

При помощи такого мультивременного слоя можно искать съёмку на конкретный район — нужно зазумиться в нужное место, выбрать период побольше и переключать слои кликами по ним. Вот [http://maps.kosmosnimki.ru/api/index.html?permalink=5U7YK&6F8B9| доступная съёмка Landsat 8 на Северобайкальск c апреля этого года] (кликайте для переключения снимков).

[[Файл:Geomixer_temporal_ais.png|700px]]

Следующий пример — мониторинг объектов. У нас ведётся несколько мониторинговых проектов, данные по которым хранятся именно в форме мультивременных рядов.

На скриншоте выше показан пример визуализации данных мониторинга судов за один день в Баренцевом море (к сожалению, лицензия на данные не позволяет нам использовать их в публичных проектах). Каждый треугольник — зафиксированное положение корабля. Направление иконки соответствует направлению движения, а цвет — типу судна. В этом слое на данный момент 3.7 млн. объектов (положений кораблей). Использование мультивременного слоя позволяет быстро просматривать данные за произвольный временной период.

== Как оно работает (скучный технический раздел :) ==

Основная проблема, которую нам пришлось решить — передача на клиент только нужных данных без существенной загрузки сервера. Можно было бы настроить в БД нужные индексы, при каждом запросе делать выборки, результаты конвертировать в понятный клиенту формат и отгружать в браузер. Но нам это показалось недостаточно эффективным решением. Кроме того, у нас есть хорошо себя показавшие векторные тайлы, которые хотелось применить и для мультивременных слоёв. Но всё оказалось не так просто…

[[Файл:Geomixer_temporal_vector_tiles.png|center|400px|]]
''Пример разбиения пространства на тайлы разного размера. Размер тайла определяется количеством попавших в него данных.''

Сначала пару слов про наши векторные тайлы. Для передачи на клиент векторных данных мы разбиваем них на квадратные кусочки (тайлы), сразу же преобразуем эти кусочки в GeoJSON-подобный формат и сохраняем на диск. Клиенту просто отдаём статические файлы. Степень разбиения контролируется размером данных — если в тайле оказывается слишком много объектов, он разбивается на 4 подтайла. Такой подход сохраняет баланс между количеством запросов на сервер и загрузкой лишних (не видимых в данный момент) данных.

Однако при применении этой схемы к мультивременным слоям мы столкнулись с проблемой формы пространственно-временной области, которая может быть запрошена.

[[Файл:Geomixer_temporal_temporal_tiles1.png|center|700px]]
''Мультивременные тайлы по дням. Дополнительно показана структура тайлов за один конкретный день. Каждый квадратик — отдельный тайл с данными. По горизонтальной оси условно показан размер тайла в пространстве, а по вертикальной — его протяжённость по времени.''

Всё дело в том, что квадратные тайлы (векторные или растровые — не важно) хорошо подходят для передачи на клиент только при условии, что область просмотра (экран монитора) тоже примерно квадратная. Но представьте на минутку, что пользователь захочет отрисовать картинку размером 1×100000 или 100000×1 пикселей! Стандартные квадратные тайлы 256×256 тут не подойдут — вам придётся передать ровно в 256 раз больше данных, чем нужно клиенту!

Именно такая ситуация возникает в случае с пространственно-временными данными — пользователи хотят смотреть и данные на весь мир за один день (аналог запроса 10000×1) и данные за 10 лет на деревню бабушки (1×10000). Если есть тайлы только за отдельные дни, во втором случае придётся сделать минимум 3650 запросов; если в каждом тайле есть данные сразу за 10 лет, при просмотре всего мира за любой день мы загрузим весь архив (точнее говоря, попробуем загрузить…).

[[Файл:Geomixer_temporal_temporal_tiles2.png|center|500px]]
''Наборы тайлов с разным разрешением по времени. Показаны характерные запросы от пользователей, которые обрабатываются этими наборами. Каждый тайл имеет примерно одинаковый размер данных, так что при увеличении протяжённости во времени размер в пространстве уменьшается.''

Решаем мы эту проблему хранением сразу нескольких наборов тайлов различной формы. Условно говоря, есть тайлы за каждый отдельный день, тайлы за неделю, за месяц и за год. Список тайлов передаётся на клиент. Когда пользователь выбирает определённый период в календарике, наш API решает, какой набор данных лучше использовать и грузит нужные тайлы (кстати, определение этого набора тоже интересная задачка, которая может быть решена разными способами).

Такой подход позволяет крайне эффективно с точки зрения сервера выбирать данные для запросов разной формы (фактически, раздаётся статика). Из минусов можно отметить увеличение объёма данных на сервере для хранения векторных тайлов (хотя для нас это всё-равно копейки по сравнению с размером наших растровых данных) и сложность обновления (каждое изменение нужно отразить сразу в нескольких наборах).

== Банальное заключение ==

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

Файл:Geomixer temporal temporal tiles2.png

2013-11-28T07:58:29Z

Parshin:

Файл:Geomixer temporal temporal tiles1.png

2013-11-28T07:47:46Z

Parshin:

Файл:Geomixer temporal vector tiles.png

2013-11-28T07:44:13Z

Parshin:

Файл:Geomixer temporal ais.png

2013-11-28T07:42:34Z

Parshin:

Файл:Geomixer temporal landsat8.jpg

2013-11-28T07:39:23Z

Parshin:

Файл:Geomixer temporal hotspots.png

2013-11-28T07:25:13Z

Parshin: