地理空間データのバージョン管理システムを実装していますか？[閉まっている]

ここで正しい答えをすぐに必要としているわけではありませんが、最近、地理データに「（分散）バージョン管理システム」の概念を導入しようとする努力がいくつか見られました。いくつかの例には、（私の知っていること）OpenGeo（から3つのホワイトペーパーです1、2＆3）と「GeosynkroniseringノルウェーのGISソフトウェア・ベンダーとノルウェーのマッピング庁（geosyncronization）」プロジェクト。地理空間データの分散バージョン管理も見つけましたか？、GeoGit（by OpenGeo）、およびバージョン管理のArcGIS ModelBuilderモデルへの適用について述べていますか？ArcGISのバージョン管理について。

開発者であるため、（少なくともそれらを使用するのに十分な）ソースコードのバージョン管理システム（SVNやGitなど）がどのように機能するかを理解し、ジオマティクスの私のバックグラウンドから、地理データにはいくつかのユニークな課題があることがわかりますソースコード（基本的にはテキスト）の処理方法とは完全には似ていません。

地理データの（d）VCSを扱う際の課題は何ですか？それらをどのように解決しますか？それらを必要としますか？

OpenGeoのホワイトペーパーが私の質問のいくつかに答えることは知っていますが、私が本当に望んでいるのは、「10歳のように教えて」というスタイルで、より「教育的な」答えです。地理データがミックスにもたらす課題と解決策の素晴らしい説明を人々に紹介できます。

現在、特定の問題を解決するつもりはないが、このトピックは興味のあるトピックだと述べたので、ある程度の洞察力のある人が問題についての考えを提供するのに時間がかかることを願っています。

現在、ジオデータストアの完全な再設計に取り組んでいます。彼らの進化は今まで20年以上かかったと言わざるを得ません。地理空間データ管理における次の主要な機能を特定しました。

• 同時編集
• データの一部を読み書きする権限
• データに依存するサービス（トランザクションとACIDパラダイム）の実行中のホットアップデート
• 内部スキーマと外部スキーマ（内部スキーマの変更はサービスに影響しないはずです）
• 大量のデータ（テラバイトのラスターと数百ギガバイトのベクターデータ）を保存およびアクセスする機能
• 異なるレイヤー間のデータの一貫性（すべての区画が地区に属するなど）

私たちは次のアプローチを評価しました。ここで私が言えることは次のとおりです。

1. ESRIエンタープライズジオデータベース（ArcGIS 10.1）; 以前のバージョン（SDE）とほぼ同じですが、トランザクションを処理するためにバージョニング機能を広範囲に使用しています。しかし、実際にはエンタープライズジオデータベースではありません。私の意見では、SDEはジオデータサーバーとしてワークグループでのみ動作し、人々は午前8時から午後8時まで働き、メンテナンスタスクのためにオフラインにすることができますトランザクションのコミット（バージョニングの調整とESRIスピーチでのポスト）、レプリケーションなど。これは、プログラミングでのビルド/テストおよびデプロイとほぼ同じです。ESRIが提供する機能豊富なパッケージは非常に優れていますが、柔軟性（スキーマの変更、または作業中のメンテナンスタスク、インデックスの作成など）に欠けています。

2. フラットファイルとバージョン管理システムGitを選択します（GeoGitが既にあることを知りませんでした）。そうそう、私の仲間の何人かと私自身もソフトウェア工学から来ています。それはすべてとても簡単かもしれません。それはその問題だと思います：自動車整備士が車を作るようなものです。彼のために維持することは簡単ですが、それはまた、確実に見るために運転し、い気にするのは面倒です。また、いくつかの大きな欠点もあると思います：2テラバイト（またはそれ以上のバイナリ）Rasterdatasetをバージョン管理する方法は？そして、どのフォーマットで？ベクターベースのデータは、テキストベースの形式（GMLなど）を使用すると簡単にバージョン管理できますが、10億行のデータセットを扱うのも困難です。誰もがすべてを編集したり表示したりすることを許可されるべきではないため、効果的なユーザー許可管理を行えるかどうかはまだわかりません。また、4人のユーザーが同時に集中的に編集したベクターデータセットをどのようにマージしますか？少なくともこのすべてを効果的に行うには、実際のコンピューター科学者/プログラマーでなければなりません...私たちのGISユーザーは、プランナー、測量士、地質学者などです。プログラマーのようにバージョンの系統を考えたり、想定された方法で分岐を使用したりすることは、単に問題です。それでも、データストアを共有リポジトリとして考えることは興味深いアイデアです。

3. 単純なコンテナとしてのフラットテーブルデータベース。SDEと同じですが、SDEがありません。RDBMSが提供する利点を実際に利用していないため、維持するのは依然として困難です。はい、データベースにすべてをロードするのは非常に簡単ですが、それはデータ管理ではありません。

4. BigdataとのNoSQL。フラットファイルおよびフラットテーブルと同じ問題。私の意見では、Webで使用するためのシンプルなファイルシステムAPIです。はい、それはウェブでうまく機能し、はい、あなたのドキュメントを投げるのは簡単ですが、テラバイトの（おそらくラスター）データの空間データ分析を達成したいなら、シリアル化およびデシリアライズされないようにしたいと思いますHTTPインターフェース経由。

2018年の更新：勢いを増している新しいものがたくさんあります。いくつか例を挙げると：

• クラウドブロックストレージとHDFS
• Python / shapely / Daskスタック

• Apache Spark

  • ベクターデータ用GeoMesa / GeoWave
  • ラスターデータのGeoTrellis

• などなど

  5. 包括的なクラシックデータベースモデリング（RDBMSを使用）。主な問題は、データをどこにでも簡単にドロップし、将来のあらゆるニーズに適合することを期待することです。しかし、データベースで堅牢なデータモデル（OSMも実際にこれを行いました）を指定する時間をかけると、その利点をすべて利用できます。分散トランザクションでデータを編集および更新できます。また、コアスキーマを変更できますが、サービスは引き続き同じデータの外部スキーマに依存し、それを維持し、一貫性を確認し、許可を許可および拒否できます。非常に大量のデータを保存できる一方で、高速にアクセスできるので、履歴データモデルを構築して、透過的にトリガーすることができます。SQLサーバーを使用しているため、ネイティブラスタータイプはまだありませんが、他のデータベースベンダーは既にこれを提供しています。

リレーショナルデータベースモデルは、ここ数年（BLO​​Bコンテナーが導入される以前）の空間データ型で空間世界に登場したばかりで、依然として最も柔軟でプロフェッショナルなデータ保存形式であると思います。これは、VCSアプローチやNoSQLで補完するべきではないという意味ではありませんが、これらのアプローチは、専門的な集中空間データ管理の形式としてよりも、ユーザーグループにおけるデータ配布の形式としての可能性が高いと考えています。また、OSMは、大量のデータのインポート（オーストリアのほとんどのOSMデータはクラウドソーシングではなく1日でインポートされた）やタイル生成など、群衆が提供できない多くのタスクを集中化しました。共同作業（クラウドソーシング）の部分は確かに非常に重要ですが、ビジネスの半分にすぎません。

私はこれの多くを言い換え、より多くの事実を提供しなければならないと思います。このような質問を数時間で包括的に答えるのは困難です。翌日、回答の質を向上させようと思います。