В.Г. Иванов

Проведения расчетов и моделирования связи с ГИС

 Широкое использование в расчетных моделях эмпирико-эвристического подхода к решению задачи построения сети связи обусловливает важное значение ЛПР в процессе выработке решения по организационно-технической структуре. Сложность системы, ее функционирования, значительная степень неопределенности исходных данных предполагает широкое использование опыта и творческих начал ЛПР, а также средств моделирования системы, т.е. реализации системного анализа на практике. При этом сформированные при помощи методики моделей варианты организационно-технических структур носят рекомендательный характер. При применении расчетных задач и моделей необходимо четкое понимание заложенных в ней допущений и ограничений в целях принятия обоснованного решения на основе разработанного рекомендуемого варианта организационно-технической системы. Выработка и принятие решения по построению организационно-технической структуры сети связи включает подготовку необходимых исходных данных, анализ, обобщение информации, оценку состояния сети, определение необходимости принятия решения, прогнозирование и разработку альтернативных вариантов решения. Принятие решения по структуре включает оценку альтернативных вариантов, выбор предпочтительного по критериям эффективности и его утверждение. Последующее планирование организационно-технической структуры призвано детализировать принятое решение, и обеспечить возможность его  реализации путем определения способов, приемов и последовательности построения организационно-технической системы, а также сил и средств, на базе которых она развертывается. Ограниченность возможностей эмпирического исследования систем связи делает актуальной разработку методики их моделирования, которая позволила бы в соответствующей форме представить процесс связи в сложных условиях функционирования, получить результаты экспериментов с моделями по оценке показателей эффективности. В ходе моделирования осуществляются наблюдение, сбор исходной информации, ее логическая обработка с помощью аналогии (метода образцов), анализа, синтеза (обобщения), индукции, дедукции, модельного эксперимента. Общая схема процесса системного моделирования представлена на рис.1

Рисунок 1. Общая схема процесса системного моделирования

 При решении задач по связи процесс моделирования (расчетов) проходит следующие фазы:

1)         Определение цели моделирования.

2)         Выбор отвечающей целям модели.

3)         Подготовка исходных данных.

4)         Оценка адекватности модели.

5)         Планирование экспериментов.

6)         Планирование прогонов.

7)         Проведение машинного эксперимента.

8)         Анализ и интерпретация результатов.

9)         Принятие решений относительно исследуемого объекта.

10)     Документирование решений.

Перечисленные этапы могут перекрываться по времени (например, документирование должно вестись с первых дней работы над проектом) и охвачены многочисленными обратными связями. Постановка цели моделирования зависит решаемых практических задач в цикле организации связи. Основными целями исследования могут быть анализ или синтез узла, сети связи, процессов обработки сообщений, алгоритмов работы органов управления связью, графиков развертывания узлов, линий и системы связи. Выбор модели зависит кроме типа решаемой задачи (анализ или синтез) определяется сложностью исследуемого объекта. Для простых систем (линия, направление связи и т.п.) с достаточной степенью адекватности подходят расчетные задачи, базирующиеся на алгебраических или дифференциальных исчислениях. Для более сложных задач подходят системы имитационного моделирования, интегрированные с геоинформационными системами. Для сложных систем и процессов, таких как система связи объединения, боевое применение соединений и частей связи в операции подходят методы системной динамике. В основу математических моделей сетей связи положены достижения прикладной математики. Назначение прикладной математики – поиск практических ин­терпретаций математических теорий и после нахождения таких интерпретаций создание на основе теорий методических средств работы с интерпретированными системами и связанными с ними задачами. В этом смысле прикладная математика ориентирована на разработку методов, базирующихся на определенных матема­тических теориях, и использование их в как можно большем чис­ле конкретных приложений (например, методы исследования операций). Эти методы подчиня­ются фундаментальным ограничениям математических теорий. Более того, любая математическая тео­рия выводится из некоторых определенных предположений (акси­ом) и, следовательно, любая методика, опирающаяся на эту тео­рию, применима только к тем задачам, которые отвечают этим предположениям. Математические модели для оценки отдельных показателей качества функционирования систем связи строятся с использованием значительного числа ограничений и допущений, что ведет к нарушению адекватности модели реальным процессам в системе связи. Кроме того, при увеличении размерности исследуемых систем, использовании в них нетривиальных алгоритмов функционирования или учете изменения структуры сети под воздействием внешней среды (прежде всего, противника) резко возрастает сложность математической модели. Можно сделать вывод, что математические модели, основанные на применении функцио­нальных соотношений, применимы для исследования сравнительно простых систем, когда можно получить явные зависимости, связывающие искомые величины с параметрами и начальными условиями моделирования системы. Другим направлением использования математических моделей является исследование наиболее общих свойств сложных систем, которые могут быть представлены путем абстрагирования реальных явлений в системе, что позволяет получить описание зависимостей между обобщенными компонентами системы. В тех случаях, когда математическую модель не удается пре­образовать в подходящую систему уравнений, а упрощение зада­чи приводит к недопустимо грубым результатам, целесообразно пе­рейти к имитационному моделированию, которое может обеспечить возможность исследования процессов функционирова­ния системы связи на требуемом уровне детализации их описания. Главная ценность имитационного моделирования состоит в том, что в его основу положена методология системного анализа. Имитационное моделирование – экспериментальная и прикладная методология решения проблем. Среди методов прикладного системного анализа имитационное моделирование является, пожалуй, самым мощным инструментом исследования сложных систем, управление которыми связано с принятием решений в условиях неопределенности. По сравнению с другими методами такое моделирование позволяет рассматривать большее число альтернатив, улучшать качество управленческих решений и точнее прогнозировать их последствия. Эффективность его значительно возросла с появлением высокопроизводительных ЭВМ и развитием специальных языков программирования. Эти новые возможности открыли путь к блочному построению моделей и преодолению таких преград для широкого использования сложных имитационных моделей в процессах принятия решений, как их недостаточная гибкость и трудность отражения в них динамики и многоуровневой структуры управления. Подготовка исходных данных состоит в сборе и обработке данных наблюдений за моделируемой системой. Обработка в типичном случае заключается в построении функций распределения соответствующих случайных величин или вычислении числовых характеристик распределений (среднего, дисперсии и т.п.). К подготовке исходных данных можно отнести и сбор информации о предполагаемых изменениях в нагрузке системы (или о прогнозируемой нагрузке). Наиболее актуальной задачей на этапе формирования исходных данных является сбор статистического материала по потребностям системы управления в информационном обмене. Объективно невозможно собрать достоверные статистические данные, необходимые для формирования структуры сети связи. Собираемый статистический материал в ходе повседневной деятельности войск, проводимых тренировок, учений и игр, должен обобщаться не с целью получения достоверного статистического материала, а с целью выявления основных закономерностей, выработки принципов, правил и рекомендаций по прогнозированию информационных потоков в системе управления объединения на основе нормативных методов определения допустимого трафика сообщений. Разработка модели заключается в записи ее на одном из языков программирования (общецелевом или специализированном), трансляции и отладке программы модели. Следует стремиться к блочному (модульному) построению программы, позволяющему независимо вносить изменения в отдельные модули и повторно использовать ранее созданные модули.

