«При чем тут, собственно, информационные системы обеспечения градостроительной деятельности (ИСОГД)?» — спросят новички. А люди «в теме» только улыбнутся: «Так и есть!» Бесконечные проблемы с поставщиками информации для ИСОГД, помноженные на региональную специфику — и вот перед вами весьма разнообразный горный пейзаж, вид снизу. Хаотически меняющиеся государственные и региональные законы и регламенты — встречный ветер. Что делать?.. Ответ один: напряженно вращать педали.
В предыдущих публикациях мы подробно рассказывали о трехзвенной ГИС-технологии, состоящей из единого хранилища пространственных данных на основе СУБД Oracle, об инструментальной ГИС CS MapDrive и специализированном семействе программных приложений UrbaniCS на основе системы публикации данных Autodesk MapGuide.
Преимущества подобной архитектуры все более очевидны всем, кому приходится заниматься не общими рассуждениями о полезности ГИС-технологий, а практическим внедрением систем, количество объектов в которых исчисляется миллионами, а число пользователей с четко разграниченными правами — десятками, а то и сотнями.
Поэтому без долгих вступлений — несколько слов о том, как развиваются компоненты этой триады.
Расширены функции топологического анализа, что позволило пользователям UtilityGuide анализировать последствия переключений инженерных коммуникаций… да-да, конечно, на стороне сервера, стандартными методами.
В СУБД теперь можно объектным образом хранить не только векторную, но и растровую информацию, а это очень важно в свете обещанной несекретности спутниковых снимков высокого разрешения, ведь примененный в версии 10g принцип «пирамидальной разрешающей способности» позволяет очень экономно расходовать ресурсы при визуализации растровых массивов, объем которых измеряется гигабайтами.
А приняв во внимание расширение хорошо знакомого специалистам по базам данных понятие «репликация» на пространственные данные, мы получим еще одно неоспоримое объяснение доминирования Oracle на рынке СУБД вообще и на рынке СУБД для ГИС в частности.
Среди нововведений в первую очередь стоит упомянуть так называемую иерархическую легенду в окне карты, которая предлагает пользователю более удобный интерфейс, а также новые возможности по управлению слоями окна карты. Помимо указания порядка отображения слоев карты, пользователь теперь может создать многоуровневую иерархию пунктов легенды в каждом окне карты. Эта возможность очень важна при работе с проектами, содержащими десятки, а то и сотни логически вложенных слоев, которыми необходимо манипулировать в зависимости от поставленной задачи и масштаба отображения.
Иерархический подход применен и в отношении стилей отображения объектов на карте с учетом их возможного составного характера, особенно при использовании векторной информации, полученной из CAD-систем. Примером сложного стиля может являться сборный стиль. Сложность заключается прежде всего в том, что стиль отрисовки составных объектов сам описывается посредством целого набора стилей — для точек, для линий, для границ и заливок площадных объектов.
Важно, что применение стилей может задаваться условиями на основе выражений пользователя и функциональных атрибутов, а сама векторная информация, полученная из CAD-систем, может быть использована для назначения символьных стилей.
Поскольку CS MapDrive ориентирован на пользователей, осуществляющих разносторонний пространственный анализ по пространственным и семантическим критериям, в новой версии особое место было уделено развитию системы запросов. Это и возможность упорядочивания большого количества запросов с использованием все того же иерархического подхода, и специальный запрос на объединение данных из разных источников.
Пользователь может управлять набором полей результирующего набора данных путем указания: использовать поля либо первого источника данных, либо набора только общих полей источников данных, либо набора всех полей источников данных.
Опыт внедрения наших ГИС-проектов свидетельствует, что CS MapDrive очень часто используется в качестве «воронки», собирающей в единое хранилище геометрические данные, подготовленные где-то вовне. При этом за качество информации, как правило, никто не отвечает, а систематический «слив» геометрически некорректной информации в общее хранилище приводит к непредсказуемым результатам. Жизнь показала, что на самых ранних этапах абсолютно необходим «входной контроль» данных, поступающих на переработку и преобразование. И такой контроль успешно реализован в версии 2.5 новой командой Запрос на правильную геометрию, позволяющей найти огрехи в данных еще до того, как это приведет к некорректным результатам анализа.
И, наконец, изменение «идеологии» печати, вызванное тем, что CS MapDrive практически всегда используется как компонент комплексных проектов, в которые обязательно включаются пользовательские приложения на основе Autodesk MapGuide. Улучшение функционала этих приложений подробнее будет рассмотрено позже, но вот об одном существенном ограничении Autodesk MapGuide нужно сказать уже сейчас. Дело в том, что в погоне за высокой производительностью системы публикации данных из него разработчики пожертвовали развитыми стилями отображения объектов, что практически исключило возможность печати выходных документов в соответствии с требованиями стандартов. Исключило бы… если бы не возможность при подготовке выходной формы в CS MapDrive записывать полученный результат в метафайл, который через специальный компонент CS MapDrive Print Server может передаваться в приложения на основе Autodesk MapGuide с сохранением всех стилей отображения.
Но анализ пожеланий пользователей привел к необходимости выпуска принципиально новой версии с двумя абсолютно новыми функциональными возможностями.
Выход был найден в недрах самого Oracle. Переход от обычной СУБД к так называемым «рабочим пространствам» решил задачу в общем виде: любой объект может иметь сколько угодно «жизней», различные «инкарнации» объекта могут быть просмотрены одновременно в хронологическом или произвольном порядке. Соответствующая модификация ранее спроектированных нами провайдеров к Oracle из CS MapDrive и Autodesk MapGuide позволила добиться элегантного и надежного решения, основанного, как всегда, на доступных базовых механизмах СУБД! С удовлетворением отмечу, что даже у коллег по OpenGIS-консорциуму подобного функционала не только нет, но даже и не заявлено к созданию…
Плодить многочисленные версии базы и интерфейса — плохая идея с точки зрения устойчивости работы, своевременности поддержки и перспектив развития. Поэтому структура данных была разделена на постоянную (включающую в себя по принципу общего знаменателя все обязательные требования пользователей в соответствии с требованиями действующего законодательства) и опциональную, которую пользователь в конкретном муниципальном образовании может задать сам. При этом уникальный механизм построения (конструктор) позволяет пользователю задать новое описательное поле, связать его с соответствующим справочником и автоматически включить в интерфейс с возможностью использования содержимого опциональных полей в генерируемых выходных документах!
То есть пользователь задает дополнительное символьное описательное поле Цвет забора объекту «Земельный участок», результат этого действия запоминается в конфигурационном файле и автоматически воспроизводится при входе в систему только данного пользователя! И никакого перепрограммирования системы! В перспективе ожидается развитие активных «горизонтальных» связей, ведь пользователи могут делиться друг с другом опытом… и конфигурационными файлами!
И в завершение — несколько слов о том, зачем вообще писалась эта статья. В меньшей степени, чтобы рассказать миру о том, как мы успешно развиваемся, хотя и не без этого… А в большей — чтобы пригласить коллег (а люди, эксплуатирующие немногочисленные пока ИСОГД, в том числе и наши заказчики, — именно коллеги) к активному и заинтересованному обсуждению специфики решаемых задач. Ведь польза от любых наших технических и программных изысков будет гораздо большей, когда мы, проектируя технологию, будем лучше знать ваши проблемы… и сможем эффективно решать их.
Вместе с вами.
