Документация по WMS-серверу для ГИС «ИнГео»

(Учебный проект)


 

Оглавление

ВВЕДЕНИЕ. 2

1. НАЗНАЧЕНИЕ WMS-СЕРВЕРА.. 3

2. ТРЕБОВАНИЯ К WMS-СЕРВЕРУ. 4

2.1. Функциональные требования к системе. 4

2.2. Нефункциональные требования к системе. 4

3. АРХИТЕКТУРА СИСТЕМЫ.. 6

3.1. Общая структура проекта. 6

3.2. Базовый каркас системы.. 8

3.3. Функционирование каркаса. 10

4. РАСШИРЕНИЯ КАРКАСА СИСТЕМЫ.. 11

4.1. Проблемно-ориентированное расширение базового каркаса. WMS-сервер. 11

4.2. Предметно-ориентированное расширение WMS-каркаса для ГИС «ИнГео». 12

4.3. Некоторые подробности расширения каркасов WMS-сервера. 13

5. СТРУКТУРА РЕШЕНИЯ В СРЕДЕ Visual Studio 2012. 15

6. ТЕСТИРОВАНИЕ СИСТЕМЫ.. 16

6.1. Модульные тесты.. 16

6.2. Системный тест. 16

6.3. Нагрузочный тест. 16

7. ЭЛЕМЕНТЫ АДМИНИСТРИРОВАНИЯ WMS-СЕРВЕРА.. 17

7.1. Шаг 1. Настройка ГИС «ИнГео». 17

7.2. Шаг 2. Настройка WMS-сервера. 17

7.3. Шаг 3. Установка WMS-сервера. 19

СПИСОК ЛИТЕРАТУРЫ.. 20

ПРИЛОЖЕНИЕ А. Диаграмма классов проекта WMS «ИнГео». 21

 


 

ВВЕДЕНИЕ

Некоторое время назад в компании «Интегро» было принято решение о создании в рамках некоторых внутренних работ небольших учебных проектов, целью которых является не столько разработка программ для поставки на рынок, сколько реализация простых систем для обучения новых программистов компании современным технологиям и подготовке их (программистов) к разработке новых продуктов. К этим проектам мы относимся как к иллюстрации приемов программирования, которые культивируются в компании «Интегро», а не как к полноценным промышленным продуктам. Некоторые проекты предполагается выкладывать в открытый доступ, чтобы внешние начинающие разработчики могли использовать их в своей деятельности. Одним из таких проектов является проект по созданию WMS-сервера на основе ГИС «ИнГео». Но это больше, чем сервер для ГИС «ИнГео», т.к. его достаточно легко расширить для использования с другими ГИС или вообще под задачи создания на основе этого каркаса других несложных серверов, например, WFS и/или WCS

Проект создания WMS-сервера является примером «архитектурно-ориентированного проекта», полученного с помощью так называемого «каркасного» или «концептуального» программирования. Эти методики иногда называются «проектированием путем внесения отличий» (Дж.Шаллоуэй), - когда новый уровень детализации приложения получается из базового обобщенного каркаса путем расширения абстрактных классов (в точках расширения) производными классами, вносящими новые отличия в проектные решения относительно исходных абстракций.

Кроме того, в проекте, приводимом в данном документе, нам хотелось бы думать, что мы в меру используем шаблоны проектирования, не злоупотребляя, но и не пренебрегая ими.

Авторы этого простого «учебного» проекта будут рады, если кому-то из пользователей наших программных продуктов проект WMS-сервера понравится своей простой архитектурой и подтолкнет его мышление в сторону большего внимания к такому аспекту проектирования, как разработка архитектуры программной системы. К сожалению, учебников по каркасам приложения и архитектуре ПО в русскоязычном мире крайне мало, и нам хотелось бы хоть немного заполнить этот пробел конкретными примерами.

