Управління великою кількістю геопросторових даних? [зачинено]

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

Я також хочу почути, чи хтось управляє своїми геопросторовими даними в системі контролю ревізії; Зараз я використовую його для свого коду та невеликих наборів даних, але не для повних наборів даних.

Я думаю, що базовою / очевидною відповіддю було б використання просторової бази даних (PostGIS, Oracle, SDE, MSSQL Spatial тощо) спільно з сервером метаданих, таким як GeoPortal esri або з відкритим кодом GeoNetwork, і в цілому я думаю, що це взагалі найкраще рішення. Однак ви, ймовірно, завжди матимете необхідність у проектних знімках / гілках / тегах. Деякі з більш досконалих баз даних мають способи управління ними, але вони, як правило, не такі прості в користуванні / керуванні.

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

Я бачив деякі цікаві рішення, хоча ...

Ще тоді, коли Міністерство навколишнього середовища Британського Комітету працювало над покриттями дуги / інформації, у них був дуже класний процес двосторонньої синхронізації на основі rsync. Покриття, що знаходились під центральним контролем, вночі були витіснені в регіони, і регіональні дані були відтіснені. Цей диференціальний перехід на рівні блоку працював дуже добре, навіть за 56 к посилань. Були подібні процеси для тиражування баз даних атрибутів на базі Oracle, але я не думаю, що вони, як правило, надто добре надходили через комутацію :)

Моє поточне місце роботи використовує подібне гібридне рішення. Кожен набір даних має свою авторитетну копію (одні в Oracle, інші в MapInfo, інші в особистих базах даних), і це перехресні ETL-ночі за допомогою FME. Тут є досить великі головні витрати, що стосуються технічного обслуговування; зусилля для створення будь-якого нового набору даних та забезпечення організаційної видимості значно вищі, ніж повинні бути. Ми переглядаємо процес розгляду, щоб знайти певний спосіб консолідації, щоб уникнути цього.

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

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

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

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

Ми використовували файлову систему, організовану ієрархічно за: - географічним ступенем (країна чи континент) - постачальником даних, ліцензіаром - доменом / набором даних - датою / версією

Після цього ми маємо політику відокремлювати вихідні дані (у тому самому форматі, який був на будь-якому CD / DVD, який ми отримали від постачальника) від будь-яких отриманих наборів даних, які ми виробляли в нашій компанії.

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

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

І так, у нас є хтось, хто відповідає за "поліцію" всієї справи, щоб вона не була занадто безладною.

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

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

Як сказав @JasonBirch, контроль над версіями - величезна проблема.

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

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

Postgres так, як говорили інші, однак якщо ви хочете зберегти його портативним та зручним для переміщення, то ви завжди можете подивитися на використання розширення SQLite + Spatialite.

Не такий простий у використанні, як Postgres, з точки зору інструментів управління, але QGis МОЖЕ говорити безпосередньо з базою даних GIS без проблем.

Я фактично використовую SQLite + Spatialite для резервного копіювання, у мене є служба Windows, яка працює у фоновому режимі (написана на замовлення), яка відстежує мій екземпляр PGSql і відображає мої дані GIS у різних БД SQLite, які знаходяться на зовнішніх накопичувачах USB.

Ще одна порада з PG, також використовуйте схеми

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

Наприклад, у моїй базі даних "Ordnance_Survey" є схеми для VectormapDistrict VectormapLocal Topo50 LookupGrids CodePointWithPolygons CodePointOpen

де я зберігаю всі супутні дані.

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

Як згадується в попередньому дописі, просторові БД і сервер метаданих - це звичайна установка. Я думаю, що одне ключове, що потрібно пам’ятати, - це те, що «один розмір не підходить усім». Ви отримаєте дані, які найкраще підходять для Oracle, файлових серверів, SQL-сервера, будь-якого іншого. Я намагався взувати всі дані, необхідні в одному рішенні, і це зазвичай не вдається.

Розраховуйте використовувати різні рішення, які відповідають даним та планують їх. Тут справді заходить геопортал (сервер метаданих).

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

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

Postgres + PostGIS: Підтримує геопросторові індекси та всілякі запити, які ви можете собі уявити. Для управління вашими терабайтами даних вам потрібно застосувати шарнінг, оптимізацію запитів тощо. Якщо завантаження вами велике, я б не рекомендував цього.

MongoDB: Це підтримує велику кількість даних. Чудово підходить для простого зберігання, пошуку та обмежених геопросторових запитів.

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

Redis: Ви можете комбінувати будь-який із перерахованих вище параметрів із підтримкою Redis Geo, щоб зберігати невелику кількість «гарячих» даних у redis, до яких потрібно часто отримувати доступ. Подумайте про це як про свій кеш.