GNSS 未処理の GNSS 観測データをアーカイブし、将来の処理に役立ちます
元のファイル、構成、および出所を保存して、生データ アーカイブが収集された日以降も理解できるようにします。
アーカイブが保持する必要があるものを定義します
生の GNSS アーカイブは、観測とそれらを解釈するために必要なコンテキストを保持する必要があります。 セットアップ情報のないレシーバー ファイルのフォルダーは、最終的な座標スプレッドシートでは、基礎となる観測値を置き換えることができない一方で、確実に処理するのが難しい場合があります。 プロジェクトの目的から始める 目的: 再処理の可能性、制御監査、プロジェクトの結果の配信、または長期的な参照作業には、さまざまなサポート レコードが必要になる場合があります。 保持するファイルを決定する前に、要件を述べてください。
元のレシーバー データ、変換された 交換用ファイル、処理出力、最終座標を区別します。 それぞれに役割があり、それに応じてラベルを付ける必要があります。 変換された RINEX ファイルは相互運用性を向上させることができますが、それでも変換設定と可能な制限がある派生製品です。 プロジェクト ポリシーが許す場所に原本を保存し、コンバージョンの履歴をそのままにしておいてください。 これにより、文書化されていない変換を、それが手付かずのフィールド レコードであるかのように扱うことを回避できます。
ファイルを物理セットアップにリンクします
観測値をマーク、レシーバー、アンテナ、および測定間隔に接続するセットアップ識別子を使用します。 アンテナの高さ法、生の高さの読み取り値、および関連するアダプターを記録します。 基本設定のための参照座標とそのソースを含めます。 アーカイブは、ファイル名だけに頼らず、またはそれをダウンロードしたオペレーターのメモリーに頼らずに、どの物理配置がファイルを生成したかを説明できるようにする必要があります。
機器の識別子とファームウェアのバージョンは、解釈に影響を与える場所に保管してください。 日中にアンテナまたはアダプターが変更された場合は、明確なイベント境界を保持します。 元の区別を保持せずに、さまざまな設定のファイルを 1 つの一般的な毎日のラベルの下に結合しないでください。 処理パッケージはマージされたファイルを受け入れることができますが、インポートが成功しても、すべての観測値が同じジオメトリまたは参照の仮定を共有することは証明されません。
さらに学ぶ GNSS 土地調査データの監査証跡を作成します
フィールドでのログ記録を確認します
ロギングが実際に開始され、意図した期間をカバーし、十分なストレージがあることを確認します。 機器のワークフローに従って、セッション中にステータスを確認してください。 昨日から有効にしてある設定は、今日のファイルが完成したという証拠にはなりません。 中断、再起動、およびロギング構成への意図的な変更を記録します。 これらのメモは、転送の失敗や処理ソフトウェアの欠陥のように見えるギャップを説明するのに役立ちます。
セッションの最後に、サイトを出る前に利用可能なファイル情報を調べます。 サポートされているツールを使用して、日付、観測間隔、および妥当なサイズを確認してください。 実用的な場合は、意図したワークフローを通じてファイルを読み取ったり変換したりできることを確認してください。 完全な整合性チェックでは、最終的な測位品質を確立できませんが、空のレコードまたは読み取り不能なレコードが表示される可能性がありますが、繰り返し観測が可能な場合もあります。
出所を失うことなく転送
ファイルを承認された方法でコピーし、元の名前を制御されたソース フォルダーに保存します。 転送日と演算子を記録します。 唯一のコピーを編集したり、同期プログラムがサイレントに置き換えられるようにすることは避けてください。 チェックサムは、プロジェクトがチェックサムを保存し、測定精度に関するクレームではなく整合性チェックとして使用する場合、コピーされたファイルがそのソースと一致することを確認するのに役立ちます。
少なくともプロジェクトに必要なバックアップの取り決めを維持し、コピーにアクセスできることを確認します。 同じ障害のあるデバイスの 2 番目のフォルダーは、チームが期待する回復力を提供しない場合があります。 パブリック シェアリング リンクを即興で使用せずに、組織のストレージとアクセス ポリシーに従ってください。 RAW ファイルとサポート レコードには、プロジェクトの場所や、承認されたワークフロー内に残す必要があるその他の情報を含めることができます。
変換と処理入力を記録
Rinex または別の Exchange フォーマットを生成するときは、コンバータのバージョン、設定、および出力名を記録します。 アンテナの識別、観測時間、およびツールがサポートする利用可能な信号を検査します。 変換によって、どの情報が表現されるか、またはどのようにラベル付けされるかを変更できます。 変換警告を保持し、ファイル拡張子だけで、意図した処理方法で必要なすべての観測が記録に含まれていることを証明するものではないと思い込まないでください。
プロジェクトが再現可能な処理を必要とする場合、参照ステーションのデータと外部製品をソースと該当する間隔で保存します。 後のアナリストは、どの最終座標が採用されたか以上のことを知る必要があります。 結果がどのように得られたかを説明する入力、処理構成、および関連するメッセージを保持します。 サービスがすべての基礎となる入力なしで処理された結果を提供した場合、完全に再現可能なローカル ソリューションを暗示するのではなく、その境界を文書化します。
明確なアーカイブ構造を使用
プロジェクト、日付、およびセットアップごとに整理し、オリジナル、派生ファイル、および承認された出力用の領域を分けて使用します。 正確なフォルダー名は、一貫した意味よりも重要ではありません。 ファイルを観測間隔とセットアップ レコードにマッピングする短いインデックスを含めます。 Final、Final New、および Final Latest と呼ばれるフォルダーの増殖は避けてください。これらの名前は、どのデータセットが承認されたか、またはどの処理ステップで生成されたかを通知しないためです。
受け入れられた処理記録とは別に、実験を続けてください。 アナリストは、診断中にいくつかのアンテナ モデルまたは処理オプションをテストすることがあります。 これらの試験は、承認された結果と見分けがつかないようにすべきです。 決定を説明するのに十分な履歴を保存し、それに取って代わられたアウトプットを明確にマークします。 クリーン アーカイブは、失敗したすべての作業を削除するものではありません。 これは、保持された各アイテムのステータスと出所を理解できるものにするものです。
さらに学ぶ GNSS 土地調査データの監査証跡を作成します
アーカイブからのリカバリーのテスト
代表的なセッションを選択し、元のオペレーター以外の誰かに、未処理の GNSS 観測データ、セットアップ ジオメトリ、および処理構成を見つけてもらいます。 実用的な場合は、文書化されたルートでサンプルを再オープンまたは再処理してください。 この演習では、単純なファイル数では明らかにできない、欠落しているコンテキストを公開します。 目的は、バックアップ アプリケーションが同期が完了したことを報告するかどうかだけでなく、アーカイブが意図した使用をサポートしているかどうかをテストすることです。
使用できない独自の変換ソフトウェアや参照データの欠落など、制限を記録します。 プロジェクトがアクティブなときに可能な限り、それらに対処します。 RAW ロギングがすべてのリアルタイム障害を後で修復できると主張しないでください。 回復可能性は、使用可能な観察と適切な処理ルートに依存します。 アーカイブは機会と証拠を保持しますが、処理された座標の受け入れは、チェックとプロジェクトの基準に依存します。
アーカイブ マニフェストで閉じる
オリジナル ファイル、派生製品、セットアップ レコード、処理出力、および承認されたプロジェクト出力を識別するマニフェストを準備します。 座標参照情報、時間規則、重要な機器イベントを含めます。 マニフェストを一般的な読み取り可能な形式で保持し、プロジェクトの結果の配信後も意味のあるリンクまたはパスを保持します。 1 つのオペレーターの一時的なデスクトップ フォルダーのみを指すパスは、永続的なプロジェクト リファレンスではありません。
たとえば、最終的な座標データセットが連続的であっても、正午のバッテリーの再起動によるセッションには、2 つのソース間隔とイベント ノートが必要です。 マニフェストにより、その履歴が表示され、アナリストは適切な間隔を検査できます。 したがって、有用な GNSS アーカイブは、観測、ジオメトリ、および決定の接続された記録です。 その価値は、フィールド キャンペーン全体を再現せずに、他の人が新しい質問に答えることができるときに現れます。
実践チェックリスト
- オリジナルとラベルから派生した変換を別々に保存します。
- 観測間隔ごとに物理セットアップにリンクします。
- データを収集しなかった人とのテスト検索。
