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

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

Именно поэтому мы решились описать ход создания и внедрения проекта для столицы Казахстана, который с некоторой осторожностью (чтобы не сглазить!) склонны считать успешным.

1. Общая ситуация

Астана удивительно сочетает в себе столь желанную для любого специалиста в информационных технологиях ситуацию «чистого листа», когда можно просто предлагать оптимальное решение, и «багаж прошлого», когда, выражаясь языком архитекторов, надо встраиваться в ситуацию, а не поднимать небоскреб на пустыре.

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

Общая степень информатизации различных служб, которые должны бы по замыслу составить единый городской ГИС-организм, примерно та же, что в большинстве российских городов. То есть самыми продвинутыми оказались службы земельного кадастра, которые по каким-то централизованным каналам получали некое программное и аппаратное обеспечение, но координация в плане совместимости информационных стандартов с городскими службами не осуществляется и всерьез никогда не планировалась.

Большой плюс ситуации в Астане: задача внедрения информационных технологий поставлена как приоритетная на государственном уровне (поверьте, любой из нас был бы рад увидеть такие формулировки в российском официальном документе!). Как следствие, в городе создано специальное предприятие МП «Астанагенплан», для которого внедрение и поддержка функционирования современных информационных технологий определены как дела первоочередной важности.

2. Стратегия вхождения

Как правило, любые попытки получить заказ (тем более столь престижный) связаны с необходимостью доказывать, что всему многообразию предложений следует предпочесть именно ваш подход. Мне кажется, что выбор, сделанный в нашу пользу, был обусловлен двумя обстоятельствами: критериями выбора компонентов программного обеспечения и степенью взаимодействия с локальными компаниями.

Что касается выбора программного обеспечения (подробности — ниже), то основной его принцип заключается в честной системной интеграции. В том смысле, что заказчику должно быть поставлено оптимальное решение его проблем без непременной оглядки на «бренды» программного обеспечения. Если вы честно и квалифицированно сопоставляете плюсы и минусы игроков ГИС-рынка, ваше предложение всегда будет предпочтительнее, чем «монолитные», как телефон из цельного куска мрамора (не забыли сказку про старика Хоттабыча?), предложения конкурентов.

Что касается степени участия в таком проекте локальных компаний, есть два экстремальных подхода. Первый — «гастрольный»: вы всё берете на себя. Помните: «Мы к вам заехали на ча-ас…». Потом «гастролеры» уезжают, дым рассеивается… а заказчик остается лицом к лицу со своими проблемами. Второй: «знаем, летали». Персонал заказчика сам борется со всеми проблемами, старательно наступая на все пыльные грабли со следами, оставленными на них несколько лет назад системными интеграторами.

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

В результате по окончании внедрения пилотного проекта:

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

3. Трудный выбор

Прежде чем до хрипоты спорить, какая ГИС лучше, полезно сформулировать критерии, которым она должна удовлетворять, согласовать общий перечень задач, которые предстоит решить, а затем уж задумываться, из каких обязательных компонентов будет состоять конкретная ГИС.

Критерии, которым должна удовлетворять внедряемая ГИС

  • Масштабируемость. Принципиальный состав решения не должен меняться при лавинообразном росте пользователей. Единственное, что должно следовать за очередным скачком количества пользователей и объема хранимых и обрабатываемых данных, — upgrade (возможный) базового программного обеспечения.
  • Открытость на вход, то есть возможность использования уже накопленной или накапливаемой информации в форматах других распространенных программных средств.
  • Расширяемость в плане возможности написания собственных приложений на распространенных языках программирования.
  • Надежность в плане разработки основных компонентов ГИС крупными и надежными компаниями, что дает основания рассчитывать на будущие upgrade и развитие базового ПО без вложений в это развитие собственных средств.

Задачи, которые необходимо решить в процессе внедрения ГИС

  • Обработка все еще имеющихся в больших количествах «сырых» данных (сканирование, калибровка, оцифровка). Читатели нашего журнала давно и безоговорочно уверовали в набор инструментов от Consistent Software, который решает эти задачи несравнимо лучше конкурентов. Верим в это и мы.
  • Формирование ГИС-данных, то есть создание и редактирование векторной информации, стыковка этой оцифрованной информации с атрибутивными таблицами.
  • Надежное хранение данных, обеспечивающее распределенное хранение, репликацию, конфиденциальность и т.д.
  • «Публикация» данных, то есть возможность получать данные только для чтения либо для редактирования только атрибутивной информации.

