Иметь под рукой описание единого, согласованного со всеми участниками проекта шаблона или структуры геоданных – это очень полезная штука, упрощающая нашу рабочую жизнь. Только представьте: не надо искать администраторов баз данных, не надо никому писать или звонить и старательно изымать информацию, нужную именно вам именно сейчас. Все становится просто: зашел, увидел, выполнил задачу!
Как своевременно доносить до коллег информацию о структуре данных, ее текущем состоянии, изменениях и дополнениях?
Такой вопрос может возникать в ряде случаев:
● вы работаете в компании, где необходимо синхронизировать структуры геоданных между отделами, а постоянно пересылать эту информацию по почте не комильфо;
● у вас распределенная команда, и все работают в разных часовых поясах, что расширяет возможности проектов, но усложняет совместную коммуникацию;
● вам требуется создавать пустые частичные наборы геоданных для их наполнения в будущем в соответствии с общим шаблоном,
● в других случаях, когда нужна регулярная и частая коммуникация между участниками.
В таких ситуациях мы приходим к выводу: необходимо где-то хранить единый шаблон геоданных и/или его описание, а также предоставлять к нему удобный постоянный доступ.
Информация, которая может входить в состав описания шаблона геоданных:
● перечень слоев;
● тип/типы геометрии для каждого слоя;
● перечень атрибутов и их параметров;
● принятые справочники;
● используемые классификаторы;
● правила топологии;
● правила атрибутивной проверки;
● используемые на предприятии системы координат;
● принятые системы кодировки объектов;
● дополнительное описание к слою/атрибуту/объекту;
● краткая история изменений элемента;
● и другие элементы, важные для конкретного проекта.
Эта информация помогает нам быстро создавать необходимые для работы слои с нужными характеристиками, чтобы после фактического наполнения их геоданными они могли бы встроиться в последующую геообработку. А реализовывать геообработку могут совсем другие люди, поэтому здесь становится критически важно правильно совместить и синхронизировать используемые разными участниками структуры геоданных.
Давайте подумаем над возможными вариантами реализации описания шаблона. Мы представим некоторые из них, а вы сможете самостоятельно подумать, какие плюсы и минусы есть у каждого:
● классика – обычные текстовые и табличные описания со своевременной актуализацией. Сами файлы могут быть в общем доступе, предоставляя пользователям последнюю версию описания;
● схемы геоданных – графические представления, которые помогают быстрее охватить структуры геоданных и увидеть имеющиеся взаимосвязи. Здесь можно использовать любые удобные участникам нотации. Такие схемы также могут распространяться в виде файлов для участников проектов,
● интерактивные веб-сервисы – здесь можно использовать весь потенциал гиперссылок, создать наиболее полное описание всех элементов геоданных и раскрыть потенциал интерактивной работы с информацией.
Сегодня мы детальнее рассмотрим вариант электронного описания в виде веб-сервиса и расскажем про реально существующий кейс из практики работы автора статьи.
Оговоримся сразу, что данный пример был реализован в компании, использующей ArcGIS, и поэтому далее могут использоваться термины, характерные для модели базы геоданных (БГД) Esri. Тем не менее, такой подход не заточен лишь под одну ГИС-платформу – он может применяться на любом предприятии, занимающемся геоданными.
Что сотрудники узнают из описания структуры геоданных
Для сотрудников компании рассматриваемый сервис был частью корпоративного сайта, где каждый мог ознакомиться с актуальной структурой базы геоданных предприятия. Здесь можно было увидеть все тематические группы геоданных, отдельные классы/слои БГД, перечень всех атрибутов и их характеристик, все справочники и классификаторы предприятия. При этом информационный ресурс содержал описание всех геоданных, с которыми работала компания. Так сотрудники постепенно получали единую структуру для всех групп геоданных, в которой применялись общие принципы классификации, кодирования и именования элементов БГД.
Сотрудники могли изучать структуру аналогично просмотру БГД в ArcCatalog, то есть идя от набора классов вниз по иерархии данных до конкретного объекта. В нашем кейсе наборы классов формировались по тематическому принципу, объединяя схожие классы/слои в некие аналоги “папок” внутри БГД. При просмотре отдельного класса можно было увидеть весь перечень атрибутов этого класса. Для каждого атрибута прописывались необходимые характеристики: наименование атрибута в БГД, псевдоним для отображения в ГИС-проекте, тип данных, размерность, наличие домена/справочника, единица измерения при необходимости, обязательность заполнения.
Каждый геообъект имел свой код согласно принятой в компании классификации и системе кодирования. Когда пользователь проводил поиск по коду, он всегда мог не только узнать, что за объект скрывается за кодом, но и получить информацию о принадлежности объекта конкретному классу и набору, а также полный список атрибутов этого объекта. Если сотрудник понимал, что для текущего проекта у объекта не хватает какого-то атрибута, то он мог сообщить об этом администратору баз геоданных для дальнейшего расширения структуры шаблона.
Для отдельных объектов также можно было узнать определение – что из себя представляет этот объект. Ведь на картах обозначается очень большое количество разнообразных объектов местности, и не всегда все сотрудники одинаково могут понимать их сущность. Например, ГИС-оператор может впервые столкнуться с терриконом в обрабатываемом им массиве геоданных. Для того, чтобы лучше понимать свои объекты, сотрудник и обращается к принятому корпоративному словарю. Это помогает организовать одинаковое восприятие терминов внутри компании.
Помимо просмотра информации по отдельным геообъектам и общему перечню классов/слоев также можно было посмотреть и общий перечень атрибутов в рамках всего шаблона БГД. Такое представление структуры очень помогало при формировании новых наборов классов, так как атрибуты могли повторяться в разных предметных областях (например, наименование или статус объекта). Это было важно для сохранения единообразия параметров атрибутов, что давало уверенность в том, что уже имеющиеся скрипты не будут “спотыкаться” на неверно настроенных атрибутах новых классов или слоев.
Как обеспечивалось развитие описания структуры геоданных
Сопровождением этого информационного ресурса занимались только администраторы БГД. Остальные сотрудники могли направлять им свои предложения по расширению шаблона. Администраторы БГД уже сами трансформировали предложения в новые элементы согласно принятым в компании стандартам, системам классификации и кодирования, а также с учетом отраслевых стандартов и классификаторов. Такое разделение обязанностей помогало всем сотрудникам “не рассыпаться” по разным аспектам организации геоданных.
Интерактивная реализация описания шаблона БГД, с которым работали сотрудники компании, экономила время на поиск нужных параметров без отвлечения администраторов и перелистывания десятков и десятков страниц классических текстовых и табличных описаний слоев геоданных.
Варианты развития электронного описания
Чем еще можно было улучшить такой сервис? Например, функцией автоматизированного создания файловой БГД на основе выбранных из общего шаблона элементов, необходимых для отдельной задачи. Это помогло бы сотрудникам уйти от ошибок “ручного ввода” при создании классов БГД и их характеристик. И, конечно же, сильно сократило бы время на создание классов и слоев для работы ГИС-операторов.
Наглядным подспорьем также стала бы возможность просмотра условных обозначений отдельных объектов для разных масштабов карт. Ведь все равно время от времени приходилось доставать сборники условных обозначений для уточнений. Безусловно, в данном кейсе еще очень помогла бы информация о правилах топологии, принятых при проверке наборов геоданных. Ох… еще много разных предложений можно было бы внести для улучшения этого корпоративного ресурса. Но даже в своем базовом варианте он реализует интерактивную и понятную работу с актуальным описанием структуры геоданных компании.
В целом, создание подобных веб-сервисов помогает предприятию создать свой электронный каталог пространственных данных, который может существенно экономить время сотрудников на поиск актуальной информации о корпоративных стандартах и гарантировать предоставление последней версии согласованных структур геоданных. Наличие единого описания также может помочь в организации системы контроля качества данных и соответствия их имеющимся стандартам. Ведь по большому счету, потребуется лишь реализовать скрипт или набор скриптов, которые будут сопоставлять фактические наборы геоданных и согласованный шаблон.
Безусловно, создание подобных информационных ресурсов и сервисов требует определенных затрат. Но, если предприятие работает “вдолгую”, то эти затраты могут хорошо окупиться в перспективе, обеспечивая необходимый уровень качества с минимальным влиянием человеческого фактора.
Все вышеописанное может касаться не только геоданных, но и баз данных вообще. Ведь единые согласованные структуры данных – основа многих корпоративных информационных систем, цифровых бизнес-процессов и взаимодействий. А документирование структур данных – частая головная боль крупных компаний или объединений предприятий.