Table of Contents

Guia de uso de multi-map e melhores práticas

No desenvolvimento de aplicações Mega, é comum perguntar se vários maps (Block) devem ser adicionados a uma única localization library. O uso incorreto de multi-map não melhora a capacidade da aplicação e pode causar queda de desempenho e positioning jumps.

Este guia ajudará você a entender e usar corretamente a função multi-map, evitando equívocos comuns.

Por que evitar adicionar vários maps?

Princípio central: não adicione vários maps para "ampliar a cobertura".

Na maioria dos casos, uma localization library deve conter apenas um Mega Block map de um único local. Abaixo estão alguns usos incorretos comuns que devem ser evitados:

  • Cenário incorreto A: multi-region

    • Ideia: criar maps separados para "Área A", "Área B" e "Área C" conectadas entre si em uma área turística, depois adicionar os três maps de uma vez à library da aplicação, esperando que usuários possam alternar sem interrupção ao se moverem pela área.
    • Problema: os três maps criados assim não têm relação matemática nas coordenadas espaciais e são independentes entre si. Como os coordinate systems não são consistentes, não é possível realizar seamless switching durante o movimento, causando positioning jumps nas fronteiras das áreas.
    • Solução: para esse tipo de cenário, a melhor abordagem é coletar "Área A", "Área B" e "Área C" conforme o método de coleta de dados de espaços muito grandes, garantindo overlap suficiente entre elas. Faça a map construction conforme a large-scale fusion task. Nesse momento será gerada uma single Block map com coordinate system unificado contendo todas as áreas acima, e esse map pode ser adicionado à localization library.

  • Cenário incorreto B: multi-location

    • Ideia: criar um map para um shopping em um local e outro map para um shopping de mesmo nome em outro local, esperando usar ambos em uma única aplicação.
    • Problema: isso reduz seriamente a velocidade de positioning. Durante positioning, o dispositivo precisa comparar simultaneamente todos os dados de maps na library, aumentando muito o cálculo e prolongando o tempo de initialization. O usuário só pode estar em um shopping por vez, portanto carregar o map de outro shopping desperdiça recursos. Quando um shopping tem grande volume de requests, também reduz o tempo de resposta do outro shopping.
    • Solução: crie localization libraries diferentes para shoppings em locais diferentes, cada library contendo apenas um map. Na aplicação, acesse dinamicamente a localization library correspondente com base na localização atual do usuário.

  • Cenário incorreto C: cross-time

    • Ideia: para o mesmo local, coletar e construir map durante o dia e também à noite, depois adicionar os maps diurno e noturno à library, esperando que usuários tenham experiência consistente em horários diferentes no mesmo local.
    • Problema: este cenário é semelhante ao cenário incorreto A; não é possível garantir a relação de posição espacial entre resultados separados de map construction.
    • Solução: coloque as coletas diurna e noturna juntas para fusion map construction conforme a large-scale fusion task. Adicione a single Block map final gerada à localization library.

  • Cenário incorreto D: cross-version

    • Ideia: para o mesmo local, um map versão A já foi construído e está em uso; durante a operação posterior, um map versão B mais novo é criado e adicionado à localization library original, esperando usar o novo map sem republicar a aplicação.
    • Problema: como são maps de versões diferentes do mesmo local, durante positioning os resultados podem saltar entre duas versões de dados diferentes.
    • Solução: faça upgrade da map construction antiga conforme lossless full update, garantindo que a versão dos dados do map seja atualizada enquanto o coordinate system permanece inalterado. Depois de adicionar o map atualizado, remova obrigatoriamente o map da versão original da localization library.

  • Cenário incorreto E: supplementary update

    • Ideia: para o mesmo local, um map versão A já foi construído e está em uso; durante a operação posterior, devido a mudanças em uma área local ou necessidade de recoletar uma pequena área, um novo map B é criado e adicionado à localization library original, esperando usar o novo map sem republicar a aplicação.
    • Problema: o novo map B da pequena área coletada não tem correlação de coordenadas espaciais com o map A original, e a experiência entre dados antigos e novos terá positioning jumps.
    • Solução: faça um supplementary update na map construction antiga, garantindo que a pequena área recém-coletada mantenha o mesmo coordinate system do map antigo. Depois de adicionar o map atualizado, remova obrigatoriamente o map da versão original da localization library.

Resumo: tentar juntar vários maps pequenos em um grande mundo não é adequado para os maps de alta precisão do Mega. A filosofia de design do Mega é uma representação 3D de alta precisão, espacialmente contínua, coordenadamente unificada e consistente no espaço-tempo.

Cenários que realmente precisam de multi-map

Então, quando realmente é necessário adicionar vários maps (Block) a uma library? Os principais cenários são "parallel tasks" ou "multi-space selection", não "spatial stitching".

  • Cenário 1: multi-space selection

    • Descrição: sua aplicação atende várias áreas completamente diferentes no mesmo local. Mas, por limitações da estrutura do edifício ou problemas na prática de coleta, essas áreas não podem ser totalmente conectadas nos dados, e o usuário pode precisar escolher primeiro a área em que está. Por exemplo, diferentes andares de um grande hospital.
    • Implementação: depois que o usuário escolhe a área, use essa prior information para ativar dinamicamente o single map correspondente a esse local. No mesmo momento, ainda há apenas um map participando do cálculo na localization library. Quando o usuário atravessar para uma nova área, será necessário confirmar novamente a escolha da área.

  • Cenário 2: parallel tasks

    • Descrição: sua aplicação precisa processar simultaneamente duas ou mais tarefas independentes e conhecidas de object tracking, e esses objetos ficam no mesmo local, mas não têm relação entre si e possuem grandes diferenças de features. Por exemplo, vários itens em exposição em um museu.
    • Implementação: nesse cenário avançado, é possível criar um map independente para cada objeto e depois adicionar esses "object maps" a uma localization library. Mas observe que a performance de positioning dependerá da quantidade de objetos adicionados à localization library. Se houver muitos objetos, talvez seja necessário equilibrar a performance de positioning e o número de localization libraries, classificando objetos e criando várias localization libraries separadamente.

Comportamento de rendering ao usar multi-map

Observe que, ao usar multi-map positioning, o comportamento de 3D rendering varia entre plataformas e versões.

Recomendações de melhores práticas

Se o seu caso realmente pertence aos cenários que precisam de multi-map, ou se for necessário usar multi-map, siga estes princípios:

  1. Ativar sob demanda: quando o usuário fizer uma escolha ou entrar em uma área específica, forneça a prior information correspondente ao enviar a positioning request e carregue apenas o conteúdo 3D correspondente.
  2. Alternância dinâmica: forneça uma UI clara para o usuário selecionar a scene. Antes de carregar o conteúdo 3D correspondente ao novo map, descarregue primeiro o conteúdo 3D correspondente ao map antigo para liberar memory.
  3. State management: gerencie explicitamente no código o map atualmente active e escute o Block ID nos resultados de positioning para distinguir o feedback positioning de diferentes maps.
  4. Performance monitoring: ao usar multi-map, acompanhe de perto a memory usage do dispositivo, a positioning latency e o consumo de energia, garantindo que a aplicação rode suavemente no target device.

Em resumo, para a maioria das aplicações, seguir o princípio "uma scene, um map" é a melhor escolha para garantir performance e estabilidade do Mega positioning.