Публікація векторних карт h2>
Пєчніков Олексій Олегович, керівник
геоінформаційного проекту "GeoMapX" p>
Підготовка
векторних карт до виду, придатного для їх використання у геоінформаційних
системах (ГІС), є необхідною частиною процесу створення карти. Однак у
даний час практично всі вітчизняні карти не можуть бути завантажені в
ГІС без значних доопрацювань, а часто потрібно їх векторизація заново.
Причиною є як множинні порушення топології, так і проблеми
денормализация просторових і метаданих. У Росії повсюдно використовуються
векторні карти у файловому форматі програми MapInfo, значно рідше - в
форматах ArcView, ArcGIS та інших, у той час як у світовій практиці великі
масиви просторових даних зберігають в так званих просторових
сховищах даних (spatial datasets), що представляють собою реляційні або
об'єктно-реляційні бази даних (БД) з підтримкою геометричних типів даних
і операцій над ними. Прикладом таких баз даних є PostgreSQL з модулем
PostGIS і Oracle. Застосування зазначеного підходу забезпечує логічну
цілісність даних і зручність застосування будь-яких перетворень даних, як у
інтерактивному режимі (під управлінням оператора), так і в пакетному режимі
(повністю автоматично, за заданим алгоритмом). Одним з таких
перетворень є зміна проекції карт "на льоту". Побудувавши
реляційне сховище просторових даних, можна отримувати з нього
різноманітні набори карт у довільній проекції, а також автоматично
генералізовані карти або синтетичні, що містять результати аналізу
збереженої географічної інформації (геоінформації). Стаття присвячена питанням
підготовки векторних карт для побудови просторових сховищ даних для
подальшого їх використання в ГІС. p>
В
загальному випадку процес підготовки векторних карт може бути представлений набором
наступних кроків: p>
Крок
1. Завантаження в БД. p>
Крок
2. Перевірка топології просторових об'єктів. p>
Крок
3. Нормалізація даних. p>
Крок
4. Агрегація даних. p>
Крок
5. Попередній аналіз та обчислення функціоналів (площа, периметр,
протяжність та ін.) p>
Розглянемо
кожен крок більш докладно. p>
Крок
1. Перетворення в sql-формат для збереження в БД може бути зроблене зі стандартного
обмінного формату шейпфайлов із застосуванням спеціальних утиліт. Завантаження в БД
sql-файл може вироблятися як вручну, так і з використанням
допоміжних програм. p>
Після
виконання перетворення необхідно перевірити, чи всі об'єкти були збережені в
БД. Для цього з БД об'єкти вивантажуються в шейпфайл новий і проводиться звірка
отриманого файлу з вихідним. Незбережені об'єкти заново векторізуются або
коригуються вручну, після чого додаються до БД. Описана процедура
повторюється до тих пір, поки всі об'єкти не будуть успішно збережено в БД. Варто
відзначити, що більшість вітчизняних карт з якими працював автор,
виявилися повністю непридатні і повинні бути оцифровані заново. І лише
деякі карти, виготовлені фахівцями, успішно і без особливих проблем
завантажуються в БД. Крім того, існують програми, які зберігають в БД
безпосередньо шейпфайли, виконуючи перетворення приховано від користувача.
Однак у більшості випадків з російськими картами такі програми не можуть працювати,
оскільки вимагають вихідні карти з коректної топологією. Так що практично
карти потрібно вантажити вручну, як описано вище, після чого перевіряти і
виправляти топологію об'єктів. p>
Крок
2. У тому випадку, коли вихідна карта має порушену топологію (практично
завжди для вітчизняних карток), необхідно виявити всі об'єкти з порушеною
топологією і виправити їх поза базою, аналогічно описаної в Шаге 1 методикою.
Визначення нетопологічних об'єктів є стандартною операцією над набором
просторових даних і може виконуватися у пакетному режимі засобами БД. p>
Крок
3. Поняття нормалізації суворо визначено в теорії реляційних баз даних.
Нормальна форма вибирається в залежності від специфіки вирішуваних завдань. Зауважимо,
що ненормалізованная БД працювати буде, але не настільки ефективно, як це може
бути досягнуто за рахунок нормалізації. Крім того, процедура приведення до
нормальній формі дозволяє швидко знайти і виправити помилки в аттрібутівних
даних. p>
Крок
4. Просторові типи даних можуть бути як простими (крапка, лінія або
полігон), так і складними (набір точок, ліній або полігонів). Агрегація
геоданних являє собою глобальну процедуру агрегування об'єктів. Інакше
кажучи, всі об'єкти (як прості, так і складові), які є логічними частинами
складних структур, повинні бути об'єднані в складові об'єкти. Зазначене
перетворення є синтетичним і при успішному використанні дозволяє
об'єднувати в одному сховищі карти різних масштабів, забезпечуючи прозорий
(непомітний для користувача) перехід між різномасштабними картами. Наскільки
відомо автору, у вітчизняній практиці описаний підхід не застосовується.
Алгоритм агрегування слід реалізовувати дуже акуратно, інакше можливе
виникнення артефактів, опис яких виходить за рамки статті. p>
Крок
5. Робота з даними може бути оптимізована за рахунок попереднього
обчислення значень деяких функцій та їх збереження в БД. Такими функціями
є площа і периметр полігональних об'єктів, протяжність лінійних і
інші. Список часто використовуваних функцій складається в ході попереднього
аналізу роботи ГІС або при тестовий запуск системи. Крім того, також
рекомендується індексування таблиць БД. При великих обсягах даних
індексування просторових даних є необхідним. p>
Застосування
вищеописаного підходу дозволяє створювати швидкі та ефективні ГІС. Автором
створена геоінформаційна система "GeoMapX", з якою ви можете
ознайомитися в мережі Інтернет за адресою http://geomapx.ru p>
Список літератури h2>
Для
підготовки даної роботи були використані матеріали з сайту http://www.citforum.ru/
p>