CADmaster

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

Результатом такой «игры на опережение» стала наращиваемая в любом направлении ГИС ОГД от группы компаний CSoft, позволяющая отражать любое организационное устройство субъекта РФ. Да и уже сейчас такие системы эксплуатируются нашими заказчиками в трехуровневом варианте «поселение — муниципалитет — субъект РФ», а ожидаемое нами добавление новых уровней иерархии (федеральный округ и, наконец, собственно уровень Российской Федерации) не потребует никаких усилий по реинжинирингу технологии. Этот результат, очевидно, достижим исключительно в случае, когда «полету организационной фантазии» ничто не препятствует, отсутствие каких-либо ограничений по объемам обрабатываемой информации или количеству пользователей можно гарантировать только при использовании апробированных для решения столь масштабных задач базовых программных средств, и альтернативы унифицированному хранилищу пространственных и описательных данных в серверной СУБД Oracle практически не существует.

Во-вторых, существует ложная посылка о том, что любой разумный заказчик стремится достичь независимости от конкретного разработчика, а любой хитрый исполнитель, напротив, стремится раз и навсегда «застолбить территорию», делая невозможным любой шаг по модернизации и развитию системы без него, исполнителя. Мы же изначально предполагали иное, ставя своей целью разработать не максимально закрытую от непосвященных технологию, а, напротив, открытую платформу, которую можно модифицировать в кратчайшие сроки силами персонала заказчика, оставляя, кроме того, для них и возможность самостоятельной разработки собственных программных средств. Да, скажете вы, но ведь практически все, играющие на этом рынке, обещают возможность расширения функционала за счет доступного интерфейса программирования, и будете правы, но весь «фокус» в том, что расширением функционала разработанного нами специализированного программного средства UrbaniCS (этакий аналог «гаражного тюнинга», только его-то многие и предлагают) наши опции доработки не исчерпываются. Есть также и возможность самостоятельного создания собственных приложений, вовсе безо всякого нашего участия, а это уже ближе к гордой концепции «Шкоды», когда идеи местных новаторов опираются на солидный фундамент всемирного признанного API…, но уже не от CSoft, а от Oracle. И тогда совершенно не удивляет, что, в отличие от подавляющего большинства конкурирующих технологий, при таком открытом подходе у заказчика сохраняется возможность использования всех ранее приобретенных рабочих мест от известных на ГИС-рынке компаний (ArcGIS, MapInfo, Intergraph, Bentley, Autodesk) без какого-либо промежуточного преобразования данных. Ну и «вишенка на торт»: для установки и тиражирования UrbaniCS совершенно не требуется покупать какие-либо компоненты третьих фирм (вспомните скороговоркой произносимое «ну и нужен еще MapXtreme» и загляните в прайс…).

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

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

Эти принципы были ранее положены нами в основу технологии, в которой до поры присутствовали только два типа клиентских приложений, имеющих доступ к единому хранилищу: «тяжелый» клиент — всем известная инструментальная ГИС (в нашем случае — CS MapDrive) и «средний» клиент — приложение непосредственно для ведения ИСОГД (в нашем случае — UrbaniCS). Оставалось сделать еще один шаг: дополнить имеющуюся технологию портальной надстройкой, исповедуя те же принципы: унифицированное хранение пространственных и описательных данных в серверной СУБД, единообразное администрирование доступа к ним, открытость для сторонних разработчиков, придерживающихся исключительно принятых международных стандартов. И вот, с 2010 года группой компаний CSoft началось промышленное внедрение портального расширения ГИС ОГД — CS UrbanView, представляющего собой серверное приложение на основе Oracle WebLogic.

По сути эта разработка дает возможность публиковать открытое подмножество данных ИСОГД в Internet, успешно решая определенную Градостроительным кодексом задачу информирования населения: ведь не требуется никакого преобразования и специальной подготовки данных, они публикуются из того же унифицированного хранилища на основе СУБД Oracle. Принцип открытости здесь реализован в еще большей степени: само базовое программное обеспечение Oracle WebLogic устанавливается на любую серверную операционную систему, прикладное программное обеспечение CS UrbanView разработано на популярной технологии Java, а клиентом может быть любой браузер из любой операционной системы, вплоть до мобильных. Естественно, что требования к аппаратным ресурсам «тонкого» клиента минимальны, а вот объемы данных, им просматриваемые, практически не ограничены, вся нагрузка ложится на высокопроизводительные серверные приложения. На рис. 1 приведен пример визуализации одного и того же фрагмента территории Домодедовского района Московской области во всех видах клиентских приложений, входящих в ГИС ОГД от CSoft. Причем в состав визуализируемых данных входят и огромные массивы данных дистанционного зондирования, обычно требующие значительных аппаратных ресурсов, но использование уникального метода Oracle GeoRaster для их хранения в СУБД позволило снять и эту проблему.

