新しいフィーチャクラスが追加された後、ユーザーが従来のバージョン管理されたフィーチャ データセットを編集できない場合は、フィーチャ データセットをバージョン管理されたものとして再登録する必要があります。
1. バージョン管理として再登録する理由
* バージョン管理されたフィーチャ データセットにフィーチャクラスを追加するには、フィーチャ データセット全体をバージョン管理用に再登録する必要があります。
* この手順により、新しいフィーチャクラスがバージョン管理システムに含まれ、バージョン管理されたワークフローに参加できるようになります。
2. 他の手順を実行しても問題が解決しなかったのはなぜですか?
* チェックされた権限: 正しい権限では、フィーチャクラスを追加した後に再登録する必要がなくなります。
* 確認済みの接続ファイル: 接続ファイルで従来のバージョン管理が使用されていることを確認しても、登録の欠落は解決されません。
* インデックスと統計の再構築: これによりパフォーマンスは向上しますが、バージョン管理には影響しません。
3. 他の選択肢はないのでしょうか?
* データ所有者として接続し、データを編集します。
* データ所有者であっても、フィーチャデータセットが再登録されるまで編集はできません。
* フィーチャデータセットのバージョン管理を解除します。
* 登録を解除するとバージョン情報が削除され、デルタ テーブルのデータ損失が発生する可能性があります。
フィーチャ データセットをバージョン管理済みとして再登録する手順:
* ArcGIS Pro を開き、データ所有者として接続します。
* フィーチャ データセットを右クリックし、[管理] > [バージョン対応として登録] を選択します。
* 必要に応じて、ベース テーブルへの編集内容を保持するオプションを選択します。
* フィーチャデータセットの編集を保存してテストします。
Esri ドキュメントおよび学習リソースからの参照:
* データをバージョン管理として登録する
* バージョン管理されたフィーチャデータセットの管理
結論：
管理者は、新しく追加されたフィーチャクラスを含め、従来のバージョン管理環境での編集の問題を解決するために、フィーチャ データセットをバージョン管理対象として再登録する必要があります。

シナリオを理解する:
* GIS アナリストは、LIDAR データの大規模なリポジトリを共有する必要があります。
* データには、地形やサーフェスのルールを適用するために使用されるブレークラインなどのサーフェス制約が含まれます。
データセットの種類の概要:
* モザイク データセット: 画像や標高グリッドなどのラスター データの大規模なコレクションを管理するために設計されています。LIDAR ポイント クラウド データ用に特別に最適化されているわけではありません。
* フィーチャ データセット: ジオデータベース内の関連フィーチャクラスのコンテナー。LIDAR データやサーフェス制約の管理とは無関係です。
* LAS データセット: LIDAR ポイント クラウドを管理するために設計された特殊なデータセット。ポイント分類、サーフェス制約 (ブレークラインなど)、LIDAR データの効率的なクエリまたは視覚化をサポートします。
LAS データセットを作成して共有する手順:
* ArcGIS Pro で LAS データセットを作成し、LIDAR ファイル (LAS または ZLAS 形式) を追加します。
* LAS データセットのプロパティでサーフェス制約 (ブレークライン) を定義します。
* LAS データセットを組織アクセス用のサービスまたはパッケージとして共有します。
参考文献:
* Esri ドキュメント: LAS データセット。
* LAS データセットでのブレークラインの管理: サーフェス制約を組み込むための手順。
正解が C:LAS データセットである理由は、ブレークラインなどのサーフェス制約を伴う LIDAR データを管理および共有するために明示的に設計されているからです。モザイク データセットとフィーチャ データセットはこの目的には適していません。

シナリオを理解する:
* フィーチャクラスに対して行われた編集は、すべてのユーザーにすぐに表示される必要があります。
* これは、バージョン管理のオーバーヘッドなしで基本テーブルを直接編集する必要があることを示しています。
編集構成の概要:
* 従来のバージョン編集: デルタ テーブルに対して編集が行われ、他のユーザーに表示されるようにするには、バージョンの調整と投稿が必要です。これにより遅延が発生し、即時の可視性の要件を満たしません。
* バージョン非対応編集: 編集内容はフィーチャクラスのベース テーブルに直接適用され、すべてのユーザーにすぐに表示されます。これは、シナリオに適した選択です。
* ブランチ バージョン編集: 編集はブランチ バージョンで行われ、編集がデフォルトのブランチに保存されない限り、他のユーザーにはすぐには表示されません。これは、すぐに表示したい場合は最適な選択ではありません。
バージョン管理されていない編集を構成する手順:
* エンタープライズ ジオデータベースでフィーチャクラスが非バージョン編集モードに設定されていることを確認します。
* すべてのユーザーにベーステーブルを編集するための必要な権限を付与します。
* データセットに加えられたすべての編集は、すべてのユーザーに即座に反映されます。
参考文献:
* Esri ドキュメント: バージョン管理されていない編集。
正解が B である理由: バージョン管理されていない編集は、すべてのユーザーが編集内容をすぐに確認できる唯一の構成です。従来のバージョン管理とブランチ バージョン管理には、編集内容の確認を遅らせるワークフローが伴います。

シナリオの概要:
* GIS 管理者は、ブランチ バージョン データセットの非同期コピーを作成する必要があります。
* 両方のコピーは編集可能でなければなりません。
ジオデータベース レプリケーションを使用する理由
* ジオデータベース レプリケーションでは、親ジオデータベースと子ジオデータベースの両方で編集を許可しながら、データセットの同期コピーの作成をサポートします。
* ブランチ バージョン データの場合、レプリケーションにより、親ジオデータベースまたは子ジオデータベースのいずれかで行われた編集が双方向レプリカを使用して同期されることが保証されます。(ArcGIS ドキュメント: ジオデータベース レプリケーション) このシナリオでのジオデータベース レプリケーションの主な機能:
* 双方向レプリケーションにより、変更を同期しながら両側で編集が可能になります。
* ブランチのバージョン管理をサポートし、バージョン管理されたワークフローがそのまま維持されることを保証します。
* 両方のジオデータベース間でスキーマの一貫性を維持します。
代替オプション:
* オプションA: 分散コラボレーション
* コラボレーションは、ArcGIS Enterprise 環境間でデータを共有するのに適していますが、両側での編集のためのアクティブな同期はサポートしていません。
* オプション C: DBMS レプリケーション
* DBMS レベルのレプリケーションは生データのレプリケーションを処理しますが、ブランチ バージョン管理などのジオデータベース固有の機能は保持されません。
したがって、ジオデータベース レプリケーションは、両方のジオデータベースでブランチ バージョン データセットを同期および編集するための適切な方法です。