JARL電子QSLのコンセプトモデル案

JARL電子QSLシステムのコンセプトモデル案を考えてみました。

随時アップデート予定です
作成：2020/10/02
更新：2020/11/01

単なる個人的なアイデアですのでいろいろと検討の必要があります。皆様の議論のたたき台としてご利用ください。

本来は、要件(要求)仕様をきちんと定義し要件仕様書とし、それを元にシステム構成を考えるべきではありますが、すでにいろいろと考えられている方々もいらっしゃるようなので、いろいろな仕様に対応できるシステム全体を作るにはどういう物が良さそうか、全体の基本思想をどうするのが良さそうなのかを考えてみました。

若い皆さんで、ぜひ、システム構成や機能の議論をしてください。

その際のたたき台としていただければ幸いです。

2020/10/31に『第3回 YOTA Japan アマチュア懇話会』でコンセプトモデル案紹介の発表をさせていただきました。その際の資料を公開します。

なお、課題事項にこの発表の際にいただいたご意見を追加しています。

ありがとうございました。
『第3回 YOTA Japan アマチュア懇話会』発表資料

基本的な考え方(仕様作成に向けてのコンセプト)は以下となります。

【基本コンセプト】

• システム構成について

1. 各機能はモジュール化し、最初は最小限の機能で開始して順次拡張可能とする。
2. 独自ハードウェアを保有せずクラウドを利用することで機器の老朽化時の追加コストを削減する。

• QSOデータについて

1. QSOデータは直接保持せず、すでにある外部システムとの連携により行う。
2. 世界的な標準であるADIFによるデータ交換を基本とし、ADIF定義の情報のみを扱う。
3. ADIFの「MY_CNTY」(JA:市区郡番号)フィールドを使用して移動情報をQSOデータ内に保有することで、移動地毎の別アカウントを不要とする。

• 外部連携について

1. 現在すでに普及している国際的なシステム(LoTW,Clublog,eQSL等)との連携を行う。
2. コールサイン所持の認証を行うことで、各外部システムとオーソライズされたデータ交換を行う。

• JARL発行アワードについて

1. JARL発行アワードの申請を電子的に行えるようにして発行コストを下げる。
2. Club Logなど既存外部システムと連携することで、海外局や非会員でも連携先にQSOデータを送っておくことでJARLアワードの確認/申請が可能となる。

• QSL画像データについて

1. QSOデータやアワードには画像データは不要であるが、QSLカードからの移行に対する心理的敷居を低くするために画像データとQSOデータを合成して表示/ダウンロード可能とする。

このコンセプトモデル案の図はアプリケーション開発が多少はわかる方を対象としています。

※以下画像へのリンクがどういうわけか作成時には表示されていても、しばらくするとエラーになってしまいます。→おそらく解決したと思われます。
エラーになっている場合はPDFファイルをダウンロードしてご覧ください。

JARL電子QSLシステム コンセプトモデル案 2020/10/04版(PDF)

【課題等メモ】

• JARLアワードに関する提言

1. JARL発行アワードではRSTレポートが必須となっているが、DXCCなどは不要である。交信の事実があればRSTレポートは特に必要はないと考えられるので、今後アワード申請にRSTレポートの要件を不要としてはどうか。
   → LoTWからのQSOデータ利用(アワード申請)を可能にできる。

• コンテストログ対応について

1. コンテストログ(Cabrillo形式)の受付、検証、QSOデータへの反映のプロセス検討
   コンテスト終了までログとして公開しないなどの機能が必要かと思われます。
2. JARL主催だけでなく、コンテスト集計エンジンの機能を外部団体へ提供しても良いかもしれない。

• QSLカード(画像データ/印刷)について

