ВАЖНОСТЬ РЕДАКТИРОВАНИЯ БД ГИС

Хотя некоторые ошибки могут происходить в результате недостатков вычислительных алгоритмов, ошибок кодирования программ и ошибок округления, и это действительно случается время от времени, все же большинство ошибок в БД обусловлены неправильным вводом.

Даже при самых педантичных процедурах подготовки карт, прекрасном оборудовании и отлично обученном персонале ошибки будут случаться. Среди причин - просто нажатие не той кнопки на курсоре дигитайзера, дрожание руки из-за усталости, опечатки при вводе атрибутов и даже трудности позиционирования курсора. Фактически, потенциальных источников ошибок - множество, включая проблемы с самими вводимыми картами [Laurini, 1994]. Но наиболее утомительным аспектом ошибок является не их источник, а то, что, поскольку такие ошибки обычно очень малы и чрезвычайно трудны для обнаружения даже с наилучшим программным обеспечением, их корректировка требует много времени и денег. Вполне возможно, что на корректировку даже небольшого числа ошибок будет потрачено времени больше, чем на подготовку и ввод карты. Ваш преподаватель может предложить упражнение в редактировании для того, чтобы познакомить вас с тщетностью часового поиска единственной ошибки, которая в принципе может быть исправлена. Такой урок — хорошее напоминание о том, что нужна тщательная подготовка перед вводом, так как редактирование еще более утомительно, чем ввод.

Мы затронули три распространенных типа ошибок. Чтобы хорошенько их запомнить, повторим их сейчас. Первый относится главным образом к векторным системам и называется графической ошибкой. Такие ошибки встречаются трех видов: пропуск объекта, неправильное положение объекта (ошибка положения, positional error) и неправильный порядок объектов (disordered entities). Позже мы обсудим это подробнее. Второй тип ошибок это ошибки атрибутов (attribute error). Они встречаются и в векторных и в растровых системах, с одинаковой частотой. Чаще всего они являются опечатками, а огромный объем работы, требующийся для больших БД, часто оказывается главным источником ошибок. В векторных системах ошибки атрибутов включают использование неправильного кода для атрибута, ошибки записи одинаковых по произношению, но разных по написанию слов, что делает невозможной выборку атрибута, если в запросе использована корректная запись. В случае растра ввод чаще всего состоит из атрибутов, поэтому результатом набора неправильного кода или помещения его в неправильную ячейку растра является карта, которая показывает эти неправильно кодированные ячейки в неправильных местах. Такие неправильно расположенные атрибутивные данные образуют третий тип ошибок, ошибки согласования графики и атрибутов (entity-attribute agreement error, or logical consistency), которые случаются и в векторных системах, когда правильно набранные коды атрибутов связываются с неправильными графическими объектами.

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

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

Хотя вы это уже слышали, ничего страшного не случится, если вы услышите это еще раз. Ошибочные данные ведут к ошибочным результатам анализа. И хотя отдельные ошибки могут выглядеть вполне безобидными, даже самые мелкие из них могут приводить к результатам, которые существенно некорректны. В качестве простого примера представьте себе БД, содержащую более 8000 полигонов, некоторые из которых изображают положения высокотоксичных материалов; а один полигон (скажем, номер 2003) имеет неправильный код атрибута, показывающий, что в это месте нет токсичных материалов. В вашем анализе вы ищете области, которые соответствуют наибольшей смертности от рака. И оказывается, что ее наибольшая величина в покрытии статистики смертности соответствует полигону 2003 в покрытии с токсическими веществами. Таким образом, хотя соображения здравого смысла говорят вам о прямой пространственной корреляции между наибольшей смертностью от рака и высокотоксичными веществами, ваш анализ не сможет это продемонстрировать. Сначала ваш географический анализ дал неправильные результаты. Потом могут оказаться неправильными решения по очистке от токсических веществ. Такие ошибочные решения являются одной из тем идущей в наши дни дискуссии о юридической ответственности авторов баз данных ГИС для принятия решений [Epstein, 1989; Seipel, 1989]. И хотя этот пример может выглядеть крайностью, он должен показать, что всегда возможно получить большие ошибки анализа из мелких ошибок в данных. Боязнь судебного иска -хорошая причина для того, чтобы потратить время, необходимое на достижение целостности и точности базы данных.

Не нашли, что искали? Воспользуйтесь поиском: