Муниципальная ГИС для российских условий: недорогие масштабируемые решения на стандартном ядре
Задача построения муниципальных геоинформационных систем сегодня обсуждается достаточно часто. Вероятнее всего, первой причиной является ухудшение экономической ситуации в стране. Сейчас, когда бюджеты всех уровней балансируют на грани дефицита, особенно важно управлять городом, районом, территорией максимально эффективно, четко планируя предполагаемые виды работ и их стоимость.
Второй причиной, стимулирующей процесс внедрения МГИС, является практически повсеместное хроническое недофинансирование работ по модернизации инженерных сетей городов и районов. Как следствие это приводит к возрастанию вероятности возникновения чрезвычайных ситуаций, быстро и эффективно реагировать на которые при отсутствии МГИС также невозможно.
Третьей причиной является поиск многими городами и регионами прямых внешних инвестиций. Однако реализация любого инвестиционного проекта неминуемо приводит к необходимости построения бизнес-плана и создания комплексной оценки по многим параметрам готовности территории для реализации конкретного проекта. Неточность и недостоверность оценок, длительное время подготовки таких предложений приводят либо к полному отказу инвестора от проекта, либо к переносу этого проекта в другой регион, где на поставленные вопросы ответят быстрее и конкретнее. То, что МГИС является наилучшим инструментом для проведения комплексной оценки возможности реализации инвестиционного проекта, сегодня уже не подлежит сомнению.
Таким образом, как ни парадоксально это прозвучит, именно финансовый дефицит обусловливает необходимость дополнительных затрат на построение эффективных управленческих систем, которые впоследствии позволят добиться существенной экономии средств.
Более того, саму муниципальную геоинформационную систему допустимо оценивать как объект инвестиций, который может окупаться напрямую (в частности, эффективная политика налогообложения, продажи и сдачи в аренду муниципальной собственности, основанная на данных МГИС, может являться дополнительным источником пополнения бюджета и внебюджетных фондов). Кроме того, МГИС позволит избежать лишних или малоэффективных затрат (так, например, строительство и реконструкцию дорог, инженерных коммуникаций можно производить в четком соответствии со степенью их загрузки, изношенностью, анализируя при этом статистику возникновения чрезвычайных ситуаций, аварий, происшествий и т.п.).
Что можно считать главными препятствиями на пути создания МГИС?
Во-первых, это разрозненность, неполнота и несистематизированность исходных данных. Система сбора, хранения и актуализации информации по инженерным инфраструктурам, которую мы имели в советское время, вряд ли была идеальной, но она все же существовала. В годы перестройки бурные преобразования часто приводили к тому, что информация об изменениях в инженерных коммуникациях или о строительстве новой ветки магистрали так и оседала в какой-либо отдельной организации. Кроме того, сложность построения единой системы возрастает также из-за отсутствия общего стандарта на хранение информации, а также бессистемных, как правило, попыток автоматизации деятельности каждой конкретной отрасли городского хозяйства.
Во-вторых, разнородность большого количества задач, которые призвана решать МГИС. Для одних случаев достаточно интеграции графической (векторной и растровой) информации, которая описывает пространственное положение строений, земельных участков, водопроводных труб, и описательной (атрибутивной) информации, дающей пользователю возможность узнать, кто владеет данным объектом, а также содержащей технические и стоимостные характеристики объекта. Однако в иных случаях обязательным является сложный топологический анализ, где необходимо проведение специальных расчетов и требуется создание аналитического программного обеспечения. Чтобы охватить полный спектр вероятных задач, придется либо делать ставку на какое-то мощное программное средство, которое «умеет все», либо стать на путь создания отдельных компонентов для решения конкретных задач — в надежде согласовать их между собой в ближайшем будущем.
Какие требования необходимо предъявлять к инструментам, с помощью которых создается муниципальная ГИС, с учетом вышеназванных проблем? Поскольку вероятность того, что с завтрашнего дня все отрасли, предприятия и организации перейдут на единый информационный стандарт, чрезвычайно низка, необходимым условием является «умение» создаваемой МГИС понимать и сопоставлять разнородные данные, «разбросанные» по разным инстанциям. При этом важно не производить никаких операций импорта/экспорта, поскольку результаты пространственного анализа в МГИС, а также неминуемой коррекции различных данных после их сопоставления придется возвращать обратно в «родном» формате.
В этом случае, как и в ряде других жизненных ситуаций, экстремальное решение не может оказаться верным. Выбирая какое-либо мощное программное средство, мы обрекаем пользователя на значительные финансовые затраты на одно рабочее место, практически подписывая тем самым приговор созданию МГИС по известным финансовым причинам. Ориентируясь же на разработки отдельных групп местных, зачастую очень талантливых программистов, мы ставим развитие МГИС в зависимость от того, будут ли у разработчиков возможности и желание заниматься проблемами МГИС через 2-3 года после успешного старта. К тому же из-за «утечки мозгов» процесс внедрения МГИС может и вовсе оказаться под угрозой.
Разумным компромиссом в данном случае представляется использование некоего стандартного, поддерживаемого крупной западной компанией ядра ГИС, оснащаемого набором разработанных на месте пользовательских приложений.
О разработке пользовательских приложений следует сказать особо. Многие стандартные базовые программные средства для построения ГИС вынуждают разработчиков использовать внутренние языки программирования (Avenue для ArcView, MDL для MicroStation). Помимо естественной ограниченности выразительных средств подобных языков этот подход неизбежно порождает проблему кадров и, как следствие, проблему сопровождения программных продуктов. Талантливые программисты, естественно, стремятся писать программы на стандартных, применяемых как у нас, так и на Западе языках (например, С++). Это обеспечивает им возможность предлагать свои услуги максимально широкому кругу клиентов. Ориентация на «мертвые» языки программирования, как правило, бессмысленна, поскольку неизвестно, насколько умение работать на них будет востребовано в дальнейшем. Это обстоятельство, как ни печально, отсекает лучших программистов от разработки приложений для МГИС, если, конечно, идти по пути программирования на «внутригисовских» языках.
Видимо, понимая это, многие фирмы-производители ГИС постепенно отходят от «внутренних» языков программирования. Например, в качестве языка создания пользовательских приложений для MicroStation в настоящий момент предлагается использовать Java.
Все эти соображения привели к созданию в Калининграде альянса между Центром инженерных технологий «Си Эс Трэйд», который специализируется на системной интеграции и реализации ГИС-проектов на основе программных продуктов Autodesk и Consistent Software, и Центром новых информационных технологий (ЦНИТ) Калининградского государственного университета, который специализируется на разработке собственных программных продуктов, в том числе и в области ГИС.
В результате в качестве стандартного ядра для реализации отдельных подсистем МГИС был выбран Autodesk World. Основными критериями выбора стали:
- низкая стоимость продукта при достаточно широких возможностях, в том числе прекрасная интеграция с любыми СУБД, возможность использования топологии, поддержка любых проекций, возможность построения тематических карт, офис-совместимый интерфейс пользователя;
- совместимость без импорта/экспорта со всеми известными ГИС- и офисными продуктами, возможность создания драйверов для работы с любыми нестандартными (в частности, собственными) форматами хранения пространственных данных;
- возможность создания пользовательских приложений на языках С++ (для опытных программистов) и VBA (для опытных пользователей).
Технологически решение специализированных задач при таком подходе выглядит как создание модулей-надстроек, работающих в среде Autodesk World. Однако потенциально такой модуль зачастую позволяет не просто решить отраслевую задачу, но и расширить возможности самой базовой системы. Например, вам необходимо обеспечить возможность взаимодействия ГИС-ядра с базами данных не через средства, предоставляемые самой ГИС (ODBC-драйверы), а через OLE-DB-провайдеры, обеспечив при этом большую скорость обработки данных. Эта задача уже сейчас решается за счет специального модуля, обращающегося, кроме API самого Autodesk World, к API операционной системы и дополнительно использующего различные библиотеки и технологии третьих производителей.
Одной из первых задач, решение которой возникло как надстройка для Autodesk
World, стала задача построения рельефа местности по отдельным точкам, в которых
заданы высотные характеристики. Решение этой задачи привело к созданию модуля
LANDTOOL 1.0, позволяющего по заданным в любом слое проекта точкам, имеющим
координату Z, построить регулярную сетку высотных отметок (цифровую модель рельефа).
На основе полученной цифровой модели рельефа модуль позволяет решать следующие
задачи:
- осуществлять просмотр полученной модели местности в виде карты цветов;
- определять по карте цветов высоты рельефа;
- осуществлять поиск и отметку точек, имеющих определенную высоту.
Важно, что просмотр координат осуществляется в стандартных, установленных в
проекте единицах измерения. Кроме того, модуль позволяет осуществлять просмотр
цифровой модели рельефа в виде трехмерного изображения. При этом возможно передвижение
по рельефу в реальном времени, а также наклоны и повороты «головы». Используя
модуль, можно также построить произвольное количество изолиний в произвольном
высотном интервале в любом слое вашего проекта. Линии уровня, создаваемые LANDTOOL,
также имеют высотные отметки (координату Z). Это открывает возможность экспорта
изолиний модели рельефа, созданной с помощью LANDTOOL для Autodesk World, в
другие CAD-продукты, например 3D Studio MAX или AutoCAD. При этом средства экспорта
предоставляются самим базовым продуктом.
Фактически LANDTOOL позволяет выйти в третье измерение в ГИС, которая изначально была рассчитана на работу с двухмерными картами. В свою очередь, это позволяет решать задачи пространственного анализа на совершенно ином уровне, привлекая Z-координату и данные о рельефе. Однако благодаря тому, что при создании модуля решалась общая задача восстановления высот на регулярной сетке, то есть задача создания цифровой модели местности, модуль можно применять для решения самых разнородных по своему происхождению задач. Для этого достаточно только использовать в качестве координаты Z любую другую характеристику, например: загрязненность (в экологических задачах), прозрачность или соленость воды (в задачах океанологии), глубину залегания каких-либо пород (в задачах геологоразведки). Таким образом, реализация задачи, казавшейся узкоспециализированной, превращается в общий подход.
Однако вернемся к проблемам создания муниципальной ГИС. Именно здесь подход,
связанный с решением узких задач посредством создания модулей-надстроек к базовому
продукту, оказывается наиболее эффективным. Действительно, задача построения
МГИС, как правило, сводится к проблеме создания большого количества рабочих
мест, на каждом из которых решаются свои задачи, но при этом используется единая
технологическая основа. Спектр решаемых проблем может быть чрезвычайно широк
— от простого мониторинга объектов коммунального хозяйства до сложных аналитических
систем оценки экологической безопасности. Искать ГИС, которая решала бы все
задачи, просто не имеет смысла как из-за высокой стоимости одного рабочего места,
так и из-за того, что вряд ли найдется такая система, в которую «вшиты» именно
ваши алгоритмы ввода, обработки, оценки данных. Поэтому обычное соотношение,
при котором 80% стоимости ГИС-проекта приходится на стоимость базового продукта
и только 20% — на его адаптацию к конкретным задачам, на сегодняшний день для
большинства российских городов является непозволительной роскошью. «Компонентный»
подход к «строительству» МГИС позволяет добиться принципиально иного соотношения:
80% средств будет потрачено на решение специализированных задач, но при этом
сохранится полная совместимость создаваемого программного обеспечения с продуктами
ведущих мировых производителей. Общий подход к решению любых частных задач позволяет
применить при создании МГИС долевой принцип, при котором каждый участник проекта
инвестирует средства только для создания собственного информационного слоя (водопровод,
тепловые сети, газовые коммуникации и т.д.), а общие, корпоративные затраты
сводятся к минимуму.
В настоящий момент компонентный подход, разработанный Калининградским университетом
совместно с центром «Си Эс Трэйд», показал свою практическую значимость. Уже
создан ряд специализированных модулей, решающих задачи нефтеразведки для Калининградской
геолого-добывающей нефтегазовой экспедиции, разработана система архивации и
обработки данных в океанологии для Атлантического научно-исследовательского
института рыбного хозяйства и океанографии. По заказу Государственного комитета
по охране окружающей среды Калининградской области ведутся работы, направленные
на решение задач экологического анализа и мониторинга окружающей среды. Также
ведутся работы по проектированию и разработке модулей для ГУП «Калининградгазификация».
Сегодня отдельные модули способны обеспечить эффективное решение самых разнообразных задач — от ввода и примитивного сопоставления атрибутивной информации с пространственными характеристиками объектов до сложного топологического анализа. Предложенный подход позволил альянсу «Си Эс Трэйд»—ЦНИТ получить на конкурсной основе заказ на проектирование сводной кадастровой карты Калининградской области; эффективность и экономическая целесообразность таких технологических решений подтверждена в ходе выполнения проекта EDRUS 9404 программы ТАСИС и получила высокую оценку международных экспертов.
И последнее замечание, отчасти подтверждающее, по мнению авторов, нашу правоту. Autodesk World был первым на рынке инструментальных ГИС средством, отвечающим всем описанным в настоящей статье требованиям. Но вышедший несколько позже программный продукт GeoMedia компании Intergraph оказался столь же пригодным для построения муниципальной ГИС ядром.
Вследствие этого сегодня, по согласованию с компанией Intergraph, авторами производятся работы по переносу разработанных на данный момент компонентов и на платформу GeoMedia, что даст возможность еще более расширить круг потенциальных пользователей модульных муниципальных ГИС и увеличить число их возможностей. Этот факт ярко свидетельствует о том, что целью деятельности авторов является не продвижение на рынок ГИС конкретного программного продукта или конкретной компании по производству программного обеспечения, а развитие самого модульного подхода к созданию ГИС, что позволит обеспечить экономию времени и средств своим потенциальным клиентам.
«САПР и графика» 5'2000