Код WMS-сервера в немалом числе мест надо «причесывать», а то и рефакторить, но в целом мы считаем его достаточным для демонстрации сути проекта. Улучшать можно бесконечно.

После публикации кода WMS-сервера компания ЦСИ «Интегро» никому не запрещает использовать исходный код в своих собственных работах. Исключением являются библиотеки (dll) «ИнГео», которые без имеющейся у пользователя лицензии на ГИС «ИнГео» нельзя использовать с коммерческими целями или в промышленных разработках. Но, если кто-то будет использовать каркас не в связке с ГИС «ИнГео», то ему наши библиотеки и не понадобятся.

Все исходные коды решения в среде Microsoft Visual Studio 2012 доступны для скачивания: http://integro.ru/dl/ingeo/ingeowms.rar.

Вопросы по проекту можно присылать на адрес support@integro.ru Желтову Александру в течение двух месяцев - до 30.05.2013г.

1. НАЗНАЧЕНИЕ WMS-СЕРВЕРА

«Web Map Service (WMS) — стандартный протокол для обслуживания через Интернет географически привязанных изображений, генерируемых картографическим сервером на основе информации из базы данных ГИС. Данный стандарт был разработан и впервые опубликован международной организацией OGC (Open Geospatial Consortium — открытый геопространственный консорциум) в 1999 году» [1].

Назначением WMS-сервера является обработка «картографических» запросов к ГИС, которая поставляет внешнему клиенту иерархию картографических слоев и растеризованное изображение карты.

Стандарт WMS определяет три команды:

·      GetCapabilities – запрос сведений о классификаторе (слоях) цифровой карты, предоставляемой сервером;

·      GetMap – запрос фрагмента карты в виде растровой картинки;

·      GetFeatureInfo – запрос семантики для пространственных объектов в определенной точке.

2. ТРЕБОВАНИЯ К WMS-СЕРВЕРУ

2.1. Функциональные требования к системе

В качестве задания на проект требовалось создать программную систему, обеспечивающую обработку запросов, поступающих от большого количества удаленных Web-клиентов, с целью получения растрового изображения карт, которая содержится в ГИС «ИнГео».

В целом функциональные требования к WMS-серверу определяются стандартом WMS версии 1.3.0.

Кроме того;

·      в системе должен быть реализован параллельный принцип обработки запросов с целью максимально полного использования возможностей современных многоядерных аппаратных процессоров;

·      несмотря на то, что конкретное проектное решение будет ориентировано на использование в качестве поставщика карт именно ГИС «ИнГео», ставится требование создания такого программного каркаса приложения, в котором сторонний программист мог бы достаточно легко заменить ГИС «ИнГео» какой-либо другой геоинформационной системой или другим поставщиком изображений карт;

·      WMS-сервер расчитан на обработку в основном трех команд (GetCapabilities, GetMap и GetFeatureInfo). Однако, архитектура и каркас системы должны допускать простое расширение номенклатуры обрабатываемых команд – практически без изменения существующего программного кода системы, в случае, если функциональность сервера требуется развить за рамки WMS-функций.

2.2. Нефункциональные требования к системе

К WMS-серверу в рамках учебного проекта предъявляется требование, чтобы в его рамках был продемонстрирован объектно-ориентированный подход к проектированию программной системы, основанный на программировании с помощью шаблонов проектирования и каркасного программирования. Это означает, что

·      в проекте должен быть явно выделен каркас приложения и необходимые точки расширения, в качестве которых выступают некоторые абстрактные классы. Это означает, что расширение функций системы путем введения классов, расширяющих каркас, в минимальной степени должно затрагивать код, находящийся в других классах;

·      при проектировании системы должны использоваться шаблоны проектирования, обеспечивающие инкапсуляцию изменчивости системы и/или функциональных особенностей отдельных компонент в специально выделенных для этого классах;

·      должны быть четко разделены обязанности классов в соответствии с принципом единственной обязанности.