Хранилище данных

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

Нравится? Нам — не очень. Поэтому мы активные сторонники общих хранилищ для всех видов данных на основе СУБД. Подход сам по себе не очень нов, его пытались применять и раньше, но только каждая идея должна соответствовать времени, иначе будет казаться милым чудачеством — как численные методы в математике, разрабатывавшиеся задолго до появления первых вычислительных машин. Сейчас, когда вычислительная мощность персональных компьютеров достигла новых рубежей, а название Oracle перестало ассоциироваться только с далекими и заоблачными RISC-станциями, время этого подхода пришло.

В неспециализированных СУБД (от Access до SQL Server) доступен только реляционный подход, при котором чем сложнее описываемый геометрический объект, тем больше строк в базе данных потребуется для его описания. И только в СУБД Oracle реализован объектный подход к хранению пространственных данных по принципу «один объект — одна запись». Помимо большего быстродействия при работе с едиными хранилищами данных, построенными по объектному принципу, есть еще одно существенное преимущество: сложные аналитические запросы с пространственными составляющими могут выполняться не инструментальной ГИС, а самим Oracle, что оптимально с точки зрения распределения ресурсов.

Единое хранилище на основе Oracle обладает способностью к репликациям, то есть «сливу» данных из многих малых хранилищ в одно централизованное для целей глобального анализа на уровне всего города. При этом вся техника поиска дубликатов записей, решения вопроса о дополнении, замене или удалении записей реализуется на основе встроенных механизмов самой СУБД.

И последнее по счету, но не по значимости: организация различных уровней доступа и защита информации. Все эти традиционно важные для нашей страны составляющие любого информационного проекта решаются на уровне СУБД — и весьма эффективно.

Надеюсь, убедили? Наши заказчики тоже сочли эти аргументы достаточными.

Выбор инструментальной ГИС

Остановив свой выбор на единых хранилищах данных на основе СУБД, переходим к выбору программного средства, которое должно:

  • обеспечивать ввод и редактирование пространственной информации;
  • уметь читать пространственные данные из традиционных ГИС-систем и сохранять результаты труда в едином хранилище с поддержкой объектного принципа хранения;
  • допускать расширение базовой функциональности за счет приложений, создаваемых на стандартных языках программирования;
  • быть разработанным крупной и имеющей авторитет в мире компанией, но с обязательной локализацией.

Проанализировав весь «парк» распространенных в России инструментальных ГИС, мы обнаружили двух явных лидеров по степени соответствия поставленным критериям: Autodesk Map и Intergraph GeoMedia. Сравнительный анализ инструментальных ГИС — тема отдельной статьи, поэтому сразу приводим вывод, как ответ в конце школьного задачника.

ПО от «родного» Autodesk как всегда превосходно по набору операций создания и редактирования векторной информации. Собственный формат хранения данных DWG перекидывает мостик к залежам технических чертежей в городских службах, а предоставленная новейшей версией возможность работать с хранилищами данных Oracle достойно дополняет список основных преимуществ. Но есть и проблема: при работе с хранилищами Autodesk Map не обеспечивает режима реального времени, то есть для редактирования данных из хранилища их придется сначала импортировать в DWG, а потом возвращать обратно. Да и интерфейс все же на мой вкус тяжеловат и рассчитан на опытных пользователей.

Поэтому в качестве второй инструментальной ГИС мы использовали GeoMedia, которая «по определению» обеспечивает режим реального времени доступа, так как вообще не имеет собственного формата хранения информации, а работает только с хранилищами на основе СУБД (и к тому же очень проста в освоении). Но вот набор операций создания и редактирования векторных объектов у привычного к AutoCAD пользователя вызовет разочарование.

Обе инструментальные ГИС обеспечивают доступ к распространенным форматам хранения пространственной информации, причем GeoMedia может даже и не импортировать данные из «чуждых» форматов, а просто ссылаться на них в общем файле ГИС-проекта (если не требуется их редактирование). И та и другая предусматривают возможность разработки пользовательских приложений на С++, Delphi, VBA, а не на «мертвых» языках типа Avenue от ESRI.

Итак, мы пришли к выводу, а наши заказчики этот вывод подтвердили, что сочетание этих двух инструментов и есть оптимальный выбор. А в общем что в этом необычного — всякий знает, что работать двумя руками удобнее, чем одной…