Оценка адекватности модели заключается в проверке:

1. a)  полноты учета основных факторов и ограничений, влияющих на работу системы;
2. b)  согласия постулируемых законов распределения с первичными данными;
3. c)  синтаксической корректности программы моделирования;
4. d) соответствия результатов имитационного моделирования и известного аналитического решения (при условиях существования этого решения);
5. e)   осмысленности результатов в нормальных условиях и в предельных случаях.

Планирование экспериментов определяет совокупность исследуемых вариантов и стратегию их перебора. При этом учитываются: цель проекта (анализ или оптимизация); степень достоверности исходных данных (при малой достоверности необходимы дополнительные исследования чувствительности модели к изменению параметров); ресурсы календарного и машинного времени. На этом этапе полезно применение общей теории планирования экспериментов. Планирование эксперимента – это процедура выбора числа и условий проведения опытов, необходимых и достаточных для решения поставленной задачи с требуемой точностью; разработка плана проведения экспериментов, который дает возможность за минимальное число прогонов модели и при минимальной стоимости работ сделать статистически значимые выводы и найти наилучшее решение.

При этом существенно следующее:

стремление к минимизации общего числа опытов;

одновременное варьирование всеми переменными, определяющими процесс, по специальным правилам – алгоритмам;

использование математического аппарата, формализующего многие действия экспериментатора;

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

Конечная цель проведения эксперимента – это получение достаточной статистической информации для принятия решений по результатам моделирования.

Для проведения эксперимента используют факторные планы, а по результатам аппроксимируют поверхность отклика полиномами разного порядка, а для поиска экстремальных значений применяются численные методы оптимизации. От выбора начальной точки в факторном пространстве во многом зависит эффективность экспериментов. Управляемость эксперимента предполагает возможность изменения в требуемых пределах значений факторов, определяющих целевую функцию модели. Фактором называется измеряемая переменная величина, принимающая в некоторый момент времени определенное значение. Факторы соответствуют способам воздействия на объект исследования. Каждый фактор может принимать в опыте одно из нескольких значений. Такие значения будем называть уровнями. Может оказаться, что фактор способен принимать бесконечно много значений (непрерывный ряд). Однако на практике точность, с которой устанавливается некоторое значение, не беспредельна. Поэтому мы вправе считать, что всякий фактор имеет определенное число дискретных уровней f. При этом возможное число опытов определяется следующим образом.

где m – количество факторов.

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

К факторам предъявляют следующие требования:

Факторы должны быть управляемыми.

Точность замера факторов должна быть возможно более высокой.

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

Факторы должны быть однозначны.

