Подготовка векторных карт к виду, пригодному для их использования в геоинформационных системах (ГИС), является необходимой частью процесса создания карты. В настоящее время практически все отечественные карты(карты России, карты Украины, карты Белоруссии) не могут быть загружены в ГИС без значительных доработок, а зачастую требуется их векторизация заново. Причиной являются как множественные нарушения топологии, так и проблемы денормализации пространственных и метаданных. В России повсеместно используются векторные карты в файловом формате программы MapInfo, значительно реже - в форматах ArcView, ArcGIS и других, в то время как в мировой практике большие массивы пространственных данных сохраняют в так называемых пространственных хранилищах данных (spatial datasets), представляющих собой реляционные или объектно-реляционные базы данных (БД) с поддержкой геометрических типов данных и операций над ними. Примером таких баз данных являются PostgreSQL с модулем PostGIS и Oracle. Применение указанного подхода обеспечивает логическую целостность данных и удобство применения любых преобразований данных, как в интерактивном режиме (под управлением оператора), так и в пакетном режиме (полностью автоматически, по заданному алгоритму). Одним из таких преобразований является изменение проекции карт "на лету". Построив реляционное хранилище пространственных данных, можно получать из него разнообразные наборы карт в произвольной проекции, а также автоматически генерализованные карты или синтетические, содержащие результаты анализа хранимой географической информации (геоинформации).
В общем случае процесс подготовки векторных карт может быть представлен набором следующих шагов:
Шаг 5. Предварительный анализ и вычисление функционалов (площадь, периметр, протяженность и проч.)
Рассмотрим каждый шаг более подробно.
Шаг 1. Преобразование в sql-формат для сохранения в БД может быть произведено из стандартного обменного формата шейпфайлов с применением специальных утилит. Загрузка в БД sql-файла может производиться как вручную, так и с использованием вспомогательных программ.
После выполнения преобразования необходимо проверить, все ли объекты были сохранены в БД. Для этого из БД объекты выгружаются в новый шейпфайл и производится сверка полученного файла с исходным. Несохраненные объекты заново векторизуются или корректируются вручную, после чего добавляются в БД. Описанная процедура повторяется до тех пор, пока все объекты не будут успешно сохранены в БД. Стоит отметить, что большинство отечественных карт с которыми работал автор, оказались полностью непригодны и должны быть оцифрованы заново. И лишь некоторые карты, изготовленные специалистами, успешно и без особых проблем загружаются в БД. Кроме того, существуют программы, которые сохраняют в БД непосредственно шейпфайлы, выполняя преобразование скрытно от пользователя. Однако в большинстве случаев с российскими картами такие программы не могут работать, поскольку требуют исходные карты с корректной топологией. Так что практически карты нужно грузить вручную, как описано выше, после чего проверять и исправлять топологию объектов.
Шаг 2. В том случае, когда исходная карта имеет нарушенную топологию (практически всегда для отечественных карт), необходимо выявить все объекты с нарушенной топологией и исправить их вне базы, аналогично описанной в Шаге 1 методике. Определение нетопологичных объектов является стандартной операцией над набором пространственных данных и может выполняться в пакетном режиме средствами БД.
Шаг 3. Понятие нормализации строго определено в теории реляционных баз данных. Нормальная форма выбирается в зависимости от специфики решаемых задач. Заметим, что ненормализованная БД работать будет, но не столь эффективно, как это может быть достигнуто за счет нормализации. Кроме того, процедура приведения к нормальной форме позволяет быстро найти и исправить ошибки в аттрибутивных данных.
Шаг 4. Пространственные типы данных могут быть как простыми (точка, линия или полигон), так и составными (набор точек, линий или полигонов). Агрегирование геоданных представляет собой глобальную процедуру агрегирования объектов. Иначе говоря, все объекты (как простые, так и составные), являющиеся логическими частями сложных структур, должны быть объединены в составные объекты. Указанное преобразование является синтетическим и при успешном использовании позволяет объединять в одном хранилище карты разных масштабов, обеспечивая прозрачный (незаметный для пользователя) переход между разномасштабными картами. Насколько известно автору, в отечественной практике вышеописанный подход не применяется. Алгоритм агрегирования следует реализовывать очень аккуратно, иначе возможно возникновение артефактов, описание которых выходит за рамки статьи.
Шаг 5. Работа с данными может быть оптимизирована за счет предварительного вычисления значений некоторых функций и их сохранения в БД. Такими функциями являются площадь и периметр полигональных объектов, протяженность линейных и другие. Список часто используемых функций составляется в ходе предварительного анализа работы ГИС или при тестовом запуске системы. Кроме того, также рекомендуется индексирование таблиц БД. При больших объемах данных индексирование пространственных данных является необходимым.
