3

СОДЕРЖАНИЕ

ВВЕДЕНИЕ .................................................................................................................................... 4

1. Ретроспективный географический тезаурус ....................................................................... 6

1.1. Географическая привязка в информационной системе .............................................. 6

1.2. Пути интеграции географических данных ................................................................... 7

1.3. Препятствия при интеграции посредством тезауруса ................................................. 8

1.4. Существующие географические тезаурусы ................................................................. 8

1.5. Стандарты регламентирующие формат представления тезауруса .......................... 10

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

2.1 Основные требования к тезаурусу .............................................................................. 12

2.2 Сценарии использования тезауруса ............................................................................ 12

2.3 Онтология Тезауруса .................................................................................................... 13

2.4 Схема данных Тезауруса .............................................................................................. 15

3. Разработка программных средств для работ с ретроспективным географическим

тезаурусом .................................................................................................................................... 16

3.1 Цели разработки программных средств ..................................................................... 16

3.2 Выбор инструментов реализации ................................................................................ 16

3.3 Архитектура системы ................................................................................................... 21

3.4 Программная реализация ............................................................................................. 21

4. База данных ретроспективного географического тезауруса ........................................... 25

4.1 О программном продукте ............................................................................................. 25

4.2 Структура записей в базе тезауруса ............................................................................ 25

4.3 Реляционная схема базы данных тезауруса ............................................................... 25

4.4 Нормативные документы ............................................................................................. 27

Заключение ................................................................................................................................... 29

Литература ................................................................................................................................... 30

Приложение А .............................................................................................................................. 32

Приложение Б .............................................................................................................................. 33

Приложение В .............................................................................................................................. 35

Приложение Г .............................................................................................................................. 39

4

ВВЕДЕНИЕ

На сегодняшний момент практически отсутствуют географические

информационные системы, способные интегрировать свои ресурсы в информационные

системы не связанные с географическим аспектом. Причина – использование в

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

игнорирование мирового, в первую очередь американского, опыта интеграции

информационных ресурсов.

Приобретает все большую актуальность разработки, направленные на интеграцию

«негеографических» информационных систем с информационными системами, изначально

предназначенные для обработки географической информации (ГИС). Кроме того,

существующие на данный момент информационные системы и программные комплексы не

имеют функциональности по хранению и обработке географических данных. Добавление

такой функциональности осложняется отсутствием единых стандартов на поиск и

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

информационных системах общего назначения географического данных необходим

тезаурус, который бы включал в себя не только географический аспект информации, но и

ее ретроспективный временной (исторический) аспект.

Одним из подходов к решению этой проблемы является создание распределенных

компьютерных систем с использованием Web и ГИС-технологий. При построении такого

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

систематизации и поиска электронной научной информации, которые позволяли бы

специалистам получать релевантный запросу комплекс взаимосвязанной научной

информации (электронные научные публикации, тематические коллекции документов,

базы данных, ГИС-системы и т.п.), а также предусмотреть автоматическое пополнение

хранилищ информационной системы новой научной информацией.

Таким образом, разработка тезауруса, обеспечивающей обработку географического

аспекта информации в информационных системах не имеющих функциональности по

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

Отсюда и возникает актуальность в разработках различных программных средств на основе

международных стандартов для работы с ретроспективным географическим тезаурусом.

Целью данной работы является разработка программных средств для работы с

ретроспективными географическими тезаурусами на основе международных стандартов.

Диссертация состоит из введения, четырех глав основного текста, заключения,

библиографического списка и 4 приложений.

5

Первая глава являет собой краткий обзор стандартов и основных понятий

предметной области, а так же истории ее изучения и современного состояния

ретроспективных географических тезаурусов. Также подробно описаны основные

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

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

исторического аспекта информации. Приводится обзор некоторых схем существующих

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

требований к разработке программных средств к тезаурусу географических наименований.

А также описывается онтология тезауруса. В третьей главе содержится подробное описание

созданного программного инструмента и последовательности действий по его созданию, от

выяснения требований до эксплуатации. В четвертой главе подробно описана база данных

тезауруса ретроспективных географических наименовании.

6

1. Ретроспективный географический тезаурус

Развитие графических пользовательских интерфейсов, основанных на

взаимодействии пользователя с географическими картами с развитым инструментарием по

навигации, масштабированию и поиску информации с использованием ее географической

привязки, позиционирует сервис работы с упомянутой информацией как неотъемлемую

часть любой современной информационной системы. Примером могут служить не только

популярнейшие справочные системы информирования мобильных пользователей с

использованием спутниковой навигации, не только сервисы информационных монстров

типа Google или Yandex, предоставляющие как возможность просмотра детализированной

информации о земной поверхности, так и создание пользовательских мультимедиа архивов

с координатной привязкой документов, но и всевозможные так называемые

геоинформационные системы (ГИС), полностью основанные на работе с информацией,

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

привязка информации и способы работы с такой информацией – достаточно актуальная

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

1.1. Географическая привязка в информационной системе

До середины 1960 годов карты являлись всего лишь способом хранения символьной

информации о географических объектах. 1960-е годы были ознаменованы появлением

географических информационных систем или ГИС. ГИС — это информационная система,

обеспечивающая сбор, хранение, обработку и визуализацию пространственных данных и

связанной с ними информации.

Уже тогда было заявлено, что приоритетной задачей картографии является не

создание визуальных продуктов, а процессы сбора, преобразования и обработки

информации. И основаны эти процессы будут на компьютерных системах [1]. Со временем

количество областей, в которых использовались ГИС, увеличивалось. Но, все же, ГИС

оставались в сферах, напрямую связанных с географией. Многое изменилось с появлением

географических интернет сервисов, таких как Google Maps [10]. Они дали возможность

интегрировать функциональность географических информационных систем в системы,

прямым образом не связанные с географией. Это так называемые «негеографические»

информационные системы, к которым относятся, например, электронные каталоги, базы

данных научно-технической информации, архивы с информацией о цифровых и

нецифровых объектах. Ведь тот факт, что данные системы напрямую не связаны с

географией, не означает, что географическая информация там не содержится. Любая статья

была где-то написана и опубликована, любой экспонат музея был где-то найден, тексты

научных трудов зачастую содержат названия географических объектов. И это только

7

несколько примеров того, что «негеографические» системы на самом деле содержат

географическую информацию. .

Под географической привязкой мы будем понимать логическую связь цифрового

объекта с некоторой геометрической областью на земной поверхности. При наличии такой

привязки в информационных объектах электронной библиотеки, задача поиска объектов,

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

геометрических областей, выполняемой математическими методами, а не методами,

основанными на лексическом анализе [2]. Такой подход обеспечивает, большую

релевантность результатов, по сравнению с текстовым поиском по названиям

географических объектов, и, во-вторых, такая функциональность уже встроена во многие

хранилища данных, чего нельзя сказать об алгоритмах лексического анализа.

1.2. Пути интеграции географических данных

Можно разграничить две важные составляющие любого объекта, характерного для

рассматриваемых систем.

Вся информация об объекте может быть разделена на две составляющие:

a) Контент – информационное наполнение объекта;

b) Контекст – среда, в которой существует объект.

В дальнейшем мы будем считать, что географический аспект информации может

быть зафиксирован на уровне метаданных, описывающих контент и контекст. При этом

«географические» метаданные объекта могут быть заданы двумя способами:

a) С помощью геометрического описания географического объекта на основе

координат;

b) С помощью ссылки на элемент некоторого тезауруса, включающего

географические названия соответствующих объектов.

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

работе под тезаурусом будем понимать информационно-поисковый тезаурус.

Информационно-поисковый тезаурус – это нормативный словарь, явно указывающий

отношения между терминами и предназначенный для описания содержания документов и

поисковых запросов. [3]

Оба варианта интеграции имеют как положительные, так и отрицательные стороны.

