Table of Contents

Guide d'utilisation multi-map et meilleures pratiques

Dans le développement d'applications Mega, la question d'ajouter ou non plusieurs maps (Block) à une seule localization library est fréquente. Une mauvaise utilisation de multi-map n'améliore pas les capacités de l'application et peut au contraire entraîner une baisse de performance et des positioning jumps.

Ce guide vous aide à comprendre et utiliser correctement la fonction multi-map, en évitant les pièges courants.

Pourquoi éviter d'ajouter plusieurs maps ?

Principe central : n'ajoutez pas plusieurs maps pour "étendre la couverture".

Dans la grande majorité des cas, une localization library ne devrait contenir qu'une seule Mega Block map pour un seul lieu. Voici quelques usages incorrects courants à éviter absolument :

  • Scénario incorrect A : multi-region

    • Idée : créer séparément des maps pour les "zone A", "zone B" et "zone C" reliées entre elles dans un site touristique, puis ajouter ces trois maps en une seule fois à la library de l'application, en espérant que les utilisateurs puissent basculer sans interruption lorsqu'ils se déplacent.
    • Problème : les trois maps créées ainsi n'ont aucune relation mathématique en coordonnées spatiales et sont indépendantes les unes des autres. En raison de l'incohérence de leurs coordinate systems, le seamless switching pendant le déplacement est impossible, ce qui provoque des positioning jumps aux limites des zones.
    • Solution : pour ce type de scénario, la meilleure méthode consiste à collecter les "zone A", "zone B" et "zone C" selon la méthode de collecte de données pour très grands espaces, en garantissant un overlap suffisant entre elles. Effectuez ensuite la map construction selon la large-scale fusion task. Cela génère une single Block map avec un coordinate system unifié couvrant toutes ces zones, et cette map peut être ajoutée à la localization library.

  • Scénario incorrect B : multi-location

    • Idée : créer une map pour un centre commercial à un endroit, puis une autre map pour un centre commercial du même nom à un autre endroit, dans l'espoir de les utiliser en même temps dans une application.
    • Problème : cela ralentit fortement le positioning. Lors du positioning, l'appareil doit comparer simultanément toutes les données de maps dans la library, ce qui augmente fortement le calcul et allonge le temps d'initialization. Un utilisateur ne peut se trouver que dans un seul centre commercial à la fois, charger la map d'un autre centre commercial est donc un gaspillage de ressources. Lorsqu'un centre commercial reçoit beaucoup de requests, cela ralentit aussi le temps de réponse de l'autre.
    • Solution : créez différentes localization libraries pour les centres commerciaux de lieux différents, chaque library ne contenant qu'une seule map. Dans l'application, accédez dynamiquement à la localization library correspondante selon la position actuelle de l'utilisateur.

  • Scénario incorrect C : cross-time

    • Idée : pour un même lieu, effectuer une collecte et une map construction de jour, puis de nuit, et ajouter les maps de jour et de nuit à la library, en espérant offrir une expérience cohérente aux utilisateurs à différents moments.
    • Problème : ce scénario est similaire au scénario incorrect A ; la relation de position spatiale entre des résultats de map construction séparés ne peut pas être garantie.
    • Solution : fusionnez les collectes de jour et de nuit pour une fusion map construction selon la large-scale fusion task. Ajoutez la single Block map finale générée à la localization library.

  • Scénario incorrect D : cross-version

    • Idée : pour un même lieu, une map version A a déjà été créée et est utilisée ; pendant l'exploitation ultérieure, une map version B plus récente est créée et ajoutée à la localization library d'origine, afin d'utiliser la nouvelle map sans republier l'application.
    • Problème : comme il s'agit de maps de versions différentes du même lieu, les résultats de positioning peuvent sauter entre deux versions de données différentes.
    • Solution : mettez à niveau l'ancienne map construction avec lossless full update, afin de mettre à jour la version des données de map tout en conservant le coordinate system inchangé. Après avoir ajouté la map mise à jour, supprimez impérativement l'ancienne version de la map de la localization library.

  • Scénario incorrect E : supplementary update

    • Idée : pour un même lieu, une map version A a déjà été créée et est utilisée ; pendant l'exploitation ultérieure, une zone locale change ou une petite zone doit être collectée en complément. Une nouvelle map B est alors créée et ajoutée à la localization library d'origine, afin d'utiliser la nouvelle map sans republier l'application.
    • Problème : la nouvelle map B de petite zone collectée n'a pas de corrélation de coordonnées spatiales avec la map A d'origine ; l'expérience entre les anciennes et nouvelles données subira des positioning jumps.
    • Solution : effectuez une supplementary update sur l'ancienne map construction, afin que la nouvelle petite zone collectée conserve le même coordinate system que l'ancienne map. Après avoir ajouté la map mise à jour, supprimez impérativement l'ancienne version de la map de la localization library.

