マルチマップ利用ガイドとベストプラクティス
Mega アプリケーション開発において、1つの位置特定ライブラリに複数のマップ(Block)を追加すべきかどうかは、よくある問題です。誤ったマルチマップの使用は、アプリケーションの能力を向上させるどころか、パフォーマンス低下や位置特定のジャンプを引き起こす可能性があります。
本ガイドでは、マルチマップ機能を正しく理解し使用する方法、および一般的な落とし穴を回避する方法を説明します。
複数のマップ追加を避ける理由
基本原則:「カバレッジ拡大」を目的とした複数マップの追加は避ける。
ほとんどの場合、1つの位置特定ライブラリには単一の場所に対応する Mega Block マップを1つだけ追加するべきです。以下は、絶対に避けるべき一般的な誤った使用方法です:
誤ったシナリオ A:複数エリア
- 考え方:1つの観光地内で接続された「Aエリア」「Bエリア」「Cエリア」それぞれにマップを作成し、アプリでこれら3つのマップをライブラリに一括追加。ユーザーが移動中にシームレスに切り替わることを期待。
- 問題点:こうして作成された3つのマップは、空間座標上で数学的に関連付けられておらず、互いに独立しています。座標系の不一致により、移動中のシームレスな切り替えは不可能で、エリア境界で位置特定のジャンプが発生します。
- 解決策:このようなシナリオでは、超大空間データ収集方法 で説明されている方法で「Aエリア」「Bエリア」「Cエリア」を収集し、十分な重複領域を確保します。超大範囲融合タスク で説明されている方法でマッピングします。これにより、上記すべてのエリアを含む統一座標系の単一の Block マップが生成され、このマップを位置特定ライブラリに追加できます。
誤ったシナリオ B:複数場所
- 考え方:ある場所のショッピングモール用にマップを作成し、別の場所の同名ショッピングモール用にもマップを作成し、1つのアプリで同時に使用したい。
- 問題点:位置特定速度が大幅に低下します。デバイスが位置特定を行う際、ライブラリ内のすべてのマップデータを同時に比較する必要があり、計算量が急増し、初期化時間が長くなります。ユーザーは同時に1つのモールにしかいられないため、別のモールのマップをロードすることはリソースの無駄です。特定のモールへのリクエストが集中すると、別のモールのリクエスト応答時間も遅延します。
- 解決策:異なる場所のショッピングモールごとに別々の位置特定ライブラリを作成し、各ライブラリには1つのマップのみを追加します。アプリケーションでユーザーの現在地に基づいて、対応する場所の位置特定ライブラリを動的にアクセスします。
誤ったシナリオ C:時間をまたぐケース
- 考え方:同じ場所で、昼間に収集・マッピングを行い、夜間にも収集・マッピングを行い、昼と夜のマップをライブラリに追加。ユーザーが同じ場所の異なる時間帯でも一貫した体験を得られることを期待。
- 問題点:このシナリオは誤ったシナリオ A と同様で、個別に作成されたマップ結果間の空間的位置関係は保証されません。
- 解決策:超大範囲融合タスク で説明されている方法で、昼と夜の収集データをまとめて融合マッピングします。生成された最終的な単一の Block マップを位置特定ライブラリに追加します。
誤ったシナリオ D:バージョンをまたぐケース
- 考え方:同じ場所で、すでにバージョンAのマップを作成・使用中。運用過程で更新されたバージョンBのマップを新たに作成し、元の位置特定ライブラリに追加。アプリを再リリースせずに新しいマップを使用できることを期待。
- 問題点:同じ場所の異なるバージョンのマップであるため、位置特定時に2つの異なるバージョンデータ間で位置特定結果がジャンプする現象が発生します。
- 解決策:ロスレスフルアップデート で説明されている方法で、旧バージョンのマッピングをアップグレードし、マップデータのバージョン更新と座標系維持を両立させます。更新後のマップを追加した後は、必ず位置特定ライブラリから元のバージョンのマップを削除します。
誤ったシナリオ E:部分更新
- 考え方:同じ場所で、すでにバージョンAのマップを作成・使用中。運用過程で一部エリアの変更や小範囲の補足収集が必要になり、新たにマップBを作成して元の位置特定ライブラリに追加。アプリを再リリースせずに新しいマップを使用できることを期待。
- 問題点:新たに収集した小範囲のマップBと元のマップAの間には空間座標の関連性がなく、新旧データ間の境界で位置特定のジャンプが発生します。
- 解決策:部分更新 で説明されている方法で、旧バージョンのマッピングに対して部分更新を行い、新たに収集した小範囲と旧マップの座標系を維持します。更新後のマップを追加した後は、必ず位置特定ライブラリから元のバージョンのマップを削除します。
まとめ:複数の小さいマップを繋ぎ合わせて大きな世界を作ろうとする試みは、Mega の高精度マップには適用できません。Mega の設計哲学は、空間的に連続し、座標が統一され、時間的にも一貫した高精度3D表現です。
本当にマルチマップが必要なシナリオ
では、いつライブラリに複数のマップ(Block)を追加する必要が本当にあるのでしょうか? 主なシナリオは、「空間の結合」 ではなく、「並列タスク」 または 「複数空間の選択」 です。
シナリオ1:複数空間の選択
- 説明:アプリケーションが同じ場所内の完全に異なる複数のエリアにサービスを提供する場合。しかし、建築構造や収集実践上の問題により、これらのエリアをデータ上で完全に接続できないため、ユーザーがまず自分がいるエリアを選択する必要がある場合。例:大規模病院の異なるフロア。
- 実装:ユーザーがエリアを選択した後、この事前情報を利用してその場所に対応する単一のマップを動的にアクティブ化します。同時刻には、位置特定ライブラリ内で計算に参加しているマップは依然として1つだけです。ユーザーが新しいエリアに移動する際は、エリア選択を再確認する必要があります。
シナリオ2:並列タスク
- 説明:アプリケーションが、同一場所内にあり互いに関連がなく、特徴が大きく異なる、2つ以上の独立した既知の物体追跡タスクを同時に処理する必要がある場合。例:博物館内の複数の展示品。
- 実装:このような高度なシナリオでは、各物体ごとに独立したマップを作成し、これらの「物体マップ」を1つの位置特定ライブラリに追加することができます。ただし、位置特定パフォーマンスはライブラリに追加された物体の数に依存することに注意が必要です。物体数が非常に多い場合は、位置特定パフォーマンスとライブラリ数の間でトレードオフが必要になる可能性があり、物体を分類して複数の位置特定ライブラリを作成し、それぞれに追加することが考えられます。
マルチマップ使用時のレンダリング側の挙動
マルチマップによる位置特定を使用する場合、プラットフォームやバージョンによって3Dレンダリングの挙動が異なることに注意が必要です。
ベストプラクティスの推奨事項
もし 本当にマルチマップが必要なシナリオ で説明されたシナリオに該当する場合、またはマルチマップを使用せざるを得ない場合は、以下の原則に従ってください:
- 必要に応じたアクティブ化:ユーザーが選択を行ったり特定のエリアに入ったりした際に、位置特定リクエスト送信時に該当する事前情報を提供し、対応する3Dコンテンツのみをロードします。
- 動的切り替え:ユーザーがシーンを選択できる明確なUIを提供します。新しいマップに対応する3Dコンテンツをロードする前に、古いマップに対応する3Dコンテンツをアンロードしてメモリを解放します。
- 状態管理:コード内で現在アクティブなマップを明確に管理し、位置特定結果の Block ID を監視して、異なるマップからの位置特定フィードバックを区別します。
- パフォーマンス監視:マルチマップを使用する際は、デバイスのメモリ使用量、位置特定遅延、電力消費を注意深く監視し、アプリケーションが対象デバイスでスムーズに動作することを確認します。
要約すると、ほとんどのアプリケーションにおいて、「1つのシーン、1つのマップ」という原則を堅持することが、Mega の位置特定パフォーマンスと安定性を保証する最良の選択です。