Location Referencing ライセンスで利用可能です。
競合の防止は、エンタープライズ ジオデータベース リニア リファレンス システム (LRS) のルート編集とイベント編集を調整することで、マルチユーザー編集のサポートを改善します。 ArcGIS Location Referencing では、編集者がルートまたはイベントを編集する前にロックを取得することを要求する一連の条件および振舞いを適用することで、編集を調整します。
Location Referencing の競合防止の主な原理は、データベース バージョンの編集者によってルートまたはイベントが編集用にロックされた場合、それらのルートまたはイベントを別のデータベース バージョンの同じユーザーや、任意のバージョンの他のユーザーが編集することはできない、というものです。
競合の防止の有効化
競合の防止は、ブランチ バージョン対応の LRS データセットでのみサポートされています。
トラディショナル バージョニングは Location Referencing でサポートされていますが、トラディショナル バージョン対応データセットで競合の防止を利用することはできません。
データセットをブランチ バージョン対応登録したら、[競合の防止] オプションを [有効] に設定した [LRS の変更 (Modify LRS)] ツールを実行します。
競合の防止を有効にすると、各編集ツールは、ロックを取得できる場合は自動的にロックを取得し、ロックを取得できない場合は警告を表示します。
競合を防止するためのルートの編集とロックの作成
競合を防止するワークフローの例をルートの廃止を使用して示します。 RouteY が廃止されます。
- [個別属性] ボタンをクリックしてから、RouteY をクリックします。
[ルートの個別属性表示] ダイアログ ボックスが表示されます。
- 選択したルート上にロックが存在していないことを確認します。
結果にはロックが表示されていないため、そのルートのロックが存在しないことがわかります。
- ルートにロックが存在しないことを確認した後、[Location Referencing] タブの [廃止] をクリックします。
[ルートの廃止] ウィンドウが表示されます。
- [ルートの廃止] ウィンドウで、[始点ルート名] ボタンをクリックして、廃止するルートをクリックします。
ルート名を選択すると、ウィンドウの上部にロック取得メッセージが表示されます。
ロック取得メッセージには、次の情報が含まれています。
- RouteY のロックが正常に取得されました。
- ロックは、ポータル ユーザー User11 によって取得されました。
- データベース バージョン Version1 の RouteY のロックは User11 によって取得されました。
注意:
次の条件を満たす場合、既存のルートまたはラインのロックが別のユーザーから自動的に転送されます。
- 別のユーザーが所有しているバージョンが公開されている。
- 他のユーザーがロックを取得しているバージョンと同じバージョンでリクエストを発行している。
- ロック バージョンが子バージョンの場合、ロックの所有者が現在そのバージョンで編集セッションを開いていない。 ロック バージョンがデフォルトの場合、ロックの所有者が現在デフォルト バージョンで読み取りセッションを開いていない。
- [個別属性] と RouteY をもう一度クリックすると、ロックの存在を確認することもできます。
[自分によってロック済み] アイコン でも、特定したルートのロックが取得され、そのルートを編集できることを確認できます。
- [Location Referencing] タブの [LRS ロック] ボタン を使用して、既存のロックを特定することもできます。
[LRS ロック] テーブルが表示されます。
競合の防止メッセージ
上記で述べたように、競合の防止ロジックにより、1 人のユーザーだけが一度に 1 つのバージョンでルートとイベントを編集できます。
たとえば、User22 が RouteY を廃止しようとした場合、同じ RouteY が User11 によりロックされていると、次のメッセージが表示されます。
メッセージには、次の情報が含まれています。
- ロックが他のユーザーに属しているため、RouteY は編集できません。
- ロックは、ポータル ユーザー User11 によってすでに取得されています。
- データベース バージョン Version1 の RouteY のロックは User11 によってすでに取得されています。
ルート識別子 は次の結果を示しています。
[LRS ロック] テーブルに、ロックが表示されます。
最新バージョンのデータセットが編集されたことを確認
最新バージョンのデータベースを編集し、データへの最新の変更内容がすべて編集中のバージョンに存在するようにします。 最新バージョンであることを確認するため、Location Referencing はロックを取得する前にデフォルト バージョンとのリコンサイルが必要かどうかを確認します。 バージョンをデフォルトとリコンサイルする必要がある場合、次のメッセージが表示されます。
[ロックの取得] が表示されている際に [はい] をクリックすると、編集者のバージョンがデフォルト バージョンとリコンサイルされます。
注意:
ルートまたはイベントを編集する前に、デフォルト バージョンとの競合がリコンサイルされていることを確認します。
ブランチ バージョンへの編集内容のリコンサイルおよび投稿、競合の解決、および変更内容の投稿の詳細
ロックを取得する前に自動的にリコンサイルすることを選択できます。 自動リコンサイルを有効にすると、リコンサイル中に競合が検出されない限り、リコンサイルしないでロックを取得できます。
次のチャートに、ルート編集時に競合を防止する全体的なロジックを示します。
ロックのタイプ
Location Referencing での競合の防止には、2 種類のロックがあります。
- ルート ロック
- イベント ロック
ルート ロック
ルート ロックは、ルート編集中に、そのルートまたはルート上のイベントが他のユーザーによって編集されないようにします。 ルート ロックには、次の特性があります。
- ネットワークのルートを編集する場合、ロックはルート ロックと呼ばれます。
- ルートがロックされると、ロックを所有するユーザーのみが、ロックが獲得されたバージョンでそのルートとルート上のイベントを編集できます。
イベント ロック
イベント ロックは、特定のルートのイベント レイヤーが他のユーザーによって編集されないようにします。 イベント ロックは、ルートのイベント レイヤー用に取得されます。
User1 が Version1 にある Route1 の Event Layer1 をロックした場合、次の条件が適用されます。
- 他のユーザーは、すべてのバージョンで Route1 の Event Layer1 を編集できません。
- User1 は、Version1 以外のすべてのバージョンで、Route1 の Event Layer1 を編集できません。
- 他のユーザーは、そのルートに対してルート ロックが存在しない限り、Route1 または他のルートの他のイベント レイヤー (Event Layer1 以外) のロックを取得できます。
- 複数のユーザーがそのルートのイベント ロックを取得している場合、どのユーザーもルート ロックを取得できません。
- 他のユーザーは、ロックを取得できるすべてのルートの Event Layer1 のロックを取得できます。
- イベントの編集にルート上のイベント ロックが必要な場合に取得されます。
注意:
- ルートまたはイベントのタイム スライスが複数存在する場合、取得したロックはすべてのタイム スライスに対して有効です。
- 必要に応じて、ロックはジオプロセシング ツールによって取得されます。
次のチャートに、イベントがルートに存在する場合に競合を防止するロジックを示します。
中心線を編集する際の競合の防止
並列ルートが存在する場合、共通の中心線に基づいてルートがロックされます。 以下の図に、この概念を示します。
- ルート X が編集されている場合、ルート X でロックが取得され、ルート X とルート Y は中心線 C2 を共有しているため、他のユーザーはルート Y のロックを取得できません。
- ルート Y が編集されている場合、ルート Y でロックが取得され、ルート X とルート Y は中心線 C2 を共有しているため、他のユーザーはルート X のロックを取得できません。
- 中心線 C1 が編集されている場合 (カートグラフィックの再配置または中心線の分割)、ルート X のみがロックされます。
- 中心線 C3 が編集されている場合、ルート Y のみがロックされます。
- 中心線 C2 が編集されている場合、C2 はルート X とルート Y の間で共有されている中心線であるため、両方のルートがロックされます。
ロックの解除
次の場合、ロックは自動的に解除されます。
- ロックを含むバージョンをデフォルト バージョンに投稿した場合。
- ロックを含むバージョンが削除された場合。
- ルート編集ツール、中心線編集ツール、ジオプロセシング ツールを使用すると、デフォルト バージョンで取得したロックはツールの実行が完了した後に解除されます。
ロックは、解除可能ステータスに応じて手動で解除できます。
解除可能ステータス値が Yes の場合、次の手順を実行してロックを解除できます。
解除可能ステータス値が No の場合、ロックを解除することはできません。
解除可能ステータス値が On Post の場合、デフォルト バージョンへの投稿後にのみロックを解除できます。
注意:
次の条件を満たす場合、既存のルートまたはラインのロックが別のユーザーから自動的に転送されます。
- 別のユーザーが所有しているバージョンが公開されている。
- 他のユーザーがロックを取得しているバージョンと同じバージョンでリクエストを発行している。
- ロック バージョンが子バージョンの場合、ロックの所有者が現在そのバージョンで編集セッションを開いていない。 ロック バージョンがデフォルトの場合、ロックの所有者が現在デフォルト バージョンで読み取りセッションを開いていない。
競合の防止ルールの概要
競合の防止が有効な場合、次の条件でルートのロックを取得した後にルートを編集することができます。
- データベースのすべてのバージョンで、そのルートのロックが取得されていない。
- 同じユーザーが、現在操作しているデータベースの同じバージョンで、そのルートに対するルートのロックをすでに取得している。
競合の防止が有効で、ロックの転送条件が満たされていない場合、次の条件ではルートを編集することができません。
- デフォルトとのリコンサイルが必要である。
- 現在のバージョンでジオデータベースの競合が存在している。
- ルートが別のユーザーによりすでにロックされている。
- 同じユーザーが、現在操作しているデータベースの別のバージョンで、そのルートに対するルートのロックをすでに取得している。
- 別のユーザーがそのルートに対するイベント ロックを取得している (ロックの転送条件が満たされていない場合)。
- 同じユーザーが、データベースの別のバージョンで、そのルートに対するイベント ロックを取得している。
競合の防止が有効な場合、次の条件でイベント レイヤーのロックを取得した後にイベントを編集することができます。
- データベースのすべてのバージョンで、そのイベントがあるルートの当該イベント レイヤーのロックが取得されていない (ロックの転送条件が満たされていない場合)。
- 同じユーザーが、現在操作しているデータベースの同じバージョンで、(イベントがあるルートの) イベント ロックをすでに取得している。
- 同じユーザーが同じバージョンで (イベントがあるルートの) ルート ロックをすでに所有しています。
競合の防止が有効な場合、次の条件ではイベントを編集することができません。
- デフォルトとのリコンサイルが必要である。
- 現在のバージョンでジオデータベースの競合が存在している。
- イベントがあるルートのイベント レイヤーが、別のユーザーによってすでにロックされている (ロックの転送条件が満たされていない場合)。
- イベントがあるルートの別のバージョンのイベント レイヤーが、同じユーザーによってすでにロックされている。
- イベントがあるルートが、別のユーザーによってすでにロックされている (ロックの転送条件を満たしていない場合)。
- イベントがあるルートの別のバージョンが、同じユーザーによってすでにロックされている。