Guide d'utilisation et meilleures pratiques pour les cartes multiples

Dans le développement d'applications Mega, la question de savoir s'il faut ajouter plusieurs cartes (Block) dans une bibliothèque de localisation est fréquente. Une utilisation incorrecte des cartes multiples n'améliorera pas les capacités de l'application, mais pourrait au contraire entraîner des baisses de performances et des sauts de localisation.

Ce guide vous aidera à comprendre et à utiliser correctement la fonctionnalité de cartes multiples, en évitant les pièges courants.

Pourquoi faut-il éviter d'ajouter plusieurs cartes ?

Principe fondamental : ne pas ajouter plusieurs cartes pour "étendre la couverture".

Dans la grande majorité des cas, une bibliothèque de localisation ne doit contenir qu'une seule carte Mega Block pour un lieu donné. Voici quelques utilisations erronées courantes à éviter absolument :

• Scénario erroné A : zones multiples

  • Intention : créer des cartes distinctes pour les zones "A", "B" et "C" d'un site touristique interconnecté, puis les ajouter toutes à la bibliothèque dans l'application, espérant une transition transparente lorsque l'utilisateur se déplace.
  • Problème : ces trois cartes n'ont aucune relation mathématique dans l'espace et sont indépendantes. En raison des systèmes de coordonnées incohérents, une transition fluide est impossible, entraînant des sauts de localisation aux frontières des zones.
  • Solution : pour ce type de scénario, collectez les zones "A", "B" et "C" comme décrit dans la méthode de collecte de données spatiales de grande taille, en veillant à des zones de chevauchement suffisantes. Effectuez la cartographie comme indiqué dans la tâche de fusion de grande étendue. Cela générera une carte Block unique dans un système de coordonnées unifié couvrant toutes les zones, que vous pourrez ajouter à la bibliothèque de localisation.

• Scénario erroné B : lieux multiples

  • Intention : créer une carte pour un centre commercial à un emplacement, puis une autre pour un centre commercial homonyme à un autre emplacement, pour les utiliser simultanément dans une même application.
  • Problème : cela ralentit considérablement la localisation. L'appareil doit comparer toutes les données cartographiques de la bibliothèque simultanément, augmentant exponentiellement la charge de calcul et prolongeant l'initialisation. L'utilisateur ne pouvant être qu'à un centre commercial à la fois, charger l'autre carte est un gaspillage de ressources. Une forte demande sur un centre commercial ralentit également les réponses pour l'autre.
  • Solution : créez des bibliothèques de localisation distinctes pour chaque centre commercial, chacune contenant une seule carte. Dans l'application, accédez dynamiquement à la bibliothèque correspondant à la position actuelle de l'utilisateur.

• Scénario erroné C : variation temporelle

  • Intention : collecter et modéliser un même lieu de jour, puis de nuit, ajouter les deux cartes à la bibliothèque, pour offrir une expérience cohérente à l'utilisateur à différents moments.
  • Problème : similaire au scénario A, les résultats de cartographie séparés ne garantissent pas une relation spatiale cohérente.
  • Solution : fusionnez les collectes de jour et de nuit selon la tâche de fusion de grande étendue. Ajoutez la carte Block unique résultante à la bibliothèque de localisation.

• Scénario erroné D : versions multiples

  • Intention : après avoir créé et utilisé une version A de la carte d'un lieu, ajouter une nouvelle version B mise à jour à la même bibliothèque, pour utiliser la nouvelle carte sans republier l'application.
  • Problème : la localisation sautera entre les données des deux versions différentes du même lieu.
  • Solution : mettez à jour l'ancienne carte selon la méthode de mise à jour complète sans perte, en maintenant le système de coordonnées. Après ajout de la carte mise à jour, supprimez impérativement l'ancienne version de la bibliothèque de localisation.

