CADmaster

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

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

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

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

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

Что является главными препятствиями на пути создания МГИС?

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

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

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

В этом случае, как и в ряде других жизненных ситуаций, экстремальное решение не может оказаться верным. Выбирая какое-либо мощное программное средство, мы обрекаем пользователя на значительные финансовые затраты на одно рабочее место, практически подписывая тем самым приговор созданию МГИС по известным финансовым причинам. Ориентируясь же на разработки отдельных групп местных, часто очень талантливых программистов, мы ставим развитие МГИС в зависимость от того, будет ли возможность и желание у разработчиков заниматься проблемами МГИС через 2…3 года после успешного старта, ясно осознавая, что из-за «утечки мозгов» процесс внедрения МГИС может и вовсе оказаться под угрозой.

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

О разработке пользовательских приложений следует сказать особо. Многие стандартные базовые программные средства для построения ГИС вынуждают разработчиков использовать внутренние языки программирования (Avenue для ArcView, MDL для MicroStation). Помимо естественной ограниченности выразительных средств таких языков, этот подход неизбежно порождает проблему кадров, а как следствие, проблему сопровождения программных продуктов. Талантливые программисты, естественно, стремятся писать программы на стандартных, применяемых и у нас, и на Западе языках (например, С++). Это обеспечивает им возможность предложить свои услуги максимально широкому кругу клиентов. Ориентация на «мертвые» языки программирования, как правило, бессмысленна, поскольку неизвестно, насколько это умение будет востребовано в дальнейшем. Это обстоятельство, как ни печально, отсекает лучших программистов от разработки приложений для МГИС, если, конечно, идти по пути программирования на «внутригисовских» языках.

Видимо, понимая это, многие фирмы-производители ГИС постепенно отходят от «внутренних» языков программирования. Например, в качестве языка создания пользовательских приложений для MicroStation в настоящий момент предлагается использовать Java.

Все эти соображения привели в Калининграде к созданию альянса между Центром инженерных технологий «Си Эс Трэйд», специализирующемся на системной интеграции и реализации ГИС-проектов на основе программных продуктов Autodesk и Consistent Software, и Центром новых информационных технологий (ЦНИТ) Калининградского государственного университета, специализирующемся на разработке собственных программных продуктов, в том числе и в области ГИС.

В результате в качестве стандартного ядра для реализации отдельных подсистем МГИС был выбран Autodesk World. Основными критериями выбора стали:

• низкая стоимость продукта при достаточно широких возможностях, в том числе прекрасная интеграция с любыми СУБД, возможность использования топологии, поддержка любых проекций, возможность построения тематических карт, офис совместимый интерфейс пользователя;
• совместимость без импорта/экспорта со всеми известными ГИС- и офис-продуктами, возможность создания драйверов для работы с любыми нестандартными, в том числе и собственными форматами хранения пространственных данных;
• возможность создания пользовательских приложений на языках С++ (для опытных программистов) и VBA (для опытных пользователей).

Скриншоты этапов работы программы Autodesk World

Технологически решение специализированных задач при таком подходе выглядит как модули-надстройки, работающие в среде Autodesk World. Однако потенциально такой модуль зачастую позволяет не просто решить отраслевую задачу, но и расширить возможности самой базовой системы. Например, вам необходимо обеспечить возможность взаимодействия ГИС-ядра с базами данных не через средства, предоставляемые самой ГИС (ODBC-драйверы), а через OLE-DB-провайдеры, обеспечив при этом большую скорость обработки данных. Эта задача уже сейчас решается за счет специального модуля, обращающегося, кроме API самого Autodesk World, к API операционной системы и использующего дополнительно различные библиотеки и технологии третьих производителей.

Одной из первых задач, решение которой возникло как надстройка для Autodesk World, стала задача построения рельефа местности по отдельным точкам, в которых заданны высотные характеристики. Решение этой задачи привело к созданию модуля LANDTOOL 1.0, позволяющего по заданным в любом слое проекта точкам, имеющим координату Z, построить регулярную сетку высотных отметок (цифровую модель рельефа). На основе полученной цифровой модели рельефа модуль позволяет решать следующие задачи:

3D просмотр модели местности

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

Важно, что просмотр координат осуществляется в стандартных единицах измерения, установленных в проекте. Кроме того, модуль позволяет осуществлять просмотр цифровой модели рельефа в виде трехмерного изображения. При этом возможны передвижение по рельефу в реальном времени, а также наклоны и повороты «головы». Используя модуль, можно также построить произвольное количество изолиний в произвольном высотном интервале в любом слое вашего проекта. Линии уровня, создаваемые LANDTOOL, также имеют высотные отметки (координату Z). Это открывает возможность экспорта изолиний модели рельефа, созданной с помощью LANDTOOL для Autodesk World, в другие CAD-продукты, например, 3D Studio MAX или AutoCAD. При этом средства экспорта предоставляются самим базовым продуктом.

Просмотр цифровой модели рельефа

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

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

В настоящий момент компонентный подход, разработанный Калининградским университетом совместно с центром «Си Эс Трэйд», показал свою практическую значимость. Уже создан ряд специализированных модулей, решающих задачи нефтеразведки для Калининградской геолого-добывающей нефтегазовой экспедиции, система архивации и обработки данных, возникающих в океанологии для Атлантического научно-исследовательского института рыбного хозяйства и океанографии. По заказу Государственного комитета по охране окружающей среды Калининградской области ведутся работы, направленные на решение задач экологического анализа и мониторинга окружающей среды. Также ведутся работы по проектированию и разработке модулей для ГУП «Калининградгазификация».

Сегодня отдельные модули способны обеспечить эффективное решение самых разнообразных задач — от ввода и примитивного сопоставления атрибутивной информации с пространственными характеристиками объектов до сложного топологического анализа. Предложенный подход позволил альянсу «Си Эс Трэйд"-ЦНИТ получить на конкурсной основе заказ на проектирование сводной кадастровой карты Калининградской области; эффективность и экономическая целесообразность таких технологических решений подтверждена в ходе выполнения проекта EDRUS 9404 программы ТАСИС и получила высокую оценку международных экспертов.

Скачать статью в формате PDF — 681.1 Кбайт