測位ログで時刻ずれが起きると何が問題になるか
測位ログには、緯度、経度、標高、測位状態、衛星数、精度指標などとともに時刻が記録されます。位置座標が正しく見えていても、時刻がずれていると、ほかのデータとの対応関係を誤る可能性があります。特に移動体の測位、連続観測、写真とのひも付け、点群取得、工事記録、車両管理、災害調査などでは、時刻の整合性が成果の信頼性を左右します。
例えば、作業者が歩きながら1秒間隔で測位した場合、測位ログの時刻が2秒ずれていれば、実際にいた場所と記録上の場所に数メートルの差が生じることがあります。移動速度が速い車両や機械では、同じ時刻差でも位置の食い違いがさらに大きくなります。静止測位では座標そのものへの影響が見えにくいものの、写真、施工記録、観測メモ、センサー値との照合時に問題が表面化します。
時刻ずれには、単純な時計の遅れだけでなく、時刻系の違い、タイムゾーンの設定、ログ出力の通信遅延、アプリ側の処理待ち、電源投入直後の未確定時刻、うるう秒情報の扱いなど、複数の原因があります。そのため、端末の時計だけを見て「合っている」と判断するのは十分ではありません。
重要なのは、どの時刻を、どの処理段階で、どの形式に変換して記録したかを明確にすることです。測位した瞬間の時刻と、位置情報を端末が受信した時刻と、ファイルへ書き込んだ時刻は、必ずしも同じではありません。この違いを理解せずにログを扱うと、数十ミリ秒から数秒程度の差が蓄積し、後処理で修正しにくくなる場合があります。
GNSS時刻同期を適切に管理するには、受信機、端末、アプリ、通信、保存ファイルという一連の流れを確認する必要があります。本記事では、測位ログの時刻ずれを防ぐために、実務で確認したい6つのポイントを順番に解説します。
GNSS時刻同期の基本を理解する
GNSSによる測位では、衛星から送信される信号の時刻情報を利用して、受信機と衛星の距離を計算します。衛星信号が届くまでの時間を精密に扱う必要があるため、GNSSにおける時刻は測位計算の中心的な要素です。ただし、測位計算に使われる時刻と、普段の業務で使用する日本標準時が、そのまま同じ形式で扱われているとは限りません。
GNSSには複数の衛星測位システムがあり、それぞれが独自の基準時刻を持っています。受信機は各システムの時刻差を考慮し、測位結果を計算します。その後、利用者が扱いやすいように、協定世界時を基準とする時刻や地域の標準時へ変換して出力するのが一般的です。
ここで注意したいのは、衛星測位システム内部の時刻には、協定世界時との間に一定の差が存在する場合があることです。その差は、受信機が保持する補正情報によって変換されます。受信機が十分な衛星情報を取得していない状態や、内部情報が更新されていない状態では、起動直後に正しい変換が完了しない可能性があります。
また、測位ログの時刻には複数の候補があります。代表的なのは、位置計算の対象となった観測時刻、受信機が測位結果を出力した時刻、端末がデータを受信した時刻、アプリが保存処理を行った時刻、ファイル自体が作成または更新された時刻です。これらは意味が異なるため、同じ「タイムスタンプ」として混同してはいけません。
高精度な同期が必要な用途では、1秒ごとの境界を示すパルス信号を利用する方法もあります。この信号は一般に1PPSと呼ばれ、測位データの時刻と外部機器の時計を高い精度で対応させるために使われます。ただし、1PPSが利用できる環境でも、パルスが示す秒と測位メッセージ内の時刻を正しく対応付けなければ、1秒単位の取り違えが起きる可能性があります。
実務では、必要な同期精度を最初に決めることが大切です。写真と測点をおおまかに対応させる用途と、高速で移動する機械の軌跡をセンサー値と統合する用途では、許容できる時刻差が異なります。求める精度を決めたうえで、受信機、端末、アプリ、保存形式の順に確認すると、過剰な設定や見落としを減らせます。
確認1 受信機が基準にしている時刻系を確認する
最初に確認したいのは、測位ログの時刻がどの時刻系を基準にしているかです。時刻欄に数字が記録されていても、それが協定世界時なのか、日本標準時なのか、衛星測位システム内部の時刻なのかが分からなければ、ほかのデータと正しく比較できません。
ログの仕様書や出力設定では、時刻の基準、日付の形式、秒以下の桁数、時刻変換の有無を確認します。時刻欄に時分秒だけが記録され、日付やタイムゾーン情報が含まれていない形式もあります。この場合、受け渡し時に基準を共有していないと、利用者によって解釈が変わるおそれがあります。
特に注意したいのが、協定世界時と日本標準時の違いです。日本標準時は協定世界時より9時間進んでいます。協定世界時のまま保存されたログを日本標準時として読むと、すべての記録が9時間ずれます。夜間をまたぐ観測では日付も変わるため、単純な時刻差だけでなく、観測日そのものを誤認する可能性があります。
複数の受信機を使用する場合は、機器ごとの出力設定が統一されているかも確認します。同じ現場で取得したログでも、一方が協定世界時、もう一方が日本標準時で保存されていれば、ファイルを結合した際に大きなずれが生じます。後処理で修正することはできますが、変換履歴が残っていないと、どちらを直すべきか判断できなくなります。
時刻系を確認するときは、表示画面だけでなく、実際に保存されたログを開いて確認することが重要です。画面上では日本標準時で表示されていても、内部ファイルには協定世界時で記録されている場合があります。反対に、保存時に地域時刻へ変換されていることもあります。表示用の時刻と保存用の時刻を分けて考える必要があります。
時刻の表記には、基準を明示できる形式を選ぶと管理しやすくなります。日付、時刻、秒以下の値、協定世界時との差を一つの値として残せれば、異なる環境へデータを渡したときも解釈しやすくなります。既存の保存形式で基準を明示できない場合は、観測記録やファイル名とは別に、時刻系を記した管理情報を残します。
現場では、受信機の設定画面を見ただけで確認を終えず、既知の時刻とログの記録値を比較してください。日本標準時で正午に測位した場合に、ログが3時前後を示していれば、協定世界時で保存されている可能性があります。このような簡単な照合でも、9時間単位の大きな設定ミスを早期に見つけられます。
確認2 UTC変換とタイムゾーン設定を確認する
時刻系を確認した後は、協定世界時から地域時刻への変換方法を確認します。測位ログの時刻ずれでは、受信機の測位時刻よりも、端末やアプリのタイムゾーン設定が原因となるケースがあります。
端末には、現在地に応じてタイムゾーンを自動設定する機能が備わっていることがあります。通常の利用では便利ですが、通信環境、位置情報の設定、手動変更、海外での利用履歴などによって、想定と異なる地域が選ばれる可能性があります。測位を開始する前に、端末の時刻だけでなく、タイムゾーンが日本標準時に相当する設定になっているかを確認します。
自動設定と手動設定が混在している場合も注意が必要です。端末の時計は自動、アプリ内の表示設定は手動、書き出し時は協定世界時という構成では、画面表示と出力データが異なる可能性があります。利用者から見ると同じ端末内の処理でも、各機能が参照する時刻設定は同一とは限りません。
ログを表計算形式や汎用データ形式で出力した後、閲覧ソフト側で時刻が自動変換されることもあります。ファイルには協定世界時が保存されているにもかかわらず、閲覧時に端末のタイムゾーンへ変換されると、元データと表示結果が一致しません。別の端末で開いたときに表示が変わる場合は、保存値ではなく閲覧側の変換が影響している可能性があります。
時刻変換を確認するには、元のログ、アプリ画面、書き出し後のファイルという3段階を比較します。同じ測点について、どの段階で時刻が変わったかを追えば、問題のある処理を絞り込めます。元ログが正しく、書き出し後だけ9時間ずれているなら、出力処理または閲覧処理の設定を確認します。
秒以下の値にも注意が必要です。時刻形式の変換時に小数秒が切り捨てられると、高速移動や高頻度観測では位置との対応が粗くなります。例えば10Hzで測位している場合、1秒間に複数の座標が存在します。時刻が秒単位までしか残らなければ、同じ秒に記録された複数点の順序を時刻だけで判定できません。
日付の境界も確認します。協定世界時から日本標準時へ変換すると、時刻によっては日付が翌日になります。日付と時刻を別々の列で管理している場合、時刻だけを9時間進めて日付を更新し忘れると、存在しない組み合わせが生じます。深夜や早朝の観測では、変換後の日付まで含めて検証してください。
確認3 端末時刻とGNSS受信時刻の同期方法を確認する
GNSS受信機から得られる時刻と、端末の内部時計は別の仕組みで動作しています。端末の画面に表示される時刻が正しくても、測位アプリがどちらの時刻をログへ記録しているかによって結果が変わります。
測位ログに記録する時刻としては、GNSS受信機が出力した観測時刻を利用する方法と、端末がデータを受信した瞬間の内部時刻を利用する方法があります。前者は位置計算の対象時刻を示しやすく、後者は端末内のほかの処理と合わせやすいという特徴があります。ただし、端末受信時刻には通信や処理の遅延が含まれるため、測位した瞬間を正確に表すとは限りません。
無線通信で受信機と端末を接続している場合、データの送信間隔、混雑、再送、端末の処理負荷などにより、到着時刻が変動することがあります。平均的な遅延が小さくても、特定の瞬間だけ遅れることがあります。端末受信時刻をタイムスタンプとして使うと、この揺らぎが測位ログへ反映されます。
一方、GNSS受信機内の時刻を使う場合も、受信機が時刻を確定できていることが前提です。衛星信号を十分に受信できていないときや、電源投入直後には、日付や時刻が暫定値となる可能性があります。ログには時刻が入っていても、受信機内部で確定前の値が使われていないかを確認する必要があります。
端末の時計は、通信ネットワークによる時刻合わせや内部時計によって維持されます。通信圏外で長期間使用した場合、内部時計にわずかなずれが生じることがあります。通常の作業では気にならない差でも、高頻度の測位データと外部センサーを統合すると影響が出ます。
確認時には、GNSS受信時刻と端末時刻の差を一定時間記録します。差が常にほぼ一定であれば、タイムゾーンや固定遅延の可能性があります。差が時間とともに広がる場合は、端末時計の進み遅れが考えられます。差が不規則に変動する場合は、通信や処理負荷による遅延を疑います。
アプリが利用する時計の種類も重要です。端末には、利用者が変更できる時刻とは別に、起動後の経過時間を測るための時計が用意されている場合があります。経過時間を測る時計は、作業途中で端末時刻が補正されても連続性を保ちやすいため、データ間隔の計測に適しています。ただし、実際の日付時刻へ変換するには、基準となる時刻との対応付けが必要です。
測位ログを設計または選定するときは、位置に付くタイムスタンプがGNSS観測時刻なのか、端末受信時刻なのか、保存時刻なのかを確認します。名称だけでは判断できないこともあるため、既知のタイミングで動作させ、出力値を比較する実測確認が有効です。
確認4 ログ記録処理の遅延とタイムスタンプ位置を確認する
測位ログの時刻ずれは、時計の誤差だけでなく、タイムスタンプを付ける処理位置によっても発生します。GNSS受信機が位置を計算してから、端末の保存領域へ書き込まれるまでには、複数の処理があります。
まず、受信機は衛星信号を観測し、一定の周期で位置を計算します。次に、測位結果を通信データへ変換し、有線または無線で端末へ送ります。端末側では通信データを受信し、解析し、画面表示や品質判定を行い、必要に応じてファイルやクラウドへ保存します。
タイムスタンプが受信機内で付与される場合は、観測時刻に近い値を残せます。端末が受信した時点で付与する場合は通信遅延が含まれます。画面表示後や保存処理時に付与する場合は、さらにアプリの処理時間が加わります。どの方法が正しいかは用途によりますが、タイムスタンプの意味を明確にしなければなりません。
高頻度測位では、データがまとめて端末へ届くことがあります。例えば、通信が一時的に遅れた後、複数の測位結果が短時間に連続して受信される場合があります。各データにGNSS観測時刻が含まれていれば本来の間隔を復元できますが、端末受信時刻だけを記録すると、複数点がほぼ同じ時刻として保存される可能性があります。
クラウドへの送信時刻も、測位時刻とは区別する必要があります。通信圏外で端末内に一時保存し、電波が回復してからまとめて送信した場合、クラウドへ登録された時刻を測位時刻として扱うと大きな誤差になります。クラウド上の更新日時や同期日時は、現地で観測した日時とは異なる管理情報です。
写真を測位ログと関連付ける場合も同様です。撮影ボタンを押した時刻、画像センサーが露光した時刻、画像ファイルが保存された時刻、位置情報が画像へ書き込まれた時刻には差が生じます。静止した状態では問題が見えにくいものの、移動しながら撮影すると位置の食い違いとして現れます。
処理遅延を確認するには、明確な動作イベントを作ります。例えば、決めた時刻に受信機を一定方向へ動かす、既知の位置で停止する、撮影と測位を同時に行うなどの試験を実施します。その結果をログ、画面記録、外部時計と比較すると、固定的な遅延と変動する遅延を分けて確認できます。
固定遅延は、処理手順が変わらなければ補正できる場合があります。しかし、端末負荷や通信状況によって変動する遅延は、単純な一括補正では解決できません。そのため、可能な限り各測位点に受信機由来の観測時刻を保持し、端末受信時刻や保存時刻を別の項目として記録する設計が望まれます。
確認5 電源投入直後と再受信時の時刻確定を確認する
GNSS受信機は、電源を入れた直後から常に正確な日付時刻を出力できるとは限りません。衛星から必要な情報を取得し、内部状態を更新するまでに時間がかかる場合があります。測位座標が表示されたことだけを確認して記録を始めると、初期ログの時刻が不安定になる可能性があります。
受信機は、前回使用時の情報や内部時計を利用して起動を早めることがあります。しかし、長期間使用していなかった場合、保管中に内部時計がずれた場合、前回とは離れた場所で起動した場合などは、衛星情報の取得に時間がかかることがあります。
起動直後は、時刻、日付、測位状態をまとめて確認します。位置が表示されていても、日付が初期値になっていないか、時刻が急に変化していないかを見ます。一定時間のログを取得し、時刻が連続して進んでいることを確認してから本観測へ移ると安全です。
トンネル、建物内、橋の下、樹木の多い場所などで衛星信号を失った後、再受信した場面にも注意が必要です。受信不能中に端末側の時計で時刻を補い、再受信後にGNSS時刻へ戻す仕組みでは、切り替え時に時刻が前後することがあります。時刻が重複したり、一部の秒が飛んだりすると、ログを時刻順に並べた際に軌跡が乱れます。
端末やアプリが、GNSS信号を失った区間でも位置を推定して記録する場合は、時刻の基準が途中で変わっていないかを確認します。衛星受信中はGNSS時刻、受信不能中は端末時刻という構成では、二つの時計の差がログに現れる可能性があります。
省電力設定も見落としやすい要因です。画面消灯中やアプリが非表示になった状態で通信や保存処理が制限されると、測位データの受信や記録が一時的に停止する場合があります。処理再開後に蓄積データがまとめて保存されると、保存時刻だけを見た際に不自然な集中が生じます。
現場試験では、電源投入直後から数分間のログを保存し、日付、時刻、測位状態、衛星数などの変化を確認します。続いて、一度衛星を受信しにくい環境へ移動し、再び開けた場所へ戻る試験を行います。再受信の前後で時刻が逆行していないか、重複していないか、一定以上飛んでいないかを確認してください。
本番作業では、起動直後の一定時間を準備区間として扱う方法も有効です。準備区間のログを削除する必要はありませんが、観測成果として使用する範囲を明確に分けます。時刻が確定したことを確認してから作業開始の記録を残せば、後処理時に採用範囲を判断しやすくなります。
確認6 うるう秒・週番号・ファームウェア情報を確認する
GNSS時刻と協定世界時の関係を扱う際は、うるう秒情報に注意が必要です。GNSSで利用される連続的な時刻と協定世界時との間には差が生じることがあり、受信機は衛星から得た情報や内部データを使って変換します。
受信機が適切な情報を取得できていれば、利用者が毎回手動で補正する必要は通常ありません。しかし、長期間更新されていない機器、古い内部データを保持した機器、時刻変換処理を独自に行うソフトウェアでは、変換値が正しいかを確認した方が安全です。
うるう秒に関する問題は、数時間単位のずれではなく、秒単位の一定差として現れることがあります。高精度なセンサー同期や移動体計測では、1秒の差でも結果に大きく影響します。複数機器のログを比較し、常に整数秒だけずれている場合は、時刻変換の違いを疑います。
GNSSの時刻表現には、基準日からの週数と週内の経過秒を使用する形式があります。限られた桁数で週番号を扱う機器では、一定期間ごとに番号が循環します。古い機器や時刻処理では、この循環を正しく解釈できず、日付が過去へ戻るような問題が起きる可能性があります。
日付が大幅にずれている場合は、タイムゾーンだけでなく、週番号の解釈も確認します。時刻は合っているのに年や月だけが不自然な場合、単純な時計の遅れとは原因が異なります。ログ変換ソフトや自作処理で週番号を日付へ変換している場合は、基準期間の扱いを確認してください。
受信機や端末の内部ソフトウェア更新には、時刻処理の修正が含まれることがあります。ただし、更新すれば必ず問題が解消するとは限りません。更新前後で設定が初期化されたり、ログ形式が変わったりする可能性もあるため、作業前に変更内容と影響範囲を確認します。
複数台の機器を管理する場合は、内部ソフトウェアの版、設定ファイル、更新日、時刻出力形式を記録します。同じ型式の機器でも、更新状態が異なればログの動作が一致しないことがあります。一台だけ時刻がずれる場合は、設定だけでなく更新状態や保管履歴も比較すると原因を見つけやすくなります。
時刻処理に関する更新を行った後は、既知の時刻を使った確認観測を実施します。以前のログと同じ形式で出力されるか、時刻系や小数秒の桁数が変わっていないか、既存の後処理で正しく読み込めるかを確認します。本番現場で初めて更新後の機器を使うのは避けた方が安全です。
複数センサーと測位ログを正しく突き合わせる方法
測位ログは、写真、映像、加速度、角速度、距離、温度、施工機械の稼働情報など、ほかのデータと組み合わせて利用されます。このとき、すべての機器が同じ時刻基準で動いているとは限りません。
複数データを統合する前に、それぞれのタイムスタンプの意味を整理します。測位ログが観測時刻、写真が保存時刻、センサーが端末起動後の経過時間を記録している場合、そのままでは比較できません。まず共通の時刻軸へ変換するための基準点を決めます。
有効な方法は、すべての機器で確認できる共通イベントを記録することです。測位アンテナを明確に動かす、センサーへ一定の衝撃を与える、撮影画面に時刻表示を写すなど、各ログで識別できる変化を作ります。イベントの記録時刻を比較すれば、機器間の固定差を推定できます。
ただし、作業開始時に一度だけ差を確認する方法では、時計の進み遅れを検出できません。長時間の観測では、開始時と終了時に共通イベントを記録します。開始時の差と終了時の差が異なる場合、観測中に時計のずれが拡大した可能性があります。
高頻度データでは、秒以下の精度も統一します。ある機器がミリ秒単位、別の機器が秒単位でしか保存できない場合、完全な対応付けは困難です。この場合は、必要な分析精度を見直し、同じ秒内のデータを平均するなど、用途に応じた処理方法を決めます。
補間処理にも注意が必要です。測位が1秒間隔、センサーが0.01秒間隔の場合、センサー時刻に合わせて測位座標を補間することがあります。しかし、時刻差が残ったまま補間すると、滑らかな軌跡に見えても実際の位置とはずれます。補間より先に時刻同期を確認する必要があります。
通信遅延を含むデータを統合する場合は、平均的な遅延だけでなく、遅延のばらつきも評価します。固定差であれば一括補正できますが、通信状況により毎回変わる差は補正が難しくなります。可能であれば、各機器の内部で観測時刻を付けて保存し、通信時刻とは分けて管理します。
現場で運用できる時刻同期の確認手順
GNSS時刻同期の確認は、専門的な解析だけでなく、現場で継続できる形にすることが重要です。確認項目が多すぎると実施されなくなるため、作業前、作業中、作業後の三つの段階に分けて管理します。
作業前には、端末の日付時刻、タイムゾーン、自動時刻設定、受信機の出力時刻系を確認します。続いて受信機を起動し、衛星受信と時刻確定を待ちます。画面表示だけでなく、短い試験ログを保存し、日付、時刻、小数秒、測位状態が想定どおりであることを確認します。
複数台を使う場合は、同じ場所で同時に試験観測を行います。各ログの先頭と末尾を比較し、時刻差が一定か、時間とともに拡大していないかを見ます。機器ごとに時刻形式が異なる場合は、本観測前に変換方法を決めておきます。
作業中は、時刻の連続性を監視します。急に時刻が戻る、同じ時刻が繰り返される、記録間隔が大きく空く、日付が変わるなどの現象がないか確認します。長時間作業では、休憩や作業区切りの時点でログを分割すると、不具合が起きた範囲を特定しやすくなります。
衛星信号を失いやすい場所へ入る前後では、時刻と測位状態を記録します。受信不能区間から復帰した際に時刻が飛んでいないかを確認します。アプリを一時停止した場合や端末を再起動した場合も、同じ確認を行います。
作業後には、ログの先頭、中央、末尾を確認します。ファイル名や更新日時だけで判断せず、ログ内部の観測時刻を見ます。作業開始記録、写真、現場メモなどと比較し、実際の時系列と一致しているかを確認します。
データをクラウドへ同期する場合は、観測時刻とアップロード時刻を分けて扱います。同期後に表示時刻が変わっていないか、別の端末で開いても同じ時刻として読めるかを確認します。後日データを利用する担当者が時刻基準を判断できるよう、観測条件と変換ルールも保存してください。
時刻ずれが見つかったときの切り分け方
測位ログの時刻ずれを発見したら、すぐに全データへ補正値を加えるのではなく、ずれ方を分類します。原因を確認せずに修正すると、一部の区間だけ正しく、別の区間がさらにずれる可能性があります。
まず確認するのは、ずれが一定かどうかです。すべてのログがちょうど9時間ずれている場合は、協定世界時と日本標準時の取り違えが疑われます。数秒の一定差であれば、時刻変換、機器間の固定遅延、タイムスタンプを付けた処理位置などを確認します。
次に、ずれが時間とともに増えるかを確認します。観測開始時はほぼ一致していたのに、終了時には差が大きくなっている場合、端末や外部センサーの時計が一定の割合で進んだり遅れたりしている可能性があります。この場合、単一の補正値ではなく、時間に応じた補正が必要になることがあります。
ずれが不規則な場合は、通信遅延、端末負荷、省電力制御、アプリの一時停止、保存処理の待ち時間などを疑います。特定の区間でデータがまとめて出力されていないか、記録間隔が突然変化していないかを確認します。
日付だけが大きく異なる場合は、週番号や日付変換の解釈を調べます。時刻が合っていても年月日が不自然なら、タイムゾーンの問題ではない可能性があります。変換前の生データが残っていれば、元の週番号や経過秒から再計算できる場合があります。
一部の測点だけがずれている場合は、測位時刻ではなく、手動記録や編集処理に原因がある可能性があります。ログを統合した際に時刻形式が変わっていないか、並べ替えで文字列と時刻が混在していないか、同じファイルへ異なる時刻系のデータを追加していないかを確認します。
補正を行うときは、元データを変更せずに残します。補正後のファイルには、補正理由、補正値、対象期間、処理日、担当者を記録します。時刻を修正した事実が分からなくなると、後から別の担当者が再度補正し、二重変換を起こすおそれがあります。
測位ログの時刻品質を高める記録ルール
時刻ずれを防ぐには、機器設定だけでなく、記録ルールの統一が必要です。測位ログを受け取った担当者が、時刻の意味を説明なしで判断できる状態を目指します。
最低限残したい情報は、観測日、使用した時刻系、タイムゾーン、測位間隔、時刻の桁数、受信機の設定、端末の設定、作業開始時刻、作業終了時刻です。機器を再起動した場合や、衛星信号を長時間失った場合は、その時刻も記録します。
ファイル名に日時を含める場合は、ログ内部の時刻と同じ基準を使います。ファイル名は日本標準時、ログ内部は協定世界時という運用も可能ですが、基準が異なることを明示しなければ混乱します。時刻基準を統一できない場合は、ファイル名や管理台帳に区別を記載します。
ログの時刻形式は、日付と時刻を一体で扱い、秒以下の情報とタイムゾーンを保持できるものが管理しやすくなります。時刻の表示を短くする必要がある場合でも、元データには詳細な値を残し、表示段階で整形する方法が安全です。
測位間隔も記録します。設定上は1秒間隔でも、実際のログには欠測や遅延が含まれることがあります。時刻差を計算して記録間隔の分布を確認すれば、表面上は見つけにくい停止や集中を検出できます。
作業ごとに確認方法を変えないことも重要です。担当者によって、端末画面を見るだけ、ファイルを開く、外部時計と比較するなどの差があると、品質が安定しません。簡潔な確認手順を決め、同じ項目を記録できる運用にします。
定期的な確認観測も有効です。決められた場所と手順で短時間のログを取得し、以前の結果と比較します。機器更新やアプリ更新後だけでなく、一定期間ごとに実施すれば、時計のずれや設定変更を本番前に発見しやすくなります。
ログの保管時には、元データ、変換後データ、補正後データを区別します。どの段階のファイルか分からなくなると、時刻変換の重複や補正漏れが起きます。観測時の原本を保持し、処理内容を記録したうえで派生ファイルを作成してください。
まとめ
測位ログの時刻ずれを防ぐには、端末の時計が合っているかを見るだけでは不十分です。受信機が使用する時刻系、協定世界時と日本標準時の変換、GNSS時刻と端末時刻の同期方法、通信や保存処理の遅延、起動直後の時刻確定、うるう秒や週番号の扱いまで確認する必要があります。
特に重要なのは、測位した時刻、端末が受信した時刻、ファイルへ保存した時刻、クラウドへ同期した時刻を区別することです。これらを同じタイムスタンプとして扱うと、移動測位、写真管理、点群処理、外部センサーとの統合で位置の食い違いが生じます。
現場では、作業前に短い試験ログを取得し、作業中は時刻の連続性を確認し、作業後はログ内部の先頭から末尾までを照合します。時刻ずれが見つかった場合は、固定差、時間とともに広がる差、不規則な差に分けて原因を切り分けます。
補正が必要になった場合も、元ログを直接書き換えず、補正値や対象期間を記録してください。時刻の基準と処理履歴を残すことで、後日データを再利用するときも測位結果の信頼性を維持できます。
測位、記録、写真、現場情報を一つの流れで扱い、時刻管理を含めた作業の効率化を進めたい場合は、LRTK Phoneの活用も検討してみてください。