Рис. 1. Визуализация данных ИСОГД городского округа Домодедово, включая ДДЗ, в специализированном приложении UrbaniCS и в портальном приложении CS UrbanView

Портальная технология CS UrbanView вновь оставляет свободу в выборе способа построения полномасштабной ГИС ОГД. Если решены все организационные и технические вопросы с требуемым уровнем защиты информации, то публикация открытого подмножества данных теоретически возможна и непосредственно из хранилища ИСОГД. Но чаще, по известным организационным причинам, все же организуют отдельный web-сервер, на котором и формируется массив информации, подлежащий публикации (сама процедура такого формирования чрезвычайно проста в силу того же унифицированного способа хранения, регламентации доступа и идентичности структур данных). Дополнительной «изюминкой» такого подхода к реализации портала является возможность совместной визуализации данных ИСОГД и данных дистанционного зондирования открытого доступа (например, с Google Maps или с отечественного ресурса www.kosmosnimki.ru), что чрезвычайно важно при сохраняющемся дефиците качественных картографических материалов. На рис. 2−5 приведен пример реализации портала ИСОГД Калининграда, на котором опубликованы адресный реестр города, данные по функциональному и территориальному зонированию, а также по объектам капитального строительства и земельным участкам. При этом реализованные в портале механизмы поиска объектов градостроительной деятельности, включая критериальный выбор, автоматическое построение буферных зон вокруг выбранных объектов и поиск в окрестности от выбранной точки, могут быть визуализированы как на «обычной» картографической основе ИСОГД, так и с наложением на данные Google Maps, причем с сохранением возможности использования привычного интерфейса навигации этого ресурса!

Рис. 2. Поиск по адресному реестру ИСОГД	Рис. 3. Совместная визуализация результатов поиска с материалами Google Maps
Рис. 4. Поиск объектов градостроительной деятельности в буферной зоне	Рис. 5. Визуализация результатов поиска по буферной зоне совместно с материалами Google Maps

Но, помимо собственно самой задачи публикации данных, выбранная технология построения портальной части ИСОГД может служить основой для успешного решения чрезвычайно актуальной задачи оказания государственных и муниципальных электронных услуг. Эта проблема, активные шаги по решению которой предполагается сделать уже в этом году, особенно сложна в области градостроительства, так как в обязательном порядке предполагает предварительное решение нескольких чрезвычайно важных задач. Первая — однозначная идентификация гражданина, запрашивающего эти услуги, вторая — запрос для нужд заявителя документов из других ведомств, необходимых для реализации запрошенной услуги. Отсюда возникает обязательное требование совместимости с иными портальными программными решениями, многие из которых еще только создаются. И здесь вновь, как и в случае с развитием «базовой» технологии ИСОГД, нужно попытаться предугадать вектор развития технологий. А критерий останется прежним: совместимость с международными стандартами (многие из них уже закреплены в качестве обязательных, например — Приказ Министерства экономического развития Российской Федерации (Минэкономразвития России) от 20 октября 2010 г. № 503 г. Москва «Об установлении требований к формату документов, представляемых в электронном виде в процессе информационного взаимодействия при ведении государственного кадастра недвижимости»), на которых, очевидно, и будут базироваться как уже активно развиваемые порталы государственных услуг, так и жизненно необходимые для успешного решения поставленной задачи СМЭВ (системы межведомственного электронного взаимодействия).

Именно поэтому мы уверены в успехе портальной технологии на основе Oracle WebLogic: ведь в ней изначально заложена возможность организации взаимодействия с иными порталами по технологии WMS, а обмен данными по протоколу SOAP с любыми современными СМЭВ можно осуществить за счет разработки соответствующего web-сервиса как на стороне самой СМЭВ, так и на стороне Oracle WebLogic.

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