Яка різниця між покриттям, шаблонами файлів та базами даних геоданих в ArcGIS?

Мені було цікаво про різницю в методології зберігання просторових даних, використовуваній Покриттями, Шаблонами даних та Базами геоданих в ArcGIS. Початковий формат покриття був слідом за файлами форми та тепер базами даних геоданих. Отже, що покращилося в цих новіших форматах баз даних Shapefiles та Geodataba?

Було б чудово, якби хтось міг пояснити це на прикладах.

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

1. Покриття:

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

«Чистий» покриття гарантує певні правила, наприклад, що є вузли на кожному вузлі перетину, ви не будете мати два (або більше) вузли друг на друга (або навіть в межах нечіткого відстані допуску), що не існує два ребра один на одного і т. д. Вони також мають відчуття напрямку (від-> до) і можуть перешкоджати між лівою та правою сторонами.

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

Покриття можуть бути дещо складнішими для роботи, коли ви маєте справу з 3D-даними (наприклад, моделювання моста, який має верхню та нижню сторону праворуч внизу), оскільки алгоритми, які ми використовували для роботи з ними, по суті мали на увазі для двовимірного плоского графа математики .

То чому ми віддалилися від цього? Це потребує більш тривалої відповіді, але, можливо, ми повинні пояснити трохи більше, що зробило ESRI Shapefiles першими популярними.

2. Шаблони ESRI:

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

Чи є кілька геометрій, які перетинаються одна з одною? Звісно, ​​чому б ні. Дві точки один на одного? Будь моїм гостем.

Іноді (мабуть) "найкращий" формат - це не той, хто виграє, а той, який стає прийнятим. Якщо формат легко реалізувати, він має більше шансів бути прийнятим, ніж складний. Це був Shapefile.

Раптом у вас було декілька бібліотек (відкритого та фірмового) та постачальників програмного забезпечення, які підтримували це. Так що все було чудово.

Очевидне питання тоді - чому геодані?

3. Геодані:

Я вважаю, що база даних геоданих є однією з найбільш неправильно зрозумілих сховищ геопросторових даних. Люди зазвичай вважають їх просто "геопросторовим форматом". Пару років тому хтось запитав "Що таке геодезичні бази ESRI?" . Замість того, щоб повторювати мою відповідь тоді, я вітаю вас першим прочитати це. Я зачекаю :)

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

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

Я сподіваюся, що це допомагає!

Більшість інформації можна знайти в довідці Esri та в пошуку, тому я тільки що склав кілька хороших читань.

Як зберігаються покриття? Оскільки це власний формат, ви не знайдете жодних технічних специфікацій щодо реалізації алгоритмів (якщо тільки @Vince не прожене трохи світла).

Пізніше Shapefiles з'явилися і були реалізовані як стандарт, який забезпечував певний рівень сумісності. Технічний опис шаблону ESRI містить повний опис.

Пізніше були введені бази даних геоданих. Спочатку з'явилися персональні бази даних геоданих (MS Access), потім файли баз геоданих (бінарний зашифрований формат) та бази даних корпоративних (або ArcSDE), які скористалися ArcSDE та технологією СУБД. Більше про геодані можна прочитати тут: Типи баз геоданих та Архітектура бази даних геоданих .

Гарне прочитання на GIS.SE: Чи слід використовувати File Geodatabase (* .gdb), персональну базу даних Geodata (* .mdb) або shapefiles?

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

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

Основна відмінність цих форматів полягає в тому, як особливості стосуються геометрії. Ще в розквіті покриттів мовою кодування було FORTRAN, що означало фіксований розмір буфера в блоках COMMON. Найбільш обмежувальним з них було 500 вершин на первісний рядок ("дуга"). Це обмеження ввело поняття "псевдовузли" (місця, де дуги з'єднуються лише з однією іншою дугою), і ускладнило багато інших операцій доступу до даних.

Модель покриття використовувала "список багатокутних дуг" (PAL) для опису багатокутників, для чого потрібен алгоритм затінення багатокутника, щоб прочитати один файл, щоб отримати список дуг, потім прочитати самі дуги, щоб отримати кількість вершин, а потім виділити достатню кількість оперативної пам'яті, щоб зберігайте всі вершини, а потім поверніться, щоб знову прочитати дуги, на цей раз скопіювавши вершини в прямому або зворотному порядку, щоб зібрати повний багатокутник. Лише після двох відвідувань файлу ARC полігон міг бути адекватно описаний, і тоді потрібно було б отримати доступ до багатьох тих самих дуг (у зворотному напрямку), щоб затінити сусідів полігону.

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

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

Ще одна відмінність форматів полягає в тому, що база даних може моделювати зв'язки між класами особливостей . Як зазначив Рагі,

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

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

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

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

Інструменти редагування топології в ArcMap допоможуть вам знайти топологічні порушення , а в деяких випадках і автоматично виправити їх .

До впровадження топології бази даних геоданих ("старі добрі часи") було прийнято писати довгі і складні сценарії AML для виявлення топологічних порушень, а потім редагувати покриття вручну в ArcEdit (не так весело).