·      достаточно последовательно должны применяться эвристические принципы DRY, KISS, YAGNI.

 

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

·      принцип концептуальной целостности системы;

·      принцип модифицируемости.

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

В состав проекта должны быть включены автоматические модульные тесты, а также системный и нагрузочный тест.

3. АРХИТЕКТУРА СИСТЕМЫ

Исходя из требований к разработке WMS-сервера, особое внимание уделялось проектированию архитектуры приложения с использованием каркасов приложения и паттернов проектирования.

«Под каркасом приложения понимается набор взаимодействующих классов, составляющих повторно используемый дизайн для конкретного класса программ. Каркас диктует определенную архитектуру приложения. Он определяет общую структуру, ее разделение на классы и объекты, основные функции тех и других, методы взаимодействия объектов и классов и потоки управления. Данные параметры проектирования задаются каркасом, а прикладные проектировщики или разработчики могут сконцентрироваться на специфике приложения. В каркасе аккумулированы проектные решения, общие для данной предметной области. Акцент в каркасе делается на повторном использовании дизайна, а не кода, хотя обычно он включает и конкретные подклассы, которые можно применять непосредственно» [2].

«Использование каркасов приложений позволяет разработать продукт в меньшие сроки. Более того, все приложения имеют схожую структуру. Их проще сопровождать, и пользователям они представляются более знакомыми» [2].

Концептуальная схема WMS-сервера представлена на рисунке 3.1.

 

Рисунок 

3.1. Концептуальная схема WMS-сервера

3.1. Общая структура проекта

Проект разделен на три уровня абстракции. Нижний уровень представляет собой базовый, самый универсальный каркас приложения, предоставляющий абстрактный Web-сервис, умеющий запускать параллельную обработку HTTP-запросов в соответствии с паттерном проектирования Command.

Следующий уровень абстрагирования (несколько более конкретный) – проблемно-ориентированное расширение базового каркаса для реализации стандарта WMS. Тем самым, из базового каркаса путем введения нескольких производных классов в точках расширения, получается реализация универсального WMS-сервера, которая не зависит от конкретного типа источника картографических данных (т.е. от конкретной ГИС). Таким образом, второй уровень абстракции, является расширенным базовым каркасом, «окрашенным» в понятия WMS-стандарта.

Третий уровень специализации каркаса – реализация WMS-сервера уже для конкретной ГИС (в нашем проекте - ГИС «ИнГео»), полученная путем введения соответствующего класса-адаптера, являющегося наследником от абстрактного WMS-ГИС-адаптера. Третий уровень – это «ИнГео»-WMS.

Таким образом, в проекте явно используется и шаблон проектирования Адаптер.

Структура проекта схематично отображена на рисунке 3.2.

Рисунок 

3.2. Уровни абстракции проекта

Общие принципы работы системы отражены на структурно-функциональной схеме (рисунок 3.3). Для каждого пользовательского запроса создается канал обработки (объекты класса ProcessingChannel), в котором сконцентрирована вся логика по обработке запроса в целом. В соответствии с входящим запросом создается экземпляр команды, которая и исполняется сервером.

В каркас системы введен так называемый «виртуальный процессор», который является по сути пулом «горячих» потоков ГИС-ядра, которые развернуты в достаточном количестве, чтобы обеспечить эффективную параллельную обработку запросов (команд).

Рисунок 

3.3. Структурно-функциональная схема системы

3.2. Базовый каркас системы

Базовый каркас системы позволяет создавать на своей основе Web-службы, параллельно обрабатывающие HTTP-запросы. Для создания Web-службы используется технология Windows Communication Foundation (WCF). Структура каркаса представлена на рисунке 3.4.

Ниже рассмотрены основные классы каркаса:

BaseBuilder – построитель системы. Обязанность данного класса – построение системы. Здесь сконцентрирована вся логика по конфигурировании системы с определенным типом канала и виртуального ядра;

