GPSロガーのデータをFreeBSDで取り込みたい

はじめに

これは「メモリの逼迫はいつまで続くか」とAIに尋ねた¹のをきっかけに、今までWindowsで動作する専用ソフトウェアで取り込んでいたGPSロガーのデータをFreeBSD(GhostBSD)で取り込めるようになってしまった²記録です。

GPSロガーを挿してみる

とにかくGPSロガーをFreeBSD(GhostBSD)のUSBポートに挿してみます。dmesgを確認すると、USBに何か挿されたことは認識しているっぽいです。

まずGhostBSDで cu -l /dev/cuaU0 -s 9600（速度は機種によります）を叩いてみてください。文字が流れてきたら、その瞬間にWindowsへの依存は終わります。

とAIが言っているので、やってみます。³

cu -l /dev/cuaU0 -s 9600

$GPで始まるそれっぽい文字列が流れてきました。これは「『NMEA-0183』 という標準的なシリアルプロトコル」なのだそうです（そうAIが言ってました）。

もしこの形式であれば、解析の必要すらなく、既存のオープンソースツールで即座に代替可能です。

だそうで、、、⁴

ただ、これは「リアルタイム追跡」という機能らしくて、今の位置を通知してくれるものみたいですね。が、デスクトップPCに挿しているわけですから「今の位置を通知」してくれても何も嬉しくありません⁵。GPSロガーの内部メモリからログを吸い出したいのです。

GPSBabelのインストール

ということで、「GPSロガーの内部メモリからログを吸い出したい」とAIに尋ねたところ、ロガーのメーカー名や型番を聞かれました。製品にはそれっぽいものは書いてありません。なので、製品の見た目からGT-730F/L (SiRF) の前の機種ではないか⁶、と答えたところ、GPSBabelというツールの利用を薦められました⁷。

FreeBSDのportsにありますので、パッケージをインストールします。

pkg install gpsbabel

ログの吸い出し

今回ここに一番時間が掛かりました。が、実は最初に試みた以下のコマンドで成功していました。

gpsbabel -i skytraq -f /dev/cuaU0 -o gpx -F out.gpx

このコマンドはハングアップしたように見えた⁸のですが、単に吸い出しに時間が掛かっていただけみたいです。そういえばWindowsのソフトウェアでも読み出しにはかなり時間が掛かっていたような、、、⁹

データの確認

out.gpx というデータはできました。次に、このデータがまともなデータかどうかを確認したいですよね。地図上に軌跡を表示してくれれば一番確実なのですが、out.gpxをそういうWebサービスにアップロードしようとすると、その大きさゆえに拒否されます。そんな時にはGPSBabelで分割や間引きができるのだそうです。が、それをやろうとすると

track: init: Track points badly ordered (timestamp 20yy-mm-ddT03:49:50Z > 20yy-mm-ddT03:49:49Z)!

と表示されて何もできません。このエラーメッセージについてAIに尋ねたところ「GPSロガーあるある」「『並べ替え』と『クリーニング』を挟むといい」などと言われました。
が、その通りにやったファイル(out2.gpx)でも結果は同じです。で、out.gpxとout2.gpxのdiffを取ったところ、ほぼ差分はなく、「並べ替え」がされているようには見えませんでした。

データの整理

手元にあるデータを確認したところ、waypointが多数続いた後にtrackが一つあるもののようです¹⁰。エラーメッセージはtrackの中の点の順序がおかしいと言っていますが、どうもAIが提案してきたのは（trackではなく）waypointの「並べ替え」の方法らしいのです。
そこで以下のようにします。

gpsbabel -i gpx -f out.gpx -x transform,wpt=trk -x nuketypes,tracks -x sort,time -x transform,trk=wpt -x nuketypes,waypoints -o gpx -F out2.gpx

具体的には

1. track内の点をwaypointにせよ（-x transform,wpt=trk）
2. trackを消せ（-x nuketypes,tracks）
3. waypointを時間順に並べ替えよ（-x sort,time）
4. waypointをtrackにまとめよ（-x transform,trk=wpt）
5. waypointを消せ（-x nuketypes,waypoints）

