当社のAndroidプロジェクトでは現在、ArcGIS Maps SDK for Kotlin 300.0.0を宣言しています。CustomLocationDataSourceを使用して、NMEA文ではなくデコードされた位置データを提供する受信機を含む外部GNSS受信機からの測位結果を表示しています。
外部GPS使用時の地図位置更新の遅延や位置・精度の不整合に関する報告を調査しています。SDKがこれらの症状を引き起こしているとは確定しておらず、カスタムプロバイダーが意図されたSDK契約に準拠しているか検証したいと考えています。
当社のCustomLocationDataSource.LocationProviderは、別々のFlow<Location>とFlow<Double>ストリームを提供します。各外部Android位置情報はWGS84座標、水平・垂直精度、速度、進行方向を用いてArcGIS Locationに変換しています。外部受信機の場合、headingフローは測位結果の方位角から進行方向を導出します。Location.create呼び出しでは受信機の元の測位タイムスタンプを明示的に渡していません。一部利用不可または無効な精度や動作値は現在0に変換しています。
以下についてご助言いただけますか？
- カスタムソースでは利用不可の精度、速度、進行方向、ヘディングをどのように表現すべきでしょうか？欠損値に0を使うことはLocationDisplayが測位結果を扱う際に影響しますか？
- 受信機の元の測位時刻はどのように保持または検証すべきでしょうか？特に再接続やソース変更後に古いまたは順序が乱れた測位結果は発行前に破棄すべきでしょうか？
- 別々のheadingストリームを測位結果の方位角から導出する方法は適切でしょうか？位置情報とヘディングフロー間で順序や同期の要件はありますか？
- プロバイダーが測位結果を発行する前の遅延とCustomLocationDataSourceや画面表示での遅延を区別するためにはどのようなバッファリング、更新頻度、計測上の指針がありますか？LocationDisplayは受信した位置をアニメーションや補間しますか？
NMEAを提供しない外部受信機の場合、CustomLocationDataSourceが推奨される方法でしょうか？基本的なサンプル以外に、測位結果の鮮度管理、欠損値対応、再接続、可変更新頻度への対応など本番実装向けのガイダンスはありますか？