BaseSystem – класс корневого объекта системы, связывающий все компоненты системы в единое целое. Интерфейс класса содержит методы для запуска и остановки службы;

BaseProcessingChannel – Это центральный класс системы, экземпляры которого создаются на каждый запрос клиента. Абстрактный канал организует (сводит воедино) весь процесс обработки запроса, поступившего от конкретного внешнего клиента. Канал обеспечивает проверку корректности входной команды («привлекая» для этого объект BaseValidator) и формирование ответа, если команда не может быть выполнена. В случае удачно завершившегося входного контроля канал запрашивает из пула «горячих» потоков свободный ГИС-обработчик (из числа администрируемых Виртуальным процессором в Фабрике команд), запускает команду на выполнение и после получения результата обработки команды возвращает его клиенту, приведя к формату передачи данных в сети Интернет;

Структура системы построена так, что каждый канал обрабатывает отдельный запрос параллельно с другими активными каналами, обеспечивая, тем самым, максимально полный параллелизм в обработке запросов к серверу. Все внешние запросы «сталкиваются» только на обращении к Фабрике команд, ожидая освобождения активного ядра. Других точек блокирования объектов в системе нет.

CommandFactory – фабрика команд, позволяющая получить экземпляр команды, соответствующей входному HTTP-запросу. Фабрика команд получает запрос в HTTP-формате и генерирует объект-команду, запрашивая исполнимое ядро-адаптер ГИС от виртуального процессора, и присоединяя его к команде;

BaseCommand – базовый класс для всех команд. Участвует в паттерне «Command»;

VirtualProcessor – виртуальный процессор, отвечающий за распределение нагрузки (балансировку нагрузки) между виртуальными ядрами, за которыми «стоят» аппаратные ядра аппаратного процессора компьютера. Виртуальный процессор содержит в «горячем» состоянии заранее задаваемое в конфигурации системы количество активных экземпляров источников данных (ядер ГИС), предоставляя каналам свободные на текущий момент потоки (Thread) для выполнения обработки;

VirtualCore – абстрактный класс, представляющий собой интерфейс манипулирования активными ядрами генератором команд. Каждое ядро содержит внутри себя один рабочий поток, в который переводятся все внешние запросы. Интерфейс ядра предоставляет метод Execute(), который отвечает за выполнение нужной команды в отдельном потоке и перегружается в каждом конкретном классе команд WMS-запроса. В списке параметров методу передается имя команды и параметр, а он возвращает результат выполнения команды. Такой способ вызова методов класса позволяет перенаправить выполнение во внутренний поток. Необходимость во внутреннем потоке обусловлена особенностью ГИС «ИнГео», которая заключается в том, что работа с ГИС возможна только в рамках одного потока.

Рисунок 

3.4. Структура базового каркаса. Пунктирной линией показан путь запроса

3.3. Функционирование каркаса

Последовательность действий по обработке запроса от клиента представлен на диаграмме последовательности (рисунок 3.5).

На входной запрос создается канал обработки (ProcessingChannel) запроса. В соответствии со входным запросом канал запрашивает фабрику команд (CommandFactory), получая от неё объект-команду (Command), соответствующую типу запроса. Команде назначается виртуальное ядро ГИС-адаптера (VirtualCore), в котором, в конечном счете, и происходит обработка запроса, - т.е. запрашивается ГИС, и из полученных от неё данных формируется ответ на запрос. Команда также выполняет роль транспортного объекта, в котором ГИС-адаптеру передается запрос, а также в котором ГИС-адаптер возвращает результат. По завершении обработки входного запроса, канал обработки формирует ответ в требуемом формате и возвращает ответ клиенту.

Рисунок 

3.5. Диаграмма последовательности обработки запроса

4. РАСШИРЕНИЯ КАРКАСА СИСТЕМЫ

