XCTrack と SeeYou 等のタスク QR コード互換用 Webアプリ
XCTrack の普及以来、パラグライダーのフライヤーにはおなじみとなった、QRコードでのタスク共有。
QRコードでのタスク共有は、XCTrack が実装し、仕様をこの公式ページ の通り公開したことで、一体型GPSバリオの一部のメーカーがそれに追従し、この仕様に沿ったQRコードでのタスク共有機能を実装するようになっています。
SeeYou Navigator や SeeYou.Cloud を提供する Naviter も、そのメーカーの一つです。2024年9月現在、どちらの製品にもQRコードでのタスク共有機能が実装されています。
Naviter の製品、またその他の 同機能をもつ製品も含め、これらのQRコードでのタスク共有は、XCTrack 同士だけでなく、SeeYou Navigator や XCTrack 間等、異なる機種間でも互換性があった方が、ユーザーにとって利便性が高くなります。また、XCTrack が公開した仕様に沿っている限り、基本的には互換性が担保されるはずです。
しかし現在、SeeYou Navigator と SeeYou.Cloud で作成したタスクのQRコードを XCTrack で読み込むと、XCTrack 側で「sss.timeGate is empty」もしくは「The time expexted in sss.timeGate[0]」というエラーを吐きタスクが読み込めないケースや、読み込めた場合でも、XCTrack 側でタスクに含まれるウェイポイントの ID（Name、名前）と Description（説明）が SeeYou Navigator と逆に登録される問題が発生しています。
タスク QR コード置換用 Webアプリ
上記の 2つの問題の回避のため、SeeYou Navigator ならびに SeeYou.Cloud のタスク QRコードのスクリーンショットをスマートフォンか PCで撮影し写真ファイルをアップロードすると、XCTrack で読み込こむことができ、ウェイポイントの ID と Description が逆に登録されない QRコードに置換して表示する Webアプリケーションを作成しました。
仕様概要：
Task definition format 2（タスクファイルに version 2 と記載）に対応
サポートするQRコードスクリーンショットのファイル形式は、JPG/PNG/他
動作確認：
SeeYou Navigator 3.1.6+2387 → XCTrack 0.9.11.11
SeeYou.Cloud (asof 09/26/2024) → XCTrack 0.9.11.11
※ SeeYou Navigator でタスクのスタート時間を設定していた場合でも、XCTrack 側にタスクのスタート時間（と終了時間）は引き継がれません。タスク読み込み後 XCTrack 側で設定をし直してください。
QR コードの互換性に関する補足：
現在、以下の XCTrack の QRコードを SeeYou Navigator で読み込むテスト環境では問題なく読み込みができており、逆に登録される問題も発生していません。このWebアプリは使用せず、そのまま読み込んでください。
XCTrack 0.9.11.11 → SeeYou Navigator 3.1.6+2387
ID と Description が逆になる問題の補足：
仮に本 Web アプリを利用せずに XCTrack でタスクを読み込めた場合、XCTrack 側でウェイポイントの ID と Description が逆に登録されても、XCTrack の動作自体には問題ありません。
XCTrack 側で逆に登録されることで発生する問題のケースは、以下の通りです。
コンペの会場でタスクボードにウェイポイントの ID しか記載されていない場合、XCTrack 側では ID がすぐに把握できないため、ユーザーがタスクボードのルート（ウェイポイントの順番）と XCTrack に登録されたルートを確認しづらくなり、混乱する。
同様に、タスクの変更があった場合、さらに混乱が生じる。
タスクを設定する際にウェイポイントの取捨選択や順番を調整しながら協議する場合、SeeYou Navigator 側の ID と XCTrack 側の ID が一致しないため、混乱する。
仲間内でタスクを設定してフライトを行う場合にも、同様の問題が発生する。
本アプリを利用し置換した QR コードを XCTrack で読み込むことで、この問題を回避することが可能です。
補足情報
本 Web アプリの動作確認は記載したバージョンの SeeYou の QR コードを XCTrack で読み込みの動作確認を行っていますが、異なるバージョンや他のアプリケーションやデバイスでも、Task definition format 2 準拠で、XCTrack で読み込んだ際に ID と Description が逆になる現象なのであれば、原則はそのまま使えます。
お使いの SeeYou ならびに XCTrack で動作しない場合、もしくは、SeeYou 以外のアプリケーションや Naviter 製品以外のデバイスで利用して上手く動作しない場合、もしくは、今回とは別の現象であっても、技術的に対応が可能で、作業をする余裕があれば、Web アプリを更新しての対応を検討するので、緩くお声がけください。
また、本件の問題に関する詳細について、Facebook アカウントをお持ちの方は、下記の投稿もあわせて参照ください。
投稿者の方は、XCTrack だけでなく、過去のGPSの仕様にも精通しており、この問題の背景についての推測も含めて詳しく解説されています。本Webアプリも、この方との協議とその際に説明を頂いた内容を基に作成したものとなります。
余談ですが
これは極めてニッチな問題です。
SeeYou Navigtor や SeeYou.Cloud を利用しているフライヤーが限られる上に、利用しているフライヤーの方もほとんどは「XCTrack で作成したタスクのQRコードを SeeYou Navigator で読み込む」という使い方しかしないでしょう。この場合、問題は発生しません。
SeeYou Navigator で作成したタスクのQRコードをXCTrackで読み込む場合に注意が必要です。
ゆる募
本件の Naviter への問題のエスカレーションを行うために、英語のサポートをしていただける方をゆる募します。
SeeYou の QR コードに SSS ゲートタイムが反映されない件については、以前、SeeYou Navigator でも SeeYou.Cloud でも発生しており、Naviter のサポート部門にエスカレーションをした経緯があります。
その際は、CEO の方が即応答してくれて、「XCTrack との互換性を重視している」ということで、しばらくしたら SeeYou Navigator の EA版（正式リリース前のアーリーアクセス版）で SSSゲートタイムが反映されるように、また、SeeYou.Cloud でも修正がありました。
ですが、今回確認では元に戻ってしまい、SSSゲートタイムは QR コードには反映されなくなりました。このために XCTrack ではエラーとなります。 「XCTrack との互換性を重視している」は何処にいってしまったのか…
SSS ゲートタイムが反映されないと、SeeYou 同士でのタスク共有でも不便なはずで、EA版のテストでなんらか問題があり、GA版（製品版）でこの機能を落としたのか、はたまた、XCTrack との互換性を重視しない方針に変わったのか謎仕様です。
また、ID と Description が逆になる件についても、以前、エスカレーションをした経緯があります。でも、こちらは全く返信がありませんでした。が、そもそも、私の英語力で発生する現象や Naviter にとっての本件のビジネスインパクトを伝えきれていないと感じていました。
いずれにしても、「XCTrack との互換性を重視している」とはなんなのか、こちらも元来から謎な仕様です。
どちらの問題も今後元に戻らないように対応を迫るには、謎仕様とビジネスインパクトについて、キッチリと説明できる英語力と根気のいるコミュニケーションが必要と感じるため、我こそはと言う方がいらっしゃれば、ゆるりとお声がけくださいませ。
最も問題が発生するケース
最後に愚痴です。
上には書きませんでしたが、最も問題が発生するケースは、SeeYou.Cloud でウェイポイントの管理をしてスタンダードタスクやトライアングル XC 等といった管理エリアの参考タスクを公開している人なのです。はい、私です。
XCTrack ユーザであるフライヤーさんから、「ID と Description 逆になる」「読み込めない」と指摘を頂くし、せっかく QR コードを公開しておいても、結局、当日に混乱して全て手作業でやり直しになるのです。
更にいうと、最近 Naviter Omni をご購入頂く会員様が徐々に増えてきており、Omni や 3年間の無料サブスクリプションがバンドルされる SeeYou.Cloud でタスク管理やタスク作成をするケースが増えることが想定でき、販売者の責務を考えると、本件、するっと見逃す訳にも参りません。
自らの製品同士でのタスク共有だけを意識し、お互いに他のデバイスとの互換性を保たない方針でユーザーにとっては帝国主義的悪魔になるなら別ですが（それならそれで宣言せい）、XCTack にも Naviter にもしっかりしていただきたい。
私は Facebook の投稿での投稿者様ほど過去の経緯をしりませんが、少なくとも GPS Dump の時代から、固有のウェイポイントを識別するための管理項目は ID と Name で、ID は一意で6文字まで、かつ最初の3文字に ID で残り3文字に Waypoint高度情報を定義するもの、Name については文字数制限が緩く、両者とも 2バイト文字は不可という仕様です。
GPS Dump の画面を見てみてもその一旦はわかります。
一方、XCTrack では、ID と Description の項目です。（下記 XCTrack のウエイポイント登録画面の写真では、日本語環境なので「詳細」となっていますが、英語環境では「Description」。）
スマホと Android の性能に乗じて ID の文字数制限をなくしたのはまだ良いとして、従来の「Name」の管理項目をなくして「詳細（Description）」としています。
この上で、XCTrack は公式ページの QR コードに出力する大元のタスクのデータ（JSONデータ）のフォーマットいついて、下記の通り説明をしています。
"n": string, required - name of the turnpoint
→ "n": 文字列、必須 - ターンポイントの名前"d": string, required - the turnpoint Description
→ "d": 文字列、必須 - ターンポンとの 詳細（Description）
この仕様に対し、XCTrack では、この「n = Name」に XCTrack 上のウェイポイントの管理項目の「ID」を、「d = Desctiption」に「Description（詳細）」を割り当てて出力する仕様となっています。
ややこしいので、もう一度書きます。
つまり、XCTrack 上でのウェイポイントの管理項目としては従来の 「Name」を排したものの、QR コードに出力する大元のタスクのJSONデータのフォーマットでは 「n = Name」を残し、そこに XCTrack 上の管理項目の「ID」を割り当てています。
なんで JSON データのフォーマットをこんなややこしい仕様にするのか…
JSCON の仕様でのパラメータが、従来の「ID」「Name」でもなく、現在の XCTrack の「ID」「Description」でもないってどういう趣旨なの？
もう一方の SeeYou.Cloud をみてみると、ウェイポイントに Name、Code、Description と3つの識別管理項目を有しています。
XCTrack の出力仕様を考えれば、このうち Code を "n" に、Name を "d"に割り当てて出力をすれば、XCTrack に読み込んだ際に登録が逆になることはないのですが、従来の形式と「"n": string, required - name of the turnpoint → "n": 文字列、必須 - ターンポイントの名前」という XCTrack の JSON データのフォーマットの説明だけに釣られて、Name を "n" に、Code を "d" に割り当てて出力してきます。だから、XCTrack で読み込んだ際に逆になります。
さらに、下記は、外部で作成したウェイポイントファイルを SeeYou Navigator と SeeYou.Cloud にインポートし、同じタスクを設定した内容になります。
SeeYou.Cloudでの TP の順番の表示は、タスクや XCのプラン上は確かに有用なのですが、元々のウェイポイントファイルにはもちろんなく、SeeYou Navigator でも XCTrack でも表示されないという点でも、見比べた時にこれが ID か Name と誤解しがちで、かつ、SeeYou Navigator でも XCTrackでも大きく表示される ID（SeeYou での Code）が変に小さく表示され、見ているユーザは更に混乱をします。
SeeYou.Cloud は、タスクを外部に公開できる機能があります。また、外部公開したタスクのページでは QRコードも表示でき、XCTrack のユーザも SeeYou Navigator のユーザも QR コードを読み込んでタスクを自分のデバイスに取り込むことができるのです。
でも、SeeYou のユーザですら SeeYou Nabigator と SeeYou.Cloud での項目表示の違いに戸惑う表示で、XCTrack のユーザが QR コードでタスクを取り込み、デバイス上で ID（Code） と詳細（Description）が SeeYou と逆になって、更にこんな表記をされていたら、なにがなんだか全くわかりません。
ウェイポイントの ID の命名規則について
本当に最後に、これだけは全世界のフライヤーと共有しておきたいこと。
ウェイポイントの識別項目に関する問題は過去からあり、例えば日本人にはおなじみの地図GPSソフトであるカシミール 3D ではウェイポイントファイルの識別管理項目が「ポイント名」と「GPSでの名前」となっており、このまま GPS Dump にインポートすると、「ポイント名」だけが（「GPSでの名前」だけだったか？）が ID として取り込まれて Name は空欄になる問題がありました。
このカシミールの問題を含め、Description 等を含めた 2バイト文字や長文が可能な項目は、他のデバイスやソフトウェアとの互換をするする際にはエラーの原因となりがちなので、省いて仕方ないといえば仕方ないし、この扱いで手間が増えたり互換性がやや損なわれるのも、ある意味で仕方ないです。
が、そもそも XCTrack は従来方式を踏襲しないのであれば、Name なんていう、本来 XCTrack 上では使っていない項目を JSON データのパラメータの名前として定めるべきではなく、"id" = ID と "d" = Description であるべきだと思うのです。それか、従来型の "id" = ID と "n" = Name で、XCTrack からの出力を "id" を ID、"ｎ" を Description とすべき。
更に、上に挙げた Facebook の投稿での投稿者様の指摘通り、「元々の ID の命名規則、6文字で最初の3文字にID残り3文字に Waypoint高度情報を XCTrack が無視した仕様としたことが問題の発端」という推測に激しく同意します。
互換性と実際の運用の利便性を考慮し、デバイスやアプリケーションの性能に関わらず、ウェイポイントの ID の命名規則は、ベンダーを問わず「6文字で最初の3文字にID残り3文字に Waypoint高度情報を定義」で統一すべきと考えます。ID については、2バイト文字を許すべきではない。
機会があれあば、この件については改めて主張をしていきたいような気がしなくもなくもありません。
この記事が気に入ったらサポートをしてみませんか？