Easy Trace Group

Вы здесь: О компании Публикации Как была оцифрована Караганда

Как была оцифрована Караганда

Оцифровка г. Караганды выполнялась нами по заказу компании СП ДАТА+. Целью проекта было создание топоосновы для ГИС Центра Оперативного Управления ГУВД города. Подробнее об этом можно узнать из статьи Геннадия Радионова, ведущего эксперта ДАТА+. Статья опубликованной в журнале ARCREVIEW №2 за 2003г.

Особенностью проекта было то, что материал передавался заказчику пятью фрагментами и прямо "с колёс" включался в создаваемую ГИС. Поэтому ни о каких возвратах на доработку не могло быть и речи. Сроки были воистину драконовские, да и сам порядок передачи информации вносил некоторую сумятицу.

Первым шагом, от которого мы не отступаем ни при каких условиях, безусловно, было выполнение пилотного проекта. Поскольку Easy Trace V 7.7 ещё не поддерживал тематическую раскраску по атрибутам, было решено поделить всё площадное покрытие на пять тематических слоёв: дороги, искусственные покрытия, вода, "зелёнка" и прочие. Точнее, площадных слоёв получилось семь, так как здания и сооружения уже выносились в отдельные слои.

Такое искусственное деление покрытия позволило отображать оцифрованные объекты в гораздо более привычном виде. С одного взгляда стали видны ошибки в построении дорожной сети, изолированные площадки с искусственным покрытием и масса других мелких "прелестей". Дополнительным призом было сокращение диапазона возможных значений при атрибутировании объектов в пределах каждого из "площадных" слоёв и, соответственно, ускорение этого процесса. Естественно, перед сдачей материала заказчику, искусственно разделённый слой покрытий был "слит" в единое целое. Это заняло не более минуты и потребовало десяток кликов мышью.

Определение оптимального слоевого состава для выполнения векторизации это малая толика работы над пилотным проектом. Идеология пакета Easy Trace позволяет рассматривать любой проект как основу для клонирования. То есть, наследование клонами ВСЕХ параметров проекта-прототипа. А их не так уж и мало.

Прежде всего, это стратегии трассировки или, проще говоря, наборы параметров для трассировщиков, оптимизированные под характер материала, разрешение и качество растра. Стратегии получают имена и служат основой для создания инструментов пользователя. Звучит загадочно, но это просто кнопки на палитре, связывающие между собой инструмент, стратегию инструмента и слой, куда будет помещён векторизованный объект. Казалось бы, мелочь, но позволяет экономить 10-15% времени.

Особенно важно заранее подготовить хранимые стратегии верификации, то есть наборы слоёв и применяемые к ним тесты. Таких наборов может быть достаточно много, но выполняются они очень быстро в отличие от тестов на контроль полигонального покрытия. Экономия на их подготовке здорово осложнит вам жизнь при окончательной зачистке проекта. Тесты все равно придется выполнять, а выявленные ошибки править. Вот только то, что могли бы сделать десятки операторов, придется выполнять небольшой группе зачистки...

Ну и последний штрих - это настройка цветов растровых и векторных слоёв. Пренебрегать этим не стоит: во-первых, единообразие настроек помогает ориентироваться в данных операторам из группы контроля, а во-вторых, фейерверк красок на экране за один день может довести вас до тихого помешательства. Предпочтение следует отдавать приглушенным серо-зелёным оттенкам для растров и контрастным к ним цветами векторных слоёв. Естественно, при этом выбранные цвета покрытий должны ассоциироваться с типами векторизуемых объектов.

Пилотный проект, а лучше - пары планшетов, оцифрованных вслед за ним, используются как основа для определения расценок, по которым в дальнейшем оплачивается работа операторов. Механизм оценки крайне прост – последовательно векторизуются объекты каждого из слоев, а затраченное время делится на число векторизованных объектов. Для такой оценки удобно использовать средства сбора статистики, встроенные в пакет Easy Trace.

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

Следующий шаг - это сборка полного растрового покрытия проекта. Параллельно с этим составляется его план-схема, и определяются единицы работы - проекты. Удобное средство ведения план-схемы - обычная таблица Excel. Используя разную закраску ячеек, легко контролировать состояние проекта и темпы его выполнения.