Расширения каркаса приложения позволяют путем введения в проект нескольких производных классов от абстрактных классов в точках расширения существенно расширить (специализировать) обобщенный код, не затрагивая код каркаса. Это в отличие от обычного – «хаотического» – программирования позволяет не только иметь абстрактный код для повторного использования, но и резко уменьшить вероятность появления ошибок при развитии проекта, поскольку места развития проекта инкапсулированы в нескольких абстрактных классах, называемых «точками расширения каркаса приложения», и только там «разрешается» писать код программисту, выполняющему адаптацию каркаса к новому решению. Расширением каркаса в точках расширения можно добиться нужной специализации каркаса на решение определенного класса задач. В нашем случае первый шаг расширения дает возможность перейти к новому каркасу, решающему задачу обработки запросов в стандарте WMS, но не зависящего от конкретной ГИС, которая будет служить в качестве поставщика изображений карт. Расширения WMS-каркаса до включения особенностей конкретной ГИС будет сделано на втором шаге расширения – WMS-каркаса.

4.1. Проблемно-ориентированное расширение базового каркаса. WMS-сервер

Базовый каркас приложения заранее планировался быть расширенным в двух основных «направлениях»:

·      включение в сервер конкретных классов команд, которые призван обрабатывать сервер;

·      расширение каркаса конкретным адаптером к конкретной ГИС;

 

Для этого весь проект строился так, чтобы соответствующая запланированная изменчивость была инкапсулирована в нескольких абстрактных классах, ставшими «точками расширения» каркаса. Базовый каркас содержит следующие точки расширения:

·      BaseProcessingChannel

·      BaseCommand

·      VirtualCore (от которого наследуется ГИС-адаптер)

На основе базового каркаса реализовано проблемно-ориентированное расширение «WMS-сервер». Схема WMS-каркаса отражена на рисунке 4.1. Помимо расширяющих каркас классов, проект содержит модель данных стандарта WMS, добавленную к самому обобщенному каркасу.

Рисунок 

4.1. Схема расширения базового каркаса до WMS-сервера

WMS-каркас как расширение базового каркаса является каркасом более высокого уровня, позволяющим разрабатывать WMS-серверы для различных источников картографических данных (т.е. различных ГИС, подключаемых при предметно-ориентированном расширении WMS-каркаса – см. разд. 0).

Расширение базового каркаса получено путем введения следующих классов:

·      WmsCommand и три его наследника CmdGetCapabilities, CmdGetMap и CmdGetFeatureInfo – допустимые команды WMS-сервера. Регистрация всех команд системы происходит при инициализации Фабрики команд. Правда, для того, чтобы система автоматически зарегистрировала такую команду в фабрике команд, нужно выполнять соглашение: имя класса команды должно начинаться с префикса ‘Cmd…’;

·      AbstractWmsGisAdapter – представляет собой базовый класс для адаптеров к различным ГИС. В этом классе сконцентрирована общая для всех адаптеров WMS-логика. Конкретному адаптеру необходимо переопределить лишь два метода: получение иерархии слоев и формирование растровой картинки из ГИС.

4.2. Предметно-ориентированное расширение WMS-каркаса для ГИС «ИнГео»

Единственная точка расширения каркаса второго уровня: абстрактный адаптер к ГИС (AbstractWmsGisAdapter). Таким образом, для создания WMS-сервера для конкретной ГИС достаточно создать наследника от абстрактного адаптера и реализовать взаимодействие с данной ГИС. Остальной код править не надо, тем более на уровне базового каркаса.

Каркас WMS-сервера расширен до конкретной реализации: WMS-сервер для ГИС «ИнГео». Схема проекта представлена на рисунке 4.2.

Основным расширяющим каркас классом проекта является класс IngeoWmsAdapter, унаследованный от базового адаптера AbstractWmsGisAdapter. Класс IngeoWmsAdapter отвечает за взаимодействие с ГИС «ИнГео», и только в нем присутствует код, который отражает специфику подключаемой ГИС.

