Table of Contents

multi-map 사용 가이드와 모범 사례

Mega 애플리케이션 개발에서 하나의 localization library에 여러 map(Block)을 추가해야 하는지는 흔한 질문입니다. multi-map을 잘못 사용하면 애플리케이션 기능이 향상되지 않을 뿐 아니라 성능 저하와 positioning jump를 유발할 수 있습니다.

이 가이드는 multi-map 기능을 올바르게 이해하고 사용하며 일반적인 오해를 피하도록 안내합니다.

왜 여러 map 추가를 피해야 합니까?

핵심 원칙: "커버리지 확대"를 위해 여러 map을 추가하지 마십시오.

대부분의 경우 하나의 localization library에는 단일 장소의 Mega Block map 하나만 추가해야 합니다. 다음은 반드시 피해야 하는 일반적인 잘못된 사용법입니다:

  • 잘못된 시나리오 A: multi-region

    • 아이디어: 관광지에서 서로 연결된 "A 구역", "B 구역", "C 구역"에 대해 각각 map을 만든 뒤, 애플리케이션에서 이 세 map을 한 번에 library에 추가하여 사용자가 관광지 안에서 이동할 때 seamless switching이 가능하길 기대합니다.
    • 문제: 이렇게 만들어진 세 map 사이에는 공간 좌표상의 수학적 관계가 없고 서로 독립적입니다. 각 coordinate system이 일치하지 않기 때문에 이동 중 seamless switching을 구현할 수 없으며, 구역 경계에서 positioning jump가 발생합니다.
    • 해결: 이러한 시나리오에서는 초대형 공간 데이터 수집 방법에 따라 "A 구역", "B 구역", "C 구역"을 수집하고 서로 충분한 overlap이 있도록 하는 것이 가장 좋습니다. 초대형 범위 fusion task에 따라 map construction을 수행합니다. 그러면 위 모든 구역을 포함하는 통합 coordinate system의 single Block map이 생성되며, 이 map을 localization library에 추가할 수 있습니다.

  • 잘못된 시나리오 B: multi-location

    • 아이디어: 한 위치의 쇼핑몰에 대해 map 하나를 만들고, 다른 위치의 같은 이름 쇼핑몰에 대해 또 다른 map을 만들어 하나의 애플리케이션에서 동시에 사용하고자 합니다.
    • 문제: 이는 positioning 속도를 심각하게 늦춥니다. 디바이스는 positioning 시 library 내 모든 map 데이터를 동시에 비교해야 하므로 계산량이 급증하고 initialization 시간이 길어집니다. 사용자는 한 시점에 하나의 쇼핑몰에만 있을 수 있으므로 다른 쇼핑몰의 map을 로드하는 것은 resource 낭비입니다. 특정 쇼핑몰의 request 양이 많을 때 다른 쇼핑몰의 request 응답 시간도 느려집니다.
    • 해결: 서로 다른 위치의 쇼핑몰에는 서로 다른 localization library를 만들고, 각 library에는 map 하나만 추가합니다. 애플리케이션에서는 사용자의 현재 위치에 따라 해당 localization library에 동적으로 접근합니다.

  • 잘못된 시나리오 C: cross-time

    • 아이디어: 같은 장소에서 낮에 수집하고 map construction을 수행하며, 밤에도 수집하고 map construction을 수행한 뒤 낮과 밤의 map을 library에 추가하여 사용자가 같은 장소의 다른 시간대에도 일관된 경험을 얻기를 기대합니다.
    • 문제: 이 시나리오는 잘못된 시나리오 A와 유사하며, 별도로 만들어진 map construction 결과 사이의 공간 위치 관계를 보장할 수 없습니다.
    • 해결: 초대형 범위 fusion task에 따라 낮과 밤의 수집을 함께 fusion map construction합니다. 최종 생성된 single Block map을 localization library에 추가합니다.

  • 잘못된 시나리오 D: cross-version

    • 아이디어: 같은 장소에 대해 버전 A map을 이미 만들고 사용 중이며, 이후 운영 과정에서 더 새로운 버전 B map을 새로 만들어 원래 localization library에 추가하여 애플리케이션을 다시 배포하지 않고 새 map을 사용하고자 합니다.
    • 문제: 같은 장소의 서로 다른 버전 map이므로 positioning 시 결과가 두 다른 버전 데이터 사이에서 jump하는 상황이 발생할 수 있습니다.
    • 해결: lossless full update에 따라 이전 버전의 map construction을 upgrade하여 map 데이터 버전을 업데이트하면서 coordinate system을 유지합니다. 업데이트된 map을 추가한 후에는 반드시 localization library에서 이전 버전 map을 삭제하십시오.

  • 잘못된 시나리오 E: supplementary update

    • 아이디어: 같은 장소에 대해 버전 A map을 이미 만들고 사용 중이며, 이후 운영 과정에서 일부 구역이 변경되었거나 작은 범위의 보충 수집이 필요해 새 map B를 만들고 원래 localization library에 추가하여 애플리케이션을 다시 배포하지 않고 새 map을 사용하고자 합니다.
    • 문제: 새로 수집한 작은 구역 map B와 원래 map A 사이에는 공간 좌표 관련성이 없으며, 기존 데이터와 새 데이터 사이의 경험에서 positioning jump가 발생합니다.
    • 해결: supplementary update에 따라 이전 버전의 map construction에 보충 업데이트를 수행하여 새로 수집한 작은 구역이 기존 map과 coordinate system을 유지하도록 합니다. 업데이트된 map을 추가한 후에는 반드시 localization library에서 이전 버전 map을 삭제하십시오.

