Table of Contents

Guía de uso de multi-map y mejores prácticas

En el desarrollo de aplicaciones Mega, si se deben agregar varios maps (Block) a una sola localization library es una pregunta frecuente. Usar multi-map de forma incorrecta no solo no mejora las capacidades de la aplicación, sino que también puede provocar degradación de rendimiento y saltos de positioning.

Esta guía le ayudará a comprender y usar correctamente la función multi-map y evitar malentendidos comunes.

¿Por qué se debe evitar agregar varios maps?

Principio central: no agregue varios maps para "ampliar la cobertura".

En la gran mayoría de los casos, una localization library debe agregar solo un Mega Block map de un único lugar. A continuación se muestran algunos usos incorrectos comunes que deben evitarse:

  • Escenario incorrecto A: multi-region

    • Idea: crear maps separados para "Área A", "Área B" y "Área C" conectadas entre sí en una zona turística, y luego agregar los tres maps de una vez a la library de la aplicación, esperando que el usuario pueda cambiar sin interrupciones mientras se desplaza por la zona.
    • Problema: los tres maps creados así no tienen relación matemática en coordenadas espaciales y son independientes entre sí. Debido a la inconsistencia entre sus sistemas de coordenadas, no se puede lograr seamless switching durante el movimiento, por lo que se producirán positioning jumps en las fronteras de las áreas.
    • Solución: para este tipo de escenarios, lo mejor es recopilar "Área A", "Área B" y "Área C" según el método de recopilación de datos de espacios muy grandes, asegurando suficiente overlap entre ellas. Realice map construction según la tarea de fusion de gran rango. Así se generará un single Block map con un sistema de coordenadas unificado que incluye todas esas áreas, y este map se puede agregar a la localization library.
  • Escenario incorrecto B: multi-location

    • Idea: crear un map para un centro comercial en un lugar y otro map para un centro comercial del mismo nombre en otro lugar, esperando usarlos simultáneamente en una aplicación.
    • Problema: esto ralentiza gravemente el positioning. Durante positioning, el dispositivo debe comparar simultáneamente todos los datos de maps en la library, aumentando mucho el cálculo y alargando el tiempo de initialization. El usuario solo puede estar en un centro comercial a la vez, por lo que cargar el map de otro centro comercial desperdicia recursos. Cuando un centro comercial tiene muchas solicitudes, también ralentiza el tiempo de respuesta de las solicitudes del otro.
    • Solución: cree localization libraries diferentes para centros comerciales en ubicaciones distintas, y agregue solo un map a cada library. En la aplicación, acceda dinámicamente a la localization library correspondiente según la ubicación actual del usuario.
  • Escenario incorrecto C: cross-time

    • Idea: para el mismo lugar, recopilar y construir map de día y también de noche, y luego agregar los maps de día y noche a la library, esperando que los usuarios tengan una experiencia consistente en distintos momentos en el mismo lugar.
    • Problema: este escenario es similar al escenario incorrecto A; no se puede garantizar la relación de posición espacial entre resultados de map construction separados.
    • Solución: combine las recopilaciones de día y noche para fusion map construction según la tarea de fusion de gran rango. Agregue el single Block map final generado a la localization library.
  • Escenario incorrecto D: cross-version

    • Idea: para el mismo lugar, ya se ha construido y usado un map versión A. Durante la operación posterior se crea un map versión B más nuevo y se agrega a la localization library original, esperando usar el nuevo map sin volver a publicar la aplicación.
    • Problema: como son maps de versiones diferentes del mismo lugar, durante positioning pueden aparecer resultados que saltan entre dos versiones de datos distintas.
    • Solución: actualice la map construction antigua mediante lossless full update, garantizando que la versión de datos del map se actualice mientras el sistema de coordenadas permanece sin cambios. Después de agregar el map actualizado, elimine obligatoriamente el map de la versión anterior de la localization library.
  • Escenario incorrecto E: supplementary update

    • Idea: para el mismo lugar, ya se ha construido y usado un map versión A. En operaciones posteriores, debido a cambios en un área local o a la necesidad de recopilar una zona pequeña adicional, se crea un nuevo map B y se agrega a la localization library original, esperando usar el nuevo map sin volver a publicar la aplicación.
    • Problema: el nuevo map B de la zona pequeña no tiene correlación de coordenadas espaciales con el map original A; la experiencia entre los datos antiguos y nuevos sufrirá positioning jumps.
    • Solución: realice un supplementary update sobre la map construction antigua, garantizando que la nueva zona pequeña recopilada mantenga el mismo sistema de coordenadas que el map antiguo. Después de agregar el map actualizado, elimine obligatoriamente el map de la versión anterior de la localization library.