Первый вариант исключает неоднозначные толкования, но, в то же время, он не

очень удобен по причине необходимости внесения существенных изменений в уже

существующие информационные системы. Второй вариант не является однозначным, но

может быть реализован на базе существующих парадигм информационных систем при

условии их небольшой модернизации, а также обладает большей гибкостью. Хотя при

8

реализации первого варианта интеграции тезаурус географических наименований также

необходим для определения координат географических объектов, имеющих отношение к

записям информационной системы.

1.3. Препятствия при интеграции посредством тезауруса

Существует множество тезаурусов географических наименований, но сложность их

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

аспект объектов, хранящихся в негеографических информационных системах, зачастую

относится не к текущему моменту времени, а к моментам времени прошедшим. Однако с

течением времени могут изменяться как географические названия, так и границы

географических объектов. Будем называть это изменение свойств с течением времени

ретроспективным аспектом информации. В то же время большинство тезаурусов содержит

сведения, относящиеся только к текущему моменту времени, т.е. не учитывает

ретроспективный аспект информации. Данная особенность препятствует использованию

существующих тезаурусов географических наименований в подобных системах.

Следует заметить, что любые изменения географических названий и геометрических

объектов, ассоциированных с ними, как правило, связаны с каким-либо нормативным

документом.

Более того, в существующих тезаурусах координаты географического объекта чаще

всего задаются в виде точки, в то время как реальные координаты объекта представляют

собой далеко не точку, а в общем случае, некоторую область. Что, конечно же, также

уменьшает полезность таких тезаурусов при проведении поиска. Поэтому более

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

границ области, занимаемой объектом.

Также, для задач поиска, полезными будут данные о том, как географические

объекты расположены относительно друг друга. Например, если производится поиск по

некоему региону, целесообразно считать релевантными также и элементы, относящиеся к

географическим объектам, лежащим в целевом регионе.

1.4. Существующие географические тезаурусы

Рассмотрим существующие на данный момент схемы представления данных и

существующие тезаурусы, которые могут представлять интерес в рамках разработки

программных средств для ретроспективного географического тезауруса.

При рассмотрении будем обращать внимание на следующие свойства:

a) Наличие ретроспективных данных. Возможность извлечь данные, относящиеся

к прошлому;

9

b) Наличие связей с нормативными документами. Возможность определить,

согласно какому документу было изменено название или координаты объекта;

c) Описание координат географического объекта согласно его форме.

Представление географического объекта не только в виде точки, а также в виде замкнутого

контура, линии, композиции примитивов;

d) Наличие связей, отражающих относительное расположение географических

объектов.

Рассмотрим существующие на данный момент схемы данных.

1) Getty Thesaurus of Geographic Names

Тезаурус географических имен Института Getty - Англоязычный тезаурус,

содержащий более чем миллион географических имен, информацию о континентах,

физических объектах, административных сущностях и нациях современного политического

мира, а также сведения об исторически значимых областях [12].

Схеме тезауруса Getty, естественно, присущи как положительные, так и

отрицательные черты.

Из отрицательных черт можно отметить отсутствие информации об изменении

координат географических объектов с течением времени. Координаты объекта могут быть

либо точкой, либо прямоугольником, что недостаточно для полного описания области на

поверхности земли.

2) Тезаурус РГБ

Справочник географических названий Российской государственной библиотеки.

Содержит наименования географических объектов (городов, рек, и т. д.) на территории

Российской Федерации [13].

Тезаурус не содержит ретроспективных данных в записях. Невозможно получить ни

данных о предыдущих названиях, ни данных о предыдущих координатах объектов.

В записях присутствуют ссылки на нормативные документы, определяющие

наименование объекта.

Координаты географических объектов заданы в виде координат точек, что не совсем

соответствует действительности.

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

3) Служба геокодирования API Карт Google

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

указанным координатам [10].

10

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

Отсутствуют связи с нормативными документами. Координаты объектов указаны в виде

точек. В записях содержатся иерархические связи.

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

географических объектах, но так же и об адресах. Есть возможность произвести обратное

геокодирование. Но, использовать службу геокодирования можно только вместе с картами

Google, что делает невозможным использование сервиса в данной задаче.

4) Служба геокодирования API Яндекс Карты

Имеет функциональность, аналогичную геокодеру Google [11]. Обладает

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

можно выделить более обширную базу российских наименований географических

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

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

Таким образом, проанализировав существующие решения, мы приходим к выводу,

что схемы тезауруса с необходимой нам функциональностью нет. Но есть достаточно

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

для тезауруса.

1.5. Стандарты регламентирующие формат представления тезауруса

Существует ряд стандартов разного уровня значимости и проработанности на

формат представления тезаурусов. Эти стандарты представляют тезаурус в виде набора

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

Некоторые стандарты регламентируют также формат представления тезауруса в

линеаризованном (текстовом) виде, пригодном для восприятия, как машиной, так и

человеком.

a) Стандарт ISO2788-1986

Основными документами, регламентирующим формат представления тезауруса,

являются стандарт ISO 2788-1986 для описания одноязычных тезаурусов, и ISO 5964-1985

для многоязычных.

Стандарт ISO 2788-1986 определяет тезаурус, как набор терминов, связанных между

собою соответствующими связями (отношениями).

Американский стандарт ANSI/NISO Z39.19-1993 расширяет и уточняет стандарт ISO

2788-1986 для одноязычных тезаурусов, а также накладывает ряд дополнительных

ограничений на структуру тезауруса.

b) Стандарт ISO 5964-1985

11

Являются основными документом, регламентирующим формат представления

тезауруса, стандарт ISO 5964-1985 используется для описания многоязычных тезаурусов

[8].

c) Стандарт ГОСТ 7.25-2001

ГОСТ 7.25-2001 – Тезаурус информационно-поисковый одноязычный.

Этот стандарт устанавливает правила разработки, структуру, состав и форму

представления информационных тезаурусов, ориентированных на использование лексики

русского языка и разрабатываемых в рамках автоматизированных информационных систем

и сетей научно-технической информации [9]. ГОСТ 7.25-2001 также, как и ANI/NISO

Z39.19-1993, расширяет и уточняет стандарт ISO 2788-1986 для одноязычных тезаурусов.

В этом стандарте определены два типа терминов: Дескриптор и Аскриптор.

d) Стандарт ГОСТ 7.24-90

Этот стандарт распространяется на многоязычные информационно-поисковые

тезаурусы и устанавливает состав, структуру и основные требования к построению

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

поисковых системах.

Многоязычные информационно-поисковые тезаурусы – согласованная

совокупность одноязычных информационно-поисковых тезаурусов, содержащая

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

поисковых тезаурусов, необходимые и достаточные для межъязыкового обмена, и

включающая средства для указания их эквивалентности.

e) ГОСТ Р 52573-2006

Национальный стандарт Российской Федерации “Географическая информация.

Метаданные”. Стандарт предназначен для специалистов в области информационных

технологий, разработчиков геоинформационных систем, баз и банков пространственных

данных, а также прикладных информационных систем различного назначения. Стандарт

разработан в соответствии с правилами создания профилей, указанными в стандарте ISO

19115 [8].

Есть сведения о документе источнике, но они привязаны к объекту в целом, а не к

данным о его координатах и наименовании. Сведения о связях между объектами

отсутствуют в данной схеме.

12

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

Проанализировав существующие решения, мы приходим к выводу что схемы

тезауруса с необходимой нам функциональностью нет. Но есть достаточно близкие схемы,

которые можно изменить для реализации желаемой функциональности. Наиболее

подходящей схемой является схема тезауруса географических наименований Getty [5].

2.1 Основные требования к тезаурусу

Сформулируем список требований к тезаурусу, подходящему для использования в

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

тезаурусами.

