Сервисы OWS. Часть 2. (?ли почему WMS = ?нтернет.)
SVG и Canvas
Для отображения любых данных на экране компьютера требуется преобразовать их в определенный вид. В веб-программировании этот процесс называется “рендеринг” и выполняет его “рендер” (render или renderer). В программировании настольных приложений используют другие термины, но суть особо не меняется.
В веб-браузере на самом низком уровне прикладные приложения могут использовать технологии VML (HTML4) и SVG/Canvas (HTML5). С использованием плагинов добавляются Flash, JavaFX и Silverlight. Заметим, что WebGL является надстройкой к Canvas.
Поскольку напрямую с любой из этих технологий работать излишне трудоемко, то используют библиотеки более высокого уровня. Для веб-карт такими служат, например, OpenLayers и Flamingo. Сюда же можно отнести Google Maps API, Bing Maps API и другие коммерческие библиотеки с открытым API.
На еще более высоком уровне находятся фреймворки MapFish, Mapbender, i3Geo, GeoMOOSE и др., которые описывают логику веб-приложений и применяют библиотеки уровня OpenLayers в качестве рендеров. Ярким примером такого поведения является библиотека Mapstraction, предлагающая для отображения геоданных множество рендеров: Google, Bing, Yahoo, OSM, OpenLayers, CloudMade.
Если вернуться к истокам, то технология VML обладает очень скромными возможностями. В OpenLayers она позволяет отобразить 500 маркеров и повысить хотя бы на порядок это число не получится. К сожалению, для Internet Explorer 8 это единственно доступный рендер. Дальнейшим развитием VML стал SVG. Технология все еще слишком молодая и текущие реализации в веб-браузерах малопроизводительны. (Проблема в браузерах, а не в технологии.) Потихоньку развивается Canvas, теоретически он также позволяет создать эффективные векторные рендеры. Но так как в результате работы Canvas получается растровый объект, то интерактивное взаимодействие с ним затруднительно. Рендер SVG с точки зрения DOM является контейнером геометрических примитивов. Каждому из них можно назначить реакцию на событие (наведение курсора, щелчок мышью) и браузер самостоятельно отслеживает возникновение таких событий. Canvas же является неделимым растром и при щелчке мышки потребуется на уровне веб-приложения проверить все объекты на совпадение с координатами курсора (или создавать пространственные индексы, доп. структуры данных и т.п.).
Для векторных слоев в OpenLayers по-умолчанию задано использование всех трех рендеров (для версии 2.10):
renderers: ['SVG', 'VML', 'Canvas']
При первом использовании проверяется: поддерживает ли браузер технологию SVG, если нет то делается попытка применения VML, иначе – Canvas. Можно принудительно указать использование нужных рендеров в параметрах слоя.
? SVG и Canvas являются активно развиваемыми технологиями и с выходом новых версий браузеров их производительность улучшается. Тем не менее до раскрытия всех их возможностей еще не скоро и работа с 50 тыс. точек (узлов полигонов) уже является затруднительной задачей (на март 2011 г.).
В целом, основные надежды в будущем направлены на SVG. При работе с изначально растровыми данными (WMS, тайлы) эффективен Canvas. Он уже сейчас частично применяется в OpenLayers, а с выходом версии 3.0 обещают возможность вращения карты.
Action Script и JavaFX обладают прекрасной производительностью, но не всегда доступны на отдельных мобильных платформах (iPhone).
Очень интересен WebGL и интеграция имеющихся виртуальных глобусов на базе этой технологии в картографические фреймворки, вероятно, всего лишь дело времени.
WMS
Что бы нанести на карту векторные объекты информацию о геометрии необходимо сперва передать на компьютер клиента. При определенном объеме данных, а также учитывая скромные возможности рендеров веб-браузера, возникает ситуация, когда выгоднее выполнить рендеринг на стороне сервера и передать клиенту готовый растр.
В ситуации чисто клиент-серверной архитектуры при использовании тонкого клиента сервер WMS становится частью веб-приложения и выполняет роль внешнего рендера.
WMS vs. WFS
Любое веб-приложение можно рассматривать как построенное по архитектуре клиент-сервер. В зависимости от “толщины” клиента выбирается тип рендера (встроенный или внешний).
В процессе проектирования рассматривают:
- источники данных;
- способы их отображения (рендеринг).
Как описывалось в первой части (“Сервисы OWS»), между двумя пунктами также нужно предусмотреть транспортировку. Для векторных данных применяется протокол WFS.
Довольно распространена ситуация, когда данные не консолидированы, содержатся в независимых хранилищах или появляются в результате выполнения запроса (процесса). В такой ситуации можно применить агрегацию. Например, в п. 1а включить БД PostgreSQL с применением расширения dblink.
Но если решить задачу готовыми средствами не получается, тогда переходят к созданию сервиса, который обращается в различные источники, собирает данные и представляет их в виде WFS. Далее поток WFS можно направить как на внешний рендер (сервер WMS), так и в OpenLayers.
В принципе, возможен вариант создания драйвера, позволяющего серверу WMS получать данные напрямую. Но с точки зрения модульности и простоты отладки предпочтительнее создание полноценного сервиса WFS. Тем более что готовых библиотек достаточно много (например, FeatureServer) и небольшая доработка под конкретную ситуацию не должны вызвать проблем.
Таким образом, публикацию данных нужно рассматривать с точки зрения возможности создания сервиса WFS. Выбор рендера производится позже. Большинство серверов WMS имеют богатые функции доступа к обычным хранилищам данных и, возможно, что в итоге потребность в сервисе WFS отпадет. Но на стадии проектирования рассуждать нужно с позиции “WMS – рендер и он получает готовые данные”.
Отличная статья, спасибо! В качестве подтверждения “скромности” VML. ?нтересно, как обстоят дела в IE9, никто не пробовал?
Хорошая статья.
Позволю себе не согласится с одним тезисом – “В принципе, возможен вариант создания драйвера, позволяющего серверу WMS получать данные напрямую. Но с точки зрения модульности и простоты отладки предпочтительнее создание полноценного сервиса WFS.” – Не стоит приравнивать WMS к простому рендереру. По идеологии OWS, и WMS и WFS являются полноценными сервисами (по крайней мере для клиента). Если у вас имеется источник данных, не поддерживаемый ни одним провайдером данных, то необходимо писать сам провайдер. ? что бы модульность была высокой, нельзя затачивать этот провайдер под WMS или под WFS сервер – провайдер должен быть универсальным, тогда не будет разницы с каким сервером его использовать. Да и не всегда работает вариант когда результат, выданный WFS, можно без проблем отрисовывать на WMS – нельзя забывать, что все данные передаются по http, и объемы этих данных могут стать серьезной преградой для использования такого варианта. В любом случае, использование WFS как источник данных для WMS – это лишняя прослойка (в случае если есть вариант прямого доступа к данным) и как следствие – задержка отклика сервиса. Данный момент нужно учитывать на стадии проектирования.
Вы правы, такой взгляд на задачу тоже возможен и тоже может быть правильным. Техническая реализация всегда субъективна, а уж производительность и вовсе никогда не дружит с идеологией.
[…] разработанным OGC: Сервисы доставки данных OWS и Сервисы OWS. Часть 2. (?ли почему WMS = ?нтернет). В статье рассмотрено назначение сервиса WFS, а также […]