Обсуждать, нужны ли сегодня геоинформационные системы, нет никакого смысла: ответ дала сама жизнь.

О том, какие именно ГИС необходимы, мнений даже больше, чем высказывающихся по этому поводу. Мы тоже внесли свой вклад в дискуссию (CADmaster, #1.2000). Автор этих строк пришел к убеждению, что универсального ответа попросту не существует: достаточно соблюдать некие общие принципы, нарушение которых сродни упрямому наступанию на грабли.

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

1. Этап первичной подготовки данных

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

  • сканирование всех материалов на профессиональном широкоформатном сканере;
  • начальная обработка результатов сканирования для устранения ошибок, возникших в результате деформации носителя (коробление бумаги, температурная/влажностная деформация пленки и т.д.)

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

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

Первичная обработка результатов сканирования потребует специализированного программного обеспечения для проведения так называемой калибровки: полуавтоматической коррекции сканированных карт и планов по идеальной сетке, представляющей собой набор точек с заранее известными координатами. Для городских планов такими точками являются угловые точки планшетов и внутренние контрольные точки, называемые также тиками. Задача оператора состоит в выборе математического метода калибровки, определении шага координатной сетки, выборе ее начальной точки и ручном указании положения узлов идеальной сетки на сканированной карте.

В первичную обработку входит и так называемое цветовое расслоение. Файл, содержащий цветную карту или карту в тонах серого, превращается в набор монохромных файлов — по принадлежности к определенному цветовому или «серому» диапазону. Это удобно для осуществления последующих этапов создания векторной карты, а также для полуавтоматического удаления из растровых файлов не требующейся на данном этапе информации (например, лесных массивов или объектов гидрографии). Разумеется, для цветового расслоения также необходимы специализированное программное обеспечение и навыки работы с ним.

Заказывать или покупать?

Ответ требует анализа конкретной ситуации у конкретного клиента.

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

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

2. Этап ввода данных

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

Оцифровка: вручную или автоматически?

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

Например, при оцифровке городских планов, если необходимо векторизовать только слой газовых коммуникаций, никаких вариантов, кроме тяжелой ручной работы, нет и быть не может. Даже самый опытный в этом деле человек будет задумываться над тем, что обозначает та или иная линия: то ли кабельную трассу, на которой со временем стерлась поясняющая надпись, то ли водовод… Чего же требовать от программы?

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

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

Делать или заказывать?

Есть соблазн все сделать собственными силами — хотя бы из соображений экономии, да и просто из вполне понятного желания оставить деньги для «своего» персонала. Ведь речь, казалось бы, идет о чисто технической работе… Верно, но… не совсем. Дело в том, что при оцифровке необходимо ОДНОВРЕМЕННО присваивать пространственные ключи объектам, а структура ключей должна отражать иерархию взаимоотношений объектов. (Например, труба должна находиться в иерархической связи с идентификатором улицы по справочнику мэрии, так как эксплуатирующая организация имеет технический архив, разбитый, в силу традиции, по улицам. Хотя на самом деле труба, отнесенная по этому принципу к Красносельской улице, может территориально находиться на улице Потемкина…). То есть, чтобы присвоить эти самые пространственные ключи, сначала нужно увидеть систему в целом. А как не бывает двух одинаковых городов, так не бывает и двух одинаковых муниципальных геоинформационных систем: слишком по-разному складываются информационные потоки, хотя, несомненно, есть и общие закономерности.

3. Разработка приложений

Какие бы красивые слова ни говорили вам поставщики ГИСовских программных средств, есть только два варианта. Вы покупаете либо уже готовую ГИС (отработанную, кстати, не на вашем городе), либо базовое программное обеспечение, чтобы адаптировать его под свои нужды. Что лучше? А что бы вы предпочли: костюм, пошитый когда-то для кого-то, пусть даже красивый и модный, или пошитый под вашу фигуру на заказ?

На самом деле главный вопрос — в выборе базового ГИСовского программного средства. Именно оно определит и выбор языка программирования для создания приложений, и способ (формат) хранения информации. Здесь необходимо учитывать несколько факторов.

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

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

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

Эта часть также нуждается в обсуждении. Многие стандартные базовые программные средства для построения ГИС вынуждают разработчиков пользоваться искусственными, внутренними языками программирования (Avenue для ArcView, MDL для MicroStation). Помимо естественной ограниченности средств таких языков, есть проблема кадров и сопровождения. Талантливые программисты, естественно, стремятся писать программы на стандартных, применяемых и у нас, и на Западе языках (С++, например). Это обеспечивает им возможность предложить свои услуги максимально широкому кругу клиентов. Ориентация на «мертвые» языки программирования, как правило, смущает, так как неизвестно, насколько это умение будет востребовано. Упомянутое обстоятельство, как ни печально, отсекает от проблем разработки приложений для МГИС лучших программистов — если, конечно, двигаться по пути программирования на «внутригисовских» языках. Кроме того, если приложение уже будет создано, а автор по каким-то причинам окажется недосягаем, вам вновь придется искать такого же редкого специалиста.

4. Информация в МГИС (Как ее хранить, или о законе больших чисел)

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

Разнообразные вариации такого решения прекрасно ведут себя при относительно небольшом числе объектов (порог, естественно, сдвигался по мере развития технических средств, операционных систем и т.д.), но когда количество объектов достигает сотен тысяч, проблема оптимизации запросов с участием пространственной и непространственной информации требует отдельного исследования.

Постольку поскольку задача оперирования сверхбольшими объемами данных возникала и решалась на уровне серверных баз данных (признанным лидером здесь является Oracle; поотстали, хотя и традиционно играют на этом рынке Microsoft SQL и Informix), логичной явилась идея хранения всех данных именно средствами серверных баз. Первым шагом стал Oracle Spatial Cartridge, эволюционировавший от реляционного к объектному принципу; об аналогичном решении уже объявил и Informix. В пользу такого решения говорит и отработанный в серверных базах данных механизм обеспечения многопользовательского доступа, а обеспечение этой возможности легко может стать «бутылочным горлышком» при переходе от разработки системы к ее внедрению.

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

5. Так что же делать?

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

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

Все это называется пилотным проектом по городской ГИС — именно его мы и предлагаем, называя себя ГИС-интеграторами.

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

PS. Чем же делать?

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

Тем не менее, кое-что из оборудования и программ для реализации ГИС можно посоветовать, не рискуя ошибиться:

  • Сканеры: Vidar или Contex. Применяются в нашей стране давно, зарекомендовали себя хорошо, производители реагируют даже на наши специфические требования (например, сканирование толстых алюминиевых и фанерных планшетов).
  • Плоттеры: Mutoh или Hewlett-Packard. Первые отличаются непревзойденными характеристиками точности, вторые — высокой производительностью.
  • Программы для оцифровки: Spotlight Pro версии 4. Кто-то назовет вполне успешный EasyTrace, но если вам важно описанное выше «выгрызание» растра — альтернативы нет.
  • Многопользовательская ГИС-среда: Autodesk MapGuide 5. Впечатляет соотношение цена/качество и глубокая интеграция со «смежными» компаниями (Oracle, Allair).
  • Настольная ГИС… А это — тема для статьи в следующем номере CADmaster. Не упустите!
Александр Ставицкий
Consistent Software Калининград
Тел.: (0112) 22−8321
E-mail: kstrade@online.ru
Internet: http://www.cstrade.ru