• Scénario erroné E : mise à jour partielle

  • Intention : après avoir créé et utilisé une version A de la carte d'un lieu, créer une nouvelle carte B pour une petite zone mise à jour ou complétée, et l'ajouter à la bibliothèque existante, pour utilisation sans republier l'application.
  • Problème : la nouvelle carte B n'a pas de relation spatiale avec la carte A d'origine, entraînant des sauts de localisation entre les données anciennes et nouvelles.
  • Solution : mettez à jour l'ancienne carte selon la méthode de mise à jour complémentaire, en maintenant la cohérence du système de coordonnées. Après ajout de la carte mise à jour, supprimez impérativement l'ancienne version de la bibliothèque de localisation.

Conclusion : tenter d'assembler un grand monde à partir de petites cartes multiples ne convient pas à la cartographie haute précision de Mega. La philosophie de Mega repose sur une représentation 3D haute précision spatialement continue, à système de coordonnées unifié et cohérente dans le temps et l'espace.

Scénarios justifiant réellement plusieurs cartes

Quand est-il réellement nécessaire d'ajouter plusieurs cartes (Blocks) dans une bibliothèque ? Principalement pour des tâches "parallèles" ou des choix "multi-espaces", et non pour un "assemblage spatial".

• Scénario 1 : choix multi-espaces

  • Description : votre application dessert plusieurs zones totalement distinctes d'un même lieu. Mais, en raison de la structure du bâtiment ou de contraintes pratiques de collecte, ces zones ne peuvent être interconnectées dans les données, et l'utilisateur doit d'abord sélectionner sa zone (ex : différents étages d'un grand hôpital).
  • Implémentation : après sélection de la zone par l'utilisateur, utilisez cette information a priori pour activer dynamiquement la carte unique correspondante. À tout moment, une seule carte de la bibliothèque participe aux calculs. Lorsque l'utilisateur change de zone, une nouvelle sélection de zone est nécessaire.

• Scénario 2 : tâches parallèles

  • Description : votre application doit suivre simultanément deux objets ou plus, indépendants et connus, situés au même endroit mais sans lien entre eux et avec des caractéristiques très différentes (ex : plusieurs objets exposés dans un musée).
  • Implémentation : dans ce scénario avancé, créez une carte distincte pour chaque objet et ajoutez ces "cartes d'objets" à une bibliothèque de localisation. Notez que les performances dépendront du nombre d'objets ajoutés. Pour un nombre élevé, équilibrez entre performances et nombre de bibliothèques en regroupant les objets par catégorie dans des bibliothèques distinctes.

Comportement du rendu lors de l'utilisation de cartes multiples

Notez que le rendu 3D lors d'une localisation multi-cartes varie selon la plateforme et la version.

• Unity
• WeChat Applet
• Natif

Recommandations de meilleures pratiques

Si votre situation correspond vraiment aux scénarios décrits dans Scénarios justifiant réellement plusieurs cartes, ou si vous devez absolument utiliser plusieurs cartes, suivez ces principes :

1. Activation à la demande : lorsque l'utilisateur fait un choix ou entre dans une zone spécifique, fournissez l'information a priori pertinente dans la requête de localisation et chargez uniquement le contenu 3D correspondant.
2. Changement dynamique : proposez une interface utilisateur claire pour choisir la scène. Avant de charger le contenu 3D d'une nouvelle carte, déchargez celui de l'ancienne carte pour libérer de la mémoire.
3. Gestion d'état : gérez explicitement la carte actuellement active dans le code. Surveillez l'ID de Block dans les résultats de localisation pour différencier les retours des différentes cartes.
4. Surveillance des performances : lors de l'utilisation de cartes multiples, surveillez attentivement l'utilisation mémoire, la latence de localisation et la consommation d'énergie de l'appareil pour garantir une exécution fluide de l'application sur l'appareil cible.

En résumé, pour la grande majorité des applications, s'en tenir au principe "une scène, une carte" reste le meilleur choix pour garantir les performances et la stabilité de la localisation Mega.