Леви К.Г., Бабичев А.А. Расширение стандарта Web Map Server Interface для создания универсального интерфейса к серверам ГИС
Леви К.Г., Бабичев А.А., Институт земной коры СО РАН, Иркутск
Для решения проблем публикаций данных ГИС удобно использовать сервера соответствующие стандарту Web Map Server Interface [1]. Этот стандарт широко поддерживается современными ГИС-приложениями и предоставляет возможность публиковать данные, не требуя наличия у клиента дорогостоящего специализированного программного обеспечения в простейшем случае будет достаточно обычного Web-броузера.
Web Map Server (WMS) представляет собой Web-приложение, обычно построенное при помощи технологии Common Gateway Interface (CGI). Запросы клиентов передаются при помощи команды GET протокола Hypertext Transfer Protocol (HTTP). Каждый запрос должен содержать в себе номер версии поддерживаемого стандарта WMS, имя запрашиваемого интерфейса, набор данных для запроса, определенных стандартом и, опционально, набор данных для использования нестандартных возможностей сервера. Результат возвращается в виде машиночитаемых данных в формате XML [2] или графического изображения в одном из популярных графических форматов, например, GIF.
Стандарт гласит, что сервер должен обладать тремя интерфейсами: Map для показа карты и данных, FeatureInfo (опционально) для предоставления клиентам подробной информации о представленных на карте данных и Capabilities, служащего для передачи клиентскому ПО данных о возможностях сервера.
WMS очень удобны в работе, но содержат один недостаток, сильно ограничивающий область их применения. Стандарт не определяет механизма создания запросов к WMS, перекладывая это на плечи разработчиков приложений. Разработчики создают свои расширения для каждой решаемой ими задачи, лишая таким образом пользователей возможности использовать универсальное клиентское приложение, которое могло бы посылать запросы к любому серверу. Это противоречит идеологиям WMS, которые задумывались как пригодные для использования любыми клиентами, отвечающими требованиям стандарта.
Проблему можно решить, расширив стандарт таким образом, чтобы клиенты могли получать информацию о поддерживаемых сервером запросах и использовать их для отбора и обработки данных. Это можно сделать, введя дополнительный интерфейс, чтобы не нарушать работу уже существующих приложений.
Для создания универсального механизма запросов предлагается ввести новый интерфейс data_works. Серверы, поддерживающие данный интерфейс, должны сообщать о его наличии по запросу capabilities. В отличие от остальных интерфейсов, интерфейс data_works ориентирован на сеансы. Это связано с тем, что максимальная длина запроса, передаваемая при помощи команды GET протокола http, ограничена, а запросы могут быть большими.
Запросы могут быть двух типов: для выборки данных и для анализа уже отобранных данных. При выборке данных на сервере создается множество данных, с которыми может вестись дальнейшая работа. Для множеств должны быть предусмотрены стандартные операции работы с ними: объединение, пересечение и исключение. На сервере должны существовать заранее отобранные множества: как минимум, по одному множеству, содержащему данные с каждого слоя, и множество данных, содержащее в себе все данные на сервере. При операциях отбора пользователь указывает исходные множества, используемые для выборки, а сервер возвращает имя результирующего множества.
Множества принадлежат пользователям, которые их создали. Пользователи ни при каких условиях не должны видеть чужие множества. Множество хранится на сервере, пока активен сеанс связи с их владельцем. Сеанс считается завершенным, когда пользователь не обращался к серверу в течение определенного времени. Чтобы исключить возможность взлома сервера, связанную с переполнением памяти, сервер может ограничивать количество одновременных сеансов и максимальное количество отобранных данных на сеанс. Клиентское программное обеспечение может периодически посылать серверу специальные пустые запросы, чтобы показать серверу, что сеанс еще не завершен и не надо уничтожать связанные с сеансом данные.
Данные, которые содержатся в ГИС-приложениях могут иметь разный характер. Например, между данными о землетрясениях и данными о разломах, с которыми они связаны, очень мало общего, поэтому сложно создать интерфейс которые позволил бы одинаково легко отбирать и те, и другие. Вместо этого лучше предоставить разработчикам сервера возможность передать клиентскому приложению информацию о поддерживаемых типах запросов
Сервер должен предоставлять клиентскому приложению информацию о форме запросов кнопках, строках ввода, выпадающих списках и т.д. подобно тому, как описываются формы в языке гипертекстовой разметки HTML [3] или в языке описания пользовательских интерфейсов XUL [4], успешно применяемом в проекте Mozilla. Задача клиентского приложения - организовать диалог пользователя и передать введенные пользователем данные обратно на сервер. В результате выполнения запроса либо будет создано новое множество, либо будет выдана форма для ввода дополнительных данных, либо показано сообщение об ошибке.
Обработка данных производится по схеме, аналогичной выбранной: клиент получает список поддерживаемых методов анализа данных, выбирает один из них, выбирает множества, данные из которых следует проанализировать, при необходимости получает форму для ввода дополнительных данных, после чего происходит обработка данных. Разница между анализом данных и выборкой состоит в том, что результатом анализа могут являться не только отобранные множества, но так же могут создаваться новые данные или слои. На созданные объекты действуют те же правила, что и на создаваемые пользователями множества: они видны только для создавшего их пользователя и время их жизни ограниченно временем сеанса.
Отбор данных и создание новых данных в результате анализа информации не имеет смысла, если эти данные нельзя увидеть. Для отображения результатов работы необходимо модернизировать интерфейс map, введя дополнительные параметры через которые передавалась бы информация о множествах, которые следует показывать. Стандарт WMS предусматривает возможность создания пользовательских атрибутов, но, к сожалению, ни как не регламентирует правила задания их имен. В стандарте говорится только, что имена надо выбирать осторожно, чтобы не создать конфликта с возможными будущими версиями стандарта . Для именования дополнительных пользовательских атрибутов представляется разумным использовать следующую схему: начинать имена с префикса ext , далее через подчеркивание ставить префикс производителя (название института, фирмы и т.п.) и через подчеркивание собственно имя расширения. Такая схема позволит свести к минимуму риск совпадения имен расширений различных производителей.
Через расширенный атрибут интерфейса map, названный ext_iec_sets, через запятую, как рекомендует стандарт, передаются имена множеств которые следует отобразить. Созданные пользователем данные передаются через атрибут ext_iec_datasets. Если атрибут ext_iec_sets не задан, то сервер должен считать, что он равен ‘all‘ имя множества, содержащего в себе все данные. Такое соглашение позволит обеспечить совместимость с клиентами, которые не понимают описанные здесь расширения.
Описанное выше расширение стандарта позволит существенно уменьшить затраты на разработку и развертывание клиентской части ГИС-приложений. Его достоинствами являются простота и обратная совместимость с существующими приложениями. Утверждение этого или подобного расширения стандарта консорциумом OpenGIS обеспечит возможность создания ГИС-приложений, не зависимых от типа клиентского программного обеспечения, а конечные пользователи получат возможность выбора наиболее удобных для них программных оболочек ГИС.
RSS
Реклама