Resumen: intentar unir varios maps pequeños para formar un mundo grande no es adecuado para los maps de alta precisión de Mega. La filosofía de diseño de Mega es una representación 3D de alta precisión, continua en el espacio, unificada en coordenadas y consistente en espacio-tiempo.

Escenarios que realmente requieren multi-map

Entonces, ¿cuándo se necesita realmente agregar varios maps (Block) en una library? Los escenarios principales son "parallel tasks" o "multi-space selection", no "spatial stitching".

  • Escenario 1: multi-space selection

    • Descripción: su aplicación sirve a varias áreas completamente diferentes en el mismo lugar. Pero debido a la estructura del edificio o a problemas en la práctica de recopilación, estas áreas no pueden conectarse completamente en los datos, y el usuario puede necesitar elegir primero el área donde se encuentra. Por ejemplo, diferentes pisos de un gran hospital.
    • Implementación: después de que el usuario seleccione el área, use esta prior information para activar dinámicamente el single map correspondiente a ese lugar. En el mismo momento, solo un map en la localization library participa en el cálculo. Cuando el usuario cruza a una nueva área, debe volver a confirmar la selección del área.
  • Escenario 2: parallel tasks

    • Descripción: su aplicación necesita procesar simultáneamente dos o más tareas independientes y conocidas de object tracking, y esos objetos están en el mismo lugar pero no están relacionados entre sí y sus características difieren mucho. Por ejemplo, varios objetos de exposición en un museo.
    • Implementación: en este escenario avanzado, puede crear un map independiente para cada objeto y luego agregar esos "object maps" a una localization library. Pero tenga en cuenta que el rendimiento de positioning dependerá del número de objetos agregados a la localization library. Si el número de objetos es muy grande, quizá deba equilibrar el rendimiento de positioning y el número de localization libraries, clasificando objetos y creando varias localization libraries por separado.

Comportamiento de rendering al usar multi-map

Tenga en cuenta que al usar multi-map positioning, el comportamiento de 3D rendering varía según las plataformas y versiones.

Recomendaciones de mejores prácticas

Si realmente pertenece a los escenarios descritos en escenarios que realmente requieren multi-map, o debe usar multi-map, siga estos principios:

  1. Activación bajo demanda: cuando el usuario haga una selección o entre en un área específica, proporcione la prior information correspondiente al enviar el positioning request y cargue solo el contenido 3D correspondiente.
  2. Cambio dinámico: proporcione una UI clara para que el usuario seleccione scene. Antes de cargar el contenido 3D correspondiente al nuevo map, descargue primero el contenido 3D correspondiente al map antiguo para liberar memory.
  3. State management: gestione explícitamente en el código el map actualmente activo y escuche el Block ID en los resultados de positioning para distinguir el feedback de positioning de diferentes maps.
  4. Performance monitoring: al usar multi-map, observe de cerca el uso de memory del dispositivo, la positioning latency y el consumo de energía para garantizar que la aplicación funcione con fluidez en target devices.

En resumen, para la gran mayoría de aplicaciones, mantener el principio "una scene, un map" es la mejor opción para garantizar el rendimiento y la estabilidad de Mega positioning.