GNSS フィールド調査での有用な時間記録の保持
タイムゾーン、観測間隔、およびデバイス イベントを記録して、受信者、コントローラー、およびサービスからのログを正しく比較できるようにします。
時間 証拠を接続
土地調査記録には、座標以上のものが含まれます。 観測時間は、ローバー ポイントをベース ログ、修正中断、写真、天気予報、および機器の変更に接続します。 時刻表が不明確な場合、有用な診断記録を別のデバイスと比較することが難しくなることがあります。 プロジェクトがどのように記録されているかを確認し、表示されるすべてのクロックが同じ量を表していると仮定するのではなく、ファイルを使用して規則を保持します。
デバイスのユーザー インターフェイスの時刻と、観測ファイルに保存された時間タグを区別します。 コントローラーは、生の GNSS データが別の文書化された時間システムを使用している間、ローカルの市民時間を表示する場合があります。 ファイルの作成時間は、観察エポックではなく、コンピュータの時計または転送操作を反映することができます。 それぞれが役に立ちますが、さまざまな質問に答えます。 すべてのタイムスタンプを交換可能な証拠として扱うのではなく、それらにラベルを付けます。
タイムゾーンとオフセットを記録
屋外測定作業中に記録されたメモには、タイムゾーンまたは UTC からの明示的なオフセットを含めます。 これは、オフィス スタッフ、リモート サポート、屋外測定チームがさまざまな場所で作業する場合に特に重要です。 どのローカル規約が使用されたかを誰も知らない場合、10 時に修正リンクが失敗したというメモは不完全です。 一貫したプロジェクト形式を使用して、オペレーターが簡単に記録できるようにします。
場所に夏時間の変更を適用する場合は、記憶されたオフセットに頼るのではなく、ワークフローでそれらを考慮してください。 地域にまたがるプロジェクトの場合、UTC は比較を簡素化できますが、現地時間は乗組員にとって便利な場合があります。 選択を文書化し、一貫して適用する必要があります。 キャンペーンの途中で、トランジションを記録し、以前のメモをどのように解釈すべきかを説明せずに、コンベンションを変更しないでください。
GNSS タイム システムについて
GNSS データ形式は、その時間規約を定義し、関連する仕様および処理ソフトウェアを使用して解釈する必要があります。 GPS 時間と UTC は関連していますが、同一ではありません。他のコンステレーションには独自のシステム定義があります。 コントローラ クロックに関する一般的な仮定に基づいて、未処理の GNSS 観測エポックを手動でシフトしないでください。 フォーマットを理解し、元のファイルを保持する、サポートされている変換および処理ツールを使用します。
不一致を調べるときは、各時間フィールドにどのプログラムが生成されたかを特定します。 変換された RINEX ファイル、コントローラーのエクスポート、およびイメージ メタデータ レコードは、それぞれ異なる時間を表現する場合があります。 変換設定とソフトウェア バージョンを適切な場所に保ちます。 これにより、記録が文書化された規約の下で実際にレコードが重複する場合、時間解釈の問題が観測の欠落または参照ステーションの停止と間違われることを防ぎます。
さらに学ぶ GNSS 調査に役立つ写真ログを作成します
セッションの前にクロックを確認する
屋外での測定作業や写真中に記録されたメモに使用されるコントローラー、カメラ、または電話の時計を点検します。 必要に応じて、承認されたデバイス プロシージャを介してそれらを同期し、既知のオフセットを記録します。 目的は、レシーバの未処理の GNSS 観測時間タグの変更ではなく、サポート レコードの実際的な調整です。 簡単なフライト比較で、写真シーケンスをポイントにマッチングしたり、後で中断を再構築したりするときに、かなりの労力を節約できます。
デバイスが同期できない場合は、オフセットを透過的に推定できるように、参照写真またはメモを取ってください。 元のタイムスタンプを保存し、解釈を別に文書化します。 変更の記録を保持せずに、すべてのファイル メタデータを書き換えないでください。 他の人が時間ベースの関連付けがどのように行われたかを理解する必要がある場合、元の証拠と修正方法はどちらも価値があります。
動作イベントを記録する
ベースの起動とシャットダウン、レシーバーの再起動、アンテナの交換、バッテリーの障害、および補正ソースの変更を記録します。 機器の識別子とジョブ名を含めます。 これらのイベントは、オフィスが構成を共有する観測値を評価するのに役立つ境界を作成します。 複数の受信機が同時に動作していて、どのデバイスまたはセットアップが変更されたかをメモで特定しない場合は、タイムスタンプだけでは十分ではありません。
障害については、気付いたときに記録し、最後に確認が成功し、時間の回復が確認されました。 これらは、正確な技術的故障時間とは異なる場合があり、区別が見える必要があります。 イベント後に記憶された時間に誤った精度を割り当てないようにしてください。 正直なおおよその間隔でもレビューの指針となる可能性がありますが、発明された正確な分は、アナリストを誤解させて関連する観察結果を除外する可能性があります。
オフィスでのログの比較
文書化された変換を使用して共通のタイムラインを作成し、ソース レコードをそのまま維持します。 ローバーの観測、基本ファイル、修正診断、乗務員のメモをそのタイムラインに配置します。 レコードが互いに矛盾することを結論付ける前に、一貫したオフセットを探します。 カメラの時計が数分遅いことがわかっている場合は、画像ファイルを黙って変更して説明を残さないのではなく、その解釈を示してください。
後処理を試みる前にオーバーラップを確認してください。 ベースとローバーの観測には、適切な時間関係と、意図したメソッドの使用可能な共通データが必要です。 同じ日を示唆するファイル名だけでは十分ではありません。 実際の観測間隔とギャップを検査します。 不足しているデータまたは互換性のないデータを特定するメッセージを処理する必要があります。これは、ソフトウェアがジョブを処理しなかったという一般的なステートメントよりも正確な説明を提供するためです。
アーカイブ内の時間規約を保存
キャンペーンの記録とともに短い時間のメモを含めます: 屋外測定作業の規則、関連するデバイスのオフセット、生の形式の定義、および重要な変換手順中に記録されたメモ。 オリジナルのファイルは、明確な名前の派生出力と一緒に保管してください。 これにより、あるコントローラーが異なるタイム ゾーンを表示したことをたまたま知っていたオペレーターのメモリに依存せずに、後のレビュー担当者がシーケンスを再構築できます。
一貫した時間記録を使用して、日常業務とトラブルシューティングを改善します。 写真を照合し、機器のイベント後に影響を受けるポイントを特定し、繰り返し観測が別の設定に属する理由を説明します。 正確な時間の取り扱いでは、それ自体では座標が正しくありません。 これは、プロジェクトがその座標がどのように取得されたかを理解、再現、または疑問視する必要がある場合に不可欠な、周囲の証拠を使用可能にします。
さらに学ぶ GNSS 調査に役立つ写真ログを作成します
写真を障害に合わせる
電話機の写真には修正警告が表示されますが、そのメタデータの時間がコントローラーのイベント ログと異なるとします。 最初に、電話クロック規則と既知のオフセットを確立します。 記録がさまざまなインシデントを説明していると判断する前に、他の写真や参照イベントを比較してください。 画像のメタデータを保存し、適切なタイムラインに合わせて写真を黙って書き換えるのではなく、解釈された関係をレビュー ノートに記録します。
オフセットが自信を持って設定できない場合は、もっともらしい間隔と関連付けの不確実性を報告してください。 この画像は、正確な観察エポックを証明することなく、機器の状態の説明をサポートできます。 この区別により、証拠は正直に保たれます。 時間記録は、不確実性を含め、実際に知られていることを保存し、別のアナリストが比較を繰り返すか疑問視できるように変換手順を十分に明示する場合に最も役立ちます。
真夜中頃にイベントを記録するときは、完全な日付を使用してください。 日付のない時間は、複数日のキャンペーン中に、特に地元の市民時間と RAW-DATA コンベンションが別の方法で 1 日の境界を越えた場合に、間違った観測ファイルに割り当てられる可能性があります。 表示されたカレンダー名だけでファイルをグループ化するのではなく、文書化された変換を保持します。
実践チェックリスト
- 屋外測定の作業時間帯に記録されたラベル ノートと、観察エポックとファイルの時間を区別します。
- デバイスのオフセットを記録し、元のメタデータを保持します。
- Land Survey ログを比較するときは、一般的な文書化されたタイムラインを使用してください。