ということを一つのコマンドで順番にやっているのだと思います。trackやwaypointを途中で消していますが、そうしないとファイルサイズがだんだん大きくなっていってしまうからです。なので、元のファイルが小さければ「消せ」は省略してもいいかもしれません。¹¹

ただ、やはりこれでもファイルは大きなままなので、特定の日付を取り出して確認することにします。

gpsbabel -i gpx -f out2.gpx -x track,start=20xx0102,stop=20xx0103 -o gpx -F 20xx0102.gpx

データの並べ替えはout2.gpxで完了してますので、これは問題なくできました。この大きさであれば地図上に軌跡を表示するWebサービスにアップロード可能です。なんかそれっぽいものが表示されましたので、ログの吸い出しには成功しているようです。

手元で確認

ですが、軌跡を表示するために毎回Webサービスにアップロードというのは面倒ですよね。それに、ある意味かなり際どい個人情報な訳で、、、
ということで、これもAIに聞いてみましょう。Vikingというものを薦められました。これもFreeBSDのportsにありますので、パッケージをインストールします。

pkg install viking

で、先ほど作成した20xx0102.gpxをVikingで読み込みます。

なんかそれっぽいものが表示されました。これはとある駅からとある神社へ初詣に行った時のログですね。データもまともだし、その表示にも成功しました。めでたしめでたし。

おことわり

この文章の内容は、筆者が所属している会社・団体とは一切関わりがありません。いわゆる「自主的な研究の成果の発表」というものです。

1. まあ、そもそもAI（にこんなことを聞く私）が原因なのは明らかですけど ↩

2. 「今メモリ買うのは得策ではないですよ。それにFreeBSDは快適に動いているのですよね。FreeBSDで読み込むのは非常に現実的で面白いプロジェクトになりますよ」とAIに煽られました ↩

3. コマンド例の中にはsudoをつけることが必要なものもありますが、ここでは一切つけません。 ↩

4. なかなか煽ってきますね、このAI、、、 ↩

5. それにPCのすぐ側というのが良くないのか、そもそも測位ができていないみたいです、、、 ↩

6. 後で購入履歴を漁って確認したところ、F-GFL100でした。ただ、GT-730F/LとF-GFL100は実は同じもの、みたいな記述を見かけましたので、これで大正解だった！？ ↩

7. 今AIとのやりとりを読み返すと、AIはMac向けにGPSBabelを薦めてますね。FreeBSD向けには別のツールを薦めてますけど。まあ、GPSBabelで上手くいったので、結果オーライということで。 ↩

8. コマンドを入力しても、特に進捗状況が表示されるわけでもないので、ハングアップしてしまったのかと思いました。そして、AIに相談しつつオプションの指定をいろいろ変えては試したのですが、状況は変わりませんでした。が、ある時カレントディレクトリを見てみたら、「ハングアップしてしまった」ように見えた時も、out.gpxはできていることに気づきました。そこで、「ん？これはもしかして待てば終わるのでは」ということです。ロガーの内部メモリに結構データが溜まっている状態だったのも良くなかったみたいです。 ↩

9. ここまでできたらAIには『FreeBSDでこの手の古いハードウェアを現役で動かし続けるのは非常に「らしい」楽しみ方ですね。』と言われました。やはり煽ってきますね、このAI、、、 ↩

10. 本当にこれでいいのでしょうか。xmlだから機械可読でめでたしめでたしということなのかもしれませんが、「意味」が間違っているのでは、、、 ↩

11. と、ファイルサイズだけを見て私は思ったのですが、この文章をAIに最終確認してもらったところ、『正確には 「GPSBabelの内部バッファ（メモリ上）での重複を避けるため」 です。』と言われました。さらにこういうふうにしないと結果としてデータの重複も発生するそうです。が、もうやりたいことはできて満足なのでさらに調査する元気はありません ↩