CC BY
42
ВЕСТНИК ЮГОРСКОГО ГОСУДАРСТВЕННОГО УНИВЕРСИТЕТА
2006 г. Выпуск 4. С. 52-57
УДК 004.65
ИНФОРМАЦИОННАЯ СИСТЕМА КАТАЛОГИЗАЦИИ ГЕОДАННЫХ
А.В. Козлов
На сегодняшний день при ежедневно возрастающих объемах хранимой геоинформации различных типов пользователи испытывают трудности при подборе необходимых им данных. Специалисты компании Core Software Technology (разработчики коммерческого продукта imageNet) утверждают, что около 75% времени работы над ГИС-проектами, уходит на поиск необходимых данных.
Даже в условиях одной крупной организации поиск геоинформации усложняется тем, что геоданные хранятся на разных носителях: жестких дисках, магнитных лентах, CD и DVD дисках. Кроме того, организации часто не имеют обобщенного каталога архивных данных с возможностью удобного поиска и предварительного просмотра информации о данных без необходимости обращения к архивному носителю информации.
Если рассматривать эту проблему на региональном уровне, то она усугубляется территориальной удаленностью держателей информации, частой неосведомленностью заинтересованных организаций о уже имеющихся в наличии геоданных в организациях этого региона и трудностями поддержания данных в актуальном состоянии на текущий момент времени.
В целях рационального использования геоинформационных данных, организациями Ханты-Мансийского автономного округа, Югорским НИИ информационных технологий c начала 2005 года ведется разработка системы каталогизации и поиска геоданных.
В качестве основных предпосылок к созданию центра геоданных можно выделить следующие:
• многократное дублирование геоданных, как на уровне региона, так и на уровне отдельно взятых организаций. Это в свою очередь приводит, во-первых, к сложности, а иногда и невозможности отслеживания различных версий одного и того же экземпляра данных, что в свою очередь влечет множество разрозненных версий одного и того же ресурса данных, которые становится невозможным синхронизировать между собой. С другой стороны, многократное дублирование данных может привести к их утрате в результате того, что каждый из совладельцев может уничтожить свой экземпляр не заинтересовавшись, что тоже не сделают другие владельцы ресурса;
• высокая стоимость данных часто не позволяет отдельным организациям приобретать их для собственных нужд, а иногда это и не является необходимым. Данный фактор становится особо весомым в случае многократной покупки одних и тех же данных несколькими организациями. Очевидно, что для стороны продающей данные эта ситуация будет выгодна, однако для организаций, использующих данные ситуация будет обратная;
• возрастающий спрос на геоданные требует максимально быстрого реагирования со стороны обладателей востребованных ресурсов, что зачастую бывает затруднено отсутствием явных связей между продавцом и покупателем до того момента, когда будет совершена первая сделка. Хотя и наличие связей не гарантирует, что в момент когда данные понадобятся, покупатель будет знать, что те данные, которые ему нужны, имеются у их владельца;
• как следствие повышенного спроса встает проблема быстрого и качественного поиска данных. Зачастую, заинтересованная в данных сторона не имеет возможности как найти, так и определить степень пригодности для своих проектов данных, предоставляемых третьей стороной, что приводит к затормаживанию промышленных или научных разработок.
Если взять в качестве примера геоданные, имеющиеся в Югорском НИИ Информационных Технологий, то можно увидеть следующую картину. В институте на конец 2005 года имелись следующие данные:
Сканерные изображения
• Метеор-ЗМ/МСУ-Э (2002-2005гг) - 700Гб
• Ресурс-01-3/МСУ-Э, МСУ-СК (1997-2000гг) - 252,4Гб
• NOAA/AVHRR (2003-2005гг) - 380Гб
• TERRA/MODIS (2003-2005 гг) - 1600Гб
• TERRA/ASTER - 15Гб
• Landsat/TM(MrSid) -12Гб
• Landsat/ETM (MrSid) - 12Гб
• Landsat/TM+ETM (GeoTiff) (1982-2003гг) - 450Гб Космофотоснимки
• Ресурс Ф1М - 4Гб
• Ресурс Ф2М/МК4 (1993 г) -108Гб Радарные изображения
• Shuttle/SIR-C -16Гб
• Shuttle/SRTM -6,8Гб
• JERS-1/SAR -6,4Гб
• ENVISAT/ASAR - 30Гб
• ERS-2/SAR - 50 лент по 30Гб
Итого имеем более 5 Тб, и это далеко не полный список имеющихся в институте геоданных. В этот список не включены различные векторные данные, данные сканированных изображений, данные геологической сейсморазведки и другие виды данных.
Очевидно, что, при обладании таким огромным объемом данных, жестко встает вопрос по их каталогизации и поиску. Для решения этой и других задач был создан Югорский Центр Геоданных, который бы позволил решать следующие задачи:
• создание библиотеки геоданных различных форматов;
• создание и поддержание в актуальном состоянии каталога геопространственных данных;
• организация взаимодействия держателей геоданных в ХМАО;
• совместная разработка нормативных документов, регулирующих работу участников проекта.
В рамках решения первых двух задач было принято решение о создании автоматизированной информационной системы по каталогизации и поиску геоданных. В качестве функциональных требований к разрабатываемой системе были выделены следующие:
• хранить метаданные о геопространственных данных (БМД - база метаданных), то есть вести базу данных метаописаний, следить за ее целостностью и непротиворечивостью;
• позволить конечному пользователю системы производить поиск метаданных по различным критериям;
• производить операции по созданию, актуализации и удалению данных из БМД, а также для случаев, где это возможно автоматизировать этот процесс в плоть до исключения из него оператора;
• обеспечивать защиту информации хранимой в базе метаданных как с точки зрения метаданных, так и самих геоданных;
• организовать систему заказов данных, найденных при поиске.
С другой стороны, с технической точки зрения, система должна удовлетворять следующим критериям:
• масштабируемость, т. е. система должна быть развиваемой с точки зрения появления новых видов данных, новых критериев поиска данных и др.;
• кроссплатформенность подразумевает возможность работы системы на любой аппарат-но/программной платформе и возможность распределения компонент системы в гетерогенной среде;
• функциональная наращиваемость, те система должна позволять вводить в себя дополнительные функциональные компоненты без модификации общей архитектуры системы;
• возможность интеграции с подобными системами, что подразумевает возможность интеграции системы каталогизации и поиска с системами других производителей.
На основании выделенных технических и функциональных требований к системе было принято решение вести разработку системы с использованием технологии Java 2 Enterprise Edition (J2EE) и использовать для хранения базы метаданных СУБД Oracle 10g. Это, с одной стороны, позволило сделать систему максимально масштабируемой и наращиваемой, с другой стороны, обеспечило кросплатформенность и широкие возможности по интеграции с другими системами используя J2EE Connector Architecture.
В результате проведенного анализа требований и выбранных технологий их реализации было выделено четыре основных компоненты системы:
• база метаданных;
• сервер приложений;
• автоматизированное рабочее место (АРМ);
• Web-интерфейс.
Для построения базы данных системы была выбрана СУБД Oracle 10g, которая, с одной стороны, обладает высокими показателями производительности и надёжности, с другой стороны, имеет встроенные средства работы с геоданными - так называемый Oracle Spatial, то есть стало возможным переложить часть функций системы, связанную с пространственными запросами, на СУБД.
В качестве основы модели данных БД был выбран стандарт ISO 19115, так как он наиболее полно описывает структуру метаданных затрагивая различные аспекты связанной с геоданными информацией. Данный стандарт описывает следующие параметры данных:
• пространственно временные характеристики данных;
• вопросы хранения и распространения данных;
• информация о качестве и сертификации данных;
• информация об идентификации данных;
• информация об изменении данных;
• информация о секретности данных и метаданных;
• персональная информация о лицах, тем или иным способом связанными с данными.
В качестве метода доступа к данным был выбран объектный подход, то есть реляционная модель данных СУБД была приведена к объектному виду с использованием Enterprise Java Beans(EJB). Это позволило, с одной стороны, значительно ускорить процесс разработки системы, с другой стороны, обеспечить максимальную гибкость и наращиваемость системы. Данная объектная модель данных была размещена на сервере приложений под управлением Sun Java System Application Server, который соответствует спецификации J2EE 1.4.
Кроме объектной модели данных на сервере приложений была размещена вся бизнес-логика системы, что в значительной степени снижает нагрузку на клиентское программное обеспечение и позволяет производить проверку данных на соответствие стандарту на стороне сервера, в месте с тем обеспечивая защиту информации системы.
Другая компонента разрабатываемой системы, которой следует уделить внимание, - это АРМ. На данную компоненту возлагается решение следующих задач:
• разграничить доступ пользователей к данным информационной системы, с целью минимизировать возможные потери информации в результате работы с ними не квалифицированных лиц, а также обеспечить соответствующий данным уровень секретности. В месте с этим обеспечить возможность журналирования всех операций, производимых с системой;
• администрировать БМД, производить комплексный анализ целостности и актуальности имеющихся данных;
• администрировать базу пользователей ИС, с целью выявления потенциальных узких мест, делегирования пользователям тех или иных прав на доступ к данным метаописаний;
• производить поиск данных по заданным критериям;
• импортировать данные из других информационных систем и производить мониторинг подсистем автоматического импорта данных, где это возможно.
Система WEB-интерфейса должна обеспечивать следующую функциональную нагрузку:
• осуществлять интерактивный и атрибутивный поиск геопространственных данных;
• осуществлять доступ к данным ИС в зависимости от прав пользователей;
• подавать заявку на предоставление данных.
Подсистема поиска логически разделяется на две части: во-первых, это непосредственно подсистема поиска геоданных (атрибутивного и интерактивного поиска) и подсистема отображения найденных данных. Подсистема атрибутивного поиска позволяет искать данные, основываясь на атрибутивные фильтры. Атрибутивный фильтр включает в себя следующие поля:
• тип данных
• временной интервал данных
• пространственные координаты объекта
• дополнительные атрибутивные данные
• ключевые слова, с которыми данные связаны.
Атрибутивный поиск требует максимальной осведомленности пользователя системы о данных, которые он ищет. В случае, если пользователь не имеет точных данных о том, что он ищет, система предлагает пользователю воспользоваться интерактивным поиском данных с использованием картографического интерфейса. Фактически, при интерактивном поиске пользователь обозначает область интересов примитивными атрибутивными фильтрами и географической областью на карте, на основе которых система осуществляет поиск. Очевидно, что в результате интерактивного поиска вместе с полезной информацией пользователю будет найдена значительная часть ненужной информации, в результате потребуется визуально отфильтровать найденные данные, однако, ввиду простоты составления запроса на поиск системе интерактивный поиск является более удобным.
Другая функция WEB-интерфейса - это предоставление пользователю только тех данных, которые ему разрешены ограничениями, находящимися в метаданных. Для этого, перед тем как начать работу с системой, пользователю предоставляется возможность идентифицировать себя, пройдя авторизацию, после чего все действия пользователя в системе протоколируются для обеспечения мониторинга за системой и последующего анализа этих данных для оптимизации поиска.
Одной из важных подсистем системы поиска является возможность осуществления заказа выбранных данных. Для этого пользователю предоставляется возможность выбрать необходимые ему объекты и отправить заявку администратору системы, которая в дальнейшем обрабатывается и направляется реальному владельцу данных.
Во время фактической реализации информационной системы каталогизации и поиска геоданных были выделены следующие функциональные блоки (Рис. 1):
1) Хранилище данных каталога (Persistence storage), реализованное в виде реляционного хранилища данных под управлением СУБД 0racle10g.
Хранилище данных каталога СУБД Oracle 10g
Система поиска и отображения метаданных
Се peep кое приложение каталога метаданных под управлением Sun Java System
Application Server
Рис.1. Основные Блоки информационной системы
2) Серверное приложение каталога метаданных, основной функцией которого является непосредственное хранение, обновление и поиск метаданных в каталоге (Рис. 2).
Сервер приложений Sun Java System Application Server
Модуль доступа к данным
X
Модуль бизнес-логики Ч-
Z
Административный модуль
Система поиска и отображения метаданных
Рис. 2. Структура серверного приложения информационной системы В данное приложение входит три функциональных модуля:
• модуль доступа к данным, представленный EJB модулем и состоящий из набора компонент, описывающих структуру файла метаданных и позволяющих хранить файлы метаданных в постоянном хранилище в базе данных. Также данный модуль обеспечивает реляционную целостность хранимой в БД информации;
• модуль бизнес-логики, основной функцией которого является корректное добавление, обновление и поиск по каталогу. Данный модуль реализован в виде набора EJB-компонент, обеспечивающих удалённый интерфейс доступа к данным каталога метаданным и его функциям;
• административный модуль, обеспечивающий функции добавления и модификации метаданных в системе. Данный модуль выполнен в виде J2EE Application Client и реализует конечный пользовательский интерфейс администратора системы.
3) Распределённая система поиска и отображения данных, находящихся в каталоге. Данная система представлена WEB-приложением построенным на базе технологий Java Servlets, Java Server Pages и Java Server Faces (Рисунок 3). Данное приложение состоит из нескольких функциональных блоков:
• Internet browser, который фактически является тонким клиентом для доступа к системе;
• WEB Front End - набор jsp страниц, реализующих внешнее представление интерфейса пользователя, реализованных с использованием пользовательских компонент Java Server Faces;
• Back End - набор Java Beans классов обеспечивающих реализацию бизнес-логики пользовательского интерфейса и интеграцию с серверным приложением каталога метаданных;
• набор серверных компонент, позволяющих реализовать картографический интерфейс поиска метаданных. Данные компоненты используют программную библиотеку JAI (Java Advanced Imaging), предоставляющую API для прорисовки изображений, содержащих карту.
В итоге, в результате использования данного компонентного подхода к реализации системы поиска и каталогизации геоданных была получена гибкая, расширяемая, кросс-платформенная информационная система, которая в настоящее время находится в стадии тестирования и в скорейшем времени готовится ее запуск в промышленную эксплуатацию. Также следует отметить, что разработанная система обладает свойством адаптивности к хранению в ней метаданных, не описанных в данной статье, например система может каталогизировать не только широко распространенные виды геоданных, но и частные данные используемые в узком кругу задач, в том числе данные используемые для или в процессе решения геолого-геофизических задач.
Данная работа выполнена при финансовой поддержке из средств комплексного проекта 2005-РИ-00.0/009/202 «Разработка комплексной технологии поиска и разведки углеводородов в сложно построенных, глубокозалегающих месторождениях» в рамках федеральной целевой научно-технической программы «Исследования и разработки по приоритетным направлениям развития науки и техники» на 2002-2006 годы в соответствии с государственным контрактом № 02.467.11.7008 от 10.11.2005 г. между Югорским научно-исследовательским институтом информационных технологий и Федеральным агентством по науке и инновациям Российской федерации и договором №05-427-ЮГУ (НИР) от 14.11.2005 г. на выполнение научно-исследовательских, опытно-конструкторских и технологических работ между ЮНИИ ИТ и Югорским государственным университетом.
