Специализированный редактор для исторических геоинформационных систем «Библиософ-ИГИС»: технологические и методические основы функционала

В статье речь пойдет об авторском варианте редактора исторических ГИС-проектов. Основной акцент сделан на описании того, каким образом решены задачи пространственно-временного анализа содержимого карты, о которых шла речь в одной из предыдущих статей автора ^[1]. Представленный редактор (рабочее название – Bibliosof-HGIS/Библиософ-ИГИС) нельзя считать полностью завершенным продуктом. Скорее, это концепция того, каким должен выглядеть специализированный сервис для создания исторически ориентированных геоинформационных систем.

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

Предыстория создания редактора по-своему необычна, так как его ядро восходит к сервису интерактивной публикации гидрогеологических и инженерно-геологических карт. Первый вариант этого сервиса был представлен на международном рабочем совещании «Состояние и перспективы развития Государственного геологического картографирования территории Российской Федерации и ее континентального шельфа масштаба 1:1 000 000 и 1:200 000» (5 апреля 2015 г.) ^[2]. Основные положения того, что из себя должен представлять проект по интерактивной публикации карты в ГИС-формате и как это может быть достигнуто, были сформулированы в статье «Технологии представления гидрогеологических и инженерно-геологических карт в интерактивном режиме» ^[3]. Благоприятное восприятие технологической составляющей проектируемого сервиса подвело к идее задействовать наработанный инструментарий для адаптации редактора под задачи исторического картографирования и исторических ГИС-проектов. Эта идея не была спонтанной, как может показаться, так как хронологически ориентированный подход оказался востребован в естественно-научном и прикладном картографировании: для гидрогеологических работ важен мониторинг состояния подземных вод, который невозможно реализовать стандартными средствами популярных ГИС-редакторов.

В дальнейшем сервис для интерактивной публикации и редактирования карт был задействован при создании системы гидрогеологической изученности, доклад о которой был сделан на IV научно-практической конференции «Актуальные вопросы геодезии и геоинформационных систем» в рамках Татарстанского нефтегазохимического форума (2-3 сентября, г. Казань) ^[4]. Уже через месяц были сделаны первые шаги на пути адаптации редактора под нужды исторически ориентированных проектов. Разработка первой версии серверной части была осуществлялась с октября по декабрь 2015 г. Параллельно создавалось ядро базы условных обозначений для исторических карт и некоторые тестовые проекты. В открытом доступе сервис был запущен в 29 января 2016 г., после чего началась работа над основным проектом по апробации функционала редактора – комплексной девятилистной картой по раннесредневековой Испании. К моменту завершения основной части карты она включала в себя обширный материал, построенный на основе нескольких сотен маркеров письменных источников. Несмотря на доказанную работоспособность редактора, в ходе создания карты были выявления новые направления по улучшению обработки хронологических данных. Так, вместо полистного, то есть дискретного подхода к хронологии было решено ввести хронологические атрибуты вместе со справочником событий, о функционале которых речь пойдет ниже. Все это было осуществлено в рамках второй версии редактора, разработка которой велась в мае-июле 2016 г. Впервые функциональные возможности и тестовые проекты сервиса были представлены 7 октября 2016 г. в ИА РАН Дмитрию Сергеевичу Коробову. Затем более обстоятельный доклад на тему редактора «Библиософ-ИГИС» был сделан на совещании Отдела теории и методики ИА РАН 10 ноября.

Более подробно возможности редактора были освещены в докладе «Перспективы моделирования исторических процессов и пространственно-исторического анализа на основе археологических источников» на III-й Международной конференции «Археология и геоинформатика» (24-26 мая 2017 г.) ^[5]. Одновременно развивалось и направление общеисторических ГИС-проектов. Так, проект по Испании послужил основной для создания карт к переводу текста «Истории Испании» Альфонсо X (автор перевода – Олег Валентинович Ауров).

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

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

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

Эталонная база условных обозначений для исторических карт(ЭБЗ). В ЭБЗ внесено около 300 условных знаков, сгруппированных по тематическим спискам. Эталонная база представляет собой не просто рекомендуемый справочник, она полностью ассоциирована с функционалом редактора карт. При создании нового слоя пользователь выбирает ту тему знаков, которая для него актуальна, после чего в форму интерфейса подгружается список конкретных объектов с соответствующими условными обозначениями. Например, при выборе тематического списка «Памятники материальной культуры, перед автором карты появятся обозначения городищ, селищ, стоянок, курганов и других объектов из этого списка. Таким образом необходимость всякий раз конструировать новый знак или заимствовать его из других проектов отсутствует. В том случае, если в эталонной базе не хватает того или иного знака, её можно пополнить. Каждое обозначение имеет свой уникальный псевдоним для идентификации, который заносится в параметры слоя, для которого используется данный знак.

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

Рис. 1. Фрагмент из эталонной базы условных обозначений.

Общая структура картографических ресурсов сервиса можно назвать традиционной для ГИС-редакторов:

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

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

Листы. Структурная единица карты, объединяет группы слоев по общей тематике или хронологии.

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

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

1 – топографическая основа I порядка;

2 – фактографическая основа I порядка;

3 – топографическая основа II порядка;

4 – фактографическая основа II

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

