Управление большими объемами геопространственных данных? [закрыто]

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

Мне также интересно узнать, управляет ли кто-нибудь своими геопространственными данными в системе контроля версий; В настоящее время я использую один для своего кода и небольших наборов данных, но не для полных наборов данных.

Я думаю, что стандартным / очевидным ответом было бы использование пространственной базы данных (PostGIS, Oracle, SDE, MSSQL Spatial и т. Д.) В сочетании с сервером метаданных, таким как Esri GeoPortal или приложение GeoNetwork с открытым исходным кодом, и в целом, я думаю, что это в целом лучшее решение Тем не менее, вам, вероятно, всегда будут нужны основанные на проекте снимки / ответвления / теги. Некоторые из более продвинутых баз данных имеют способы управления ими, но, как правило, они не так просты для пользователя / управления.

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

Я видел некоторые интересные решения, хотя ...

Еще в то время, когда Министерство охраны окружающей среды BC работало над покрытиями Arc / Info, у них был действительно крутой процесс двусторонней синхронизации на основе rsync. Покрытия, которые находились под центральным контролем, передавались в регионы по ночам, а региональные данные возвращались обратно. Эта дифференциальная передача на уровне блоков работала действительно хорошо, даже по линиям связи по 56 тыс. Были аналогичные процессы для репликации баз данных атрибутов на основе Oracle, но я не думаю, что они, как правило, работали слишком хорошо по коммутируемому соединению :)

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

Метаданные - безусловно самая важная проблема здесь. Если метаданные отвечают кому, когда, почему, где это приемлемая запись метаданных.

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

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

Сложный вопрос заключается в том, кто будет отвечать за QA / QC, эти наборы данных и их метаданные. Хотя процессы, управляемые компьютером, работают отлично, они не могут быть такими же строгими, как хороший менеджер данных / хранитель данных, что было сделано в этой компании, с которой я работал. Теперь есть кто-то исключительно для просмотра / фиксации метаданных и организации геопространственных данных, которые не централизованы в СУБД.

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

После этого у нас есть политика для отделения исходных данных (в том же формате, который был на любом CD / DVD, который мы получили от провайдера) от любых производных наборов данных, которые мы произвели в нашей компании.

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

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

И да, у нас есть кто-то, кто отвечает за «охрану» всего этого, так что это не становится слишком грязным.

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

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

Как сказал @JasonBirch, контроль версий - это огромная проблема.

Также мы обнаружили, что соответствующий рабочий процесс чрезвычайно важен. Например, когда мы собираем полевые данные, мы склонны использовать промежуточные базы данных, где полевые данные могут быть проверены перед объединением в основной набор данных. В зависимости от того, сколько данных должно быть проверено, это всегда будет создавать дополнительные издержки.

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

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

Не так легко использовать как Postgres с точки зрения инструментов управления, но QGis МОЖЕТ общаться без проблем с базой данных ГИС с пространственным контролем.

Я на самом деле использую SQLite + Spatialite для резервного копирования, у меня есть служба Windows, которая работает в фоновом режиме (на заказ), которая контролирует мой экземпляр PGSql и зеркалирует мои ГИС-данные в различные базы данных SQLite, которые находятся на внешних USB-накопителях.

Еще один совет с PG тоже, используйте схемы

Многие люди, которых я знаю, просто выкладывают все в «общедоступный» и покончат с этим, но если вы правильно организовываете свою базу данных, это создает мир различий.

Например, в моей базе данных "Ordnance_Survey" есть схемы для VectormapDistrict VectormapLocal Topo50 LookupGrids CodePointWithPolygons CodePointOpen

где я храню все связанные данные.

Между тем таблицы метаданных, такие как столбцы геометрии и т. Д., Все просто живут в Public, расширение Postgis также включено только в общедоступной схеме, но доступно из всех других используемых схем.

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

Ожидайте использовать различные решения, которые соответствуют данным и планируют их. Это где Geo-портал (сервер метаданных) действительно приходит.

Я должен согласиться с «Джорджем» выше, что метаданные должны играть большую роль в управлении геопространственными данными. На самом деле для любых цифровых данных метаданные являются ключевыми - подумайте о фотографе, который пытается управлять своими файлами цифровых фотографий без надлежащих метаданных. Жизнь становится намного проще, если вы помечаете вещи религиозно и имеете хорошее программное обеспечение, которое может использовать данные. Теперь первоначальный вопрос об «управлении геопространственными данными» довольно широк - это могут быть форматы данных для хранения, соглашения об именах, иерархия наборов данных и функций, редактирование ролей и привилегий и т. Д. И т. Д. И т. Д. И т. Д.

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

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

MongoDB: поддерживает большие объемы данных. Отлично подходит для простого хранения, поиска и ограниченных геопространственных запросов.

Хранение файлов: если вы на самом деле просто архивная система и используете для запроса только некоторую часть данных, хранение ваших данных в виде файлов может быть экономически выгодным. Ваше требование контроля версий может быть вполне удовлетворено этим.

Redis: Вы можете объединить любой из вышеперечисленных параметров с поддержкой Redis Geo для хранения небольшого количества «горячих» данных в Redis, к которым вам необходимо часто обращаться. Думайте об этом как о своем кеше.