Портал в вéдомое

0

А. М. Ставицкий

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

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

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

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

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

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

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

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

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

 

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

ris_2_web
Рис. 2. Поиск по адресному реестру ИСОГД

 

ris_3_web
Рис. 3. Совместная визуализация результатов поиска с материалами  Google Maps

 

ris_4_web
Рис. 4. Поиск объектов градостроительной деятельности в буферной зоне

 

ris_5_web
Рис. 5. Визуализация результатов поиска по буферной зоне совместно с материалами Google Maps

 

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

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