バージョン対応環境でリプレゼンテーションを操作する

バージョン対応環境でのリプレゼンテーションの仕組みを理解するためには、まずバージョニングの原理とフィーチャクラス リプレゼンテーションがジオデータベースに格納される方法を十分に理解することが重要となります。

バージョニングの詳細リプレゼンテーションの格納方法の詳細

バージョン対応環境でのリプレゼンテーションの仕組み

リプレゼンテーションを持つフィーチャクラスは、リプレゼンテーションを持たないフィーチャクラスとほぼ同じように、バージョン対応環境に参加します。これには、注意点がいくつかあります。

バージョン対応環境でリプレゼンテーションを使用する場合の推奨されるワークフロー

シナリオ 1

  • 親バージョン(ターゲット バージョン)が、フィーチャ リプレゼンテーションのルール ID を R から R* に変更します。
  • 子バージョン(編集バージョン)は、同じフィーチャ リプレゼンテーションを編集しますが、代わりに属性のオーバーライドを追加し、オーバーライド フィールドに O* として格納されます。
    • 子バージョンが、親バージョンに対してリコンサイルされます。競合の定義方法により、結果は異なります。
    • オブジェクト(行)単位:両方のバージョンで同じフィーチャが編集されているので、競合が検出されます。競合は、優先度に基づき、どちらかのバージョンを使用することで解決できます。したがって、最終的なリプレゼンテーションは、ルール ID が R でオーバーライドが O*、またはルール ID が R* でオーバーライドが O のいずれかになります。結果は一貫しています。
    • 属性(列)単位:同じフィーチャ リプレゼンテーションが編集されますが、編集は 2 つの異なるフィールドまたは属性(ルール ID とオーバーライド)で行われたので、競合は検出されません。リコンサイルでは、フィーチャ リプレゼンテーションはルール ID が R* で属性オーバーライドが O* です。フィーチャ リプレゼンテーションの属性オーバーライドは、表現されているリプレゼンテーション ルールに属さないプロパティに対するものです。結果は一貫していません。
    • この状況を避けるには、代わりに row_level オプションを使用します。

シナリオ 2

  • 親バージョン(ターゲット バージョン)は、フィーチャ リプレゼンテーションのシェープを変更するか、またはシェープ オーバーライドを追加します。このオーバーライドは、オーバーライド フィールドに O* として格納されます。
  • 子バージョン(編集バージョン)は、同じフィーチャ リプレゼンテーションを編集しますが、代わりに属性のオーバーライドを追加します。このオーバーライドは、オーバーライド フィールドに O** として格納されます。
  • 子バージョンが、親バージョンに対してリコンサイルされます。競合を解決するためどちらのバージョンを選択しても、同じ結果になります。
    • オブジェクト(行)単位または属性(列)単位:同じフィーチャ リプレゼンテーションが両方のバージョンで編集されます。また、編集は同じ属性オーバーライドに対して行われます。シェープと属性のオーバーライドは 2 つの異なるエンティティですが、これらを編集すると、同じオーバーライド フィールドに結果が保存されます。競合が検出され、どちらかの編集(O* または O**)を保持することになります。
    • 回避策: 属性の編集結果を、オーバーライド フィールドに格納する代わりに、明示的なフィールドに格納します。リコンサイル時に、属性(列)単位の定義を選択すると、編集結果は 2 つの異なるフィールド(オーバーライド フィールドと明示的フィールド)に格納されるので、競合は発生しません。結果として、両方の編集を維持できます。

シナリオ 3

  • 親バージョン(ターゲット バージョン)が、フィーチャ リプレゼンテーションに対する属性オーバーライドを作成します。オーバーライド フィールドは O* に更新されます。
  • 子バージョン(編集バージョン)は、同じフィーチャ リプレゼンテーションを編集しますが、フィーチャ リプレゼンテーションをフリー リプレゼンテーションに変換します。ルール ID の値は -1 に変化し、グラフィックス オブジェクトがオーバーライド フィールドに設定されます。その結果、このステップはルール ID フィールドとオーバーライド フィールドを R* および O** に変更します。
  • 子バージョンが、親バージョンに対してリコンサイルされます。
    • オブジェクト(行)単位または属性(列)単位: 競合があります。親(ターゲット)バージョンを優先して競合を解決すると、結果は一貫性がなくなります。属性オーバーライド O* が、ルール ID の値 -1 または R* とともに存在します。
    • 回避策:一貫性のない結果を避けるには、子バージョンを優先して競合を解決します。この場合は、子バージョンによって行われた変更を保持し、親バージョンによって行われた編集を無視します。ただし、この場合は親バージョンによって行われた編集が失われることに注意する必要があります。

シナリオ 4

同じフィーチャクラスに存在する複数のフィーチャクラス リプレゼンテーションに基づく複数の地図を調整する場合は、複数プロジェクトのシナリオを使用して地図を編集します。たとえば、地図ごとに M1、M2、M3 などのような異なるバージョンを作成します。これらのバージョンを編集した後、属性(列)単位の定義を使用して親バージョン(または SDE.Default)でリコンサイルとポストを行い、競合はすべて編集バージョンを優先して解決します。オーバーライド フィールドの代わりに明示的フィールドに属性オーバーライドを書き込みたい場合は、地図ごとに異なる明示的フィールドを作成します。

ベスト プラクティス

関連トピック

5/10/2014