К совокупности факторов предъявляют требования по совместимости и независимости. Совместимость факторов означает, что все их комбинации осуществимы. Независимость факторов означает возможность установления фактора на любом уровне вне зависимости от уровней других факторов (отсутствие корреляции между факторами). В целях сокращения количества проводимых экспериментов целесообразно строить математическую модель функции отклика, чтобы с ее помощью предсказывать значения показателя эффективности в тех состояниях, которые не изучались экспериментально. Для решения данной задачи, как правило, делают предположения о непрерывности поверхности функции отклика, ее гладкости и наличии единственного оптимума. При этом функция отклика апроксимируется полиномами различной степени, начиная с простейшей линейной модели, путем повышения ее степени добиваясь ее адекватности. Под адекватностью функции отклика понимается возможность прогнозирования значения функции отклика в любой точке факторного пространства, не отличающегося от значения, полученного в опыте на достаточно малую величину, определяемую экспериментатором. Если будут известны (спрогнозированы) значения показателя эффективности в нескольких соседних точках факторного пространства, то в силу гладкости и непрерывности функции отклика можно представить результаты, которые можно ожидать в других соседних точках. Следовательно, можно найти такие точки, для которых ожидается наибольшее увеличение (или уменьшение) показателя оптимизации. Тогда ясно, что следующий эксперимент надо переносить именно в эти точки. Сделав новый эксперимент, снова можно оценить направление, в котором, скорее всего, следует двигаться. При этом в факторном пространстве выбирается некоторая точка и рассматривается множество точек в ее окрестности, т. е. в области определения факторов выбирается малая подобласть, в которой будут проводиться эксперименты, на основании которых будет построена функция отклика. Эта функция будет использована для предсказания результатов опытов в тех точках, которые не входили в эксперимент. Если эти точки лежат внутри выбранной подобласти, то такое прогнозирование называется интерполяцией, а если вне – экстраполяцией. Планирование прогонов имеет целью получить возможно лучшие статистические оценки исследуемых показателей: несмещенные, с минимальной дисперсией. При этом объем вычислительных работ обычно ограничен (ограничено время на постановку экспериментов). Отдельным прогоном называется однократное выполнение программы модели, в котором модельное время монотонно возрастает. Очень часто моделирование имеет целью получение стационарных характеристик, т.е. соответствующих типичным условиям работы. Поэтому важен вопрос определения длительности разгонного участка и времени вхождения в стационарный режим во время одного прогона. Этот момент обычно определяется экспериментально. Статистика, накопленная за время разгона, не должна учитываться в расчетах. Важно правильно задать критерий останова прогона (например, рассчитать время моделирования, которое достаточно для получения достаточно точных характеристик системы). К этому этапу относятся вопросы уменьшения или исключения корреляции результатов, уменьшения дисперсии результатов, задания начальных условий моделирования. Документирование должно сопровождать весь процесс разработки модели и хода экспериментов. Оно облегчает взаимодействие участников процесса моделирования, обеспечивает возможность использования модели в будущем в других разработках. В целях реализации эмпирико-эвристического подхода при планировании организационно-технической структуры сети связи программная реализация итерационного процесса формирования структуры должна обеспечить диалоговый режим общения ЛПР с системой автоматизированного планирования связи. Система автоматизированного планирования связи должна включать в себя подсистему, позволяющую проводить машинные эксперименты на основе систем имитационного моделирования. Результаты машинного эксперимента после статистической обработки должны быть представлены ЛПР для выбора рационального варианта структуры. Вариант логической блок-схемы системы автоматизированного планирования структуры сети связи представлена на рисунке.2

Рисунок 2. Вариант логической блок-схемы системы автоматизированного планирования структуры сети связи

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

 С. В. Павлов, Т. М. Усов, Р. А. Шкундина

Сервис-ориентированная архитектура программного обеспечения корпоративных геоинформационных систем

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

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

Стремление преодолеть названные ограни­чения привело к развитию архитектур и техно­логий создания программного обеспечения, свя­занных с размещением логики приложений (компонентов ПО) и всех данных на серверных вычислительных комплексах, что особенно важно для геоинформационных систем ввиду большого объема пространственных данных и ресурсоемкости операций их обработки. В то время как позволяющие размещать пространст­венные данные на серверах системы управления базами данных (СУБД) повсеместно использу­ются в рамках геоинформационных систем на основе клиент-серверных архитектур с «тол­стым» клиентом, задача размещения на серве­рах логики приложений ГИС долгое время ос­тавалась нерешенной и является актуальной се­годня. Наиболее перспективной архитектурой программного обеспечения, в рамках которой возможно эффективное решение этой задачи (с позиций сложности реализации, сопровожде­ния, интеграции с другими информационными системами, программного обеспечения много­процессорных вычислительных комплексов), является сервис-ориентированная архитектура (СОА). Однако при внедрении новых типов ар­хитектур ПО корпоративных информационных систем требуется сохранять функциональные возможности существующего программного обеспечения, поэтому представляется актуаль­ной задача преобразования компонентов суще­ствующего ПО ГИС при переходе от клиент- серверной архитектуры к сервис-ориентирован­ной с «тонким» клиентом.

В статье приводится анализ особенностей сервис-ориентированной архитектуры про­граммного обеспечения корпоративных геоинформационных систем, рассматриваются воз­можности создания программного обеспечения для многопроцессорных вычислительных ком­плексов, предлагается метод решения названной задачи преобразования ПО ГИС при переходе к сервис-ориентированной архитектуре.

Проанализируем различия клиент-серверной и сервис-ориентированной архитектур про­граммного обеспечения ГИС, рассмотрев их в контексте развития архитектур программного обеспечения корпоративных информационных систем [3, 5].

Рис. 1. Размещение компонентов ПО ГИС системы моделирования распространения нефти по суше и речной сети в рамках двухъярусной клиент-серверной архитектуры

 Программное обеспечение первых корпора­тивных информационных систем представляло собой монолитные модули, включающие в себя все компоненты программного обеспечения (СУБД, логику приложения, логику взаимодей­ствия с пользователем), размещаемые на мейн­фреймах. Доступ к таким системам осуществ­лялся посредством «тонких» клиентов, напри­мер, текстовых терминалов. В силу концентра­ции всего ПО на сервере (мейнфрейме), такой тип архитектуры называют одноярусной клиент- серверной архитектурой (с «тонким» клиентом).

С начала 90-х годов начинает преобладать двухъярусная клиент-серверная архитектура (с «толстым» клиентом), в рамках которой на серверах размещаются данные и СУБД, а ос­тальные компоненты программного обеспече­ния (логика приложений и графический интер­фейс пользователя) размещаются на настольных компьютерах («толстые» клиенты). Для многих типов ресурсоемких приложений, например, приложений обработки видео, графики, систем автоматизированного проектирования - САПР, а также геоинформационных систем этот тип архитектуры остается распространенным и се­годня. В некоторых случаях сервер данных мо­жет отсутствовать, но это не меняет архитекту­ры клиентского программного обеспечения.