Структура тезауруса должна позволять эффективно решать следующие задачи:

a) Прямое и обратное геокодирование;

b) Ретроспективное прямое и обратное геокодирование;

c) Содержать внутренние связи:

1) По географическим объектам,

2) По временным характеристикам,

3) По документам;

d) Тезаурус должен быть представлен в схеме, максимально приближенной к

какой-либо стандартной.

2.2 Сценарии использования тезауруса

Для упрощения задачи проектирования схемы тезауруса рассмотрим основные

сценарии использования тезауруса географических наименований.

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

геометрического примитива объекта по имени этого объекта и запрос всех имен объектов

по заданных координатам привязанному геометрическому примитиву. Обычно это

называется прямым и обратным геокодированием. Для электронных библиотек, которые

потенциально могут содержать ретроспективную информацию, отличительной

особенностью становится необходимость указания времени, для которого

соответствующее геокодирование будет актуальным. При этом отсутствие задания момента

времени может служить указанием на использование текущего момента времени в качестве

параметра запроса.

Существенным моментом прямого геокодирования, является тот факт, что заданные

в запросе имя и время могут быть взаимно противоречивы. Например, запрос на

координаты объекта (Новосибирск, 19200520) должен возвращать ответ (Новониколаевск,

{координаты геометрического примитива}, 19200520). Запросы обратного геокодирования

13

в этом смысле более просты, т.к. задаваемые в запросе координаты не связаны с

действующей топонимикой.

Заметим, что правильно организованный тезаурус географических названий может

служить основой и для получения и другой информации. В частности,

a) Информации о документах, связанных с конкретным географическим объектом;

b) Информации о времени актуальности названий объектов;

c) Информации о времени актуальности координат объектов;

d) А также о временных характеристиках производных параметров.

Следует также заметить, что любой тезаурус является лишь дополнительной базой

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

информационным массивам. Ретроспективный тезаурус географических названий может

быть задействован при обработке запросов, включающих ретроспективные географические

названия.

Можно выделить три вида условий в запросе к тезаурусу:

a) По имени;

b) По координатам;

c) По времени.

Данные условия могут комбинироваться друг с другом.

2.3 Онтология Тезауруса

На основании приведенных выше данных, была построена онтология тезауруса,

отвечающего приведенным требованиям, представленной на рисунке 1.

14

Рисунок 1 Онтология Тезауруса

Для интеграции с существующими информационными системами и обеспечения

интероперабельности необходимо зафиксировать профиль доступа к тезаурусу. При этом

профиль должен определять:

a) Схему данных;

b) Структуру записи и наборы элементов;

c) Обязательные и дополнительные индексы (точки доступа);

d) Синтаксис поисковых запросов и поисковые атрибуты;

e) Форматы представления данных;

f) Протоколы доступа к ресурсу.

Протоколы доступа

Для обеспечения интероперабельности доступ к RGeoThes должен обеспечиваться

по протоколам

a) Z39.50

b) HTTP/XML/SOAP/SRW

c) HTTP/SRU

Каждый из указанных способов доступа имеет свои специфические особенности,

которые должны быть определены общим профилем.

Форматы представления данных

В качестве основного обязательного формата представления записи RGeoThes для

всех способов доступа является формат XML. Дополнительными необязательным

Географический объект

Геометрическое представлениеТекстовое представление

Документ

Точка

Многоугольник

Композиция многоугольников

Язык

Тип

Описание Дата вступления в силу

Содержит атрибут Содержит атрибут

Является

Является

Является

Содержит Содержит

Содержит атрибут

Содержит атрибут

Определяет дату начала действия

Определяет дату окончания действия

Определяет дату начала действия

Определяет дату окончания действия

Административная связь

Ссылается на родительский объект

Ссылается на дочерний объект

Определяет дату начала действия связи

Определяет дату окончания действия связи

15

форматом является HTML. Для доступа по Z39.50 также обязательным форматом является

GRS-1. В качестве дополнительных (необязательных) форматов могут использоваться

RUSMARC, MARC21 и др.

2.4 Схема данных Тезауруса

Схема данных определяется в терминах XML (XSD) и должна соответствовать

онтологии, схематично представленной на рисунке 1.

Для хранения данных о том, как географические объекты соотносятся друг с другом

будем использовать иерархическую структуру записей тезауруса, т. е. каждая запись (кроме

корневой) содержит одного родителя (географический объект, внутри которого расположен

указанный объект) [4].

Каждая запись содержит первичное название, являющееся основным названием

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

дополнительных названий объекта.

Так как необходимо будет ссылаться на элементы тезауруса из других систем,

каждая запись должна иметь уникальный квалификатор. Наиболее подходящим для данной

задачи представляется использование UUID идентификатора.

Данный квалификатор уникально идентифицирует запись тезауруса о

географическом объекте и может быть использован при внедрении географической

информации в информационную систему.

Рассмотрим подробнее элемент, представляющий наименование географического

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

языка, и ссылки на нормативные документы, вводящие в действие данное название и

отменяющее его. Привязка нормативных документов к наименованиям географических

объектов обеспечивает ретроспективную составляющую названий.

Запись, представляющая документ содержит поля c описанием документа, его URI,

датой создания документа и датой вступления изменений в силу.

Так как координаты географических объектов также изменяются с течением

времени, в элементы, представляющие географические координаты объектов, также

добавлены ретроспективные составляющие в виде ссылок на нормативные документы.

16

3. Разработка программных средств для работ с ретроспективным

географическим тезаурусом

3.1 Цели разработки программных средств

Связи с возрастающей потребностью общества в информационном обеспечении, в

том числе и связанным с географическим аспектом информации, все большую актуальность

приобретают разработки, направленные на интеграцию «негеографических»

информационных систем с информационными системами, изначально ориентированными

на обработку географической информации (ГИС). Добавление географического аспекта к

информации, хранящейся в таких системах, позволяет существенно повысить

функциональность навигационных, поисковых и сервисов визуализации этих систем.

Например, позволяет находить информацию, которая относится к конкретному

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

географические метаданные уже есть, так как такие системы являются

специализированными. Но, в то же время, интеграция географических метаданных в другие

системы позволит существенно упростить их взаимодействие с системами мониторинга. В

частности, интеграция таких данных в электронные библиотеки, содержащие научные

труды, расширит границы информационной обеспеченности исследований в области

мониторинга окружающей среды.

Таким образом, разработка программных средств, обеспечивающие обработку

географического аспекта информации в «негеографических» информационных системах

общего назначения, является актуальной и перспективной.

Одной из целью является создание шаблонов конвертирования данных. На основе

расширяемого языка разметки XML с помощью XSLT трансформации. Извлеченные

данные о географических наименовании из различных источников имеют в XML формат.

И схемы источников разные. Тут к нам приходит в помощь XSLT. С помощью которого мы

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

Также основной целью является создание веб-интерфейса для редактирования и

добавления новых записей о географических наименовании, получаемых из различных

источников, на основе Java EE.

3.2 Выбор инструментов реализации

3.2.1. XML (eXtensible Markup Language) - расширяемый язык разметки

Большинство извлекаемых данных для заполнения тезауруса имеют формат XML. И

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

XML является отраслевым стандартом системно-независимого способа

представления данных. Подобно HTML (HyperText Markup Language) XML заключает

17

данные в теги, но между этими двумя языками разметки есть существенные различия. Во-

первых, XML-теги связаны со значением заключенного в них текста, в то время как HTML-

теги указывают лишь способ отображения текста. Поскольку XML-теги указывают на

структуру и содержимое данных, они дают возможность производить такие операции, как

архивирование и поиск.

Вторым основным отличием между XML и HTML является расширяемость XML.

При помощи XML вы можете определять свои собственные теги для описания содержимого

конкретного типа документа. При использовании HTML вы ограничены только теми

тегами, которые определены в спецификации HTML. Вторым аспектом расширяемости

XML является возможность создания файла, называемого схемой и описывающего

структуру конкретного типа XML-документа.

Технология XML – простой, стандартный способ взаимообмена

структурированными текстовыми данными между компьютерными программами. Рост ее

популярности связан отчасти с тем, что для прочтения XML-документов или для их

создания достаточно простого текстового редактора, но это никак не умаляет основного

назначения XML – служить средством связи между программными системами. В этом

плане XML характеризуется следующими преимуществами:

– отделение данных от их представления. Это возможность отделять информацию

от деталей способа ее отображения на конкретном устройстве.

– передача данных между приложениями. Возможность передавать информацию

между платформами и программами, не тратя при этом средства на интеграцию специально

заказываемого программного обеспечения.

– независимость от платформы. Возможность однозначно интерпретировать XML-

данные на разных программных и аппаратных платформах.

XSL-трансформация.

Для преобразования XML-данных чаще всего используется технология XSLT

(eXtensible Stylesheet Language for Transformations, расширяемый язык стилей для

преобразований) [15].

XSLT представляет собой мощную прикладную XML-технологию, которая может

применяться везде, где есть два документа разной структуры. XSLT предоставляет

высокоуровневые средства для манипуляции данными, которые хранятся в виде XML.

3.2.2. Java Platform Enterprise Edition

Java 2 Enterprise Edition или J2EE — набор спецификаций и соответствующей

документации для языка Java, описывающей архитектуру серверной платформы для задач

средних и крупных предприятий. Данная платформа является широко распространенной в

18

мире в настоящее время и доказала свою эффективность при решения широкого диапазона

различных задач. Программирование на Java предполагает использование объектно-

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

встроенных классов, а в языке существует широкий набор различных синтаксических

конструкций, что в совокупности позволяет эффективно реализовать решение

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

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

технология является кроссплатформенной. Данная среда распространяется свободно.

3.2.3. Google Web Toolkit свободный Java-фреймворк

Google Web Toolkit (GWT) -свободный Java-фреймворк, который позволяет

создавать Ajax-приложения на основе Java. Выпускается под лицензией Apache версии 2.0.

GWT делает акцент на повторное использование и кросс‐браузерную совместимость [16].

Основные компоненты GWT:

Компилятор GWT Java-to-JavaScript - переводит Java код в JavaScript.

GWT Hosted Web Browser - позволяет запускать GWT приложения в режиме hosted

(приложения запускаются как Java код в JVM без компиляции в JavaScript).

JRE emulation library - реализация часто используемых стандартных Java классов на

JavaScript.

GWT Web UI class library - множество пользовательских интерфейсов и классов для

создания виджетов.

Используя GWT, разработчики могут быстро писать и отлаживать AJAX

приложения на языке Java, используя инструментарий отладки Java. Компилятор GWT

переведёт код Java приложения в соответствующий браузеру JavaScript и HTML.

Утилита командной строки applicationCreator, поставляемая вместе с GWT,

автоматически создает все файлы, необходимые для нового GWT-проекта. Она также

позволяет создавать файлы проекта Eclipse.

GWT также позволяет разработчикам эффективно тестировать и отлаживать

приложения без необходимости преобразования приложений в JavaScript и развертывания

их на веб-сервере [18]. GWT позволяет приложениям быть запущена в так называемом

"Хостинг режиме"(Hosted Mode). В "Хостинг режиме" JVM исполняет код вашего GWT

приложения в виде Java байт-кода внутри встроенного браузера. Запуск GWT приложений

в "Хостинг режиме" делает отладку вашего GWT приложения очень простой. После того,

как Вы проверили ваши GWT приложений в "Хостинг режиме", вы можете скомпилировать

исходный код Java в JavaScript и развернуть ваше приложение. GWT приложения, которые

были развернуты, называются запущенными в "Веб-режиме"(Web Mode).

19

В конце можно развернуть эти JavaScript и HTML на ваших веб-серверах, так что

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

классы серверной стороны могут быть развернуты на Tomcat или на любом сервлет-

контейнере по вашему выбору.

3.2.4. Hibernate (библиотека)

Hibernate — библиотека для языка программирования Java, предназначенная для

решения задач объектно-реляционного отображения (object-relational mapping — ORM).

Она представляет собой свободное программное обеспечение с открытым исходным кодом

(open source), распространяемое на условиях GNU Lesser General Public License. Данная

библиотека предоставляет лёгкий в использовании каркас (фреймворк) для отображения

объектно-ориентированной модели данных в традиционные реляционные базы данных.

Основные возможности

Целью Hibernate является освобождение разработчика от значительного объёма

сравнительно низкоуровневого программирования по обеспечению хранения объектов в

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

проектирования системы классов и таблиц, так и для работы с уже существующей базой

данных.

Hibernate не только решает задачу связи классов Java с таблицами базы данных (и

типов данных Java с типами данных SQL), но также предоставляет средства для

автоматической генерации и обновления набора таблиц, построения запросов и обработки

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

тратится на ручное написание SQL- и JDBC-кода. Hibernate автоматизирует генерацию

SQL-запросов и освобождает разработчика от ручной обработки результирующего набора

данных и преобразования объектов, максимально облегчая перенос (портирование)

приложения на любые базы данных SQL.

Hibernate обеспечивает прозрачную поддержку сохранности данных (persistence) для

«POJO» (то есть для стандартных Java-объектов), единственное строгое требование для

сохраняемого класса — наличие конструктора по умолчанию (без параметров).

Mapping (сопоставление, проецирование) Java-классов с таблицами БД

осуществляется с помощью конфигурационных XML файлов или Java-аннотаций. При

использовании файла XML Hibernate может генерировать скелет исходного кода для

классов длительного хранения (persistent). В этом нет необходимости, если используется

аннотация. Hibernate может использовать файл XML или аннотации для поддержки схемы

базы данных.

20

Обеспечиваются возможности по организации отношения между классами «один-

ко-многим» и «многие-ко-многим». В дополнение к управлению связями между объектами,

Hibernate также может управлять рефлексивными отношениями, где объект имеет связь

«один-ко-многим» с другими экземплярами своего собственного типа данных.

3.2.5. Jetty сервер приложении

Jetty - свободный контейнер сервлетов, написанный полностью на Java. Может

использоваться как HTTP-сервер или в паре со специализированным HTTP-сервером (к

примеру, с Apache HTTP Server) [19].

С ним легко разрабатывать как маленькие веб-сайты, так и большие веб-

приложения. Его преимущество перед другими подобными изделиями типа Apache или

Nginx — простота. Если, например, для запуска Apache нужно иметь подходящий под

операционную систему исполняемый файл, два десятка конфигурационных файлов и что-

то еще, то для Jetty нужна только Java.

Сервлет является Java-интерфейсом, реализация которого расширяет

функциональные возможности сервера. Сервлет взаимодействует с клиентами посредством

принципа запрос-ответ.

Хотя сервлеты могут обслуживать любые запросы, они обычно используются для

расширения веб-серверов. Для таких приложений технология Java Servlet определяет

HTTP-специфичные сервлет классы.

Пакеты javax.servlet и javax.servlet.http обеспечивают интерфейсы и классы для

создания сервлетов.

Клиент, которым обычно является веб-браузер, передаёт веб-серверу запросы на

получение ресурсов, обозначенных URL-адресами. Ресурсы — это HTML-страницы,

изображения, файлы, медиа-потоки или другие данные, которые необходимы клиенту. В

ответ веб-сервер передаёт клиенту запрошенные данные. Этот обмен происходит по

протоколу HTTP.

Веб-серверы могут иметь различные дополнительные функции, например:

a) Автоматизация работы веб страниц;

b) Ведение журнала обращений пользователей к ресурсам;

c) Аутентификация и авторизация пользователей;

