Подготовка векторных карт к виду, пригодному для их использования в геоинформационных системах (ГИС), является необходимой частью процесса создания карты. Однако в настоящее время практически все отечественные карты не могут быть загружены в ГИС без значительных доработок, а зачастую требуется их векторизация заново. Причиной являются как множественные нарушения топологии, так и проблемы денормализации пространственных и метаданных. В России повсеместно используются векторные карты в файловом формате программы MapInfo, значительно реже - в форматах ArcView, ArcGIS и других, в то время как в мировой практике большие массивы пространственных данных сохраняют в так называемых пространственных хранилищах данных (spatial datasets), представляющих собой реляционные или объектно-реляционные базы данных (БД) с поддержкой геометрических типов данных и операций над ними. Примером таких баз данных являются PostgreSQL с модулем PostGIS и Oracle. Применение указанного подхода обеспечивает логическую целостность данных и удобство применения любых преобразований данных, как в интерактивном режиме (под управлением оператора), так и в пакетном режиме (полностью автоматически, по заданному алгоритму). Одним из таких преобразований является изменение проекции карт "на лету". Построив реляционное хранилище пространственных данных, можно получать из него разнообразные наборы карт в произвольной проекции, а также автоматически генерализованные карты или синтетические, содержащие результаты анализа хранимой географической информации (геоинформации). Статья посвящена вопросам подготовки векторных карт для построения пространственных хранилищ данных для дальнейшего их использования в ГИС.

В общем случае процесс подготовки векторных карт может быть представлен набором следующих шагов:

• Шаг 1. Загрузка в БД.
• Шаг 2. Проверка топологии пространственных объектов.
• Шаг 3. Нормализация данных.
• Шаг 4. Агрегирование данных.
• Шаг 5. Предварительный анализ и вычисление функционалов (площадь, периметр, протяженность и проч.)

Рассмотрим каждый шаг более подробно.

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

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

Шаг 2. В том случае, когда исходная карта имеет нарушенную топологию (практически всегда для отечественных карт), необходимо выявить все объекты с нарушенной топологией и исправить их вне базы, аналогично описанной в Шаге 1 методике. Определение нетопологичных объектов является стандартной операцией над набором пространственных данных и может выполняться в пакетном режиме средствами БД.

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

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

Шаг 5. Работа с данными может быть оптимизирована за счет предварительного вычисления значений некоторых функций и их сохранения в БД. Такими функциями являются площадь и периметр полигональных объектов, протяженность линейных и другие. Список часто используемых функций составляется в ходе предварительного анализа работы ГИС или при тестовом запуске системы. Кроме того, также рекомендуется индексирование таблиц БД. При больших объемах данных индексирование пространственных данных является необходимым.

Применение вышеописанного подхода позволяет создавать быстрые и эффективные ГИС. Автором создана геоинформационная система "GeoMapX", с которой вы можете ознакомиться в сети интернет по адресу http://geomapx.ru