Впроваджується система управління версіями геопросторових даних? [зачинено]

Мало того, що мені тут потрібна правильна відповідь, але останнім часом я бачив певні зусилля, щоб запровадити поняття "(розподіленої) системи управління версіями" для географічних даних. Деякі приклади (про які я знаю) - це три статті від OpenGeo ( 1 , 2 і 3 ) та проект " Геосинхронізація (геосинхронізація)" норвезьких постачальників програмного забезпечення GIS та Норвезького агентства з картографування. Я також знайшов розподілену версію геопросторових даних? , де згадується GeoGit (від OpenGeo) та Застосування контролю версій до моделей ArcGIS ModelBuilder? про управління версіями в ArcGIS.

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

Які проблеми виникають при роботі з (d) ДКС щодо географічних даних, як би ви їх вирішили, чи потрібні вони нам та чи є інші спроби вирішити ці питання, ніж ті, про які я згадував?

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

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

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

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

Ми оцінили наступні підходи, ось що я можу сказати про них:

1. ESRI Enterprise Geodatabase(ArcGIS 10.1); майже те саме, що було раніше (SDE), але з широким використанням функції версій для обробки транзакцій. Але це насправді не база даних Enterprise Geodatabase. На мою думку, SDE працює лише в робочій групі як сервер геоданих, де люди працюють з 8:00 до 20:00, і ви можете взяти її в автономному режимі для виконання завдань технічного обслуговування, здійснення транзакцій (узгодження версій та публікація в ESRI-мовленні), реплікація тощо ... Якщо ви будуєте служби на основі цих даних, вам потрібно обробляти базу даних по етапах (де виконується робота) з реплікуваною виробничою базою даних. Це майже так само, як збірка / тест і розгортання в програмуванні. Хоча пакет ESRI, багатий на функціональні можливості, є досить приємним, йому не вистачає гнучкості (зміни схеми або завдання технічного обслуговування, коли люди працюють, наприклад, створення індексу).

2. Плоскі файли та система управління версіямими вибираємо Git (не знав, що вже є GeoGit). О так, деякі з моїх друзів і я також походять з програмної інженерії. Все могло бути таким простим. Я думаю, що це її проблема: це як автомобільний механік, що будує автомобіль. Дотримуватися його буде просто, але також дратувати їзду і чортово негарно дивитись точно. Я думаю, що це також має деякі основні недоліки: як керувати версією 2 TeraByte (або навіть більше, бінарний) Rasterdataset? І в якому форматі? Векторні дані можна легко керувати версіями, якщо ви використовуєте текстові формати (наприклад, GML), але також важко працювати з набором даних на мільярд рядків. Я все ще не впевнений, чи зможемо ми ефективно керувати дозволами користувача, тому що не всім потрібно дозволяти редагувати чи навіть переглядати все. І як ви об'єднаєте векторний набір даних, який інтенсивно редагували 4 користувачі одночасно? Принаймні, ви повинні бути справжнім комп'ютерним вченим / програмістом, щоб зробити все це ефективно ... наші користувачі ГІС - це планувальники, геодезисти, геологи тощо. Для них просто проблема думати про версії версій, як це роблять програмісти, або використовувати розгалуження так, як слід. Тим не менш, мислення сховищ даних як спільних репостів є цікавою ідеєю.

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

4. Bigdata та NoSQL . Ті ж проблеми, що і плоскі файли та плоскі таблиці. На мій погляд, простий API файлової системи для використання в Інтернеті. Так, він добре працює в Інтернеті, і так, просто його передати документи, але я думаю, що якщо я хочу здійснити аналіз просторових даних на терабайтах (можливо, растрових) даних, мені подобається, щоб вони не були серіалізовані та десеріалізовані через HTTP-інтерфейс.

ОНОВЛЕННЯ 2018: Ось багато нового, що створює багато імпульсу. Назвати декілька:

• Хмарне сховище та HDFS
• Python / стройно / Dask Stack

• Apache Spark

  • GeoMesa / GeoWave для векторних даних
  • GeoTrellis для растрових даних

• і багато іншого

  5. Комплексне класичне моделювання баз даних(з RDBMS). Основна проблема полягає в тому, що важко просто скинути дані куди завгодно і сподіватися, що вони підходять під будь-яку майбутню потребу. Але якщо ви вкладете в базу даних кількість часу, щоб вказати надійну модель даних (OSM також це зробив насправді), ви зможете використати всі її переваги. Ми можемо редагувати та оновлювати дані в розподілених транзакціях, ми також можемо змінювати їх основні схеми, в той час як сервіси все ще покладаються на зовнішні схеми одних і тих же даних, ми можемо їх підтримувати, ми можемо перевірити його узгодженість, ми можемо дозволити і заборонити дозволи, ми в змозі зберігати дуже великі обсяги даних, поки ми все ще можемо швидко отримати доступ до них, ми можемо створити історизуючі моделі даних та запустити їх прозоро тощо. Оскільки ми використовуємо sql-сервер, нам все ще не вистачає рідного растрового типу, але інші виробники баз даних вже пропонують це.

Я думаю, що модель реляційних баз даних просто з’являється в просторовому світі з типами просторових даних за останні пару років (до цього це контейнери BLOB) і досі є найбільш гнучкою та професійною формою зберігання даних. Це не означає, що він не повинен доповнюватися підходами VCS або NoSQL, але я вважаю ці підходи скоріше формою розподілу даних у групах користувачів, ніж як формою професійного централізованого управління просторовими даними. Також OSM централізував безліч завдань, які натовп просто не може надати, наприклад, імпорт великих обсягів даних (більшість OSM-даних в Австрії було імпортовано за день, а не з масовим замовленням) та створення плитки. Справді дуже важлива частина (співпраця з натовпу), але це лише її половина.

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