6. Проверка работоспособности модели

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

Используя подмножество изучаемой области и блок-схему модели, мы начинаем с нижнего уровня каждой подмодели и, выполняя ее действия, отвечаем на следующие вопросы:

1. Если мы переклассифицируем категории, то сконфигурирована ли наша БД для выборки соответствующих значений? Или, если мы переклассифицируем категории в растровой системе без БД, имеет ли значение порядок переклассификации?

2. Если есть альтернативные методы или альтернативные комбинации методов, то какие из них скорее дадут нам корректный ответ при наименьших затратах труда?

3. Есть ли у нас абсолютная уверенность в том, что выбранные операции действительно представляют функционирование моделируемой среды?

4. Что мы будем делать с недостающими переменными в каждом покрытии, если таковые обнаружатся?

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

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

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

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