d) Поддержка динамически генерируемых страниц;

e) Поддержка HTTPS для защищённых соединений с клиентами.

Часто на компьютере вместе с веб-сервером устанавливается также и почтовый

сервер.

21

Кратко о контейнере сервлетов, это программа, представляющая собой сервер,

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

в соответствии с правилами, определёнными в спецификациях. Может работать как

полноценный самостоятельный веб-сервер, быть поставщиком страниц для другого веб-

сервера, например Apache, или интегрироваться в Java EE сервер приложений.

Обеспечивает обмен данными между сервлетом и клиентами, берёт на себя выполнение

таких функций, как создание программной среды для функционирующего сервлета,

идентификацию и авторизацию клиентов, организацию сессии для каждого из них.

3.3 Архитектура системы

Архитектура системы состоит из шаблона XML который содержит географические

наименования объектов. Состоит из шаблона XSL необходимого для преобразования XML

файлов в единый формат. Также состоит из модуль Upload разработанного на Java. В задачу

которого входит получения список имеющихся XLS шаблонов, и отправку файла сервлету

FileUpload. Архитектура состоит из сервлета FileUpload и из модуля Edit. В задачи, которых

входит загрузка и преобразование извлеченных данных и редактирование записей.

Архитектура системы представленной на рисунке 2.

Рисунок 2. Архитектура системы

3.4 Программная реализация

Обеспечены следующие возможности:

a) Возможность преобразования данных из Яндекс карт с помощью XSL шаблона,

по следующей схеме:

1) featureMember - record

2) Text - name/name

22

3) CountryNameCode - name/language

4) Kind - name/type

5) Point/post - locations/point/latitude, locations/point/latitude

b) Возможность выбора типа данных при загрузке (данные карт Гугла или Яндекс),

использующих соответствующий шаблон преобразования, представленного на рисунке 3;

Рисунок 3 Страница загрузки данных

c) Возможность редактирования с помощью редактора следующих полей

полученных в результате преобразования данных, представленного на рисунке 4, 6:

1) Запись о географическом объекте:

Название

Тип

Язык

Широта/Долгота

Документ начала действия

Документ окончания действия

2) Нормативный Документ:

URI

Описание

Дата

Дата создания

d) Возможность записи отредактированных данных в базу данных заданного

формата базы.

23

Рисунок 4 Страница добавления нормативных документов

Принцип работы приложения в следующем:

Загружается модуль Upload (представлено в Приложении Г). Получает список

имеющихся XLS шаблонов через RPC. После нажатия на кнопку "Загрузить", отправляет

файл сервлету FileUpload. Сервлет преобразует данные и читает полученный XML в

объекты с помощью JAXB [16]. Если все хорошо, и не произошли ошибки, объекты

сохраняются в сессии текущего пользователя на сервере Получив сообщение о том, что все

хорошо, модуль Upload загружает модуль Edit (представлено в Приложении Г). Модуль Edit

получает объекты с сервера через RPC, предоставляет интерфейс для редактирования

данных и отправляет их через RPC на сервер при нажатии на кнопку "Импорт". На сервере

объекты записываются в базу при помощи Hibernate.

Работа модуля Upload заключается в создании интерфейса со стандартной mutlipart

веб-формой (<form/>), содержащей список полученных через RPC запрос с сервера XSL

шаблонов. Содержимое формы отправляется на сервлету FileUpload с помощью AJAX

запроса, сервлет возвращает JSON со статусом обработки (OK, Error), если произошла

ошибка, выводится присланное в JSON сообщение об ошибке, если нет, осуществляется

переход (редирект) на страницу Edit.html, которая загружает модуль Edit.

PGGeometryTransformer: класс для преобразования данных из XML (полей latitude,

longitude) в точку (PGpoint из jdbc драйверов postgresql) для записи в базу.

HibernateFactory –класс для инициализации Hibernate и фабрика для создания

Hibernate-сессий. Классы записываются в базу с помощью метода session save.

Сервер postgresql работает по сети через TCP/IP. Для связи с сервером сервер

приложений создает DataSource (именно он определяется в файле jetty-web.xml) и hibernate

использует его автоматически через jndi (настройки hibernate прописаны в

hibernate.cfg.xml). Сохранение производится в процедуре

EditingServiceImpl.storeGeoObjects с использованием транзакции (в случае ошибок, никакие

24

данные не сохраняются), перед сохранением записям проставляется сгенерированный

UUID и данные (координаты) конвертируются для достижения соответствия с форматом

данных в базе.

25

4. База данных ретроспективного географического тезауруса

4.1 О программном продукте

В качестве основной СУБД, хранящей и обрабатывающей служебную и

пользовательскую информацию, выбрана PostgreSQL. Этот выбор продиктован хорошей

функциональностью и быстродействием этой системы, а также возможностью ее

функционирования на разных программно-аппаратных платформах. Немаловажным

аргументом в пользу этой системы явилось наличие в PostgreSQL механизмов обработки

географической информации, представленной в количественном виде на основе описания

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

4.2 Структура записей в базе тезауруса

При наличии соответствующих данных нормативная запись включает следующие

основные сведения:

a) Нормализованное наименование географического объекта, представленный на

рисунке 7;

b) Не принятые на текущий момент наименования географических объектов (иные

варианты названий, сокращенные названия);

c) Географические названия на других национальных языках субъектов РФ и РК, и

на иностранных языках в различных алфавитах;

d) Географические координаты; род географического объекта; административный

статус населенного пункта, представленной на рисунке 9;

e) Административно-территориальная привязка географического объекта

(наименование субъекта РФ, наименование административного района);

f) Территориальное типовое деление;

g) Источники данных и другие примечания.

Структура записи обеспечивает учет смысловых связей между географическими

названиями. Например, для конкретных регионов можно получить на экране входящие в

него географические объекты, как показано на рисунке 8.

Нормализованному наименованию географического объекта присваивается

неповторяющееся поле qualificator нормативной записи.

4.3 Реляционная схема базы данных тезауруса

Используя реляционную СУБД PostgreSQL в качестве хранилища данных, и

построили реляционную схему данных.

Основной в данной схеме является таблица «Запись тезауруса» (далее будем ее

упоминать как «главная таблица»), в которой находится список квалификаторов записей

тезауруса. Схема представлена на рисунке 5. Строка из данной таблицы может содержать

26

ссылку на предыдущий вариант записи и на родительскую запись. Связи между записями

тезауруса содержатся в таблице «Связь между записями». Каждая связь содержит

квалификаторы двух записей тезауруса, которые она, соответственно, связывает. Также

связь характеризуется двумя документами (что представлено в виде внешних ключей).

Один из документов - «Начальный документ» - определяет документ, в котором

зафиксировано появление связи. Второй – «Конечный документ» - который может быть не

указан, определяет документ, в котором зафиксировано исчезновение связи.

Рисунок 5 Реляционная схема данных тезауруса

В таблице «Имя объекта» задаются наименования географических объектов,

содержащихся в тезаурусе. Каждая из записей главной таблицы может быть связана с

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

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

типом объекта и языком. Под типом объекта понимается, например, тип населенного

пункта. Каждая запись таблицы «Имя объекта» содержит идентификаторы двух документов

– начального и конечного. «Начальный документ» определяет документ, в котором

зафиксировано присвоение данного имени географическому объекту. «Конечный

документ» определяет документ, в котором зафиксировано окончание срока действия

данного имени.

27

Таблица «Местоположение объекта» содержит данные о координатах

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

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

«Местоположение объекта» может быть связана только с одной строкой из главной

таблицы. Каждая запись таблицы «Местоположение объекта» содержит идентификаторы

двух документов – начального и конечного. «Начальный документ» определяет документ,

в котором зафиксировано присвоение данного местоположения географическому объекту.