Поскольку все метрические и атрибутивные данные хранятся в общей базе данных, возникает проблема скорости считывания информации. Осуществление выборки из базы всякий раз, когда меняется содержимое проекта, приводит не только к увеличению нагрузки на сервер, но и существенно замедляет работы автора карты, который вынужден ждать новой отрисовки картографического материала. Конечно, это не касается проектов, которые оперируют с небольшим объемом информации, однако если количество объектов по отдельным слоям исчисляется сотнями и более, вопрос оптимизации считывания карты становится особенно актуальным, причем не только для авторов проекта, но и для пользователей. Для решения этой проблемы был добавлен менеджер кэширования проекта, в котором можно сделать выгрузку всей информации по отдельным блокам проекта: кэшируются атрибутивные таблицы, легенда карты; картографическое содержимое кэшируется по четырем частям: топографическая основа I и II порядков, фактография I и II порядков. В ходе кэширования осуществляется выборка всех записей из базы по текущей карте, затем на их основе формируется файл кэша, который подставляется в соответствующий блок проекта. В менеджере фиксируются даты кэширования, что позволяет проследить, когда были сделаны последние обновления по проекту в том или ином разделе карты. Ещё одно преимущество кэширования карты состоит в сохранности данных: если записи в базе по какой-либо причине были повреждены (подобные ситуации в клиент-серверной системе вполне вероятны) и бэкапы (резервные копии) не сохранились, файлы кэша могут послужить материалом для восстановления данных по проекту.

Объекты. Атрибуты объектов определяются автором карты. Обязательным атрибутом являются только атрибут id – идентификатор объекта.

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

Поскольку все данные по проектам хранятся в общей базе, возникает проблема скорости считывания информации. Осуществление выборки из таблиц всякий раз, когда меняется содержимое проекта, приводит не только к увеличению нагрузки на сервер, но и существенно замедляет работы автора карты, который вынужден ждать новой отрисовки картографического материала. Конечно, это не касается проектов, которые оперируют с небольшим объемом информации, однако если количество объектов по отдельным слоям исчисляется сотнями и более, вопрос оптимизации считывания карты становится особенно актуальным, причем не только для авторов проекта, но и для пользователей. Для решения этой проблемы был добавлен менеджер кэширования проекта, в котором можно сделать выгрузку всей информации по отдельным блокам проекта: кэшируются атрибутивные таблицы, легенда карты; картографическое содержимое кэшируется по четырем частям: топографическая основа I и II порядков, фактография I и II порядков. В ходе кэширования осуществляется выборка всех записей из базы по текущей карте, затем на их основе формируется файл кэша, который подставляется в соответствующий блок проекта. В менеджере фиксируются даты кэширования, что позволяет проследить, когда были сделаны последние обновления по проекту в том или ином разделе карты. Ещё одно преимущество кэширования карты состоит в сохранности данных: если записи в базе по какой-либо причине были повреждены (подобные ситуации в клиент-серверной системе вполне вероятны) и бэкапы (резервные копии) не сохранились, файлы кэша могут послужить материалом для восстановления данных по проекту.

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

Паспорт карты. Помимо вышеперечисленных параметров карты содержит описание полной структуры и статистику по всем слоям. Назначение паспорта – предоставление информации об информационной насыщенности карты и уровне её готовности.

Рис. 2. Фрагмент паспорта комплексной карты раннесредневековой Испании.

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

Атрибутивные таблицы могут быть связаны между собой и преобразованы в полноценную реляционную базу данных. С помощью связанных индексов автор проекта может создать иерархическую структуру объектов; к примеру, есть возможность ассоциировать населенные пункты с административными регионами. Часто есть необходимость задействовать некартографируемые, справочные слои, которые выполняют чисто служебные задачb, дополняя сведения о других объектах. Подобная система связанных слоев и таблиц была реализована в тестовом проекте «Археологическая изученность европейской части России». Целью проекта было создание сервиса по мониторингу хода археологического изучения. Основными объектами на карте были собственно объекты изучения и маркеры археологических экспедиций, однако в виду необходимости предоставить как можно более полную информацию о той или иной экспедиции в состав проекта было включено несколько вспомогательных справочников. Проследить взаимодействие между таблицами слоев можно на примере слоя «Экспедиции», к которому прилагались следующие атрибуты: название, начальная и конечные даты экспедиции, организация, руководитель, объект изучения, результаты. Поле «объект изучения» было связано через идентификаторы со слоями по различным археологическим памятникам. В свою очередь к последним прилагался справочник по типам объектов (городища, селища, отдельные артефакты, могильники, эпиграфические памятники и другие группы), причем присвоенный индекс того или иного типа определял внешний вид условного обозначения. Полям по руководителю экспедиции и организации соответствовали два некартографируемых справочника. Таким образом, при запросе информации о той или иной экспедиции, пользователь получает разветвленную структуру сведений, что было бы невозможно при использовании обычной автономной атрибутивной таблицы. Очевидны преимущества использования связанных таблиц и с точки зрения осуществления сложной выборки объектов. К примеру, в описанном проекте вместо того, чтобы прибегать к SQL-запросу на отбор экспедиций по той или иной организации, можно просто выделить её в соответствующем справочнике, после чего будут активированы все записи по экспедициям, связанные с выделенным объектом.

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

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

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

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

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

Рис. 4. Интерфейс опубликованной карты с активированной атрибутивной таблицей и информационным окном по объекту.

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