GNSS ポイント観測のためのジオデータベース スキーマの設計
安定した識別子、参照定義、観測履歴を含む座標を保存して、最初の土地調査後もデータセットが役に立ちます。
列を選択する前に、オブジェクトをモデル化します
GNSS ポイント データベースは、物理的特徴、個々の観察結果、または受け入れられた位置を表すことができます。 これらは関連していますが、異なる概念です。 スキーマを構築する前に、それぞれの表またはレイヤーが説明するものを決定します。 1 つのアセットには、特定のリリースで多数の観測と承認された座標が含まれる場合があります。 1 つのフラット テーブルで、これらの関係が隠され、更新を解釈するのが難しくなります。
目的のライフサイクルについての簡単な説明を書きます: 作成、レビュー、受け入れ、再訪、退職。 受け入れられた位置を変更できるのは誰であり、証拠がどのように保持されるかを特定します。 スキーマは、最初のインポートだけでなく、そのプロセスをサポートする必要があります。 技術的に有効なポイント レイヤーは、まだ維持管理されている土地調査データベースではありません。
ジオメトリに依存しない識別子を使用してください
安定した機能と観測識別子を割り当てます。 後で測定または変換すると値が変わる可能性があるため、座標自体をオブジェクトのアイデンティティとして使用しないでください。 外部資産識別子は、ソースとともに別のフィールドに保管してください。 スプレッドシートで数値として再解釈できるようにするのではなく、プロジェクトのルールに従って先頭のゼロと文字のケースを保持します。
選択したデータベースがそれらをサポートする一意性制約を定義し、インポートが重複を処理する方法をテストします。 観測識別子が繰り返されると、レビューがトリガーされますが、1 つの機能に関連するいくつかの観測は正当な場合があります。 廃止または結合された識別子の相互参照を保持します。 これにより、将来のデータセットが以前のフィールド レコードや写真との接続を失うことを防ぎます。
座標の起源から幾何学を分離します
レイヤーの座標参照を明示的に保存し、インポートされた観測のためのソース参照情報を保持します。 プロジェクトに関連するデータムの実現、調整エポック、高さタイプを含めます。 ジオメトリ列は、その値を生成したすべての変換またはローカル キャリブレーションを記録せずに、CRS 識別子を保持する場合があります。 来歴フィールドは、その情報のギャップを埋める必要があります。
配達のために座標が変換される場合は、元の観測またはトレース可能なソース レコードを保持します。 使用した操作とモデルのバージョンを記録します。 1 つの行に、説明のつかない座標ペアを複数格納することは避けてください。 各ペアは、受け入れられたジオメトリに対して定義された目的、参照、および関係を持つ必要があります。これにより、レビュー担当者は、特定のリリースに対して権限のある値を特定できます。
測定と品質のフィールドを慎重に定義してください
観測方法、補正源、アンテナの高さの規則、および関連する品質の証拠が含まれています。 ドキュメント ユニットと受信者が提供するインジケーターの意味。 内部精度の見積もりを、独立して実証された精度としてラベル付けしないでください。 スキーマでは、独立したチェック結果とレビュー ステータスを機器の出力とは別に記録できるようにする必要があります。
ターゲットの定義と、障害物、ソフト グラウンド、またはオフセットの導出などのローカル制限のフィールドを指定します。 不明な値をゼロから区別してください。 ゼロ オフセット、欠落オフセット、および測定されなかったオフセットは、異なる状態です。 慎重なフィールドの定義により、後のユーザーが一般的なメモまたは空のセルから意味を推測する必要がなくなります。
観測履歴を保存し、決定を確認します
日付とステータス フィールドを使用して、未加工、レビュー済み、受理済み、置き換えられた観測値、拒否された観測値を区別します。 却下または座標補正の理由はそのままにしてください。 後で受け入れられる立場は、その前の証拠の削除を要求すべきではありません。 この履歴は、変更された座標が、より良い測定値、参照更新プログラム、またはフィーチャの物理的変化を反映しているかどうかを説明するのに役立ちます。
プロジェクトのプロセスに従って、レビューの決定を責任ある役割とリリース バージョンにリンクします。 ポイントがマップ境界内にあるかどうかだけに依存するようにしないでください。 空間的妥当性は 1 つのチェックですが、アイデンティティ、参照の互換性、観察品質も重要です。 データベースは、文書化されていない 1 つのフラグにまとめることなく、これらのさまざまな評価をサポートする必要があります。
明示的な関係を介して添付ファイルを接続します
写真、スケッチ、生のファイルは、安定したキーまたは文書化された添付ファイルを介してリンクする必要があります。 フォルダ内のファイルの順序に頼らないでください。 添付ファイルの種類と役立つ日付を含めます。 いくつかの観察を含むポイントでは、訪問ごとに異なる写真が表示される場合があり、その区別は回復可能である必要があります。
バックアップ、エクスポート、受信システムへの転送を通じて、添付ファイルの動作をテストします。 フォルダが移動すると相対パスが破損することがありますが、コピーされたファイルはデータベース レコードとの関係を失います。 オーサリング アプリケーションで表示される添付ファイルがすべての受信者に自動的に表示されると仮定するよりも、小規模なエンド ツー エンドのテストの方が便利です。
データ変換としてインポートおよびエクスポートを検証します
長い識別子、不明な値、特殊文字、日付、オフセット、および複数の観測値を持つサンプルを作成します。 意図したフォーマットとアプリケーションを移動します。 ラウンドトリップ後のフィールド名、タイプ、値、およびジオメトリを比較します。 一部の形式では、ブラインド セーブ アズとしてブラインド マップではなく、明示的なエクスポート マッピングが必要な制限が課せられます。
信頼できるスキーマとデータ ディクショナリをバージョン管理または別の制御リリース プロセスの下に置いておきます。 派生フィールドと失われた情報を文書化します。 簡略化されたエクスポートが必要な場合は、完全なデータベースを別々に保存します。 受信者は、配信されたポイント レイヤが完全な観察アーカイブか、または縮小された受理位置ビューかを知る必要があります。
スキーマの配信 別のチームが維持できる
フィールド定義、ユニット、コード化された値、リレーションシップ、リファレンス メタデータ、および更新ルールを提供します。 新しい機能の例、再訪、および置き換えられた観測を含めます。 どのジオメトリがリリースに適しているかを示し、サポートする証拠が保存されている場所を指定します。 これにより、データベースは元の測量士の個人的な知識を超えて役立ちます。
初期の収集後だけでなく、最初の運用更新後のスキーマを確認します。 新しいポイントを適切に処理するモデルは、アセットがマージ、移動、または廃止された場合でも失敗する可能性があります。 信頼できる GNSS データベースは、これらの変更によって ID と出所を維持します。 その目的は、単に多数の点の形状を格納するのではなく、座標を証拠として理解できるようにすることです。
履歴を失うことなく改善された座標を処理します
暫定的な資産の位置が、後で確認された土地測量観測に置き換えられたとします。 元の観察結果をメソッドとステータスで維持し、新しい観察結果を追加し、承認されたレビュー プロセスを通じて承認された位置関係を更新します。 アセット識別子は安定しています。 これにより、既存のメンテナンス レコードと写真が同じ物理オブジェクトを参照し続けることができます。
新しいポジションが採用された理由とそれを含むリリースを記録します。 差異が予想外の場合は、アセットが移動したことを宣言する前に、参照互換性と ID を調査してください。 座標の更新と物理的な再配置は別のイベントです。 スキーマは、両方を明確に表現できるようにする必要があります。後で分析しても、測定の改善がインフラストラクチャの変更として解釈されないでしょう。
受け入れ位置ビューは、履歴観測表が変更されていないまま、承認済みの観測値を選択できます。 その選択ルールを文書化し、再訪した後にテストします。 マップ ユーザーは現在の位置のみを必要とする場合がありますが、土地調査のレビュー担当者は以前の証拠も必要とします。 明確なスキーマを通じて両方のビューを提供することで、トレーサビリティを犠牲にすることなく、通常の使用をシンプルに保つことができます。 また、データベースがアイデンティティ、測定履歴、および現在の採用されている空間状態をすでに分離しているため、将来の座標変換または資産の再配置をより簡単に表現できるようになります。
実践チェックリスト
- 機能、観察、および受け入れられた位置は別のものです。
- ドキュメント リファレンスの起源は、Geometry CRS ラベルを超えています。
- 再訪、添付ファイル、および簡素化されたエクスポートをテストします。