«Конечный документ» определяет документ, в котором зафиксировано окончание срока

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

содержит поле «тип местоположения», содержащее идентификатор типа местоположения

объекта. Таким типом может быть: точка, прямоугольник, многоугольник, линия, регион и

прочие. Благодаря использованию отображения «Одна иерархия – одна таблица» для

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

местоположения в уже работающую схему. Для хранения координатных данных

используются поля «Точка», «Прямоугольник», «Многоугольник», «Линия», «Регион» с

типами данных point_type, rectangle_type, polygon_type, line_type, circle_type

соответственно. Типы данных для этих полей являются композитными типами,

содержащими всю координатную информацию характерную для представления. Например,

тип данных rectangle_type, соответствующий прямоугольной области на поверхности

Земли, содержит поле rect встроенного типа box. Данное разделение на типы для различных

видов географических объектов сделано в целях повышения гибкости схемы.

Таблица «Документ» содержит данные о документах, регистрирующих изменение

характеристик объектов с течением времени. Каждый документ содержит описание,

уникальный идентификатор ресурса (URI), дату создания и дату вступления в силу. Именно

датой вступления в силу документов определяются временные рамки существования той

или иной характеристики географического объекта.

4.4 Нормативные документы

При наполнения базы данных тезауруса о географических наименовании объектов

РК использовались следующие нормативные документы, как показано на рисунке 10:

a) Справочник административно-территориального деления Казахстана (1920 –

1936 гг.).

b) Сборник законов Каз.ССР и указов Президиума Верховного Совета Каз.ССР

1938-1957 гг.

c) Сборник законов и указов Президиума Верховного Совета Казахской ССР. (1960

– 1980 гг.).

28

d) Закон СССР от 15 января 1938 года «Об изменении и дополнении ст.ст. 22, 23,

26, 28, 29, 49, 77, 70, 78 и 83 Конституции (Основного Закона) СССР».

e) Справочник по истории административно - территориального устройства

Карагандинской области (29 июля 1936 г. - 1 января 2006 г.).

f) Справочник по административно-территориальное делению Города Алма-Ата

(12 сентября 1936 г. - 17 октября 1980 г.).

g) Справочник по административно-территориальное делению Города Астана (6

мая 1998 г. - 5 августа 2008 г.)

h) Справочник по административно-территориальному устройству Восточного

Казахстана (11 декабря 1920 г.- 29 июня 2002 г).

i) Очерк по Территориально-административному устройству Республики

Казахстан (1932 – 1990 гг.) Андрей Грозин, Алматы 2003 г.

j) Указ Президиума ВС СССР от 14.10.1939 об образовании Семипалатинской,

Акмолинской и Джамбулской областей в составе Казахской ССР.

k) Хроника Павлодарской области 1938 г.

l) Государственный архив Восточно-Казахстанской области (ГАВКО), ф.767,

оп.13, д.131

m) Сборник Законов КССР и Указов ПВС КССР, 1938-1957,с.281

n) Указ Президиума Верховного Совета РСФСР от 3 ноября 1965 г.

o) Постановление Президиума Верховного Совета Республики Казахстан от 4 мая

1993 года № 2001 «Об упорядочении транскрибирования на русском и казахских

топонимов, наименовании и переименовании отдельных административно-

территориальных единиц Республики Казахстан.

p) Постановление Правительства Республики Казахстан от 23 мая 1997 г.

29

Заключение

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

с ретроспективными географическими тезаурусами на основе международных стандартов,

а так же создание пользовательского интерфейса для редактирования и добавления новых

данных.

В рамках данной работы были решены следующие задачи:

a) Изучение предметной области работы, а также функциональных возможностей,

архитектуры и особенностей реализации ретроспективных географических тезаурусов.

b) Выяснение и формализация функциональных требований к создаваемому

программному обеспечению;

c) Разработка архитектуры;

d) Анализ доступных средств реализации требуемой функциональности, а также

накопленного опыта разработки программного обеспечения для данной предметной

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

e) Разработка и реализация удобного для пользователя интерфейса для

редактирования данных о наименовании географических объектов.

f) Приведен вариант реляционной схемы для хранения данных тезауруса. Схема в

настоящее время используется для хранения данных, собираемых в тезаурус в рамках

данной работы.

g) Создана специализированная база данных по Новосибирской области и

Республике Казахстан.

Таким образом, поставленные цели были достигнуты.

30

Литература

1. Жижимов О.Л., Мазов Н.А. География и стандарты метаданных для электронных

библиотек: содержание, применение, проблемы [Электронный ресурс] // Электронные

библиотеки, - Режим доступа к журн.:

http://www.elbib.ru/index.phtml?page=elbib/rus/journal/2009/part1/ZM, свободный.

2. Жижимов О. Л., Мазов Л. А. Проблемы географической привязки цифровых объектов

в электронных библиотеках. // Электронные библиотеки: перспективные методы и

технологии, электронные коллекции. Труды XII Всероссийской научной конференции

RCDL'2010; Казань, Россия, 2010 г.

3. Жижимов О. Л., Мазов Л. А. Использование географических координат при

информационном поиске НТИ в библиографических базах данных. Новосибирск: ОИГГМ

СО РАН; ИВТ СО РАН, 2004. 361 с.

4. Скачков Д.М., Жижимов О.Л. О профиле доступа к данным тезауруса для

ретроспективного геокодирования и географического поиска в электронных библиотеках

// Восемнадцатая международная Конференция «Крым 2011», Судак, 4–12 июня 2011 г. -

Режим доступа к журн.: http://www.gpntb.ru/win/inter-events/crimea2011/disk/059.pdf,

свободный.

5. Скачков Д.М., Жижимов О.Л. Об использовании ретроспективного геокодирования

для географического поиска в электронных библиотеках // Труды Тринадцатой

Всероссийской научной конференции «Электронные библиотеки: перспективные методы

и технологии, электронные коллекции» (RCDL’2011). – Воронеж, 19-22 октября 2011 г. С.

30-37.

6. Соловьев В.Д., Добров Б.В., Иванов В.В., Лукашевич Н.В. Онтологии и тезаурусы.

Учебное пособие. // Казань, Москва, 2006. с. 75-90.

7. Лаврёнова О.А. Многоязычный доступ к данным на основе тезауруса географических

названий // Сборник тезисов постерных докладов 9-ой Всероссийской научной

конференции «Электронные библиотеки: перспективные методы и технологии,

электронные коллекции» - RCDL’2007 (Переславль-Залесский, Россия, 15-18 октября 2007

г), Переславль-Залесский: изд-во "Университет города Переславля", 2007. - с.57-62 -

Режим доступа к журн.: http://rcdl.ru/doc/2007/paper_56_v1.pdf, свободный.

8. ISO 5964:1985. Guidelines for the establishment and development of multilingual thesauri.

Режим доступа к ресурсу:

http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?ics1=01&ics2=140

&ics3=20&csnumber=12159, свободный.

31

9. ГОСТ Р 7.24-2007. Тезаурус Информационно-поисковый многоязычный. Состав,

структура и основные требования к построению. // Москва. Стандартинформ, 2006. с.47-

52.

10. Геокодирование - Службы API Карт Google. - Режим доступа к ресурсу:

http://code.google.com/intl/ru/apis/maps/documentation/geocoding/, свободный.

11. Поиск по карте - Яндекс. Карты. - http://api.yandex.ru/maps/geocoder/

12. Getty Thesaurus of Geographic Names® Online. - Режим доступа к ресурсу:

http://www.getty.edu/research/tools/vocabularies/tgn/index.html, свободный.

13. Тезаурус РГБ. - Режим доступа к ресурсу:

http://aleph.rsl.ru/F/?func=file&file_name=find-b&local_base=tst11, свободный.

14. Электронный учебник по практике XML - Режим доступа к ресурсу:

