Каталог Данных Каталог Организаций Каталог Оборудования Каталог Программного Обеспечения Написать письмо Наши координаты Главная страница
RSS Реклама Карта сайта Архив новостей Форумы Опросы 
Здравствуйте! Ваш уровень доступа: Гостевой
Навигатор: Публикации/Наши издания/Управление развитием территории/№2_2007/
 
Rus/Eng
Поиск по сайту    
 ГИС-Ассоциация
 Аналитика и обзоры
 Нормы и право
 Конкурсы
 Дискуссии
 Наши авторы
 Публикации
 Календарь
 Биржа труда
 Словарь терминов
Проект поддерживают  










Авторизация    
Логин
Пароль

Забыли пароль?
Проблемы с авторизацией?
Зарегистрироваться


width=1 Rambler_Top100

наша статистика
статистика по mail.ru
статистика по rambler.ru

Реклама на сайте
Новостные ленты

Правила езды на велосипеде, или Куда дует ветер

А.М. Ставицкий (Группа компаний CSoft)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Окно печати


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

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

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

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

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

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

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


См. также:
Каталог Программного обеспечения:
   - UrbaniCS
   - UtilityGuide
   - CS MapDrive
   - Oracle Spatial
   - Autodesk MapGuide
Каталог Организаций:
   - CSoft (СиСофт)
Каталог Авторов:
   - Ставицкий А.М.

Разделы, к которым прикреплен документ:
Тематич. разделы / Технологии
Страны и регионы / Россия
Тематич. разделы / Регион. и муниц. ГИС
Публикации / Наши издания / Управление развитием территории / №2_2007
 
Комментарии (0) Для того, чтобы оставить комментарий Вам необходимо авторизоваться или зарегистрироваться




ОБСУДИТЬ В ФОРУМЕ
Оставлено сообщений: 0


Источник: УПР №2_2007
Цитирумость документа: 6
11:06:50 10.07 2007   

Версия для печати  

© ГИС-Ассоциация. 2002-2016 гг.
Time: 0.030668020248413 sec, Question: 96