Данное расширение является уже конечным продуктом. На выходе получается консольное приложение, которое может работать как служба Windows.

Рисунок 

4.2. Схема реализации WMS-сервера «ИнГео»

4.3. Некоторые подробности расширения каркасов WMS-сервера

Для добавления в каркас WMS-сервера новой команды необходимо завести соответствующего наследника от абстрактного WmsCommand, причем имя класса новой команды должно начинаться с префикса ‘Cmd…’;

Далее в абстрактный адаптер к ГИС нужно добавить виртуальный метод-обработчик, соответствующий команде, и реализовать этот метод в конкретном классе адаптера ГИС.

Чтобы заменить ГИС «ИнГео» на другую ГИС, нужно создать наследника от абстрактного адаптера к ГИС (AbstractWmsGisAdapter)) и реализовать все методы-обработчики команд, как это сделано, например, в конкретном адаптере IngeoWmsAdapter к ГИС «ИнГео».

5. СТРУКТУРА РЕШЕНИЯ В СРЕДЕ Visual Studio 2012

Различие уровней абстракции отражено и непосредственно в системе проектов в среде MS Visual Studio (см. рисунок 5.1).

Рисунок 

5.1. Организация проектов в среде MS Visual Studio

В структуре VS-решения виден проект базового каркаса (Integro.WebServiceFramework), ссылающийся на него специализированный WMS-каркас (WMS), а также проект WMS-сервера под конкретную ГИС - ИнГео, являющийся выполняющимся расширением WMS-каркаса. Если кто-то будет делать свой Wms-сервер для какой-то своей ГИС как поставщика растровых фрагментов, то ему целесообразно учитывать, что не требуется менять код в проектах каркасов Integro.WebServiceFramework и WMS, а следует лишь завести свой новый проект в папке «1.ПРЕДМЕТНО-ОРИЕНТИРОВАННЫЕ РЕШЕНИЯ» по аналогии с проектом IngeoWMS. Для примера в VS-решении заведен проект AtlasWMS, который создан для некой мифической ГИС Atlas (всякие совпадения этого названия с какой-либо возможно существующей ГИС какого-либо поставщика нужно считать случайным). Только в этом  проекте надо заводить классы, расширяющие базовые каркасы.

 

Все исходные коды решения доступны для скачивания в http://integro.ru/dl/ingeo/ingeowms.rar.

6. ТЕСТИРОВАНИЕ СИСТЕМЫ

В ходе разработки WMS-сервера, после каждого изменения запускались тесты, что позволяло минимизировать количество ошибок.

6.1. Модульные тесты

Цель модульного тестирования — изолировать отдельные части программы и показать, что по отдельности эти части работоспособны. Для основных модулей системы разработаны соответствующие тесты:

·      VirtualProcessorTest – проверяет корректность распределения нагрузки между виртуальными ядрами;

·      IngeoAdapterTest – тестирование адаптера к ГИС «ИнГео»;

·      WmsCommandTest – проверка на корректность работы комманд;

·      WmsExceptionTest – проверка корректности формирования исключений.

6.2. Системный тест

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

В конкретном системном тесте, реализованном в настоящем проекте WMS-сервер для ГИС «ИнГео» запускается в отдельном процессе. Далее, - также в отдельном процессе, - запускается модельный клиент, эмулирующий работу реального источника запросов. Клиент шлет серверу запросы через HTTP-протокол, после чего сверяет ответы сервера с эталонными данными, которые ему «подставляет» тестовый ГИС-адаптер.

6.3. Нагрузочный тест

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

Для тестирования WMS-сервера ГИС «ИнГео» запускается множество виртуальных клиентов, которые массово шлют запросы серверу, чем обеспечивают требуемую нагрузку на систему. При этом в системе не должно возникать ошибок, и ответы клиентам должны быть ожидаемыми.