http://www.w3schools.com/xml/default.asp, свободный.

15. Электронный учебник по практике HTML- Режим доступа к ресурсу:

http://htmlbook.ru/html, свободный.

16. JAXB Электронный учебник - Режим доступа к ресурсу: https://jaxb.java.net/tutorial/,

свободный.

17. Электронный учебник Практика XSLT - Режим доступа к ресурсу:

http://www.musuk.info/blogpost/xslt#xml-to-html, свободный.

18. Документация Google Web Toolkit - Режим доступа к ресурсу:

https://developers.google.com/web-toolkit/?hl=ru, свободный.

19. Документация Google плагина для Eclipse - Режим доступа к ресурсу:

https://developers.google.com/eclipse/, свободный.

20. Электронный учебник Введение в GWT - Режим доступа к ресурсу:

http://www.quizful.net/post/gwt-tutorial-introduction, свободный.

21. Документация Jetty - Режим доступа к ресурсу:

http://www.eclipse.org/jetty/documentation/current/, свободный.

32

Приложение А

(обязательное)

Разработанный веб-интерфейс для редактирования и добавления записей в

ретроспективный географический тезаурус.

Рисунок 6. Веб-интерфейс для редактирования и добавления записей

33

Приложение Б

(обязательное)

База данных о географических объектах Республики Казахстан

Рисунок 7. Страница наименовании географических объектов

Рисунок 8. Страница связей между объектами

34

Рисунок 9. Страница координат объекта

Рисунок 10. Страница нормативных документов объекта

35

Приложение В

(обязательное)

Шаблоны преобразовании данных

Пример преобразованого кода на XML из службы геокодирования Яндекс:

<?xml version="1.0" encoding="UTF-8"?>

<records xmls:addr="urn:oasis:names:tc:ciq:xsd:schema:xAL:2.0"

xmlns:gc="http://maps.yandex.ru/geocoder/1.x" xmlns:gml="http://www.opengis.net/gml"

xmlns:ym="http://maps.yandex.ru/ymaps/1.x">

<record>

<names>

<name>Россия, Новосибирская область, Новосибирск</name>

<type>местность</type>

<language>RU-ru</language>

</names>

<locations>

<point>

<latitude>55.028739</latitude>

<longitude>82.906928</longitude>

</point>

</locations>

</record>

<record>

<names>

<name>Россия, Новосибирская область, городской округ Новосибирск</name>

<type>область</type>

<language>RU-ru</language>

</names>

<locations>

<point>

<latitude>55.024259</latitude>

<longitude>82.946445</longitude>

</point>

</locations>

</record>

<record>

36

<names>

<name>Россия, Новосибирская область, вокзал Новосибирск-Восточный</name>

<type>железные дороги</type>

<language>RU-ru</language>

</names>

<locations>

<point>

<latitude>55.067499</latitude>

<longitude>82.974544</longitude>

</point>

</locations>

</record>

<record>

<names>

<name>Россия, Новосибирская область, вокзал Новосибирск-Южный</name>

<type>железные дороги</type>

<language>RU-ru</language>

</names>

<locations>

<point>

<latitude>55.004385</latitude>

<longitude>82.951871</longitude>

</point>

</locations>

</record>

<record>

<names>

<name>Россия, Новосибирская область, вокзал Новосибирск-Главный</name>

<type>железные дороги</type>

<language>RU-ru</language>

</names>

<locations>

<point>

<latitude>55.035550</latitude>

<longitude>82.894334</longitude>

37

</point>

</locations>

</record>

</records>

Пример кода на XSLT, используемого для преобразования входных XML из службы

геокодирования Яндекс по заданных схеме данных:

<?xml version="1.0" encoding="ISO-8859-1"?>

<xsl:stylesheet version="1.0"

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

xmlns:gml="http://www.opengis.net/gml"

xmlns:gm="http://maps.yandex.ru/gmaps/1.x"

xmlns:gc="http://maps.yandex.ru/geocoder/1.x"

xmlns:addr="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0">

<xsl:template match="/ym:ymaps/ym:GeoObjectCollection">

<records>

<xsl:apply-templates select="gml:featureMember"/0>

</records>

<xsl:template match=:"gml:featureMember">

<record>

<names>

<name><xsl:value-of

select="ym:GeoObject/gml:metaDataProperty/gc:GeocoderMetaData/gc:text"/></name>

<type><xsl:apply-templates

select="ym:GeoObject/gml:metaDataProperty/gc:GeocoderMetaData/gc:kind"/></type>

<language><xsl:apply-templates

select="ym:GeoObject/gml:metaDataProperty/gc:GeocoderMetaData/addr:AddressDetail/addr:C

ountry/addr:CountryName"/></language>

</names>

<locations>

<point>

<latitude>

<xsl:value-of select="substring-after(ym:GeoObject/gml:Point/gml:pos, ' ')"/>

</latitude>

<longitude>

<xsl:value-of select="substring-before(ym:GeoObject/gml:Point/gml:pos, ' ')"/></longitude>

38

</point>

</locations>

</record>

</xsl:template>

<xsl:template

match="ym:GeoObject/gml:metaDataProperty/gc:GeocoderMetaData/addr:AddressDetails/addr:

Country/addr:CountryName">

<xsl:choose>

<xsl:when test="@xml:lang = 'ru'">Ru-ru</xsl:when>

<xsl:otherwise><xsl:value-of select="@xml:lang"/></xsl:otherwise>

</xsl:choose>

</xsl:template>

<xsl:template match="ym:GeoObject/gml:metadataProperty/gc:GeocoderMetaData/gc:kind">

<xsl:choose>

<xsl:when test=". = 'province'">область</xsl:when>

<xsl:when test=". = 'locality'">населенный пункт</xsl:when>

<xsl:when test=". = 'district'">район</xsl:when>

<xsl:when test=". = 'area'">местность</xsl:when>

<xsl:when test=". = 'airport'">аэропорт</xsl:when>

<xsl:when test=". = 'hydro'">водный объект</xsl:when>

<xsl:when test=". = 'street'">улица</xsl:when>

<xsl:when test=". = 'railway'">железные дороги</xsl:when>

<xsl:when test=". = 'route'">дорога</xsl:when>

<xsl:when test=". = 'other'">другое</xsl:when>

<xsl:when test=". = 'cemetery'">кладбище</xsl:when>

<xsl:when test=". = 'vegetation'">лесонасаждения</xsl:when>

<xsl:otherwise><xsl:value-of select="."/></xsl:otherwise>

</xsl:choose>

</xsl:template>

</records>

</xsl:stylesheet>

39

Приложение Г

(обязательное)

Веб интерфейс редактирования географических данных.

Пример кода модуля Edit, используемого для создания интерфейса редактирования

данных:

package edu.ict.rgeothes.imp.client;

import java.util.Map;

import java.util.Map.Entry;

import com.google.gwt.core.client.EntryPoint;

import com.google.gwt.core.client.GWT;

import com.google.gwt.core.client.JsonUtils;

import com.google.gwt.user.client.Cookies;

import com.google.gwt.user.client.Window;

import com.google.gwt.user.client.rpc.AsyncCallback;

import com.google.gwt.user.client.ui.FormPanel;

import com.google.gwt.user.client.ui.FormPanel.SubmitCompleteHandler;

import com.google.gwt.user.client.ui.FormPanel.SubmitCompleteEvent;

import com.google.gwt.user.client.ui.FlexTable;

import com.google.gwt.user.client.ui.CaptionPanel;

import com.google.gwt.user.client.ui.HTML;

