990204 – サイトのGPSログのジオイド高修正の話
前回の記事で、WP GPX Mapsのプラグインでログごとにマップデータの種類を変える方法が分かったので、街中散策のデータをOpen Street Mapで表示させるオプションを付けて更新した。
更新後にちゃんと反映されているか確認するために、それぞれページをロードさせてチェックしていた時に、ふとおかしなことに気が付いた。
よく見ると、海岸沿いの平坦地を歩いているログで標高データが30ｍ前後の値を指していて、全体的に実際より高く表示されている。
あれ、と思って他のデータも改めてチェックしてみると、富士山の山頂に到達した時の標高が3819mになっている。今まで、グラフ表示が登山のデータに限られていて、数字が大きかったせいかあまり気にならなかったらしい。
いうまでもなく富士山の標高は3776mであり、43mも高い値になっている。それ以外のデータも標高値を下回るものはなく、全てが上振れしている感じだ。
まぁ、上振れしているからと言って、そこを気にしてい見ている人は多分いないと思うので、放っておいても何ら実害はないのだが、何となくすっきりしない。簡単に直せるものなら、修正しておきたい。
ということで、調査開始。
まず、加工中の改変を疑った。掲載しているGPSログは実は生データではない。実際に行動していると休憩などで一か所に留まったり、数m程度の範囲を行ったり来たりすることがあるが、そういう時の計測データはばらつきが起こって線がぐちゃぐちゃになるので、それら見栄えが悪くなるデータを間引きして保存したデータを使っている。
その作業の最中に何らかの改変が起こってしまったのではないかと思ったのだが、原本の標高データも同じ値だったのでその線は消えた。
GPSデータは複数のGPS衛星によって位置や標高などを計測しているので、実際の位置から多少の誤差が生じると言うことは知っているが、位置は合っているのに標高だけずれる、と言うのは何だろうか。
スマホ搭載のGPSアンテナの精度の悪さのせいなら、あれこれ悪あがきしてもしょうがない気がするが、何か原因となることがあるかもしれないと思い、ネットで調べて見る。
だが、「GPS 標高 ずれ」などのキーワードで調べてみたが、ピンとくる情報は得られなかった。
原因が分からないのはすっきりしないが、データが全体的に３～40m上振れしていることは分かっている。ならばデータから一括でそのくらいの数値を引けばいいのだろう、と思って、次にアプリの機能を調べてみた。
現在GPSデータのチェックや加工はカシミール3Dというアプリを使っている。
あれこれ調べていくと、「標高の変換」というメニューを見つけた。これだ。
ところが、これは地図上の標高値に対していくらか増減させた値で一括更新をかけるか、全ての値を指定した値で一括で書き換える機能しかなく、各ポイントのデータから一括で増減させるための機能ではないようだ。
アプリ上で修正できないので、次にデータのCSVエクスポートができないか調べてみた。エクスポートさせて、EXCELかなんかで修正してまたインポートすれば、まぁひと手間ではあるが許容範囲だ。
だが、CSVエクスポートの機能もないっぽい。。。
他のフリーウェアなども探してみたが、標高値を書き換えたり、CSV変換をかけてくれそうなソフトも見つからない。。。こんな要望ないのだろうか？
こまった、こりゃ意外と手ごわい。データがいじれないとなると、手も足も出ない。。。
何でもいいからヒントが得られないかとさらに調べる、と、「ジオイド高」というキーワードが目に止まった。
細かい説明は本家を参照願いたいのだが、GPSの高度測定は、地球を仮想的な楕円の球体(地球楕円体)に見立てて、測位衛星からその地球楕円体までの距離と、計測で得られた実測値との差分によって標高を導き出しているらしい。
一方、日本の標高データは測量法という法律に基づき、標高は平均海水面からの高さと定められている。
平均海水面の高さはそのまま地中にも適用されるのだが、地球の中身は様々な物質で組成されているため、場所により重力が変わる。水が高い所から低い所へ流れるのは重力のためだが、その重力が場所によってまちまちなので、事と次第によっては(見た目上)低い所から高い所へ水が流れる可能性もある。まぁ、それは極端な話だが、平たい所を流れる水流がどちらへ向かって流れていくか、と言ったような場面では、影響を無視できないらしく、平均海水面の値から、更にその場所の重力による差分を補正して標高を決めているらしい。
この補正を反映した地中の平均海水面の高さをジオイド高と言うそうだ。要は、地理院地図に記載されている標高はジオイド高を反映した値なので、GPSによって計測された標高データとは差分がありますよ、ということだ。
で、その差分が日本国内では概ね30m～40m程度らしい。
それだ！
だから30mくらい数値がずれていたのか。。。スマホのせいにしてごめんな。
それが分かればやることは一つ、現在の標高データからジオイド高を引けばいい訳だ。
国土地理院のサイト上に指定された地点のジオイド高を表示させてくれるアプレットがある。
これは、地点データをアプレットにインポートすると、その地点のジオイド高情報をエクスポートしてくれる。
データフォーマットの説明によれば、緯度と経度のDMS形式データを作って、拡張子.inで保存し、アプレットにインポートするそうだ・・・って、DMS形式ってなんだ？
いやまて、そもそも、GPSデータをエクスポートする方法がまだわかっていないではないか。それが分からなければ、ジオイド高云々も絵に描いた餅だ。
CSVエクスポートが出来ないなら、カシミール3Dで選べる保存形式を一つ一つ選んで保存して、そのデータを覗いてみることにした。
エクスポートしたデータをテキストエディタで開くと、ttrk形式のデータがスペース区切りになっていた。これなら使えるかな。。。
ただ、表示されているデータがどういう規則で書かれているものなのかが分からなかった。と言うのも、カシミール3Dのトラックデータ編集画面に出てくる数値とエクスポートしたデータの数値が合っていないのである。
例えば、カシミール3Dのデータは、緯度に「N 35°17’07.64」、経度に「E 136°33’11.44」と表示されているのだが、同じデータのtrkファイルを見ると、緯度が「N35.2854560」、経度が「E136.5531780」となっている。これはどういうことだろう？
またまたGoogleセンセに質問してみたら、緯度経度の表示方法として複数の種類があることが分かった。
カシミール3D画面上の「N 31°48’19.43」という表記はDMS形式というそうだ。「北緯31度48分19秒43」ということだ。
対して、エクスポートした方のデータはDEG形式といい、単純に緯度経度を度数で表現したものだそうだ。
そう言えば、DMSとDEGって保存画面の中で選べたな。
ということで、DMSを選んで保存したら、ちゃんとDMS形式のスペース区切りデータを取り出すことができた。
これのヘッダー部を除いた実データ部分をコピーしてEXCELに貼り付け、[データ]-[区切り位置]でスペース区切りで区切ってやる。
次に、区切ったデータから緯度、経度のデータが記載されているセル(B,C列)のみをコピーしてテキストエディタに貼り付けて、.inの拡張子を付けて保存。やっとデータが作れたー。
そのあと、作ったデータをジオイド高計算ツールに食わせて、計算実行をすると程なく元データにジオイド高が追加されたデータが.outの形式で吐き出された。
テキストエディタで開いてみたら、元のデータの右側にジオイド高の値が小数点第4桁までの値で追記されていた。
そこで、今度はそのデータを再びEXCELの元データの隣の列(I列)に貼り付けて、同様に区切り位置で区切る。するとレコードとその場所のジオイド高が紐づく。
小数点以下の値はWebやカシミール3Dで表現できないし、そもそも元データに計測誤差が含まれるので、補正しても実際の値との誤差は出てしまう。なので厳密な値を求めてもしょうがない。INT関数を使って整数部分のデータだけ利用することにした(M列)。その値を引き算で引いた値が実際の値に近い標高となるわけである(N列)。
公開しているすべてのGPSログデータのジオイド高を抽出したら、やっぱり全体的に35～40m程度のジオイド高があり、それを差し引いてみたら、概ね実際の標高データに近い数値を求めることが出来た。
ただし、海岸沿いの散策など、全体的に標高が低いデータによっては標高が20m以下で記録されていることもあり、ジオイド高を引くと海抜がマイナスになりがちになる。
スマホの精度の問題なのか、GPS計測上のクセなのか、海岸付近のジオイド高が実際より過剰なのか、その辺は良く分からなかったが、マイナスデータが続くとグラフ上気分が悪いので、更にいくらかの補正をして概ね0m以上になるように修正した(O列)。補正値はデータを見ながら適当に決めた。まぁ、この辺りは蛇足である。
といっても、単純に補正値を入れただけなので、街中から山に登るようなデータだと、どっちかが不自然な値になってしまう。この辺は追及してもキリがなさそうだったので、あまり深追いしないことにした。
まぁ、元が正しくないデータに何をやっても正しいデータにはならないので、気分的な折り合いが付けば良しとした。
ジオイド高を考慮した標高データに修正した後、元のデータ部分の標高値を計算によって求められた値で上書き(O列の値をF列にコピー)して、A列からF列までをCSVで保存する。
trkファイルはスペース区切りデータなのだが、EXCELから直接スペース区切りで出力する方法がないので、一旦CSVでエクスポートして、それをテキストエディタで開き、置換を使って","を”"に置換した。
更に元のtrkファイルのヘッダー部分をコピーしてCSVデータの先頭に貼り付けて保存。
(逆に元のtrkファイル側のデータ部を差し替えても良いかもしれない)
最後に、拡張子csvをtrkに変更。
これをカシミール3Dで開いて、そのままGPX形式で保存したら作業完了である。もちろん最後にWebサーバー上に転送させるのも忘れずに。
手数が多いので、マクロやバッチファイルなどを作成してもよかったのだが、それぞれのステップで都度データがどのように更新されているか確認しながら進めたかったのもあって、最後までステップバイステップでやったので、そこそこ時間がかかった。
ファイル数がせいぜい100個くらいだったので何とかなったが、数百といったレベルだったら自動化しないと心が折れる。。。
と言うか、今後アップロードの度にこれをやるべきかどうか悩みどころである。。。
さて、最後にもう一つ。
GPSログを貼り付けた記事をブラウザで表示させると、ログが貼られているところに下記のエラーが出る。
何故か初回だけ表示され、ブラウザをリロードさせればエラーは出なくなり、それ以降は表示されない、という、Internal Server Errorに匹敵する悩ましいエラーなのだが、こちらは原因が分かった。
エラーメッセージを見るとGPXデータの中に読めないタグが設定されているよ、と書かれている。
GPXファイルをテキストエディタで開いたら、該当のパラメータが記載されたタグがヘッダー部分にあったので、そこを丸っと削除。
これでエラーが出なくなった。
ただし、カシミール3Dで開いて上書き保存するとこのセクションが復活してしまう。
上記のジオイド高反映作業と一緒にこれも毎度やらなければならないということか。
考えただけでやや憂鬱である。。。