logデータの突き合わせプログラムを書けという自分への指令(4)

最初のバージョンでは,日付とコールサインとモードが一致するという条件にしました.レコードが完璧に抜け落ちていたのは,2QSOのみで,それがいずれもUR2FEO局です.全くの偶然か,そのコールサインだけひっかかるような原因があるか,当時のLog200からMySQLにexportするスクリプトは残っていないので,全く探りようがありません.

この段階で,レコードの不一致があったものは,293件です.全レコード数は,7万9千件ほどなので,0.37%です.先日発表された,東京の新コロナの抗体保有者とコンパラです😓

目だったレコードの不一致は,モードの不一致です.50MHz帯の交信のSSBとCWが入れ替わっていることが多いです.周波数からモードを自動的に決める機能が,50MHzではあだとなっています.交信相手からQSLカードをもらって,気づいて修正しているところが多いです.

MariaDB(かつてはMySQL)のデータは修正しますが,オリジナルのログデータは修正しないことにしているのでこの不整合が発生します.

考えてみれば,ログソフトからMariaDBに取り込むときの漏れを問題にしているので,モードの不一致はドントケアーとします(警告だけ出すようにします).

その代わりに,時刻を±5分のマージンで絞ることにしました.この制限を付けても,全体の処理時間はほとんど変わりません.

そんな感じで何度か試行錯誤して練ってきたほぼ最終版を今走らせています.一度走らせると3時間待たないと結果が出ないので,試行錯誤のサイクルは長いです

関連項目

MariaDBのデータをMacかCore i7のWSに移して,テストすればたぶん何倍か早くなると思いますが,慌てることはないので😓

logデータの突き合わせプログラムを書けという自分への指令(3)

今日は少し元気なので,課題に😓実質的に着手しました.

とりあえず今日のところの成果物は,日付とモードとコールサイン指定して,検索して,もし結果が返らなかったら”die”する,つまり最初に未登録のデータを見つけたらそこまででおしまいというプリミティブなものです.

作業的には元のスクリプトから削除するのが大部分となりました.

走らせたところ,3時間ちょっとで終了です.Perlの実行時間はなんとそのうちの33.7秒で,ほとんどはmysqldの所要時間です.

topからも,そこら辺が解ります.

まだ,dieしなければ,何にも返ってこない仕様なので,これだけではスクリプトが正しいかどうか解りません.また,日付とモードとコールサインだけで指定しているので,コンテストなどだと,複数レコードが返ってくるはずなので,そこら辺を表示するように改良したいと思います.

関連項目

logデータの突き合わせプログラムを書けという自分への指令(2)

スクリプト名だけを考えました.

call_db_intactness.pl

です.拡張子の通り,Perlスクリプトです.

中身は,Log200の中身をMariaDBに放り込むスクリプトをコピーした段階です(つまり,実質的には何もしていない😓).

Log200のログデータを読み込んでparsingするところは,そのまま流用できます.

その後,Log200の1レコードずつについて,日付,交信開始時,コールサイン,周波数,モードを抜き出して,MariaDBに検索をかけて,ヒットするレコードがひとつならばOKなので無罪放免,ヒットするレコードがなければエラーを出す,2つ以上あれば警告を出す,という仕様にします.

ちなみに,現在,MariaDBには,アマチュア無線人生全ての期間(1972〜現在)の95,000余りのレコードが登録されていて,Log200は,1998年4月以降の分の8万弱レコードが登録されています.

今日はここまで(って結局実質的に何もしないでおしまい😓).

関連項目

Google Maps Timelineがどうしようもない

Google Maps Timelineのデータ修正機能が復活したと喜んだのもつかの間,とんでもないことになってしまいました.表示がめちゃくちゃです.

これまでほぼローデータを地図上にマッピングしてきていましたが,少し前から自動車のデータを道路に沿わせる機能が付きました.ただし,これはオプションで,ローデータのままにしておくこともできます.

ところが,今回,自動車ばかりでなく自転車や徒歩のデータも何かしようとしているようです.オプションではなく無理矢理のようで,しかも副作用がひどすぎて,私の徒歩と自転車移動が中心のデータは,ほとんど消えてしまった状態です.

かれこれ何年か,Google Maps Timelineが,GPSロガーとして使えると思ってやってきましたが,また,GPSロガーアプリを探すことにします.

追記: ほぼ元通り(2020/06/27)

今日確認したら,データの修正機能の不具合はほとんど正常に戻っていました.また,無理矢理道路にマッチングさせるのもなくなりました.ほとんど以前の正常だった頃へリバートされた感じです.

ただし,Pokémon GOと併用した場合.

logデータの突き合わせプログラムを書けという自分への指令

最近は,スマホやパソコンのTo Doに書いておいても,完全に無視するのでBLOGに書いときゃやる気になるかなと言う試みです.

私はログは書き込みのフロントエンドと,データベースのコア部分とは別立てとして,特にデータベースには信頼性の高いものを使うべきとも考えています.

フロントエンドは通常運用,コンテスト,デジタル運用とそれぞれの運用の特性に適したものを使うべきです.

そういう訳で,通常の運用全般には,JH3GBD堀野さん作のLog200を長年愛用しています.Log200の交信データはテキストなので,これをPerlの自作スクリプトで中核のデータベースであるMariaDBに放り込んでいます.

データベースはもともとMySQLを使用していましたが,いろんな意味であんまり信頼できない会社に買収されてしまったので,オープンソース社会の流れに従ってMariaDBに移行しました.

また,コンテストのフロントエンドとしてはN1MM+を使いますが,中間的にLog200にマージしてから,同じスクリプトでMariaDBに送り込みます.

FT4/FT8はWSJT-XのmacOS版を使用し,そのログをMariaDBに別のスクリプトで送り込んでいます.

今は改修済みなのですが,Log200からMariaDBに送り込むスクリプトの,既にMariaDBに送り込んだレコードかどうかを判別する部分にバグがあって,頻度は少ないはずですがレコードを取りこぼしている可能性があります.

その取りこぼしを検証するスクリプトを書かなければいかんと前から思っているのですが,取りこぼしがあったところで,痛くもかゆくもないし,あまり楽しいスクリプト書きではなさそうなので,伸ばし伸ばしにしてきたというわけです.

関連項目