なお、データ読み込みの遅延については、昨晩に解消されています。
マイル・ｋｍ換算と、
UTC・JSTの時差を考慮して、
アプリのデータを補正してみます。
以下、あくまで私の勝手な想像です。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
１．走行距離の異常について（想像）
世界ではマイル表示を採用する国の方が少数派ですが、
超巨大市場であるアメリカがマイル表示ですので、
本アプリも距離の単位としてマイルが選べるようになっていると仮定します。
日本向けにはマイル→ｋｍに換算が必要なので、
もし、元データがマイルで保存されているなら、
データの取り込み時に約1.61倍する必要があります。
今回は、この1.61を余計に乗じてしまったと仮定します。
２．走行時間の異常について（想像）
Mitsubishi Connectには、
スマホだけでなくPCからでもアクセスすることが可能です。
PCでアクセスすると、
「(*) 日時はUTC表記になっています。」
との注釈があり、
ローカライズがイマイチ、
もといｗ、グローバル視点でシステムが構築されていることがわかります。
今回、アプリ上の１日の走行時間・距離が実際の走行時間・距離の約半分になる日があり、
そんな日の翌日の走行時間・距離が逆にやたらと長くなるケースが見られました。
もし、日付変更をJSTではなく、UTCで行ってしまった場合、
日付変更は日本のAM9時になりますので、
時差的に整理すると、
・前日AM９時～当日AM９時 → 前日分
・当日AM９時～翌日AM９時 → 当日分
のように走行距離や走行時間が
実際とは半歩程度ズレて加算されることとなります。
その日、0時～9時で車に乗らなかった日は、
この時差による誤差が乗って来ないため、
マイル・ｋｍによる誤差だけで説明できてしまう日が多数派となるのも、
我が家の場合は頷けます。
今回は、日付変更をUTCのままで行ってしまったと仮定します。
３．補正結果（想像）
毎日の走行が、AM9時よりも前か後かまでは、さすがに記録していなかったため、
簡易的ですが1日のアプリでの走行距離と時間を、3：5に分割し日付をズラして加算し直し、
更に、走行距離については1.61で割ってみました。
結果を図1に示します。
青がオドメーターでの距離、オレンジがアプリからのRAWデータ、
グレーがアプリのRAWデータを今回の簡易的な方法で補正した結果です。
かなり乱暴な補正方法でしたが、そこそこ一致してますねｗ
日々毎の走行距離の変動が多いところは、
さすがに３：５分割では誤差が乗ってしまっていますね。
この方法で計算した日々の平均速度は、
時速300キロ超！！なんて異常値は無くなり、
全てが時速20～40キロの範囲に収まるようになりました。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
以上、あくまで私の想像で、
原因はもっと高度なトラブルなのかもしれません。
昨晩の改修で、
１年分のデータでも一瞬で再表示されるため、
かなり快適になりそうです。
では、今日はここまで！
