Формалізована методологія проектування ГІС.

Спіральна модель – швидке створення прототипів. У 1994 році групою фахівців в США був розроблений та реалізований гнучкий багаторівневий процес проектування – спіральна модель. В ньому виділяється три рівня детальності і три завдання проектування геоінформаційної системи: збір, організація і аналіз інформації (рис. 8.5).

 

 

Перший рівень – початкова модель – найбільш загальна основа обговорення реалізації ГІС. Другий рівень – концептуальна модель включає аналіз потреб і перше обговорення проектування бази даних. Третій рівень – детальне проектування – відпрацьовуються питання конкретного програмного забезпечення для реалізації системи.

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

Розглянемо тільки початкову модель та загальні питання руху по спіралі. Кожний блок цієї моделі має кілька детальних рівнів. Концептуальна і детальна моделі також мають кілька рівнів деталізації. На першому кроці (рис. 8.6) інформація про завдання від користувача використовується для визначення цілей організації. Другий крок (1.1.2) – визначення того, як повинна і що повинна робити геоінформаційна система.

Завдання всіх можливих користувачів повинні бути ураховані при визначенні цілей створення геоінформаційної системи. Корисним методом є з’ясування того, які кінцеві просторово-інформаційні продукти прагнуть отримати користувачі від системи. Тому нам потрібно визначити відношення між цими просторово-інформаційними продуктами, які потрібні користувачу в організації і завданнями, які кожний з них повинен виконати.

 

 

	Рис. 8.6. Кроки процесу проектування. Початкова модель, як послідовність рішень про продовження або відмову від впровадження ГІС в організації.

 

 

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

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

Далі ми переходимо до кроку 1.2.2, порівнюючи потреби користувачів з наявними обмеженнями.

Наступні кроки (1.2.3 і 1.2.4) напрямку використовують результати потреби користувачів і наявних обмежень. Перевизначення цілей, що пов’язані з геоінформаційною системою, або обмежень розробки (крок 1.2.3) може потребувати вирішення конфлікту при формуванні балансу потреб і обмежень для визначення ступеню реалізуємості геоінформаційної системи. Такий баланс важко досягається, тому потрібно буде встановити деякі пріоритети і ними користуватися в подальшому. Необхідно відмітити, що вартість реалізації – важливе, але не завжди головне обмеження. Більш вагомим є прибуток, який аналізується на кроці 1.2.4. До витрат входять: вартість придбання даних, апаратного і програмного забезпечення, їх супроводження, навчання і робота персоналу, ввід даних та інші питання. Витрати розподіляються на початкові інвестиції і експлуатаційні витрати.

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

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

Рис. 8.7 а) показує лінійний підхід до проектування геоінформаційної системи, який йде від дослідження реалізуємості системи через стадію проектування до реалізації системи. Як ми бачимо, вивчення системи починається досить пізно, коли система вже спроектована і розпочата її реалізація. Таким чином, користувачі вимушені вивчати та експлуатувати систему, яка може не відповідати їх потребам.

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

Проектування баз даних. Розглянувши основні положення процесу проектування геоінформаційних систем потрібно розглянути і основні положення щодо проектування баз даних.

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

В випадку, коли планується використовувати який-небудь вид інтерполяції то, як ми пам’ятаємо, границя області дослідження повинна бути розширена у достатній мірі, щоб забезпечити коректні результати інтерполяції на її краях. І чим більше область дослідження, тим більше часу і витрат коштів потрібно на створення відповідної бази даних. Це все потрібно пам’ятати.

Масштаб, детальність, дозвільна спроможність. Існує зв’язок між розміром області, яка вивчається, і масштабом карт, які вводяться. Чим дрібніше масштаб карт, тим більше ступінь генералізації, тим менш точніше подані об’єкти місцевості. На вибір масштабу впливає також важливість відповідного покриття (тематичного шару інформації) для моделей аналізу. Тут не існує загальних вказівок для встановлення значення потрібного масштабу, але більшість спеціалістів використовують підхід “використання найкращих доступних даних”. Він передбачає, що чим більше подробиць, тим краще для виконання завдань аналізу.

Крім того нам відомо, що растрові дані мають наступну особливість: з зменшенням розміру чарунок растру швидко зростає обсяг даних. В наслідок цього збільшується час на обробку даних. В одних випадках розмір чарунок растру залежить від розміру найменшого об’єкту, що буде зображений, в інших – вимогами моделі, в третіх – питаннями сумісності з іншими цифровими даними, наприклад, з даними матеріалів дистанційного зондування з супутників.

Класифікація. При проектуванні геоінформаційних систем ми повинні розглядати не тільки наявні джерела даних, але і систему класифікації, яка задовольняє умовам моделювання. Рішення про систему класифікації краще приймати після розгляду видів даних, що вводяться. Використання більш детальної класифікації часто має більше переваг за двома причинами: вона надає користувачу більший обсяг даних і під час порівняння з даними другого покриття меншої детальності (докладності) завжди можна узагальнити деякі класи, в той же час, як зворотній процес або ускладнено, або зовсім неможливо.

Але класифікація – це більше ніж вибір потрібного рівня детальності. Необхідно враховувати, що ми робимо порівняння між покриттями і, таким чином, між класифікаціями. Крім того, часто необхідно мати можливість проводити узгоджену класифікацію в межах одного покриття даних з різних джерел. Якщо ці дослідження приводилися на значному часовому проміжку один від одного, то буде необхідно переробити їх, щоб встановити однорідність класифікації.

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

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

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

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

Перевірка та приймання (затвердження). З точки зору експлуатації, методологія проектування геоінформаційної системи позитивна лише настільки, наскільки добрі результати були отримані від реалізації. Головне питання на яке потрібно отримати відповідь: Чи буде геоінформаційна система вирішувати необхідні організації завдання своєчасно і коректно?

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

Відомо, що це краще зробити правильно і добре, ніж потім перероблювати кінцевий результат. Вартість переробки може бути набагато більше, ніж вартість розробки правильної системи на основі систематичного, повного і добре організованого аналізу потреб організації.

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