はじめに
かなり長い間、QtLocation の今後の方向性について検討を重ねてきました。主な使用例は何でしょうか？将来的に最も適した技術やアーキテクチャは何でしょうか？そして、サーバー、データソース、レンダラー、アプリケーションなど、より広範なシステムの中で、プロジェクトおよび企業としての当社の役割はどのようなものになるのでしょうか？
まだ一つの決定的な答えには至っていませんが、それがプロセスの一部です。これらの質問は複雑で興味深く、多くの可能性を秘めており、その一部に参加できることは非常に刺激的です。また、位置情報機能はQtのような汎用UIフレームワークの核心ではないかもしれませんが、現代のアプリケーションでQtが提供できる機能を拡張する真の機会を提供しています。
学生プロジェクト
QtLocation の未来像を初めて垣間見ることができました。これは、NTNU の 3 人の優秀な学生による学士論文です。学生たちは、多くの地図プロバイダーが採用している Mapbox Vector Tile 仕様を実装しました。この仕様は、MapTiler、HERE、ESRI など、さまざまな形で採用されています。学生たちは、ネットワークプロトコル、データとスタイルシートのデコーダー、および当社の QPainter API に基づくソフトウェアレンダラーを実装しました。学生たちにとって素晴らしいプロジェクトであるだけでなく、ベクター地図レンダリングの経験を得るとともに、当社のスタックを検証する絶好の機会となりました。
学生たち以降
地図の大ファンとして、このプロジェクトを放置しておくわけにはいきませんでした。最後の更新からほぼ1年が経過し、次のステップに進む前に、最新情報とフィードバックを共有する時期が来たと考えています。過去1年間は、プロトコル処理コードのリファクタリングと、QtQuick、SceneGraph、ハードウェアレンダリングへの移植に注力してきました。現在のプロジェクトの現状は、OpenStreetMapスタイルでオスロのフィヨルド地域をレンダリングしたものです。
curve rendererを使用して、建物、湖、森林、境界線、道路をポリゴンとポリラインとしてSceneGraphに読み込んでいます。曲線レンダラーは問題なく動作しており、そのアーキテクチャはベクターマップパイプラインにうまく適合しています。すべての高負荷処理は、新しいタイルが曲線レンダラーで受信され処理される際に実行されます。このステップで、すべてのレイアウトプロパティ（例：テキスト位置、塗りつぶしパターン、オーバーラップ許可）を設定し、曲線レンダラーから返されるハンドラーを通じて、各フレームごとにペイントプロパティ（例：色、線幅）が更新されます。正直なところ、このAPIは最初は難しそうに思えましたが、実際に使ってみると非常に快適でした。カスタムのハードウェアアクセラレーション対応2Dグラフィックスが必要な場合は、ぜひ試してみてください！
ただし、曲線レンダラーは地図を構成するシンプルな多角形や多角線にはやや過剰な機能です。これはベジエ曲線向けに設計されており、そのコストはメモリ使用量と処理時間に現れます。同時に、中央に隙間のある線やぼかしなどのマップ固有の機能が欠けています。このようなドメイン固有のロジックを曲線レンダラーに負担をかけたくないですが、どちらの問題もマップ固有のバージョンで解決可能です。
曲線レンダラーは、アイコン用のテクスチャノードとラベル用のテキストノードで補完されています。Mapbox仕様では、QtQuickのテキストレンダリングAPIがサポートするよりも多くのテキストカスタマイズが可能です。例えば、特定の幅のテキストアウトラインやオプションのぼかしといった機能が欠けています。しかし、これらの機能は将来的にQtフレームワークに追加される可能性があると想像できます。もう一つの欠落している機能は、ポリラインに沿ったテキストです（道路や川の名前のイメージです）。現在は、テキストを線に接する方向に描画しています。それでも、これはQtの一部として追加される可能性があると考えることができます。例えばQSGCurvedTextNodeとしてでしょうか？
当然ながら、複数のレイヤー（地図の右側に一覧表示されています）をサポートしており、異なる解像度やズームレベルを持つ複数のソースを使用できます。これにはラスターレイヤーも含まれ、衛星画像のベースレイヤーなど、ベクター地図でも有用です。これらすべてを約4,500行のコードで実装しました。これは、Qtでハードウェアアクセラレーション対応のピクセルを画面に表示する容易さを示す好例です。
現在は、最も重要なレイアウトと描画プロパティに焦点を当てており、より詳細な機能、3Dレイヤー、レイヤータイプなどは一時的に省略しています。したがって、これはまだ進行中のプロジェクトであり、明らかに概念実証段階です。しかし、少なくとも私の（偏った）意見では、このプロジェクトは主張を十分に証明しています。このプロジェクトに絶対的な愛着を感じています。
ビジョン
Qtが最近、高品質なベクターグラフィックスへの取り組みを強化している点（SVGモジュール、カーブレレンダー、VectorImageアイテムのアップデートなど）を考慮すると、適切なQVectorMapアイテムは完璧なフィットだと考えています。
Mapboxの仕様は、私の意見では、初期の遺物の一部を除けば、まさに芸術品であり、支援に値するものです。そのアーキテクチャは、現在のQtLocation MapのプラグインやPlaces API、後付けのMapアイテムに比べて大幅にシンプルになります。適切な統合を実現すれば、Qtエコシステム内の第一級市民として、あらゆるプラットフォーム上のQtアプリでマップを活用できるようになります。これほど素晴らしいことはありますか？
アクティブなレイヤーのリストを作成することは簡単で（スクリーンショット参照）、Qtスタイルやイベント、甚至いはQt Design Studioとのより緊密な統合も容易に想像できます。マップにQuickItemsを追加することも、現在よりもはるかに簡単で効率的になるでしょう。Qt Quick 3Dをベースにした3Dマップ？完全に可能です — そしてQtへの素晴らしい追加機能となるでしょう。道路や建物へのタップをキャッチするためのQt入力ハンドラーを追加することも問題ありません。
もちろん、代替手段もあります。MapLibre Nativeは、Mapbox仕様のほぼ完全な実装を、スタンドアロンライブラリまたはQtLocationのプラグインとして、すぐに使用始めることができます。しかし、完全にネイティブなQt実装と同じ満足感は得られません。
これまで、これは主に趣味のプロジェクトとして進めてきました — 過去1年間、インターンと共に空き時間に推進してきました。しかし、次のステップにはより専門的な体制が必要となり、顧客やユーザーからの関心とフィードバックも不可欠です。
この機能をQtに実装してほしいと思いますか？優先度はどのくらいでしょうか？進める前に知っておくべきことはありますか？コメントでご意見をお聞かせください。もしかしたら、このビジョンを実現できるかもしれません。