Рассмотрим типовое распределение компо­нентов программного обеспечения геоинформационных систем между вычислительными узла­ми в рамках двухъярусной клиент-серверной архитектуры на примере системы моделирова­ния распространения нефти и нефтепродуктов по суше и речной сети в рамках геоинформационной системы Федерального агентства водных ресурсов (рис. 1). На сервере данных размеща­ется программное обеспечение системы управ­ления базами данных и базами пространствен­ных данных. Обозначим множество фрагментов исходного кода серверного ПО, реализующих модели данных, как MD, а множество фрагмен­тов исходного кода серверного ПО, реализую­щих систему безопасности, как KD (верхним ин­дексом D будем обозначать множества фраг­ментов исходного кода, размещаемых на серве­рах данных). На компьютерах клиентов разме­щается программное обеспечение геоинформационной системы, реализующее логику прило­жения и графический интерфейс пользователя, представленное, как правило, тремя компонен­тами (физическими модулями): модуль базового ПО ГИС, модуль геообработки и модуль специ­ального ПО ГИС.

Модуль базового ПО ГИС (например, Arc- Map) решает общие для различных геоинформационных систем задачи, а именно: отрисовка изображений карт (множество фрагментов ис­ходного кода ПО, реализующих эту задачу, обо­значено как GB), графический интерфейс поль­зователя (UB).

Модули геообработки (например, ArcTool- box) реализуют тематическую обработку про­странственных данных (множество соответст­вующих фрагментов исходного кода ПО обо­значено как {PBi}) в виде совокупности базовых операций (например: пересечение, объединение и другие множественно-ориентированные опе­рации над пространственными объектами) и специфических операций (например: интер­поляция точечных значений, построение топо­логических отношений объектов базы простран­ственных данных). В качестве примера такого модуля геообработки системы моделирования можно привести PZ3 - модуль построения циф­ровой модели рельефа (растра высот рельефа) на основе векторных данных (изогипс, отметок высот, речной сети).

