2.4 Введення, збереження та редагування бд гіс

У растрових системах головними даними є значення атрибутів осередків растра, що зберігаються в комп'ютері звичайно на твердому диску. Положення кожного осередку растра визначається щодо положень інших осередків растра. З цієї причини редагування зв'язане головним чином із правильним відносним положенням кожного осередку растра.

Якщо растрова система забезпечує зв'язок із зовнішньої СУБД, питання стає трохи складніше в тім, що кожному осередкові растра приєднано кілька різних кодів атрибутів.

У випадку векторів графіка й атрибути зберігаються або як окремі таблиці всередині однієї БД, або як самостійні набори даних, зв'язані набором покажчиків. Поділ графіки й атрибутів вимагає уваги до процедур редагування, застосовуваним до графіки, атрибутам і базам даних. Багато векторні ГІС дозволяють зберігати окремо частини БД, як великі секції для цілей архівування Ця процедура, називана мозаїчним розміщенням, найчастіше використовується для зменшення обсягу даних, необхідних для одноразового аналізу в дуже великих БД. Хоча мозаїка не вимагає застосування такої формальної схеми, багато хто вважають її корисною для спрощення управління даними.

Найчастіше БД цілком редагується і вичищається перед мозаїчною розбивкою, архівацією і визначенням доступу для відновлення й аналізу. Але так буває не завжди, і тоді вам доведеться вибирати підходящі блоки для редагування. У деяких випадках може знадобитися виконання операції ув'язування по границях блоків для забезпечення стикування частин об'єктів, що перетинають границі блоків.

Загалом, сучасне програмне забезпечення ГІС, будь те растрове, векторне або на квадродереві, забезпечує механізм візуального відображення, що підвищує можливості візуалізації помилок. Конкретні методи будуть залежати від використовуваної моделі даних і складності системи. Оскільки більшість систем дають можливість інтерактивного редагування усередині підсистеми візуалізації, то звичайно мається також і можливість коректувати помилки безпосередньо при виявленні кожної з них.

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

Перший тип помилок відноситься головним чином до векторних систем і називається графічною помилкою. Такі помилки зустрічаються трьох видів: пропуск об'єкта, невірне положення об'єкта і невірний порядок об'єктів.

Другий тип помилок це помилки атрибутів. Вони зустрічаються й у векторних і в растрових системах, з однаковою частотою. Найчастіше вони є помилками, а величезний обсяг роботи, що вимагається для великих БД, часто виявляється головним джерелом помилок. У векторних системах помилки атрибутів включають використання невірного коду для атрибута, помилки запису однакових за вимовою, але різних за написанням слів, що унеможливлює вибірку атрибута, якщо в запиті використаний коректний запис. У випадку растра введення найчастіше складається з атрибутів, тому результатом набору невірного коду або приміщення його в невірний осередок растра є карта, що показує ці невірно кодовані осередки в невірних місцях. Такі невірні розташовані атрибутивні дані утворять третій тип помилок, помилки узгодження графіки й атрибутів, що трапляються й у векторних системах, коли вірно набрані коди атрибутів зв'язуються з невірними графічними об'єктами.

Методи, за допомогою яких це буде зроблено, залежать до деякої міри від наявного устаткування і від конкретної системи, що під рукою. Незалежно від того, що за система і як вводять у неї просторові дані, підсистема введення буде мати загальні з іншими характеристики. По-перше, вона спроектована для переносу графічних і атрибутивних даних у комп'ютер. По-друге, вона повинна відповідати хоча б одному з двох фундаментальних методів представлення графічних об'єктів - растровому або векторному. По-третє, вона повинна мати зв'язок із системою збереження і редагування, щоб гарантувати збереження і можливість вибірки того, що введено, і що можна буде усувати помилки і вносити зміни в міру необхідності.

Правило номер один говорить: насамперед визначите, для чого ви створюєте БД ГІС. Це щонайменше обмежить уведення даних темами, що швидше за все будуть використовуватися. Тематичні покриття, що вводяться, повинні бути прямо зв'язані з моделюванням і аналізом, що ви маєте намір виконувати, і результатами, що маєте намір одержати.

Необхідність визначення того, які покриття знадобляться в майбутньому, являє собою деяку проблему. Єдиним випадком, коли база даних може створюватися без чіткого розуміння передбачуваного результату (іноді називаного просторово-інформаційним продуктом, є проекти, головна мета яких - визначити можливі взаємозв'язки між даними тематичних покрить для формулювання початкової наукової гіпотези. Цей підхід не прийнятний для комерційних проектів.

Тому правило номер два, зв'язане з першим, вимагає як можна більш точного визначення цілей перед вибором тематичних покрить.

Правило третє: уникайте використання даних з екзотичних джерел, коли маються звичайні, особливо якщо останні забезпечують подібний рівень точності.

Правило четверте: використовуйте найкращі, найбільш точні дані, необхідні для вашої задачі.

Правило п'яте: вибирайте адекватний рівень точності даних.

Більшість тематичних карт містять також інформацію про дороги й інші антропогенні об'єкти, що можуть бути дуже корисними для введення в ГІС. Скрізь, де можливо, і де їхня якість прийнятна, належить уводити ці дані як окремі покриття з того ж листа карти.

Правило шосте, говорить, що кожне покриття повинне бути як можна більш спеціалізованим. Тобто покриття повинні бути як можна більш спеціалізовані за темами. Чим більш спеціалізоване покриття, тим легше виконувати пошук, якщо треба довідатися щось, що відноситься до даних, які утримуються в одному покритті.