1. 画像データとQSOデータは表示の際に合成することでデータ保持量を減らす。
2. QSLカード画像とデータの合成の負荷を小さくするために、画像エリアとデータエリアを区切って定型にしてはどうか。→負荷が小さく自由度の高い実装ができる方のアイデアをお願いします。
3. QSOデータからQSLカード印刷、発送機能は必要か。
4. 移動時などQSL画像データを複数持たせることができるか、実装をどうするか。
5. 登録者を会員に限定することで画像データ保持量削減と上限量の見積もりをしやすくする。
6. 画像データ内に電子透かしとしてデータを埋め込めないか。QSOデータを可読状態のデータだけでなく埋め込んだり、偽造防止に使えるかもしれない。
   ただし、QSL画像データダウンロード時にリアルタイム処理が必要となるとCPU処理が間に合うかを考える必要がある。
7. 画像データ内にデータを埋め込むのはEXIFデータとして埋め込む案も提案されました。こちらのほうが使いやすいかも知れないです。「ユーザーコメント」タグにADIFを埋め込む形になるでしょうか。

• 移動対応について

1. 国内移動情報はQSOデータ内の[MY_CNTY]フィールドに市郡区番号情報(JARL定義/ADIF指示)として保持する。→ ログアプリへの実装が必要
2. 日本語データを使う場合は[IntlString](UTF-8)を使用することのできるフィールド([MY_CITY_INTL]、[QSLMSG_INTL]、[MY_NAME_INTL]など)に限られ、データ交換にはxml形式のファイル[ADX]対応が必要である。
3. 国内運用の場合はポータブルエリア番号の有無は区別しないことを考え、アワードでは[MY_CNTY]内容を参照することで対応できないか。

• アワード発行について

1. アワード申請から課金、印刷(紙？、PDF?)連携が必要である。
2. アワード申請以外のインタフェースを会員のみへのサービスとするか非会員へも公開するか。
3. アワード申請の紙QSLカードとのハイブリッド対応の実現方法は？
   
4. このモデルはJARL発行アワードのみを考慮しているため、各種アワード発行者の方々はADIFの既存フィールドを使っての対応を考えてみてください。
5. JARL以外のアワード発行団体へ、アワード発行サービス提供を考えても良いかも知れない。

• 外部連携について

1. 今回はClub Logとの連携を想定しているが、これは、個人的感想としてClub LogがQSOデータ保持に一番柔軟性があるように感じていること、また、Club LogのQSOデータ量の増加が見込めることから、お互いの望む方向が一致しているように思われるためで、特に固執するつもりはない。(日本国内QSOデータが増えることでClub Log側のデメリットが増えるようであれば、この前提は覆る)
2. QSOデータを預ける外部システム側で、[MY_CNTY]フィールドに「市郡区番号情報」の扱いを依頼する必要がある。
3. QSOデータアップロードは会員に制限することで、コールサイン認証済みデータとして扱える。
4. LoTW、IOTA、SOTAなどのアワード申請を可能とすることは必要か、または可能か。
5. [MY_CNTY]フィールドの活用に向けて、過去のQSOデータにどうやって埋め込み、反映するかも大きな課題となると思われる。これについては、各種ソフト開発の方々のご協力をお願いすることになるでしょう。

• その他

1. 正確にはADIFに定義されていないフィールドもユーザー定義が可能であるが、各種ソフトでの対応を考えるとできれば使用は控えたい。ただし、禁止する必要はない。
   
2. できればJARL会員に限定せずに、LoTW同様、全世界のアマチュア無線局へ開放すべきであると考えるが、経済的な負担などを考慮して運営を考える必要がある。
3. ログソフト作成者に、ADIFに定義されている種々データへの対応を呼びかけ、例えばアンテナ情報、リグ情報などが集まればその活用が出来たりしないか。

参考

• ADIF ver3にて日本語など多言語文字(UTF-8)対応が定義されているが、データ交換にはxml形式(ADX形式)への対応が必要であり、現在多言語対応を実装しているソフトは存在していないと考えられる。
  https://adif.org/
• Cabrillo形式：世界標準のコンテストログ提出時のファイル形式
  https://wwrof.org/cabrillo/

修正履歴(細かな修正は記載しません)
2020/10/19：【基本コンセプト】【課題等メモ】をカテゴリー分け、記載追加/修正

2020/10/31：『第3回 YOTA Japan アマチュア懇話会』発表資料追加と、その際に議論された課題について追加