電子ログのログシート部分の解析についての考察

2005年に行われるALLJA0コンテストにおいて受付時のログシートの解析が行われる見込みとなりました。

日本におけるコンテストの電子ログ受付も５年が過ぎ、しっかり定着してきましたね。私がかかわるJARL長野県支部でもALLJA0コンテストに導入してから３年が過ぎました。

当初順調と思われた電子ログもサマリーシートについてはかなりしっかり解析をしているものの、ログシートについてはまったくのノーチェックで、人間の手にゆだねられていました。提出されたログのチェックと言うものは結構大変なものがあって、特にALLJA0コンテストは得点計算やマルチがユニークなため(そこが面白いのですが)、得点計算の間違いが多く、そのチェックは大変なようです。

少しでも効率のよいログチェックはできないかとコンテスト委員会は21,28MHzコンテストにおいてはバンド別にログシートを記入するように規約を決めました。しかし多くの電子ログ提出者は電子ログには当てはまらないものと解釈し、また、コンテスト委員会の宣伝不足もあいまって大量の失格者を生む羽目になってしまいました。

そこでログシートの解析、自動集計ができないかということになったのですが、それは結構大変なものでした。その顛末をここに記録しておきたいと思います。

もともと電子ログ受付プログラムはJARLのコンテスト委員会から無償で提供を受けたものです。(感謝) ITの時代にふさわしく、郵送でのみ受け付けていたコンテストのログを電子メールでも受け付け、コンテストを盛んにしようという試みだったと思います。すでに多くの海外におけるコンテストでは電子ログ受付が進んでおり、日本のコンテスト事情に合わせた受付となったと思います。

プログラムはperlで書かれており、メールサーバーに仕掛けて使います。受付プログラムのほかに集計の一覧表が簡単にできるものとなっています。

サマリーシート部分についてはXMLに準拠した方式となっていて解析がしやすいようになっているのですがログシートについては奨励パターンはあるものの、詳細は決まっていません。提出されるログシートのひとつでも多くのログが解析できるように考えました。

JARLにおけるログシートの推奨方式はZLOGのものです。本来はLOGSHEET TYPEによっていくつかの解析パターンを用意し、それによって解析しようと、設計者は考えていたのではないかと想像します。ところが同じZLOG(Zprint)の出力したログにも非常に多くのパターンが存在し、LOGSHEET TYPEを見ただけでは解析できませんでした。同じZLOGでも１０種類くらいあります。

提出されたログシートを分析すると、一番多いのがZLOG、ついでHLTST(ターボハムログ)の形式です。まずはこれに標準をあわせます。これを見比べると得点の記入位置が違うだけでほぼ同じ並び順であることがわかります。他のログを調べても一部の例外はありますが、コンテストナンバーの部分までは同じ並び順であることがわかりました。

そこでLOGSHEET TYPEを無視し、並び順で解析していくことにしました。区切り文字はスペース、タブ、カンマ(，)が使えるわけですが、内部では処理しやすいカンマに統一しています。

解析手順は１行を大きく分けて４つに分けて解析します。日付時間、コールサイン、送受信ナンバー、その他の４つです。

日付時間

まず日付および時間です。一体で切り出していきます。ざっと調べただけで次の種類があります。

3 7 0801
3 6 21:08
3/06 2100
03/07 08:58
2004/03/07 08:33
2004-03-07 08:33
04/03/07 10:17
040306 2233
0307 0828
2004 3/06 2100

他にも今回は対応できなかった(しなかった)形式に 8-Feb-04 1022 なんてのもありました。

コールサイン

コールサインはALLJA0の場合、直接得点、マルチに結びつきますので、国内のコールサインであることを厳しくチェックしています。

コンテストナンバー

次にコンテストナンバーを検出します。これは 599001 599001 、 599 001 599 001の両方がありますが、他に 599001 599 001、599 001 599001なんてのもあります。全部で４つの形式を順番に比較し、検出します。

その他

その他にはバンド、モード、得点、マルチ、備考がありますがこのうちバンドとモードのみ検出します。これによってZLOGとHLTSTは同じ形式と見ることができます。それ以外の得点およびマルチは検出されたコールサインから切り出します。バンドとモードは一体で検出します。数字の次にアルファベットのモードが続いていることで判断しています。また、3.5および7MHzのコンテストはマルチバンドでないので検出できなかった場合は参加部門から判断しています。

もうひとつ問題になったのが２行に分かれてしまっているログです。多くのメールソフトは１行の行数を75-80文字として自動で折り返す機能があります。多くのログシートはこの桁数を超えています。しかしほとんどは空白部分で折り返されるのでコールサインまで検出できたものがそれ以降の空白で折り返された場合に限って２行のログも受付できるようにしました。

これで90%以上のログは解析できるようになりました。本当は100%でないとだめなのでしょうが、自由形式のログシートでは不可能でした。

ログの解析結果は、その結果を重視し、提出者の得点を無視するのも一つのやり方ですが、提出者のデーターを重視するようにというコンテスト委員会の方針に従い、総得点が一致しない場合はエラーとし、解析結果は確認の意味を含めてすべてのログに添付して返信するようにしました。

終わりに

ZLOGの形式がいくつもあるのはJARLのコンテスト委員会のページのサンプルにelogmakerのまま提出せずにZLOGと書きなさい(本当は違う意味なんですが)と書いてあるためがあるせいかなとも思いますが、それにしてもいろいろあります。

まだログシートの解析を実行している電子ログ受付は国内には無いと思います。これからどんどん普及していくでしょうが、そのときの参考にしていただけたらと思います。なお今回の受け付けプログラムの変更部分は要望があれば公開していきたいと思います。

最後に電子ログ受付プログラムを公開してくださったJARLコンテスト委員会ならびに開発者の JN2MRJ/1 間野 さん、およびこのプログラム開発に協力してくださったJA0FVU,JG0SXC,JJ0ACAの各位、ならびにJARL長野県支部コンテスト委員会に感謝申し上げます。

文責 JH0CFK 大森俊樹 2004年12月記