public class Upload implements EntryPoint {

RootPanel r = RootPanel.get();

protected HTML lblError;

@Override

public void onModuleLoad() {

UploadingServiceAsync uploadingService = (UploadingServiceAsync) GWT

.create(UploadingService.class);

VerticalPanel verticalPanel = new VerticalPanel();

r.add(verticalPanel, 0, 0);

verticalPanel.setWidth("100%");

Label lblTitle = new Label("ИМПОРТ ДАННЫХ ТЕЗАУРУСА РЕТРОСПЕКТИВНЫХ

ГЕОГРАФИЧЕСКИХ НАЗВАНИЙ");

lblTitle.setHorizontalAlignment(HasHorizontalAlignment.ALIGN_CENTER);

lblTitle.setStyleName("app-title");

verticalPanel.add(lblTitle);

40

HorizontalPanel horizontalPanel = new HorizontalPanel();

horizontalPanel.setHorizontalAlignment(HasHorizontalAlignment.ALIGN_CENTER);

verticalPanel.add(horizontalPanel);

horizontalPanel.setWidth("100%");

HorizontalPanel horizontalPanel_1 = new HorizontalPanel();

horizontalPanel.add(horizontalPanel_1);

final FormPanel formUpload = new FormPanel();

horizontalPanel_1.add(formUpload);

formUpload.setEncoding(FormPanel.ENCODING_MULTIPART);

formUpload.setAction("FileUpload");

formUpload.setMethod(FormPanel.METHOD_POST);

CaptionPanel captionPanel = new CaptionPanel("Загрузка данных");

formUpload.setWidget(captionPanel);

captionPanel.setSize("", "");

captionPanel.setStyleName("rounded");

FlexTable flexTable = new FlexTable();

captionPanel.setContentWidget(flexTable);

flexTable.setSize("5cm", "3cm");

flexTable.setCellSpacing(5);

flexTable.setCellPadding(5);

Label label = new Label("Файл данных:");

label.setStyleName("gwt-Label bold margin-top-7px");

flexTable.setWidget(0, 0, label);

label.setWidth("91px");

FileUpload fileUpload = new FileUpload();

fileUpload.setStyleName("gwt-FileUpload margin-top-5px");

fileUpload.setName("data-file");

flexTable.setWidget(0, 1, fileUpload);

Label label_1 = new Label("Тип данных:");

label_1.setStyleName("gwt-Label bold margin-top-7px");

flexTable.setWidget(1, 0, label_1);

label_1.setWidth("91px");

final ListBox cbxDataType = new ListBox();

cbxDataType.addItem("Без обработки");

cbxDataType.setName("data-type");

41

cbxDataType.setStyleName("gwt-ListBox margin-top-5px");

flexTable.setWidget(1, 1, cbxDataType);

Button button = new Button("Загрузить");

flexTable.setWidget(2, 1, button);

flexTable.getCellFormatter().setHorizontalAlignment(2, 1,

HasHorizontalAlignment.ALIGN_RIGHT);

flexTable.getCellFormatter().setHorizontalAlignment(1, 1,

HasHorizontalAlignment.ALIGN_LEFT);

flexTable.getCellFormatter().setHorizontalAlignment(0, 1,

HasHorizontalAlignment.ALIGN_LEFT);

button.addClickHandler(new ClickHandler(){

public void onClick(ClickEvent event){

formUpload.submit();

String data_type = cbxDataType.getValue(cbxDataType.getSelectedIndex());

Cookies.setCookie("data_type", data_type);}});

formUpload.addSubmitCompleteHandler(new SubmitCompleteHandler()}}

Пример кода модуля Edit, используемого для редактирования данных:

package edu.ict.rgeothes.imp.client;

import java.util.Date;

import java.util.List;

import com.google.gwt.cell.client.AbstractCell;

import com.google.gwt.core.client.EntryPoint;

import com.google.gwt.core.client.GWT;

import com.google.gwt.core.client.Scheduler;

import com.google.gwt.core.client.Scheduler.RepeatingCommand;

import com.google.gwt.event.dom.client.ClickEvent;

import com.google.gwt.event.dom.client.ClickHandler;

import com.google.gwt.event.logical.shared.ValueChangeEvent;

import com.google.gwt.event.logical.shared.ValueChangeHandler;

import com.google.gwt.i18n.client.DateTimeFormat;

import edu.ict.rgeothes.imp.shared.pojo.Document;

import edu.ict.rgeothes.imp.shared.pojo.Name;

import edu.ict.rgeothes.imp.shared.pojo.Point;

import edu.ict.rgeothes.imp.shared.pojo.Record;

42

import edu.ict.rgeothes.imp.shared.pojo.Records;

public class Edit implements EntryPoint{

private final String CHANGES_LOST = "Внесенные изменения потеряны. Используйте

кнопку " +

"\"Применить\" для сохранения изменений.";

private int idSeq = 0;

private Records objects;

private RootPanel r = RootPanel.get();

private CellList<Record> clObjects;

private ListDataProvider<Record> dpObjects;

private SingleSelectionModel<Record> smObjects;

private Record selectedObject;

private boolean cancelSelection;

Record getSelectedObject(){

return selectedObject;}

private CellList<Name> clNames;

private ListDataProvider<Name> dpNames;

private SingleSelectionModel<Name> smNames;

private Name selectedName;

private CellList<Point> clLocations;

private ListDataProvider<Point> dpLocations;

private SingleSelectionModel<Point> smLocations;

private Point selectedLocation;

private CellList<Document> clDocuments;

private ListDataProvider<Document> dpDocuments;

private SingleSelectionModel<Document> smDocuments;

private Document selectedDocument;

private enum RefsTo{

NAME,

LOCATION}

private class DocAnchor extends Anchor{

public static final String EMPTY_CAPTION = "<не указан>";

private Document doc;

private RefsTo ref;

public DocAnchor(RefsTo ref){

43

super(EMPTY_CAPTION);

this.ref = ref;

addClickHandler(new ClickHandler() {

public void onClick(ClickEvent event) {

final PopupPanel popupPanel = new PopupPanel(true, true);

MenuBar popupMenuBar = new MenuBar(true);

popupMenuBar.addItem(EMPTY_CAPTION, false, new Command() {

public void execute() {

popupPanel.hide();

setDoc(null, true);}});

if (selectedObject != null)

for (final Document doc : selectedObject.getDocs())

popupMenuBar.addItem(doc.getDescription(), false, new Command() {

public void execute() {

popupPanel.hide();

setDoc(doc, true);}});

popupPanel.add(popupMenuBar);

popupPanel.setStyleName("menu-border", true);

popupPanel.setPopupPosition(getAbsoluteLeft(), getAbsoluteTop() + getOffsetHeight());

popupPanel.show();}});}

public Document getDoc(){

return doc;}

public void setDoc(Document doc, boolean modify){

this.doc = doc;

if (doc == null)

setText(EMPTY_CAPTION);

else

setText(doc.getDescription());

if (modify){

selectedObject.setModified(true);

switch (DocAnchor.this.ref){

case NAME: selectedName.setModified(true); break;

case LOCATION: selectedLocation.setModified(true); break;}}}}

private void setNameData(Name name){

txtObjName.setText(name.getName());

44

txtObjType.setText(name.getType());

txtObjLang.setText(name.getLanguage());

lnkObjDocBegin.setDoc(name.getBeginDocument(), false);

lnkObjDocEnd.setDoc(name.getEndDocument(), false);}

private void applyNameData(Name name){

name.setName(txtObjName.getText());

name.setType(txtObjType.getText());

name.setLanguage(txtObjLang.getText());

name.setBeginDocument(lnkObjDocBegin.getDoc());

name.setEndDocument(lnkObjDocEnd.getDoc());

name.setModified(false);}

private void setLocationData(Point loc){

dbbLatitude.setValue(loc.getLatitude());

dbbLongitude.setValue(loc.getLongitude());

lnkLocDocBegin.setDoc(loc.getBeginDocument(), false);

lnkLocDocEnd.setDoc(loc.getEndDocument(), false);}