Table of Contents

Multi-map usage guide and best practices

In Mega application development, whether to add multiple maps (Blocks) to a single positioning library is a common question. Incorrect use of multiple maps not only fails to enhance application capabilities but may also lead to performance degradation and positioning jumps.

This guide will help you correctly understand and use the multi-map feature, avoiding common pitfalls.

Why avoid adding multiple maps?

Core principle: do not add multiple maps to "expand coverage".

In most cases, a positioning library should contain only a single Mega Block map for one location. Below are some common incorrect usages to avoid:

  • Error scenario A: multi-region

    • Idea: Create separate maps for interconnected "Area A", "Area B", and "Area C" in a scenic spot, then add all three maps to the library at once, hoping for seamless switching as users move through the areas.
    • Problem: These three maps lack spatial mathematical relationships and exist in independent coordinate systems. Due to inconsistent coordinate systems, seamless switching during movement is impossible, causing positioning jumps at area boundaries.
    • Solution: For such scenarios, follow the large-space data collection method to capture "Area A", "Area B", and "Area C" with sufficient overlap. Then perform mapping via the large-scale fusion task. This generates a single Block map covering all areas in a unified coordinate system. Add this map to the positioning library.

  • Error scenario B: multi-location

    • Idea: Create a map for a mall at one location and another map for a same-named mall at a different location, hoping to use both in one application.
    • Problem: This severely slows positioning. Devices must compare against all maps in the library simultaneously, increasing computational load and prolonging initialization. Users can only be in one mall at a time, making loading another mall's map wasteful. High demand for one mall also slows response for the other.
    • Solution: Create separate positioning libraries for different locations, each containing only one map. Dynamically access the corresponding library based on the user's current location.

  • Error scenario C: cross-time

    • Idea: Capture and map a location during daytime and nighttime separately, then add both maps to the library, hoping for consistent experiences at different times.
    • Problem: This shares the same issue as Error Scenario A—separate maps cannot guarantee spatial relationships.
    • Solution: Fuse daytime and nighttime captures using the large-scale fusion task. Add the resulting single Block map to the positioning library.

  • Error scenario D: cross-version

    • Idea: After deploying version A of a map for a location, add a newer version B map to the same library, hoping to use the new map without redeploying the app.
    • Problem: Positioning results may jump between the two versions due to coordinate inconsistencies.
    • Solution: Upgrade the old map using lossless full updates, ensuring coordinate system consistency during updates. After adding the updated map, remove the old version from the library.

  • Error scenario E: supplementary update

    • Idea: After deploying version A of a map, create a new map B for a small updated area (e.g., partial renovation) and add it to the original library.
    • Problem: The new partial map B lacks spatial correlation with the original map A, causing positioning jumps near updated areas.
    • Solution: Perform a supplementary update to align the new area with the original map's coordinate system. After adding the updated map, remove the old version from the library.

Summary: Attempting to stitch multiple small maps into a large world is incompatible with Mega's high-precision design philosophy, which requires a spatially continuous, coordinate-unified, and temporally consistent 3D representation.

When multiple maps are truly needed

When should you add multiple Block maps to a single library? Valid scenarios involve "parallel tasks" or "multi-space selection", not "spatial stitching".

  • Scenario 1: multi-space selection

    • Description: Your application serves multiple disconnected areas at the same location (e.g., separate hospital floors) that cannot be physically connected in the data. Users must select their current area first.
    • Implementation: After user selection, dynamically activate only the corresponding single map. Only one map participates in positioning at any time. Re-confirm the area selection when users move to a new zone.

  • Scenario 2: parallel tasks

    • Description: Your application tracks multiple independent objects at the same location with distinct features and no mutual correlation (e.g., museum exhibits).
    • Implementation: Create a separate "object map" for each item and add them to one positioning library. Note: performance degrades with more objects. For large numbers, balance performance by grouping objects into separate libraries.

3D rendering behavior with multiple maps

When using multi-map positioning, 3D rendering varies across platforms and versions.

Best practice recommendations

If your use case aligns with truly multi-map scenarios, follow these principles:

  1. Activate on demand: Load only the relevant 3D content when users select an area or enter a specific zone.
  2. Dynamic switching: Provide clear UI for scene selection. Unload old 3D content before loading new content to free memory.
  3. State management: Explicitly track the active map in code. Monitor the Block ID in positioning results to handle map-specific feedback.
  4. Performance monitoring: Closely watch memory usage, positioning latency, and power consumption when using multiple maps.

In summary, for most applications, adhering to "one scene, one map" is the optimal choice for Mega's positioning stability and performance.