GNSS 土地調査受入チェックリストの作成
土地調査データセットの公開準備が整ったと判断する前に、目的の用途、現場の証拠、配達チェックを接続します。
意図された用途から始める
受け入れチェックリストは、プロジェクトが土地調査から何を必要としているのか、そしてどのような証拠がそれを裏付けるかを表明する必要があります。 決定。 これは単なる受信者のステータス メッセージのリストではありません。 おおよその資産の場所に使用されるデータセットには、制御または高さに敏感な設計をサポートするために使用されるものとは異なる要件がある場合があります。 水平、垂直、属性の要件を別々に定義して、レビューが複数の異なる質問を 1 つの漠然とした正確さの主張にまとめないように定義します。
可能な場合は、生産前の基準に同意します。 乗組員は、どの観察結果が繰り返されるか、どのチェックが独立しているか、どのように例外を処理するかを知る必要があります。 データが収集された後にのみ作成されたチェックリストは、ギャップを明らかにする可能性がありますが、欠落しているフィールドの証拠が常に置き換えられるとは限りません。 最終レビューを、以前の省略を修復する別のオフィス アクティビティとして扱うのではなく、受け入れ計画を収集方法に接続したままにします。
リファレンス ファンデーションを確認する
座標参照系、単位、軸の順序、高さの定義を確認します。 基本座標または制御座標とローカル変換のソースを確認します。 承認された改訂が各作業期間中に実際に使用されたことを確認してください。 間違ったシステムを参照しているときに、座標ファイルが内部的に整頓されている可能性があるため、統計的要約またはコスメティック フォーマットの前に参照検証を行う必要があります。
アンテナの形状を同じ基礎の一部としてトレースします。 レビュー担当者は、アンテナの識別、高さの測定方法、および関連するセッションのセットアップ レコードを見つける必要があります。 コンポーネントが変更された場合は、影響を受ける間隔を特定します。 機器リスト内のレシーバー モデルがすべての測定セッションの物理ジオメトリを確立するとは考えないでください。 チェックリストは、機器が正しく使用されたという単なる一般的な声明ではなく、観察に関連する証拠を求める必要があります。
フィールドの品質の証拠を確認する
プロジェクト計画に従って、独立したチェック結果と繰り返しの測定セッションを検査します。 水平コンポーネントと垂直コンポーネントを比較し、空間パターンを調べて例外を保持します。 全体平均が小さいからといって、プロジェクトの一端で大きな不一致を無視することは正当化されません。 変換を適合させるために使用されたポイントは、それをテストするために予約された点と区別されていることを確認してください。これらの役割は異なる証拠を提供するからです。
レビュー ソリューションの状態、修正中断、困難な観測環境を外部チェックと並べて表示します。 内部受信者の見積もりは評価をサポートできますが、その意味は機器とモデルによって異なります。 Keep them distinct from demonstrated agreement with control. 計画されたチェックが完了しなかった場合は、ギャップを記録し、欠落している証拠をレポートのより自信のある形容詞に置き換えるのではなく、必要な追加作業を決定します。
完全性と意味を調べる
必要な領域と機能タイプがカバーされていることを確認します。 正確な座標は、地形の傾きの変化を示す意図した資産または線が省略されている場合は役に立ちません。 フィールド レコードを作業計画、マップ、フィーチャ ディクショナリと比較します。 必須の属性を確認し、不明な値を明示してください。 受け入れレビューは、すべてのセルを満たすだけの発明値に報酬を与えるのではなく、乗組員が特徴を観察できなかった不確実性を維持する必要があります。
ポイントの識別子と、繰り返し測定セッション、写真、および最終的な特徴の間の関係を検査します。 文書化されたプロセスによって重複が解決され、名前を変更しても証拠のリンクが破られなかったことを確認します。 線画とポリゴンの場合は、接続性と物理的解釈、および座標値を確認してください。 ファイルに有効なジオメトリが含まれる可能性があります。これは、観察されたポイントの間違ったシーケンスを結合したり、クライアントが予想するフィーチャーの別の部分を説明したりする場合があります。
さらに学ぶ GNSS プロジェクトの品質ダッシュボードの設計
処理と改訂の履歴を確認
マテリアルの変換、変換、および座標の修正を確認します。 ソース ファイルと、受け入れられた各リビジョンの基礎を保持します。 エラーが修正された場合は、影響を受けるスコープと、修正された結果のチェックを確認します。 最終的なラベルは、正しく収集された観測値と、後で承認されたプロセスを通じて修復された観測値との違いを消去してはなりません。 どちらも使えるかもしれませんが、証拠の歴史は理解できるはずです。
暫定的および置き換えられた出力が明確にマークされていることを確認します。 未処理の GNSS 観測データが処理を待機している場合は、ステータスが明示的でプロジェクトの結果の配信に適切でない限り、それらを許容座標配信の範囲外に保ちます。 チェックリストは、ファイルが Final というフォルダーにあるという理由だけで承認されるのを防ぐ必要があります。 承認は、記録されたレビューによってサポートされる定義済みのデータセットおよびリビジョンに属します。
デリバリーフォーマットをテストする
プロジェクトの出力を意図した宛先ソフトウェアで開き、代表者の記録を調べます。 座標の配置、高さ、単位、識別子、属性、および文字エンコーディングを確認します。 インポートが成功すると、プログラムが構文を受け入れたことが確認されます。 データがユーザーの想定を意味することを証明するものではありません。 インポート後に既知のポイントと機能を比較して、解釈とファイルの読みやすさをテストします。
プロジェクトの結果の場所からのメタデータとサポート リンクを確認します。 一時的なローカル ドライブを指す写真インデックスは、完全な配信ではありません。 GeoJSON またはその他の標準化された形式の場合は、座標タプルが許容されると仮定するのではなく、フォーマットの要件に従います。 エクスポート設定を保持し、マニフェストで承認された出力ファイルを特定して、クライアントが作業ファイルや代替フォーマットと区別できるようにします。
例外を明示的に処理する
影響を受ける識別子、理由、結果、および解決策を持つ簡潔な例外レジスタを作成します。 一部の例外は、プロジェクトの範囲内で許容される場合があります。 それ以外の場合は、追加の測定または処理が必要です。 レビュー担当者は、その決定の根拠を確認できるはずです。 データセット内でそれらを特定するための実際的な方法を提供しない、一般的な免責事項で未解決のポイントを隠すことは避けてください。
例外によって特定の用途への適合性が変更された場合は、その結果を明確に述べてください。 たとえば、観測されていない排水インバートは、後の分析で測定された高さとして扱われるべきではありません。 受け入れプロセスは、制限を含め、使用する証拠を結び付ける必要があります。 明らかに異なる、または検証されていない条件下で収集されたポイント全体で一様な信頼度を暗示しているよりも、明確に制限された正直なデータセットをリリースする方がよいでしょう。
承認決定を記録
プロジェクトのワークフローに従って、レビュー担当者、データセットの改訂、レビュー日、およびサポート レコードを特定します。 未解決のアクションと使用条件を含めます。 チェックリストは、重複したレポートではなく詳細な証拠へのリンクを使用して、一貫して適用できるほど簡潔に保ちます。 記入済みのフォームは、ファイルを開かなくてもすべてのボックスにチェックを入れることができるため、署名は追加されず、実際の評価を表す必要があります。
実際のテストとして、屋外測定チームと話すことなく、別の同僚が承認された座標系、関連チェック、および例外を特定できるかどうかを尋ねます。 そうでない場合は、リリース前にパッケージを改善してください。 土地調査の受け入れは、参照定義、観察、処理、および意図された用途に基づく合理的な決定です。 チェックリストは、その決定が具体的で再現性があり、座標に依存する人々にとって理解できるようになったときに成功します。
すべてのプロジェクト出力フォーマットが同じ承認されたリビジョンを表していることを確認してください。 修正された GIS レイヤーと古いスプレッドシートはどちらも、意見が一致しないように最終的に見える場合があります。 エクスポート全体で代表的な識別子と調整を比較してから、リリースされたファイルを 1 つのマニフェストにリストします。 これにより、解決された土地調査の問題が、代替の代替形式を介して再表示されるのを防ぎます。
さらに学ぶ GNSS プロジェクトの品質ダッシュボードの設計
実践チェックリスト
- 生産前に基準と必要な証拠に同意します。
- リファレンス、品質、完全性、および配信を個別の質問として確認してください。
- 正確に承認されたリビジョンとその例外を特定します。
