Ехидный Мэрфи в свое время сформулировал основное правило езды на велосипеде: «Куда бы вы ни ехали, это все равно будет в гору и против ветра». Знатоки велоспорта дополняют это наблюдение жизненной правдой — пустившись в дорогу, остается только крутить педали, остановка равносильна падению…

«При чем тут, собственно, информационные системы обеспечения градостроительной деятельности (ИСОГД)?» — спросят новички. А люди «в теме» только улыбнутся: «Так и есть!» Бесконечные проблемы с поставщиками информации для ИСОГД, помноженные на региональную специфику — и вот перед вами весьма разнообразный горный пейзаж, вид снизу. Хаотически меняющиеся государственные и региональные законы и регламенты — встречный ветер. Что делать?.. Ответ один: напряженно вращать педали.

В предыдущих публикациях мы подробно рассказывали о трехзвенной ГИС-технологии, состоящей из единого хранилища пространственных данных на основе СУБД Oracle, об инструментальной ГИС CS MapDrive и специализированном семействе программных приложений UrbaniCS на основе системы публикации данных Autodesk MapGuide.

Преимущества подобной архитектуры все более очевидны всем, кому приходится заниматься не общими рассуждениями о полезности ГИС-технологий, а практическим внедрением систем, количество объектов в которых исчисляется миллионами, а число пользователей с четко разграниченными правами — десятками, а то и сотнями.

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

СУБД

С СУБД все понятно: версия Oracle 10g еще более ориентирована на распределенную работу с огромными массивами данных. В модуле Spatial, предназначенном для хранения пространственных данных, возможности пространственного анализа данных расширены силами самой СУБД (все преимущества этого в полной мере ощутили, например, пользователи системы в Мытищинском районе, которым нужно было при помощи самых обычных по конфигурации рабочих станций быстро накладывать определенные пространственные фильтры на более чем пять миллионов объектов).

Расширены функции топологического анализа, что позволило пользователям UtilityGuide анализировать последствия переключений инженерных коммуникаций… да-да, конечно, на стороне сервера, стандартными методами.

В СУБД теперь можно объектным образом хранить не только векторную, но и растровую информацию, а это очень важно в свете обещанной несекретности спутниковых снимков высокого разрешения, ведь примененный в версии 10g принцип «пирамидальной разрешающей способности» позволяет очень экономно расходовать ресурсы при визуализации растровых массивов, объем которых измеряется гигабайтами.

А приняв во внимание расширение хорошо знакомого специалистам по базам данных понятие «репликация» на пространственные данные, мы получим еще одно неоспоримое объяснение доминирования Oracle на рынке СУБД вообще и на рынке СУБД для ГИС в частности.

CS MapDrive

Инструментальная ГИС CS MapDrive растет, черпая силы как бы из двух источников. Развитие корпорацией Intergraph возможностей базовых компонентов GeoMedia Objects, используемых при проектировании этого программного средства, и внимательный учет замечаний и пожеланий наших пользователей привели к закономерному появлению версии 2.5.

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

Окно иерархической легенды

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

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

Окна настройки стилей
Окна настройки стилей

Поскольку CS MapDrive ориентирован на пользователей, осуществляющих разносторонний пространственный анализ по пространственным и семантическим критериям, в новой версии особое место было уделено развитию системы запросов. Это и возможность упорядочивания большого количества запросов с использованием все того же иерархического подхода, и специальный запрос на объединение данных из разных источников.

Папки запросов
Папки запросов

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

Запрос на объединение
Запрос на объединение

Опыт внедрения наших ГИС-проектов свидетельствует, что CS MapDrive очень часто используется в качестве «воронки», собирающей в единое хранилище геометрические данные, подготовленные где-то вовне. При этом за качество информации, как правило, никто не отвечает, а систематический «слив» геометрически некорректной информации в общее хранилище приводит к непредсказуемым результатам. Жизнь показала, что на самых ранних этапах абсолютно необходим «входной контроль» данных, поступающих на переработку и преобразование. И такой контроль успешно реализован в версии 2.5 новой командой Запрос на правильную геометрию, позволяющей найти огрехи в данных еще до того, как это приведет к некорректным результатам анализа.

Запрос на корректность
Запрос на корректность

И, наконец, изменение «идеологии» печати, вызванное тем, что CS MapDrive практически всегда используется как компонент комплексных проектов, в которые обязательно включаются пользовательские приложения на основе Autodesk MapGuide. Улучшение функционала этих приложений подробнее будет рассмотрено позже, но вот об одном существенном ограничении Autodesk MapGuide нужно сказать уже сейчас. Дело в том, что в погоне за высокой производительностью системы публикации данных из него разработчики пожертвовали развитыми стилями отображения объектов, что практически исключило возможность печати выходных документов в соответствии с требованиями стандартов. Исключило бы… если бы не возможность при подготовке выходной формы в CS MapDrive записывать полученный результат в метафайл, который через специальный компонент CS MapDrive Print Server может передаваться в приложения на основе Autodesk MapGuide с сохранением всех стилей отображения.

