Портал в ведомое
Опыт промышленного внедрения технологии ведения ИСОГД от группы компаний CSoft привел нас и к некоторым выводам, которыми захотелось поделиться, и к новому, «портальному» этапу в развитии самой технологии.
Вопервых, всегда существует дилемма: либо в процессе постановки задачи для разработчиков просто стараться строго следовать требованиям действующего законодательства, либо стремиться предугадать, каковы будут эти требования в ближайшем будущем. Второе предполагает известный риск, можно ведь и не угадать, зато в случае удачной попытки мы оказываемся далеко впереди «основной группы». Мы пошли именно по второму пути: закон определял муниципалитет как единственный «доверенный» уровень ведения ИСОГД, но логика указывала на то, что из «ста зайцев лошадь не составляется» и вопрос о региональных ГИС ОГД (чтобы не путать с закрепленным законом «муниципальным» понятием ИСОГД) — лишь дело времени. Однако не утихающее по всей стране реформирование муниципальных образований указывало и на то, что уровень может наращиваться не только вверх, но и вниз в зависимости от того, как поделят между собой полномочия муниципалитеты и поселения.
Результатом такой игры на опережение стала наращиваемая в любом направлении ГИС ОГД от группы компаний CSoft, позволяющая отражать любое организационное устройство субъекта РФ. Уже сейчас такие системы эксплуатируются нашими заказчиками в трехуровневом варианте «поселение — муниципалитет — субъект РФ», а ожидаемое нами добавление новых уровней иерархии (федеральный округ и, наконец, собственно уровень Российской Федерации) не потребует никаких усилий по реинжинирингу технологии. Этот результат, очевидно, достижим исключительно в случае, когда полету организационной фантазии ничто не препятствует; отсутствие какихлибо ограничений по объемам обрабатываемой информации или количеству пользователей можно гарантировать только при использовании апробированных для решения столь масштабных задач базовых программных средств, и альтернативы унифицированному хранилищу пространственных и описательных данных в серверной СУБД Oracle практически не существует.
Рис. 1. Визуализация данных ИСОГД городского округа Домодедово, включая ДДЗ, в специализированном приложении UrbaniCS и в портальном приложении CS UrbanView
Вовторых, есть ложная посылка о том, что любой разумный заказчик хочет стать независимым от конкретного разработчика, а любой хитрый исполнитель, напротив, стремится раз и навсегда застолбить территорию, делая невозможным без него любой шаг по модернизации и развитию системы. Мы же изначально предполагали иное, ставя своей целью разработать не максимально закрытую от непосвященных технологию, а, напротив, открытую платформу, которую можно модифицировать в кратчайшие сроки силами персонала заказчика, предоставляя, кроме того, ему возможность самостоятельной разработки собственных программных средств. Да, скажете вы, но ведь практически все играющие на этом рынке обещают возможность расширения функционала за счет доступного интерфейса программирования, и будете правы, но весь фокус в том, что расширением функционала разработанного нами специализированного программного средства UrbaniCS (этакий аналог «гаражного тюнинга», только егото многие и предлагают) наши опции доработки не исчерпываются. Есть также возможность самостоятельного создания собственных приложений вовсе безо всякого нашего участия, а это уже ближе к гордой концепции «Шкоды», когда идеи местных новаторов опираются на солидный фундамент всемирно признанного API, но уже не от CSoft, а от Oracle. И тогда совершенно не удивляет, что, в отличие от подавляющего большинства конкурирующих технологий, при таком открытом подходе у заказчика сохраняется возможность использования всех ранее приобретенных рабочих мест от известных на ГИСрынке компаний (ArcGIS, MapInfo, Intergraph, Bentley, Autodesk) без какоголибо промежуточного преобразования данных. Ну и «вишенка на торт»: для установки и тиражирования UrbaniCS не требуется покупать какиелибо компоненты третьих фирм (вспомните скороговоркой произносимое «ну и нужен еще MapXtreme» и загляните в прайс…).
Рис. 2. Поиск по адресному реестру ИСОГД
Такая инвариантность развития дала полную свободу в архитектуре системы: как правило, в силу отсутствия надежных и мощных каналов связи наша ГИС ОГД разворачивается в виде распределенной системы, в которой каждая точка ведения ИСОГД замыкается на свой локальный сервер, а вся совокупность серверов — на сервер регионального уровня. Чтобы сделать такую конструкцию работоспособной, пришлось разработать и внедрить технологию отложенных инкрементальных репликаций, когда на сервере регионального уровня находятся копии данных локальных серверов, а по каналам связи передаются только сформированные специальными утилитами небольшие бинарные массивы, содержащие информацию об изменениях пространственных и семантических характеристик объектов ИСОГД, произошедших со времени передачи последней репликации. Это стало возможным за счет включения своеобразной «машины времени», то есть хранения всех «инкарнаций» объектов ИСОГД и обеспечения возможности возврата в прошлое для разрешения конфликтных ситуаций, разумеется с исключением возможности это прошлое изменять: переписывать историю вообще неправильно, а в случае информационных технологий — нельзя.
Рис. 3. Совместная визуализация результатов поиска с материалами Google Maps
Однако при желании, а главное — при возможности развертывания централизованной системы с единым сервером никакого реинжиниринга приложений вновь не потребуется, можно даже начать с распределенной архитектуры, а потом перейти к централизованной и наоборот, никак не уведомляя разработчика. Важно только помнить, что централизованная архитектура дает такое преимущество, как абсолютная актуальность данных, без интервала запаздывания между репликациями, но зато создает опасность «сложить все яйца в одну корзину»: остановка такого сервера или проблемы на канале связи неминуемо приведут к легкому параличу градостроительной деятельности на всей территории региона.
Данные принципы были ранее положены нами в основу технологии, в которой до поры присутствовали только два типа клиентских приложений, имеющих доступ к единому хранилищу: «тяжелый» клиент — всем известная инструментальная ГИС (в нашем случае — CS MapDrive) и «средний» клиент — приложение непосредственно для ведения ИСОГД (в нашем случае — UrbaniCS). Оставалось сделать еще один шаг — дополнить имеющуюся технологию портальной надстройкой, исповедуя те же принципы: унифицированное хранение пространственных и описательных данных в серверной СУБД, единообразное администрирование доступа к ним, открытость для сторонних разработчиков, придерживающихся исключительно принятых международных стандартов. И вот с 2010 года группой компаний CSoft началось промышленное внедрение портального расширения ГИС ОГД — CS UrbanView, представляющего собой серверное приложение на основе Oracle WebLogic.
По сути, эта разработка дает возможность публиковать открытое подмножество данных ИСОГД в Интернете, успешно решая определенную Градостроительным кодексом задачу информирования населения, — ведь не требуется никакого преобразования и специальной подготовки данных, они публикуются из того же унифицированного хранилища на основе СУБД Oracle. Принцип открытости здесь реализован в еще большей степени: базовое программное обеспечение Oracle WebLogic устанавливается на любую серверную операционную систему, прикладное программное обеспечение CS UrbanView разработано на основе популярной технологии Java, а клиентом может быть любой браузер из любой операционной системы, вплоть до мобильных. Естественно, требования к аппаратным ресурсам «тонкого» клиента минимальны, а вот объемы данных, им просматриваемые, практически не ограничены, вся нагрузка ложится на высокопроизводительные серверные приложения. На рис. 1 приведен пример визуализации одного и того же фрагмента территории Домодедовского района Московской области во всех видах клиентских приложений, входящих в ГИС ОГД от CSoft. Причем в состав визуализируемых данных входят и огромные массивы данных дистанционного зондирования, обычно требующие значительных аппаратных ресурсов, но использование уникального метода Oracle GeoRaster для их хранения в СУБД позволило решить данную проблему.
Рис. 4. Поиск объектов градостроительной деятельности в буферной зоне
Портальная технология CS UrbanView вновь оставляет свободу в выборе способа построения полномасштабной ГИС ОГД. Если решены все организационные и технические вопросы с требуемым уровнем защиты информации, то публикация открытого подмножества данных теоретически возможна и непосредственно из хранилища ИСОГД. Но чаще, по известным организационным причинам, всё же применяют отдельный вебсервер, на котором и формируется массив информации, подлежащий публикации (процедура такого формирования чрезвычайно проста в силу того же унифицированного способа хранения, регламентации доступа и идентичности структур данных). Дополнительной изюминкой такого подхода к реализации портала является возможность совместной визуализации данных ИСОГД и данных дистанционного зондирования открытого доступа (например, с Google Maps или с отечественного ресурса www.kosmosnimki.ru), что чрезвычайно важно при сохраняющемся дефиците качественных картографических материалов. На рис. 25 приведен пример реализации портала ИСОГД Калининграда, на котором опубликованы адресный реестр города, данные по функциональному и территориальному зонированию, а также по объектам капитального строительства и земельным участкам. При этом реализованные в портале механизмы поиска объектов градостроительной деятельности, включая критериальный выбор, автоматическое построение буферных зон вокруг выбранных объектов и поиск в окрестности от выбранной точки, могут быть визуализированы как на «обычной» картографической основе ИСОГД, так и с наложением на данные Google Maps, причем с сохранением возможности использования привычного интерфейса навигации этого ресурса!
Рис. 5. Визуализация результатов поиска по буферной зоне совместно с материалами Google Maps
Но, помимо задачи публикации данных, выбранная технология построения портальной части ИСОГД может служить основой для успешного решения чрезвычайно актуальной задачи оказания государственных и муниципальных электронных услуг. Эта проблема, активные шаги по решению которой предполагается сделать уже в этом году, особенно сложна в области градостроительства, так как в обязательном порядке предполагает предварительное решение нескольких чрезвычайно важных задач. Первая — однозначная идентификация гражданина, запрашивающего эти услуги, вторая — запрос для нужд заявителя документов из других ведомств, необходимых для реализации запрошенной услуги. Отсюда возникает обязательное требование совместимости с иными портальными программными решениями, многие из которых еще только создаются. И здесь вновь, как и в случае с развитием базовой технологии ИСОГД, нужно попытаться предугадать вектор развития технологий. А критерий останется прежним: совместимость с международными стандартами (многие из них уже закреплены в качестве обязательных, например Приказ Министерства экономического развития Российской Федерации (Минэкономразвития России) от 20 октября 2010 г. № 503 г. Москва «Об установлении требований к формату документов, представляемых в электронном виде в процессе информационного взаимодействия при ведении государственного кадастра недвижимости»), на которых, очевидно, и будут базироваться как уже активно развиваемые порталы государственных услуг, так и жизненно необходимые для успешного решения поставленной задачи СМЭВ (системы межведомственного электронного взаимодействия).
Именно поэтому мы уверены в успехе портальной технологии на основе Oracle WebLogic — ведь в ней изначально заложена возможность организации взаимодействия с иными порталами по технологии WMS, а обмен данными по протоколу SOAP с любыми современными СМЭВ можно осуществить за счет разработки соответствующего вебсервиса как на стороне самой СМЭВ, так и на стороне Oracle WebLogic.
