Реализация системы контроля версий для геопространственных данных? [закрыто]

Не то чтобы я тут нуждался в правильном ответе, но в последнее время я видел некоторые попытки ввести концепцию «(распределенных) систем контроля версий» для географических данных. Некоторыми примерами (о которых я знаю) являются три документа из OpenGeo ( 1 , 2 и 3 ) и проект « Geosynkronisering (geosyncronization)» от норвежских поставщиков программного обеспечения ГИС и Норвежского картографического агентства. Я также нашел Распределенные версии геопространственных данных? , в котором упоминается GeoGit (от OpenGeo) и применение контроля версий к моделям ArcGIS ModelBuilder? о контроле версий в ArcGIS.

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

Каковы проблемы при работе с (d) VCS для географических данных, как бы вы их решили, нужны ли они нам, и есть ли другие попытки решить эти проблемы, помимо тех, которые я упомянул?

Я знаю, что технические документы OpenGeo ответят на некоторые из моих вопросов, но на самом деле я хочу получить более «педагогический» ответ в стиле «скажи мне, что я 10-летний», так что Я могу отослать людей к отличному объяснению проблем и решений, которые географические данные приносят к соединению.

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

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

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

Мы оценили следующие подходы, вот что я могу о них сказать:

1. ESRI Enterprise Geodatabase(ArcGIS 10.1); почти то же самое, что было раньше (SDE), но с широким использованием функции управления версиями для обработки транзакций. Но на самом деле это не корпоративная база геоданных, по моему мнению, SDE работает только в рабочей группе как сервер геоданных, где люди работают с 8:00 до 20:00, и вы можете перевести его в автономный режим для задач обслуживания, фиксация транзакций (согласование версий и публикация в речи ESRI), репликация и т. д. Если вы строите сервисы на основе этих данных, вы должны обрабатывать промежуточную базу данных (где выполняется работа) и реплицированную производственную базу данных. Это почти то же самое, что сборка / тестирование и развертывание в программировании. Несмотря на то, что многофункциональный пакет, который предоставляет ESRI, довольно приятен, ему не хватает гибкости (изменения схемы или задачи обслуживания, когда люди работают, например, создание индекса).

2. Плоские файлы и система контроля версиймы выбираем Git (не знал, что GeoGit уже есть). О да, некоторые из моих друзей и я тоже родом из разработчиков программного обеспечения. Все может быть так просто. Я думаю, что это его проблема: это похоже на автомеханика, строящего автомобиль. Его будет просто поддерживать, но также будет раздражать вождение и чертовски уродливо смотреть на него. Я думаю, что у него также есть несколько существенных недостатков: Как контролировать версию 2-терабайтного (или даже более, двоичного) набора растровых данных? И в каком формате? Векторные данные можно легко контролировать по версии, если вы используете текстовые форматы (например, GML), но в то же время сложно работать с набором данных из миллиарда строк. Я до сих пор не уверен, сможем ли мы эффективно управлять разрешениями пользователей, потому что не всем разрешено редактировать или даже просматривать все. И как объединить векторный набор данных, который интенсивно редактировался 4 пользователями одновременно? По крайней мере, вы должны быть настоящим ученым-программистом, чтобы делать все это эффективно ... наши пользователи ГИС - специалисты по планированию, геодезисты, геологи и так далее. Для них просто проблема думать о происхождении версий, как это делают программисты, или использовать ветвление так, как предполагалось. Тем не менее, думать о хранилищах данных как о совместных репозиториях - интересная идея.

3. Плоская табличная база данных в виде простого контейнера. Так же, как это делает SDE, но без SDE. Все еще трудно поддерживать, потому что вы на самом деле не используете преимущества, которые предлагает вам СУБД. Да, очень просто загрузить все в базу данных, но это совсем не управление данными.

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

ОБНОВЛЕНИЕ 2018: здесь много нового, что создает большой импульс. Назвать несколько:

• Облачное хранилище блоков и HDFS
• Python / стройный / Dask Stack

• Apache Spark

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

• и многое другое

  5. Комплексное классическое моделирование базы данных(с РСУБД). Основная проблема заключается в том, что трудно просто отбросить данные в любом месте и надеяться, что они соответствуют всем будущим потребностям. Но если вы потратите определенное количество времени, чтобы указать надежную модель данных (OSM также сделала это) в базе данных, вы сможете использовать все ее преимущества. Мы можем редактировать и обновлять данные в распределенных транзакциях, мы также можем изменять их базовую схему, в то время как сервисы по-прежнему полагаются на внешние схемы тех же данных, мы можем поддерживать их, мы можем проверять их согласованность, мы можем разрешать и запрещать разрешения, мы мы можем хранить очень большие объемы данных, в то время как мы по-прежнему можем получать к ним быстрый доступ, мы можем создавать исторические модели данных, прозрачно запускать их и т. д. Поскольку мы используем sql-сервер, нам все еще не хватает встроенного типа растра, но другие поставщики баз данных уже предлагают это.

Что ж, я думаю, что модель реляционной базы данных просто встала в пространственном мире с пространственными типами данных за последние пару лет (до этого там были BLOB-контейнеры) и до сих пор является наиболее гибкой и профессиональной формой хранения данных. Это не означает, что его не следует дополнять подходами VCS или NoSQL, но я рассматриваю эти подходы скорее как форму распределения данных в группах пользователей, чем как форму профессионального централизованного управления пространственными данными. Кроме того, OSM централизовала множество задач, которые толпа просто не может выполнить, например, импорт больших объемов данных (большинство данных OSM в Австрии было импортировано за день, а не краудсорсинг) и генерация листов. Сотрудничество (краудсорсинг) действительно очень важно, но это только половина дела.

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