На сайте www.gis-lab.info/blog размещена статья одного из пользователей ресурса "Сервисы OWS. Часть 2 (или почему WMS = Интернет)". Ознакомиться с публикацией полностью можно по ссылке - http://gis-lab.info/blog/2011-03/wms-vs-wfs/#comments

Для отображения любых данных на экране компьютера требуется преобразовать их в определенный вид. В веб-программировании этот процесс называется «рендеринг» и выполняет его «рендер» (render или renderer). В программировании настольных приложений используют другие термины, но суть особо не меняется.

В веб-браузере на самом низком уровне прикладные приложения могут использовать технологии VML (HTML4) и SVG/Canvas (HTML5). С использованием плагинов добавляются ActionScript (в народе «флэш») и 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 становится частью веб-приложения и выполняет роль внешнего рендера.

Любое веб-приложение можно рассматривать как построенное по архитектуре клиент-сервер. В зависимости от «толщины» клиента выбирается тип рендера (встроенный или внешний).

В процессе проектирования рассматривают:

1. источники данных;
2. способы их отображения (рендеринг).

Как описывалось в первой части («Сервисы OWS»), между двумя пунктами также нужно предусмотреть транспортировку. Для векторных данных применяется протокол WFS.

Довольно распространена ситуация, когда данные не консолидированы, содержатся в независимых хранилищах или появляются в результате выполнения запроса (процесса). В такой ситуации можно применить агрегацию. Например, в п. 1а включить БД PostgreSQL с применением расширения dblink.

Но если решить задачу готовыми средствами не получается, тогда переходят к созданию сервиса, который обращается в различные источники, собирает данные и представляет их в виде WFS. Далее поток WFS можно направить как на внешний рендер (сервер WMS), так и в OpenLayers.

В принципе, возможен вариант создания драйвера, позволяющего серверу WMS получать данные напрямую. Но с точки зрения модульности и простоты отладки предпочтительнее создание полноценного сервиса WFS. Тем более что готовых библиотек достаточно много (например, FeatureServer) и небольшая доработка под конкретную ситуацию не должны вызвать проблем.

Таким образом, публикацию данных нужно рассматривать с точки зрения возможности создания сервиса WFS. Выбор рендера производится позже. Большинство серверов WMS имеют богатые функции доступа к обычным хранилищам данных и, возможно, что в итоге потребность в сервисе WFS отпадет. Но на стадии проектирования рассуждать нужно с позиции «WMS – рендер и он получает готовые данные».