요약: 여러 작은 map을 이어 하나의 큰 world로 만들려는 방식은 Mega의 고정밀 map에 적합하지 않습니다. Mega의 설계 철학은 공간적으로 연속되고, 좌표가 통일되며, 시공간적으로 일관된 고정밀 3D 표현입니다.

실제로 multi-map이 필요한 시나리오

그렇다면 언제 하나의 library에 여러 map(Block)을 추가해야 할까요? 주요 시나리오는 "parallel tasks" 또는 **"multi-space selection"**이며, **"spatial stitching"**이 아닙니다.

  • 시나리오 1: multi-space selection

    • 설명: 애플리케이션이 같은 장소의 완전히 다른 여러 구역을 서비스합니다. 그러나 건물 구조나 수집 실무상의 문제로 인해 이 구역들을 데이터상 완전히 연결할 수 없고, 사용자가 먼저 자신이 있는 구역을 선택해야 할 수 있습니다. 예: 대형 병원의 서로 다른 층.
    • 구현: 사용자가 구역을 선택한 뒤, 이 prior information을 사용하여 해당 장소의 single map을 동적으로 활성화합니다. 같은 시점에는 localization library 안에서 여전히 하나의 map만 계산에 참여합니다. 사용자가 새로운 구역으로 넘어갈 때는 구역 선택을 다시 확인해야 합니다.

  • 시나리오 2: parallel tasks

    • 설명: 애플리케이션이 독립적이고 알려진 둘 이상의 object tracking 작업을 동시에 처리해야 하며, 이 객체들이 같은 장소에 있지만 서로 관련이 없고 feature 차이가 매우 큽니다. 예: 박물관의 여러 전시품.
    • 구현: 이러한 고급 시나리오에서는 각 객체에 대해 독립적인 map을 만들고, 이러한 "object maps"를 하나의 localization library에 추가할 수 있습니다. 단, 이때 positioning performance는 localization library에 추가된 객체 수에 따라 달라집니다. 객체 수가 매우 많으면 positioning performance와 localization library 수 사이에서 균형을 잡아야 할 수 있으며, 객체를 분류하고 여러 localization library를 각각 만들 수 있습니다.

multi-map 사용 시 rendering 동작

multi-map positioning을 사용할 때는 플랫폼과 버전에 따라 3D rendering 동작이 다르다는 점에 유의해야 합니다.

모범 사례 권장 사항

실제로 multi-map이 필요한 시나리오에 해당하거나 multi-map을 반드시 사용해야 하는 경우 다음 원칙을 따르십시오:

  1. 필요 시 활성화: 사용자가 선택하거나 특정 구역에 들어갈 때 positioning request를 보낼 때 해당 prior information을 제공하고, 대응하는 3D 콘텐츠만 로드합니다.
  2. 동적 전환: 사용자가 scene을 선택할 수 있도록 명확한 UI를 제공합니다. 새 map에 대응하는 3D 콘텐츠를 로드하기 전에 기존 map에 대응하는 3D 콘텐츠를 먼저 unload하여 memory를 확보합니다.
  3. State management: 코드에서 현재 active map을 명확히 관리하고 positioning 결과의 Block ID를 listen하여 서로 다른 map의 positioning feedback을 구분합니다.
  4. Performance monitoring: multi-map을 사용할 때는 디바이스의 memory usage, positioning latency, 전력 소모를 면밀히 확인하여 애플리케이션이 target device에서 원활히 실행되도록 합니다.

요컨대 대부분의 애플리케이션에서는 "하나의 scene, 하나의 map" 원칙을 지키는 것이 Mega positioning performance와 안정성을 보장하는 최선의 선택입니다.