Третий типовой компонент клиентского ПО ГИС - модули специального программного обес­печения, решающие предметно-ориентирован­ные задачи, свойственные конкретной геоинформационной системе. В рассматриваемом примере это модуль моделирования распро­странения нефти, состоящий из пяти логических модулей: создание отчетов (P^); моделирование распространения нефти по речной сети (P^); моделирование распространения нефти по суше (PZ3); построение цифровой модели рельефа (PZi); графический интерфейс пользователя, в состав которого входят собственно графиче­ский интерфейс (UZ) и модуль управления всем приложением (CZ). Помимо программных ком­понент модуль моделирования содержит три набора данных: параметры алгоритмов геооб­работки {APj}, временные данные {DTt} и доку­менты карт {Е^. Основные недостатки исполь­зования двухъярусной клиент-серверной архи­тектуры в рассматриваемом примере заключа­ются в следующем.

Для использования системы конечному пользователю (клиенту) необходим производи­тельный компьютер с установленным на нем специальным программным обеспечением. Для обновления этого программного обеспечения требуется выполнение процедуры обновления модулей ПО у всех клиентов, что приводит к большим затратам времени.

Несмотря на то, что задача моделирова­ния распространения нефти по суше и речной сети является востребованной для многих госу­дарственных ведомств и коммерческих органи­заций, ее решение в виде системы с «толстым» клиентом не позволяет предоставлять доступ к функциональным возможностям системы уда­ленным пользователям либо другим информа­ционным системам.

Названные недостатки частично преодоле­ваются в рамках многоярусных клиент-сервер­ных архитектур традиционных интернет-прило­жений, позволяющих удаленным пользователям получать доступ к функциональным возможно­стям ГИС без установки специального ПО на компьютеры клиентов. При этом программное обеспечение «толстых» клиентов разбивается на физические компоненты, которые распределя­ются между несколькими архитектурными уровнями - ярусами: ярусом данных (файлы данных и СУБД, размещаемые на серверах дан­ных), ярусом приложений (компоненты про­граммного обеспечения, реализующие логику приложения, размещаемые на серверах прило­жений) и ярусом графического пользователь­ского интерфейса (соответствующие компонен­ты ПО распределяются между серверами и кли­ентскими компьютерами либо размещаются це­ликом на клиентских компьютерах). Для систе­мы моделирования распространения нефти та­кое размещение компонентов «толстых» клиен­тов представлено на рис. 2.Сервер данных (ярус данных)

Рис. 2. Размещение компонентов ПО ГИС системы моделирования распространения нефти по суше и речной сети в рамках многоярусной клиент-серверной архитектуры

 Однако в многоярусной клиент-серверной архитектуре отсутствуют единые подходы к разбиению логики приложения на компоненты и единые способы реализации взаимодействия компонентов, что существенно осложняет мас­штабирование системы, организацию и управ­ление параллельным доступом пользователей и других информационных систем к отдельным подсистемам ГИС. Так, серверное приложение ГИС в рамках многоярусной архитектуры (рис. 2), как правило, представляет собой моно­литный программный модуль, поэтому реализа­ция взаимодействия внешних информационных систем с отдельными логическими компонента­ми этого приложения является трудоемкой либо невозможной без разбиения серверного ПО на физические модули.

Эти ограничения преодолеваются в рамках сервис-ориентированной архитектуры. Единые межплатформенные механизмы взаимодействия отдельных частей программного обеспечения, отсутствующие в двухъярусной и многоярусной клиент-серверных архитектурах, и декомпози­ция ПО ГИС на набор сервисов - слабосвязан­ных исполняемых и готовых к использованию модулей - позволяют эффективно решать зада­чи интеграции ГИС с другими информацион­ными системами предприятия путем предостав­ления межплатформенного сетевого доступа к функциональным возможностям сервисов ГИС конечным пользователям и другим инфор­мационным системам. На рис. 3 представлено размещение компонентов ПО системы модели­рования распространения нефти по суше и речной сети, соответствующее требованиям сервис- ориентированной архитектуры: в отличие от клиент-серверных архитектур (рис. 1, 2) компо­ненты ПО ГИС сгруппированы в набор серви­сов, взаимодействующих между собой и с другими ИС посредством межплатформенных протоколов (HTTP, SOAP и других).

Рис. 3. Размещение компонентов ПО ГИС системы моделирования распространения нефти по суше и речной сети в рамках сервис-ориентированной архитектуры

В следующем разделе приводится метод преобразования ПО ГИС при переходе от кли­ент-серверной архитектуры с «толстым» клиен­том к сервис-ориентированной архитектуре с «тонким» клиентом, позволяющий сохранить большую часть исходного программного кода, реализующего основные расчетные функции (логику приложения). Преобразование программного обеспечения геоинформационных систем при переходе от двухъярусной клиент-серверной к сервис- ориентированной архитектуре. Предлагаемый метод преобразования ПО ГИС при переходе от двухъярусной клиент- серверной к сервис-ориентированной архитек­туре включает в себя решение двух основных задач: преобразование модулей настольного ПО ГИС для обеспечения возможности их вы­полнения на стороне серверов; реализация серверного ПО ГИС в виде набора сервисов. Исходное ПО ГИС реализовано множеством фрагментов исходного кода R = {MD, KD, GB, UB, {PBi}, {PZi}, UZ, CZ, {Ek}, {DTt}, {APj}} (рис. 1). Решение двух названных задач позволяет вы­полнить преобразование g:R^Rs, где Rs - реализация исходной системы R в рамках сер­вис-ориентированной архитектуры. Выделим следующие этапы решения первой задачи - преобразования модулей ПО ГИС, размещенных на стороне клиента в рамках двухъя­русной клиент-серверной архитектуры, для их размещения на серверах - на примере преобра­зования модуля моделирования распростране­ния нефти по суше и речной сети (рис. 1, 2). Из модуля моделирования удаляются фрагменты исходного кода, реализующие гра­фический интерфейс пользователя ({UZ, CZ}), и определяются фрагменты исходного кода, осуществляющие связь логики приложения с графическим интерфейсом пользователя (Is). Создаются картографические сервисы {Gsk, KGk}, выполняющие отрисовку карт. Отрисовка изображений карт является ресурсоемкой задачей, так как включает в себя запрос вектор­ных данных из базы пространственных данных, их проецирование в используемую для отобра­жения систему координат и собственно отри­совку изображений. Поэтому для снижения на­грузки на серверы создаются графические кэши карт {Hk} — заранее отрисованные и хранимые на серверах изображения карт. Создание карто­графических сервисов и ограничение доступа к ним удаленных пользователей (реализация системы безопасности {KGk}), как правило, вы­полняется средствами базового серверного ПО ГИС (например, ArcGIS Server), то есть не тре­бует разработки дополнительного ПО. Создается серверное приложение ГИС, в рамках которого преобразованный (п. 1) мо­дуль моделирования размещается на сервере. Проектируется (на основе форм исходно­го графического интерфейса) и создается (без использования программного кода исходного приложения) модуль графического интерфейса пользователя {Us, Cs}, размещаемый на компь­ютере клиента. После выполнения перечисленных этапов возможен ввод системы моделирования распро­странения нефти в промышленную эксплуата­цию, однако архитектура ПО системы в целом остается клиент-серверной - многоярусной (рис. 2). Поэтому необходимо решить вторую задачу рассматриваемого метода - реализация серверного ПО ГИС в виде набора сервисов. Рассмотрим этапы решения этой задачи. Анализ и проектирование сервисов: каж­дый проектируемый сервис должен решать от­дельную прикладную задачу, например, моде­лирование распространения нефти по речной сети, по суше, формирование отчетов. Во время проектирования выполняется иерархическое упорядочивание сервисов и проектирование ка­талога сервисов C'. При иерархическом упоря­дочении часть сервисов может быть скрыта от пользователей и других информационных сис­тем (сервисы геообработки и построения циф­ровой модели рельефа), а часть сервисов, непо­средственно используемых пользователями и другими ИС (моделирование распространения по речной сети, по суше, построение отчетов), должны иметь неизменяемый со временем про­граммный интерфейс. Информация о них (мета­данные) должна быть размещена в каталоге сер­висов для их поиска, например, по таким запро­сам: «Найти сервис, позволяющий выполнять моделирование распространения нефти по реч­ной сети на основе векторных данных (изогипс, отметок высот, речной сети) масштаба 1:50 000». Выполнение декомпозиции серверного ПО. Модуль моделирования разбивается на пять сервисов si (рис. 3) по количеству исходных ло­гических модулей, при этом каждый исходный логический модуль PZi дополняется системой безопасности KBi (ограничения доступа удален­ных пользователей) и исходным кодом Qsi, реа­лизующим возможности программного взаимо­действия с другими сервисами и информацион­ными системами посредством межплатформенных интерфейсов. То есть § = {PZi, KZi, QZi}. Аналогично выполняется преобразование моду­лей геообработки P^ сервисы SP;. Таким образом завершается преобразование g:R ^ Rs, при этом Rs = {{Us, Cs}, {§}, {5ч}, {Gi}, {MD, KD}}. Рассмотренный метод преобразования ПО ГИС учитывает специфику геоинформационных систем (например, ресурсоемкость задач обра­ботки пространственных данных, необходи­мость визуализации результатов работы систе­мы в виде карт) и позволяет управляемо, в не­сколько итераций, решить задачу преобразова­ния клиент-серверного программного обеспече­ния ГИС с «толстым» клиентом при переходе к сервис-ориентированной архитектуре с «тон­ким» клиентом с сохранением исходных функ­циональных возможностей и основной части кода исходного программного обеспечения. 

     В статье предложено решение актуальной задачи преобразования программных модулей существующего двухъярусного клиент- серверного программного обеспечения геоинформационных систем с «толстым» клиентом в сервис-ориентированное ПО ГИС с «тонким» клиентом. Предложен метод поэтапного, управ­ляемого решения этой задачи с учетом специ­фики ГИС, который позволяет выполнить пре­образование компонентов исходного ПО ГИС с сохранением большей части исходного кода, реализующего логику приложения, понизить общую сложность системы, воспользоваться преимуществами сервис-ориентированной ар­хитектуры, разместив программное обеспечение ГИС на серверных вычислительных комплексах и обеспечив к нему доступ посредством «тон­ких» клиентов. Предложенный метод применен [1, 2] для преобразования задач моделирования природных и техногенных процессов - аварий­ных разливов нефти по суше и речной сети, по­строения водосборных бассейнов, моделирова­ния зон затопления при паводковых ситуациях - в геоинформационной системе Федерального агентства водных ресурсов России.

 Список литературы

1. Распределенная обработка пространственной информации по водным ресурсам в геоинформаци­онной системе Росводресурсов / Иванов И. Г. [и др.] // Управление водно-ресурсными системами в экстремальных условиях: Сб. докл. конф. М., 2008. С. 323.
2. Павлов С. В., Шкундина Р. А., Усов Т. М. Преимущества сервис-ориентированной архитекту­ры геоинформационных систем на платформе ArcGIS (на примере ГИС Росводресурсов) [Элек­тронный ресурс] // Материалы XV конференции пользователей ESRI в России и странах СНГ. 1 элек­трон. опт. диск (CD-ROM). 2009/
3. Мацяшек Л. А. Анализ и проектирование информационных систем. М.: ООО «Вильямс», 2008. 816 с.
4. Шекхар Ш., Чаула С. Основы пространст­венных баз данных. М.: КУДИЦ-ОБРАЗ, 2004. 336 с.
5. Erl T. Service-oriented architecture. Concepts, Technology, and Design. Prentice Hall, 2005.

В. Г. Иванов

ГИС в сфере транспорта

     ГИС являются оптимальной платформой для комплексных решений в сфере транспорта. Транспортные системы с их территориальной распределенностью — идеальный объект автоматизации посредством геоинформационных систем. Пространственная составляющая является естественной основой интеграции задач управления транспортной инфраструктурой, расчетных задач, задач оперативного управления, навигации и т. д. Тем не менее, по настоящему комплексных решений в России пока не видно. Быть может, из-за инерции мышления управленцев и большого количества несоорганизованных участников, каждого из которых интересует только своя задача. Вот почему внедрение ГИС-технологии у нас происходит не по всему «фронту» транспортных и смежных с ними задач, что обеспечило бы наиболее эффективные решения и наибольшую отдачу от их внедрения, а по отдельным целевым направлениям. Рассмотрим некоторые из этих направлений, учитывая опыт, накопленный как у нас, так и в мире. Управление имуществом терминальных комплексов. Это, прежде всего, морские и аэропорты. Здесь «имущество» рассматривается в широком смысле, а не только как объект учета основных фондов. Следует отметить, что это направление использования географических информационных систем не так уж сильно отличается от управления имуществом других предприятий и компаний. Здесь ГИС — логическое продолжение традиционных баз данных и учетных систем. К ним лишь добавляется способность всесторонне моделировать территориально распределенную инфраструктуру предприятия — земельные участки, коммуникации, размещение объектов и т. д. Сочетание табличной информации и графики для транспортных предприятий особенно ценно, поскольку позволяет наглядно представлять взаимное расположение различных объектов. Чем лучше информированы специалисты, тем более эффективно они могут управлять. Такую модель лучше создавать с помощью современных средств геодезических измерений и, прежде всего, спутникового позиционирования.

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

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

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

       Важно отметить, что далеко не каждый ГИС-пакет позволяет сочетать в единой среде общий трехмерный план территории предприятия, поэтажные планы входящих в него зданий, схемы коммуникаций и другую информацию. Нужен такой, который позволяет хранить различные представления терминального комплекса, может по заданному шаблону сгенерировать из базы геоданных схему коммуникаций: систему электропитания, сеть связи или водопровод. База геоданных позволяет хранить комплексное представление любого объекта, который может играть роль имущественного элемента в учетной системе, объемной модели в системе трехмерной визуализации или элемента схемы в системе управления коммуникациями. Здесь, правда, нужно отметить, что создание такого комплексного представления — задача не простая, и она, как правило, ставится уже после «обкатки» пилотного проекта или первой очереди геоинформационной системы, в которой используются более простые средства, понятные прикладным специалистам без специальной подготовки.

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

Рассмотрим управление парком транспортных средств. Эта задача стоит перед коммерческими перевозчиками, которые осуществляют заказную транспортировку грузов и пассажиров (такси), перед сетевыми торговыми компаниями, сбытовыми подразделениями нефтяных компаний, а также компаниями, торгующими по каталогам и через интернет-магазины. Цель — снизить общие расходы на транспортировку и ускорить выполнение заказов.

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

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

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

Что можно сказать о построении и оптимизации маршрутов на существующей дорожной сети? В больших городах это очень важная задача. В Москве, например, больше тысячи маршрутов общественного транспорта, не считая «маршруток». Удержать их в памяти и проанализировать просто невозможно. К тому же оптимизировать нужно не один вид транспорта, а всех их в комплексе: метро, автобусы, трамваи, троллейбусы, электрички. Эта задача — сложная организационно, потому что требует координации большого количества управляющих организаций. Она сложна также и технически, так как требует сбора, систематизации и анализа большого объема исходных данных.

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

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

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

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

Важно отметить, что средства анализа, имеющиеся в ГИС, позволяют не только прокладывать маршруты по существующей улично-дорожной сети, но и оценивать эффективность самой этой сети, вычислять узкие места, планировать развитие. Практически в любом городе можно найти примеры, когда длина даже самого оптимального маршрута во много раз превышает геометрически кратчайшее расстояние между пунктами отправления и назначения. А на идеальной сети превышение не может быть больше 40%. Причины этого — низкая связность сети, обусловленная препятствиями (железные дороги, реки и, как ни парадоксально, магистрали непрерывного движения при нашей хронической недостаточности развязок), а также неудачная организация движения. Результат — значительный перепробег для всех участников дорожного движения: и общественного транспорта, и коммерческого, и личного. Ну, а последствия известны — пробки, шум, загазованность, ускорение износа дорожного полотна. Жаль, что у нас миллионы и миллиарды тратятся на проекты дорожного строительства, дающие копеечный результат только потому, что при их обосновании и отборе не проводится анализ изменения свойств улично-дорожной сети в целом и транспортных потоков на ней. Жалко, что инструменты для такого анализа уже есть и доступны за существенно меньшие деньги.

Одно из наиболее популярных направлений применения ГИС в дорожных администрациях — мониторинг состояния дорожного полотна и планирование ремонтов. Часто одного лишь цветового кодирования участков дорог по срокам ремонта бывает достаточно, чтобы повысить качество дорожного покрытия в целом, существенно оптимизировать процесс. Если же использовать ГИС для интеграции разносторонней информации по дорожной сети (виды, качество покрытия, транспортная нагрузка, даты ремонтов), на ее основе можно построить динамическую модель износа и автоматизировать планирование ремонтов. На Западе уже давно так делают. В базе геоданных удобно хранить и сведения о дорожных знаках, и другую «придорожную» информацию, привязанную к географическим или линейным координатам.

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

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

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

Только в последние месяцы, даже не годы, ситуация начала меняться под давлением популярности зарубежных проектов, стали развиваться аналогичные отечественные сервисы. Но пока они далеки от того, что необходимо всем как потребителям. А нужны актуальные карты дорог для планирования поездок, планы УДС и маршрутов общественного транспорта, схемы организации движения, информация о ремонтах и закрытых участках дорог, о пробках. Интернет — идеальная среда для предоставления информационных услуг на основе этих данных: от простого отображения карт до поиска оптимального маршрута с учетом различных факторов. Серверная технология позволяет легко создавать такие информационные системы и транспортные порталы в Интернете. И как только ситуация с пространственными данными придет в цивилизованное правовое состояние, связанные с транспортом интерактивные услуги станут одними из фаворитов геоинформационного рынка. Причём, это случится в недалеком будущем.

Средства программирования для разработки геоинформационных порталов

    При разработки геоинформационных порталов (ГИП) используются интернет технологии которые широко применяются при разработке сайтов. Рассмотрим данные средства программирования. JavaScript— объектно-ориентированный скриптовый язык программирования. Является диалектом языка ECMAScript. JavaScript обычно используется как встраиваемый язык для программного доступа к объектам приложений. Наиболее широкое применение находит в браузерах как язык сценариев для придания интерактивности Web-страницам. Основные архитектурные черты: динамическая типизация, автоматическое управление памятью, объектно-ориентированное программирование, представление функций как объектов единого родительского класса. JavaScript обладает рядом свойств объектно-ориентированного языка, но и имеет существенные отличия по сравнению с традиционными объектно-ориентированными языками. Кроме того, JavaScript имеет ряд свойств, присущих функциональным языкам — функции как объекты первого класса, объекты как списки и т.д. — что придаёт языку дополнительную гибкость.

  Особенность языка JavaScript заключается в том, что Web-сервисы написанные с использованием данной технологии являются межплатформенными сервисами, т.е. клиенты не зависят от конкретной операционной системы пользователя. JavaScript поддерживается всеми современными браузерами и у пользователя сети Интернет, отпадает необходимость в установке дополнительных сторонних модулей и библиотек. JavaScript используется в AJAX, популярной технологии построения интерактивных пользовательских интерфейсов Web-сервисов, заключающейся в «фоновом» асинхронном обмене данными браузера с Web-сервером. В результате, при обновлении данных Web-страница не перезагружается полностью и интерфейс Web-сервиса становится быстрее, чем это происходит при традиционном подходе (без применения AJAX). PHP (англ. PHP: Hypertext Preprocessor — «PHP: препроцессор гипертекста») — скриптовый язык программирования общего назначения, интенсивно применяющийся для разработки Web-приложений. В настоящее время является одним из лидеров среди языков программирования, применяющихся для создания динамических Web-сайтов. Язык и его интерпретатор разрабатываются группой энтузиастов в рамках проекта с открытым кодом. В области программирования для сети Интернет PHP — один из популярнейших скриптовых языков благодаря своей простоте, скорости выполнения, богатой функциональности, кроссплатформенности и распространению исходных кодов на основе лицензии PHP. Популярность в области построения Web-сайтов определяется наличием большого набора встроенных средств для разработки Web-приложений. PHP поддерживает широкие объектно-ориентированные возможности. Работу с PHP поддерживает большинство наиболее популярных Web-серверов, таких, как Apache, Microsoft Internet Information Server, Microsoft Personal Web Server, Netscape, iPlanet, Oreilly Website Pro, Caudium, Xitami, OmniHTTPd и другие. PHP способен генерировать не только HTML документы, но и изображения разных форматов, файлы PDF и Flash, а также данные в любом текстовом формате, включая XHTML и XML. PHP поддерживает работу с большим количеством платформ баз данных: AdabasD, InterBase, PostgreSQL, dBase, FrontBase, SQLite, Empress, mSQL, Solid, FilePro, DirectMS-SQL, Sybase, Hyperwave, MySQL, Velocis, IBMDB2, Unix, dbm, Informix, Oracle, DBX, Ingres, Ovrimos. Возможно создание PHP сценариев для работы с почтовыми  протоколами, протоколами передачи данных и многими другими. PHP поддерживает функции для работы со сжатыми файлами (gzip, bz2), функции календарных вычислений, функции перевода и т.п.

Собственно разработанные технологические решения rроме рассмотренных общеизвестных технологий, использованных при разработке порталов, были спроектированы и реализованы собственные алгоритмы отображения и поиска данных, а именно, пирамида детализации, поиск информации по набору атрибутов, поиск оптимального пути движения. Готовые серверные программы для разработки ГИП. На рынке программного обеспечения присутствуют программные продукты двух типов: коммерческие и бесплатные. Коммерческие продукты характеризуются достаточной простотой использования и обширным набором функций, но за этот набор приходится платить зачастую очень большие деньги. Бесплатные же продукты с открытым кодом, в большинстве случаев, требуют высокой квалификации разработчиков для создания и поддержки программных продуктов. Рассмотрим примеры готовых коммерческих продуктов которые используются силовыми министерствами и ведомствами, таких как ESRI ArcIMS и КБ «Панорама».

Серверная программа   ESRI ArcIMS

ArcIMS – это серверный программный продукт компании ESRI, обеспечивающий масштабируемое решение для распространения ГИС-служб и данных через Web рис 1.

Рис 1. Диалоговое окно серверной программы   ESRI ArcIMS

 ArcIMS позволяет публиковать в Web карты, сопровождаемые базовым ГИС-инструментарием, данные и метаданные, обеспечивая к ним одновременный доступ неограниченного числа пользователей. Пользователи ArcIMS могут обращаться к этими ресурсам, используя приложения HTML или Java, входящие в состав ArcIMS и работающие в обычном Web-браузере. В качестве клиентских приложений со службами ArcIMS могут работать стандартные приложения ArcGIS Desktop (ArcInfo, ArcEditor, ArcView), пользовательские приложения, созданные с помощью ArcGIS Engine, ArcReader, ArcPad, ArcGIS Server, а также приложения для мобильных и беспроводных устройств.

Достоинства ArcIMS:

легкость создания картографического сервиса;

поддержка очень большого числа растровых и векторных форматов данных;

полное соответствие стандартам, разработанным OpenGIS Consortium в отношении Web mapping services (поддержка WMS, WFS, WCS стандартов);

конфигурирование и программирование с использованием ASP, JSP, .NET;

интеграция с системой управления базами данных (СУБД) Oracle и другими СУБД через ArcSDE;

создание высококачественного картографического результата;

возможность публикации проектов ArcGIS "как есть".

Недостатки:

невозможность работы с СУБД напрямую – только через ArcSDE;

ресурсоемкость и относительная нестабильность;

более медленная скорость обработки запросов (по сравнению, например, с MapServer);

закрытость кода;

GIS WebServer  КБ Панорама

Данное приложение предназначено для доступа к инфраструктуре пространственных данных (векторных, растровых, матричных карт, данных ДЗЗ и информации баз данных) рис 2.

Рис.2 . Диалоговое окно серверной программы   GIS WebServer  КБ Панорама

 Имеются функции масштабирования, перемещения, изменения размеров карты. Выполняется поиск и фильтрация информации в базе данных, поиск объектов на карте: поиск объектов по названию, по области, поиск по адресу, поиск перекрестков улиц (для крупномасштабных карт и планов городов). Поддерживается редактирование точечных объектов карты, вывод всплывающих подсказок, обработка гиперссылок. Режим периодического обновления изображения карты позволяет создавать системы слежения за подвижными объектами. Доступны функции измерения расстояний по карте, создания пользовательских закладок, формирования отчетов, печати карты в файл, публикация новостей в формате RSS. Взаимодействие с внешними Web-приложениями через расширенный набор HTTP-запросов при формировании геопорталов различного назначения. Настраиваемый интерфейс пользователя, поддержка протоколов OGC (Web-сервис метаданных и карт WMS OGC - GIS WebService). Использование стандарта WMS OGC обеспечивает GIS WebServer общепринятым международным протоколом поиска, обмена и использования геопространственных данных.

В приложении применяется механизм идентификации пользователей для защиты информации и обеспечения безопасности данных. Могут использоваться различные СУБД для создания баз данных: MS SQL Server, Oracle, MS Access и другие.

Недостатки:

закрытость кода;

высокая цена на развёртывание сервера в Интернет.