Государственный градостроительный кадастр или ГГК, как его сокращенно называют, — это уже не первая «инкарнация» идеи создания на уровне города или региона всеобъемлющих информационных систем, содержащих всю возможную графическую и описательную информацию. До этого увлеченно говорили о муниципальных ГИС, о земельном кадастре, о «едином окне»… У людей, не знакомых с трудной историей «ГИСизации» в России, может сложиться впечатление либо «повторения пройденного», только под новым знаменем, либо создания чего-то принципиально иного, с чистого листа.
Неверно ни то ни другое. Все предыдущие попытки реализации ГИС-проектов были естественно ограничены или кругом решаемых задач, или рамками конкретной отрасли, или компетенцией ветви власти — так что речь, главным образом, идет о новом уровне обобщения данных.
С одной стороны, ГГК должен вырасти на почве, удобренной (или испорченной…) предшествующими проектами, а с другой — изначально отличается максимальным уровнем интеграции данных разных уровней, что заставляет уделять особое внимание задачам их сбора, интерпретации, а также агрегирования.
В общем виде ГИС ГГК строится по тем же принципам, что и всякая другая современная ГИС.
Рассказывать сегодня, почему именно Oracle лучшее хранилище для пространственных и описательных данных — пустая трата времени и пишущего, и читающего. Отметим только новые возможности, доступные пользователям Oracle 10g.
В первую очередь это давно ожидавшееся хранение не только векторных, но и растровых данных в СУБД с так называемым пирамидальным подходом (в память загружается не весь растр, а только необходимый его «срез», что исключительно важно для оптимизации вычислительных ресурсов при использовании данных ДДЗ как компонента ИС ГГК).
Кроме того, топология векторных данных может теперь унифицированно храниться в самой СУБД. Как следствие, открываются новые возможности анализа переключений, что очень и очень существенно при анализе инженерных коммуникаций.
Инструментальная ГИС — это по определению инструмент, совместимый с международным стандартом OpenGIS, коль скоро мы выбрали единое хранилище на основе СУБД. Не претендуя на жизненное пространство коллег-конкурентов, мы тем не менее наращиваем дополнительный функционал собственной разработки — CS MapDrive, о чем ниже.
Фаворитом при выборе системы публикации данных по-прежнему остается Autodesk MapGuide, просто к известному семейству приложений для мониторинга инженерных коммуникаций UtilityGuide, в соответствии с веяниями времени дополненному функциями моделирования переключений и специализированными инженерными расчетами (тема отдельной статьи…), добавился UrbaniCS, впитавший весь опыт наших клиентов в части внедрения ГИС ГГК: и весь опыт наших разработчиков.
Если ГГК — это «кадастр кадастров», то интеграции подлежат данные разного состава и из совершенно разных источников. Но никто же не гарантировал, что предшествующие проекты, данными которых должен питаться ГГК, были успешны. Нередки случаи, когда попытки внедрения ГИСоподобных систем не были доведены до практической реализации, напоминая о себе лишь пухлыми отчетами (особенно в случае международных проектов) или сиротливо стоящими на полках коробками с разношерстным программным обеспечением. Данные же по-прежнему хранятся в необъятных бумажных «закромах». Что делать с «бумагой», в общем-то понятно: этот путь, требующий лишь концентрированных усилий и правильного выбора инструментов, пройден многократно. Как всегда, на арену выходит наш старый знакомый Spotlight, часто и успешно использовавшийся для обработки безбрежных архивов бумажных карт и исполнительных съемок. Возможности этого инструмента детально описаны во множестве статей, нет нужды повторяться, однако хочется лишний раз напомнить: это не «волшебная палочка» — трудозатраты, разумеется, уменьшаются, но не исчезают.
Пожалуй, еще сложнее ситуации, когда информация в электронном виде вроде бы и есть, но вид этот настолько странен, что дешевле и проще кажется «растеризовать» пространственные данные, нацифрованные безо всякого учета их будущего использования, и начать с нуля. Представьте себе линию электропередачи, нарисованную, скажем, в AutoCAD, но не как единое целое, а как сотня не связанных между собой отрезков, «утыкающихся» в кружочки, они же опоры… Поэтому проблема не в использованном программном обеспечении (сейчас даже нестандартные «рукописные» программные инструменты зачастую способны выдавать вовне данные в некоем стандартном формате), а в организации этих данных, в их объектном составе. Перефразируя профессора Преображенского, разруха не в программах, а в головах. Особую сложность этой «псевдоцифровой» ситуации придает тот факт, что очень часто руководители верхнего звена свято верят, что все результаты уже получены, деньги и силы потрачены не напрасно. Разочаровывать их в этом случае — дело опасное… но необходимое.
А проблема согласования и трансформации данных ложится на инструментальную ГИС, для которой почти непременно придется писать интеллектуальные конверторы данных. Общего рецепта здесь нет, но помимо «обязательной программы» поддержки всех стандартных форматов данных известных инструментальных средств (SHP, MIF/MID, DGN, DXF…), необходимы специальные усилия. Проект создания ИС ГГК сопряжен с обостренной необходимостью «встраиваться» в ситуацию — ведь информация от местных поставщиков данных обычно поступает «как есть». К тому же преобразование этой внешней информации никак нельзя считать однократной акцией — это реакция на регулярный процесс получения данных извне, и шансы как-то воздействовать на вид используемых данных очень малы.
Так, в весьма успешном проекте в подмосковных Мытищах стандартные возможности инструментальной ГИС CS MapDrive в части чтения файловых данных были существенно расширены под конкретные требования, чтобы автоматически трансформировать и объектный состав, и имена слоев и классов объектов, поступающих от геодезических компаний в виде файлов CREDO и AutoCAD, в атрибутивную информацию единого хранилища на основе Oracle.
Помимо «наследуемых» данных в ГГК в обязательном порядке должна войти именно градостроительная информация. Причем речь идет как о данных, создаваемых на уровне традиционной для ГИС топоосновы городских планов, так и об информации более общего характера (генеральные планы с зонированием, схемы ТКС).
Говорить о связи ГИС-проектов с градостроительной документацией как-то не очень принято… За очень малым счастливым исключением такая документация существует либо на той же «бумаге», либо в упомянутом «псевдоцифровом» виде. Нередки случаи, когда даже весьма уважаемые проектные организации предоставляют генпланы, например, в формате Corel Draw… Вроде бы есть и логика в аргументации, что высокой точности от этих данных не требуется, что это просто иллюстрация для принятия стратегических решений, но помилуйте, господа: генплан — это зонирование, а вопрос, где заканчивается рекреационная зона и начинается зона жилой застройки или промышленного производства, очень важен, когда решается, быть или не быть будущему объекту.
Нам кажется, что в отличие от обязательного регулярного «перемалывания» свежих геодезических данных, следует попробовать внедриться в сам процесс подготовки градостроительной документации. Первые шаги в этом направлении мы уже сделали, начав интеграцию разрозненных файловых данных НИиПИ Генплана Москвы в единое хранилище на основе Oracle. Естественно, не обошлось без разработки специализированных клиентских приложений, отражающих особую логику проектирования территорий; пока осваиваются подсистемы транспорта и инженерных коммуникаций, на очереди многое другое. Подробнее об этом проекте мы расскажем позже, а пока просто порадуемся тому, что и здесь «лед тронулся».
Чем же ГИС ГГК, по нашему мнению, отличается от предшествующих ГИС-проектов? По сути, составляющие части — те же, иначе и быть не могло. Но вот акценты по сравнению с традиционным ГИС-проектом несколько смещены.
В ГИС ГГК обязательно присутствуют элементы документооборота. Ведь всё привязано именно к документу, заявке от юридического или физического лица на строительство дома, завода, стадиона. Именно этот документ должен тут же зафиксироваться в системе, должен быть поручен конкретному исполнителю из конкретного отдела, именно к документу привязываются графические объекты, отражающие жизненный цикл от эскиза до воплощения: документ-заявка первичен и сроки его исполнения жестко контролируются.
Реализуя эту задачу, мы вынуждены были немного отойти от классического строгого подхода, при котором все новые графические объекты создаются только в инструментальной ГИС, а в легких клиентских приложениях производятся просмотр, анализ и редактирование доступной конкретному пользователю атрибутивной информации.
Часть атрибутивной информации пришлось разрешить вводить еще на этапе оцифровки в инструментальной ГИС (мы называем это «данными с земли»: то, что видно непосредственно при обработке исполнительных съемок). Неоценимым преимуществом CS MapDrive оказывается в этом случае построение иерархий данных с подключением отраслевых справочников. Эта зарезервированная ранее возможность нашей инструментальной ГИС стала просто необходимостью при реализации проектов ГГК.
В свою очередь, несложные графические объекты, не требующие особой пространственной точности (например, предварительный отвод), пришлось разрешить создавать в клиентских приложениях за счет прямой работы с Oracle Spatial.
В ГИС ГГК очень важны функции автоматического пространственного анализа — ведь предварительный или окончательный землеотвод обязательно будет проверен и на попадание в запретную для строительства зону, и на соответствие «красным линиям», и на угрожающую близость к охранным зонам инженерных коммуникаций или природным объектам.
Не раз представленные нами плюсы решения с единым хранилищем на основе СУБД в случае ГИС ГГК становятся еще более очевидными. Ведь эта система просто обречена на лавинообразный рост пользователей с принципиально разными уровнями доступа. Поэтому ролевой принцип на уровне системного администратора Oracle выглядит не как экзотика, а как единственно возможное решение.
С другой стороны, ГИС ГГК — по определению пространственно распределенная система, и организация информационного обмена на уровне репликаций как пространственных, так и атрибутивных объектов — просто попадание в точку. С одной стороны, всегда можно избежать нудной работы по сличению картины вчерашнего и сегодняшнего дней. С другой — репликации представляют собой относительно небольшие бинарные файлы, которые можно передать по каналам связи, не предъявляя к этим каналам специальных требований по пропускной способности.
Внедрение ГИС-проектов в России постоянно сопряжено с необходимостью учитывать требования режимности. Упростить ситуацию пока не удается, хотя постоянные усилия, предпринимаемые в этом направлении ГИС-Ассоциацией, внушают сдержанный оптимизм. Но пока всё остается так, как есть, и принцип обмена репликационными файлами дает дополнительное преимущество: такой бинарный файл абсолютно бессмыслен сам по себе, его несанкционированное использование просто исключено (попробуйте составить представление о книге по списку внесенных в нее поправок…).
Построение ГИС ГГК, которое как дамоклов меч с запланированным временем падения (1 июля 2006 года) «висит» над местными властями, — хороший стимул обратить внимание на успешные и апробированные в мировой практике технологии построения геоинформационных систем на основе единого хранилища пространственных описательных данных в Oracle. Так уже и сделали наши заказчики в части ГИС ГГК из Московской, Калининградской и Тюменской областей. Просто раньше этот подход виделся как некий «high-end» в области ГИС-технологий, который, конечно, несет массу преимуществ… но без которого можно обойтись, бесконечно латая старые фрагментарные подходы и создавая иллюзию экономии средств, а на самом деле просто откладывая решение насущных проблем и многократно увеличивая будущие затраты.
Задача построения ГИС ГГК по сути не оставляет выбора — конечно, это не просто; конечно, это путь решения проблем, а не само «коробочное» решение. Но свет в конце этого пути виден совершенно явственно… а другого пути просто не просматривается, поэтому не стоит терять времени!