Окно печати
Окно печати

UrbaniCS

Теперь про UrbaniCS… Все традиционные преимущества очевидны и сохранены в новой версии: здесь и разветвленные системы справочников, исключающие ошибки ввода, и регламентированный доступ к данным в зависимости от принадлежности к «ролевой группе», определяемой администратором СУБД, и генерация выходных форм по шаблонам Crystal Reports, расширенным для возможности использования графической информации из CS MapDrive Print Server…

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

«Ретроспективный анализ»

Система поддержки градостроительной деятельности направлена на осуществление мониторинга объектов, которые подвержены постоянным изменениям, причем меняются и пространственные, и семантические характеристики. Все очень просто и жизненно: земельный участок принадлежал Иванову, который брал его под строительство автомойки, потом он охладел к этой затее и продал его (или передал право пользования им) Петрову, который через некоторое время решил изменить функциональное назначение участка и построил на нем гостевой дом (разумеется, оформив такое изменение). Но тут Сидоров, который решил на принадлежащем ему соседнем участке построить теннисный корт, обнаружил, что площади совсем чуть-чуть, но не хватает, а виной тому — неправильно стоящий забор… Скандал, конфликт, вызов геодезистов, изменение границ… А ведь в традиционной ГИС-системе хранится только последняя «инкарнация» объекта и в пространственном, и в семантическом смысле, как же в конфликтной ситуации проследить весь жизненный цикл объекта или группы объектов? Делать «откат» на неделю или месяц назад — абсолютно непродуктивно, объекты могут меняться асинхронно, не говоря уже о сложной процедуре восстановления массивов данных из прошлых копий содержимого базы. Создавать свои механизмы отслеживания изменений — долго, дорого, не очень надежно. К тому же в этом случае придется жестко прописать, каким объектам и сколько раз мы разрешаем измениться, а жизнь, как известно, непредсказуема…

Выход был найден в недрах самого Oracle. Переход от обычной СУБД к так называемым «рабочим пространствам» решил задачу в общем виде: любой объект может иметь сколько угодно «жизней», различные «инкарнации» объекта могут быть просмотрены одновременно в хронологическом или произвольном порядке. Соответствующая модификация ранее спроектированных нами провайдеров к Oracle из CS MapDrive и Autodesk MapGuide позволила добиться элегантного и надежного решения, основанного, как всегда, на доступных базовых механизмах СУБД! С удовлетворением отмечу, что даже у коллег по OpenGIS-консорциуму подобного функционала не только нет, но даже и не заявлено к созданию…

Репликации данных

ИСОГД — по определению распределенная система. То есть предполагается, что ведение ИСОГД по муниципальным образованиям, городским и сельским поселениям производится локально, «кустовым» методом. При этом результаты такой работы, безусловно, должны быть доступны в региональных центрах, иначе просто невозможно использовать актуальную информацию для принятия обоснованных градостроительных решений. Все замечательно, если каналы связи позволяют производить репликацию данных (то есть передачу обновлений) в режиме он-лайн, на это, собственно, и ориентирован Oracle. Но такая ситуация, мягко говоря, пока нехарактерна для нашей страны, а о необходимости офф-лайн репликаций специалисты Oracle как-то и не задумывались. Выход, разумеется, есть, и до сих пор применялись специализированные парные наборы так называемых скриптов, записывавшие образы обновляемых классов объектов в бинарные файлы, которые в одном месте формировались, а в другом, соответственно, восстанавливались в агрегированное хранилище. Но необходимость использования средств шифрования типа CryptoPro заметно увеличивала объем передаваемой открытым каналам информации (а много ли у нас в стране специализированных закрытых линий передачи данных?..). Переход же к системе «рабочих пространств», помимо ретроспективного анализа, позволил в качестве вторичного положительного эффекта на порядки снизить объемы передаваемой информации, упрощая и интенсифицируя как процесс внедрения, так и процесс эксплуатации ИСОГД.

Модифицируемая структура семантических данных

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

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

То есть пользователь задает дополнительное символьное описательное поле Цвет забора объекту «Земельный участок», результат этого действия запоминается в конфигурационном файле и автоматически воспроизводится при входе в систему только данного пользователя! И никакого перепрограммирования системы! В перспективе ожидается развитие активных «горизонтальных» связей, ведь пользователи могут делиться друг с другом опытом… и конфигурационными файлами!

И в завершение — несколько слов о том, зачем вообще писалась эта статья. В меньшей степени, чтобы рассказать миру о том, как мы успешно развиваемся, хотя и не без этого… А в большей — чтобы пригласить коллег (а люди, эксплуатирующие немногочисленные пока ИСОГД, в том числе и наши заказчики, — именно коллеги) к активному и заинтересованному обсуждению специфики решаемых задач. Ведь польза от любых наших технических и программных изысков будет гораздо большей, когда мы, проектируя технологию, будем лучше знать ваши проблемы… и сможем эффективно решать их.

Вместе с вами.

Александр Ставицкий,
к.т.н.,
директор по ГИС-направлению
компании CSoft