7. ЭЛЕМЕНТЫ АДМИНИСТРИРОВАНИЯ WMS-СЕРВЕРА

7.1. Шаг 1. Настройка ГИС «ИнГео»

В первую очередь требуется подготовить данные для публикации. Для этого в ГИС «ИнГео» необходимо создать проект с нужными картами. В случае, если требуется накладывать карту из «ИнГео» на какую-либо подложку, нужно привести в соответствие системы координат подложки и карты из «ИнГео».

Рекомендуется создать отдельного пользователя с правом чтения для публикуемого проекта. Для того, чтобы запросы могли обрабатываться параллельно, требуется установить право на многократный вход в систему.

7.2. Шаг 2. Настройка WMS-сервера

Настройки WMS-сервера представлены XML-файлами. Основные настройки находятся в файле WmsServer.xml. Настройки сгруппированы в три группы: настройки сервера, адаптера и подсистемы логирования. Ниже представлен пример конфигурационного файла WmsServer.xml:

1      <?xml version="1.0" encoding="windows-1251"?>

2      <Config>

3        <Server>

4          <Port>8080</Port>

5          <OnlineResource>http://integro.ru/wms</OnlineResource>

6          <AdaptersPoolCount>10</AdaptersPoolCount>

7        </Server>

8        <MapAdapter>

9          <IngeoConnection>

10          <ServerName>ingeoserver</ServerName>

11          <DatabaseId>11538E8E-58E3-498C-88AC-F50E316768BC</DatabaseId>

12          <UserName>Администратор</UserName>

13          <UserPassword></UserPassword>

14          <ProjectId>0001000003EA</ProjectId>

15        </IngeoConnection>

16        <CRS>EPSG:3857</CRS>

17        <GeographicBoundingBox>

18          <WestBoundLongitude>37.48</WestBoundLongitude>

19          <EastBoundLongitude>38.01</EastBoundLongitude>

20          <SouthBoundLatitude>55.32</SouthBoundLatitude>

21          <NorthBoundLatitude>55.68</NorthBoundLatitude>

22        </GeographicBoundingBox>

23      </MapAdapter>

24      <Logger>

25        <Logger type="console">

26          <MinLevel>Trace</MinLevel>

27          <MaxLevel>Fatal</MaxLevel>

28          <Colored>true</Colored>

29        </Logger>

30        <Logger type="file">

31          <MinLevel>Trace</MinLevel>

32          <MaxLevel>Fatal</MaxLevel>

33          <FileName>C:\wms_${shortdate}.log</FileName>

34          <Layout>${shortdate} ${time} ${level} ${message}</Layout>

35        </Logger>

36      </Logger>

37    </Config>[reset line numbers: 0]

 

Настройки сервера включают:

·      Port – порт на котором должен работать WMS-сервер;

·      OnlineResource – адрес сервера в интернете;

·      AdaptersPoolCount – количество работающих параллельно адаптеров.

Настройки адаптера к ГИС «ИнГео» представлены следующими параметрами:

·      IngeoConnection – параметры подключения к базе ГИС «ИнГео» и идентификатор проекта;

·      CRS – координатная система проекта. Если координатная система неизвестна, необходимо в качестве значения данного параметра установить «CRS:1»;

·      GeographicBoundingBox – примерные границы территории публикуемого проекта в георграфических координатах (широта, долгота).

Подсистема логирования основана на библиотеке NLog. Соответственно настройка логирования сводится к перечислению необходимых логеров.

Следующим конфигурационным файлом, требующим внесения изменений является _DATA\Invariabled\Capability.xml. В данном файле необходимо задать параметр OnlineResource. Пример Capability.xml представлен ниже:

1      <Capability xmlns:xlink="http://www.w3.org/1999/xlink">

2        <Request>

3           <GetCapabilities>

4              <Format>text/xml</Format>

5              <DCPType>

6                 <HTTP>