Résumé : tenter d'assembler plusieurs petites maps en un grand monde ne convient pas aux maps haute précision de Mega. La philosophie de conception de Mega est une représentation 3D haute précision spatialement continue, unifiée en coordonnées et cohérente dans l'espace-temps.

Scénarios qui nécessitent vraiment multi-map

Alors, quand faut-il vraiment ajouter plusieurs maps (Block) dans une library ? Les principaux scénarios sont "parallel tasks" ou "multi-space selection", et non "spatial stitching".

  • Scénario 1 : multi-space selection

    • Description : votre application dessert plusieurs zones complètement différentes dans un même lieu. Mais en raison de la structure du bâtiment ou de problèmes dans les pratiques de collecte, ces zones ne peuvent pas être entièrement reliées dans les données, et l'utilisateur peut devoir d'abord choisir la zone où il se trouve. Par exemple, différents étages d'un grand hôpital.
    • Implémentation : après le choix de zone par l'utilisateur, utilisez cette prior information pour activer dynamiquement la single map correspondant à ce lieu. À un même moment, une seule map de la localization library participe encore au calcul. Lorsque l'utilisateur passe dans une nouvelle zone, il faut confirmer à nouveau le choix de la zone.

  • Scénario 2 : parallel tasks

    • Description : votre application doit traiter simultanément deux ou plusieurs tâches object tracking indépendantes et connues, et ces objets se trouvent au même endroit mais ne sont pas liés entre eux, avec des features très différentes. Par exemple, plusieurs objets exposés dans un musée.
    • Implémentation : dans ce scénario avancé, vous pouvez créer une map indépendante pour chaque objet, puis ajouter ces "object maps" à une localization library. Notez toutefois que la performance de positioning dépendra du nombre d'objets ajoutés à la localization library. Si le nombre d'objets est très important, vous devrez peut-être équilibrer performance de positioning et nombre de localization libraries, par exemple en classant les objets et en créant plusieurs localization libraries séparées.

Comportement rendering lors de l'utilisation de multi-map

Notez que lors de l'utilisation de multi-map positioning, le comportement de 3D rendering varie selon les plateformes et les versions.

Recommandations de meilleures pratiques

Si votre cas appartient réellement aux scénarios qui nécessitent vraiment multi-map, ou si vous devez utiliser multi-map, suivez les principes suivants :

  1. Activer à la demande : lorsque l'utilisateur fait un choix ou entre dans une zone spécifique, fournissez la prior information correspondante lors de l'envoi de la positioning request et ne chargez que le contenu 3D correspondant.
  2. Bascule dynamique : fournissez une UI claire pour que l'utilisateur choisisse la scene. Avant de charger le contenu 3D correspondant à la nouvelle map, déchargez d'abord le contenu 3D correspondant à l'ancienne map pour libérer de la memory.
  3. State management : gérez explicitement la map actuellement active dans le code et écoutez le Block ID dans les résultats de positioning afin de distinguer le feedback positioning des différentes maps.
  4. Performance monitoring : lors de l'utilisation de multi-map, surveillez de près la memory usage de l'appareil, la positioning latency et la consommation d'énergie, afin que l'application fonctionne fluidement sur le target device.

En résumé, pour la grande majorité des applications, respecter le principe "une scene, une map" est le meilleur choix pour garantir la performance et la stabilité de Mega positioning.