Наконец, специальной утилитой из проекта с полным покрытием (надо ли говорить, что он был сделан на основе тщательно настроенного пилотного проекта!) высекались проекты и раздавались операторам на выполнение.

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

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

Кстати о терминологии: мы выделяем 5 уровней деления материала по площади. Прежде всего, это конечно планшет. Ну, с этим всё ясно и пояснений не требуется. Следующий уровень - это проект, т.е. группа смежных планшетов, выделенных в виде задания одному оператору. Затем следует блок или несколько "сшитых" проектов. Наконец собирается фрагмент, передаваемый заказчику, ну а фрагменты покрывают весь город.

Зачем вводилось такое деление? Ну, во-первых, мы стараемся не обрабатывать планшеты по одиночке. Это просто экономически не выгодно!

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

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

Во-вторых, обработка нескольких планшетов как единого целого позволяет оператору реже менять свою внутреннюю "настройку" на планшет. Ну, например, если после векторизации садовых участков (которых в наших городах просто немеряно!), вам попадает на оцифровку промзона, то достаточно долго чувствуешь себя "не в своей тарелке". Здесь требуются несколько иные приёмы оцифровки. Да и вообще, работая с большим районом, начинаешь понимать его структуру и быстрее разбираться в обстановке. А это далеко не мелочь, если учесть крайне низкое качество исходных растров и постоянную необходимость не столько векторизовать, сколько дешифровывать данные!

Что до ограничений по ресурсам, то Easy Trace настолько не требовательная к ним программа, что на древнем Pentium 233 MHz c 64 Mb можно запросто обрабатывать несколько ч/б планшетов сразу!

Роль качества растров в масштабных проектах - это отдельный вопрос. Экономия на подборе параметров сканирования или разрешении растра для уменьшения хранимых объёмов данных (это сейчас-то, когда днём с огнём не найдешь винчестер меньше чем на 40 Gb!) гарантированно отзывается головной болью у десятков операторов. Если исходный материал был достаточно хорош, а разрешение растра выбрано в 150 dpi при "жирных" сливающихся между собой линиях (а чтоб виднее было!) – знайте, время выполнения проекта вам придется, как минимум, удвоить…

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

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

 

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

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

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

Во-первых, в пакете имеется специальный режим отображения объектов, не связанных с атрибутивными данными. В этом режиме на общем сером фоне, "проблемные" объекты не только сверкают ярко жёлтым цветом, но и дополнительно выделяются все их вертексы. Пропустить такие объекты практически невозможно. Задача сводится к последовательному "гашению" объектов посредством назначения им атрибутов. Удобно это делать групповым редактором, одновременно присваивая атрибуты целой группе однотипных объектов.

Ну, а во-вторых, для проверки уже введённых атрибутов, использовалась утилита их контрольной прорисовки. Любые атрибутивные значения можно надписать над объектом и проверить их совпадение с данными, имеющимися на растре. И конечно, здесь тоже не обходится без маленьких "know-how". Если просто надписать расшифровки кодов атрибутов, на экран можно уже не смотреть – всё равно ничего не будет видно под несколькими слоями текста. Поэтому для контроля используются специальные сокращённые "псевдонимы" атрибутивных значений (они были подготовлены один раз, во время выполнения пилотного проекта).

Собственно, на этом можно завершить рассказ об оцифровке Караганды. Следующая пара замечаний носят скорее методический, чем технологический характер. Операторы - прежде всего люди, и для них абсолютно верна пословица "лучше один раз увидеть…". Поэтому стоит сделать пилотный проект доступным всем операторам, это сразу снимет массу вопросов. И, безусловно, будет не лишним потратить пару дней лучшего специалиста по оцифровке на составление краткой методички-комикса поясняющего неочевидные технологические моменты. Эта книжка с картинками должна лежать на столе каждого оператора. Поверьте – это окупится.

P.S. Версия 7.8 пакета даёт гораздо больший контроль над корректностью векторных и атрибутивных данных. Это, прежде всего, прозрачная заливка полигонов и тематическая прорисовка векторов по значениям присвоенных атрибутов. И многое, многое другое...