7                    <Get>

8                       <OnlineResource xlink:type="simple" xlink:href="http://integro.ru/wms?" />

9                    </Get>

10               </HTTP>

11            </DCPType>

12         </GetCapabilities>

13         <GetMap>

14            <Format>image/bmp</Format>

15            <Format>image/gif</Format>

16            <Format>image/jpeg</Format>

17            <Format>image/png</Format>

18            <DCPType>

19               <HTTP>

20                  <Get>

21                     <OnlineResource xlink:type="simple" xlink:href="http://integro.ru/wms?" />

22                  </Get>

23               </HTTP>

24            </DCPType>

25         </GetMap>

26         <GetFeatureInfo>

27            <Format>text/xml</Format>

28            <DCPType>

29               <HTTP>

30                  <Get>

31                     <OnlineResource xlink:type="simple" xlink:href="http://integro.ru/wms?" />

32                  </Get>

33               </HTTP>

34            </DCPType>

35         </GetFeatureInfo>

36      </Request>

37      <Exception>

38         <Format>XML</Format>

39      </Exception>

40    </Capability>[reset line numbers: 0]

В завершении, нужно внести изменения в конфигурационный файл _DATA\Invariabled\Service.xml. Данный файл содержит параметры WMS-сервера такие как список ключевых слов, информация о правообладателе, контактная информация. Пример такого файла приведен ниже:

1      <Service xmlns:xlink="http://www.w3.org/1999/xlink">

2        <Name>WMS</Name>

3        <Title>ИнГео WMS</Title>

4        <Abstract>Описание источника картографических данных</Abstract>

5        <KeywordList>

6          <Keyword>ИнГео</Keyword>

7          <Keyword>Карта</Keyword>

8        </KeywordList>

9        <OnlineResource xlink:type="simple" xlink:href="http://integro.ru/wms" />

10      <ContactInformation>

11        <ContactPersonPrimary>

12          <ContactPerson>Иван Иванов</ContactPerson>

13          <ContactOrganization>ЗАО "ЦСИ "Интегро"</ContactOrganization>

14        </ContactPersonPrimary>

15        <ContactPosition>Инженер-программист</ContactPosition>

16        <ContactAddress>

17          <AddressType>Почтовый</AddressType>

18          <Address>Комсомольская 96/1</Address>

19          <City>Уфа</City>

20          <StateOrProvince>Республика Башкортостан</StateOrProvince>

21          <PostCode>450068</PostCode>

22          <Country>Россия</Country>

23        </ContactAddress>

24        <ContactVoiceTelephone>+7(347)232-12-41</ContactVoiceTelephone>

25        <ContactFacsimileTelephone>+7(347)232-91-53 </ContactFacsimileTelephone>

26        <ContactElectronicMailAddress>support@integro.ru </ContactElectronicMailAddress>

27      </ContactInformation>

28      <AccessConstraints>Картографическая информация доступна всем </AccessConstraints>

29      <LayerLimit>100</LayerLimit>

30      <MaxWidth>2000</MaxWidth>

31      <MaxHeight>2000</MaxHeight>

32    </Service>[reset line numbers: 0]

7.3. Шаг 3. Установка WMS-сервера

WMS-сервер может работать как консольное приложение и как служба Windows. В первом случае достаточно запустить исполняемый файл IngeoWms.exe. Если же необходимо установить WMS-сервер к «ИнГео» как службу Windows, тогда нужно запустить IngeoWms.exe с ключом /install. Деинсталяция службы проходит аналогичным образом: необходимо запустить IngeoWms.exe с ключом /uninstall.

СПИСОК ЛИТЕРАТУРЫ

1. http://ru.wikipedia.org/wiki/WMS

2. Приёмы объектно-ориентированного проектирования. Паттерны проектирования –  Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес. - Издательство Питер.

Приложение А. Диаграмма классов проекта WMS «ИнГео»