Выбор средств публикации данных, или «Живая» работа с клиентом

Обоснованность выбора Autodesk MapGuide подтвердит каждый, кто хоть сколько-нибудь с ним знаком. Тут и возможность работы как во внутренней корпоративной сети, так и в Internet, и прямая поддержка Oracle, и удобная возможность разработки собственных приложений. Последнее особенно важно, потому что, в отличие от большинства программных средств, созданных по принципу «включил-работай», Autodesk MapGuide скорее инструмент, платформа для создания приложений, чем ПО для конечного пользователя.

Мы активно использовали Autodesk MapGuide для разработки приложений как способствующих эффективному процессу внедрения ГИС, так и обеспечивающих удобный и простой просмотр результатов, простые средства анализа.

Судите сами: работа началась после того как мы определились с объектным составом и номенклатурой ГИС-слоев, определили структуру баз описательных данных. Эффективно используя все перечисленные выше средства для обработки данных и инструментальные ГИС, сами ГИС-слои удалось создать просто в рекордные сроки. А как быть с описательными данными по сооружениям, по инженерным коммуникациям? Понятно, что нет никакой возможности перетащить, пусть даже ненадолго, все технические архивы в одно место, где «ваяется» ГИС. Значит, ввод описательных данных нужно проводить непосредственно на территории эксплуатирующих коммуникации и сооружения организаций и с участием их же персонала. Соответствующее распоряжение городских властей Астаны, обязывающее такие организации принять участие в создании ГИС, было издано. Но как это организовать в реальных условиях? Мы приняли решение разработать для каждой организации специализированные программные средства. В качестве основы используется один и тот же набор ГИС-слоев, а интерфейс предусматривает структуру и иерархию данных конкретной организации. Редактировать можно только атрибуты обслуживаемого вида коммуникаций, но для удобства ориентирования видны все слои. Так, например, при выборе кабельной трассы автоматически показываются связанные с ней объекты: трансформаторные подстанции, кабельные воронки и т.д. При этом исключена возможность ввода данных по воронке без описания самой трассы; благодаря использованию набора специализированных справочников минимизируются ошибки, допущенные оператором при вводе, а обработанный объект тут же меняет цвет — так проще оценить продвижение работы. Добавьте возможность адресной навигации по городу даже при наличии неполной или неточной информации и вы получите полное представление о наборе инструментов на основе Autodesk MapGuide, который в каталоге Consistent Software назван «MapGuide-паспортизация». Описанный набор программных средств успешно применяется как на этапе первичного ввода информации, так и при эксплуатации ГИС.

Впрочем, на этапе эксплуатации больше используется (прежде всего административным персоналом) другой наш инструмент на основе Autodesk MapGuide — «MapGuide-навигация». Главный принцип: все операции должны производиться одним нажатием кнопки. Администраторы — люди занятые, ответ на вопрос нужен им «здесь и сейчас», а учиться навыкам пользования программными средствами просто некогда да и незачем.

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

Как с чрезвычайными ситуациями, так и с обыденной деятельностью связан следующий компонент на основе Autodesk MapGuide — «PathGuide». Он позволит найти между заданными точками маршрута оптимальный путь с учетом «весовых коэффициентов» (то есть можно принять во внимание и интенсивность движения, и состояние дорожного покрытия).

Как уже не раз сказано выше, «общим знаменателем» для ГИС является СУБД Oracle. Режим реального времени доступа к нему со стороны Autodesk MapGuide может быть обеспечен и «штатным» провайдером данных, но мы сочли необходимым разработать свой собственный, чтобы обеспечить большую гибкость как в манипуляции данными, так и в ценовой политике…

4. Заключение

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

Мы не стали здесь раскрывать еще один важный компонент ГИС-проекта: мобильные решения на основе «наладонных» компьютеров типа iPAQ или Casio, созданные с применением базового программного обеспечения OnSite Enterprise. Это тема следующей статьи, а пока скажем только, что такие решения уже есть и они органично вписываются в предлагаемый нами подход к разработке и внедрению ГИС-проектов.

И еще одно важное замечание. Все описанное выше — не результат, а скорее подход. Программные средства нашего изготовления постоянно модифицируются в соответствии с замечаниями пользователей. Каждый пользователь не только находит какие-то неточности или неудобства, но и обязательно выдвигает уникальные требования, поэтому заказчику продается не набор программных средств, а РЕШЕНИЕ.