Guida all'uso multi-map e best practice
Nello sviluppo di applicazioni Mega, se aggiungere più map (Block) a una singola localization library è una domanda comune. Usare multi-map in modo errato non solo non migliora le capacità dell'applicazione, ma può causare cali di prestazioni e positioning jumps.
Questa guida aiuta a comprendere e usare correttamente la funzione multi-map, evitando errori comuni.
Perché evitare di aggiungere più map?
Principio fondamentale: non aggiungere più map per "ampliare la copertura".
Nella maggior parte dei casi, una localization library dovrebbe contenere solo una singola Mega Block map per un singolo luogo. Di seguito sono riportati alcuni usi errati comuni da evitare:
Scenario errato A: multi-region
- Idea: creare map separate per "Area A", "Area B" e "Area C" collegate tra loro in un'area turistica, quindi aggiungere tutte e tre le map alla library dell'applicazione in una sola volta, sperando che gli utenti possano passare senza interruzioni mentre si muovono.
- Problema: le tre map create in questo modo non hanno alcuna relazione matematica nelle coordinate spaziali e sono indipendenti tra loro. A causa dell'incoerenza dei rispettivi coordinate systems, il seamless switching durante il movimento non è possibile e ai confini delle aree si verificano positioning jumps.
- Soluzione: per questi scenari, il metodo migliore è raccogliere "Area A", "Area B" e "Area C" secondo il metodo di raccolta dati per spazi molto grandi, assicurando sufficiente overlap tra loro. Eseguire poi la map construction secondo la large-scale fusion task. Verrà generata una single Block map con coordinate system unificato che include tutte le aree indicate, e questa map può essere aggiunta alla localization library.
Scenario errato B: multi-location
- Idea: creare una map per un centro commerciale in un luogo e un'altra map per un centro commerciale con lo stesso nome in un altro luogo, sperando di usarle contemporaneamente in una sola applicazione.
- Problema: questo rallenta gravemente il positioning. Durante positioning, il dispositivo deve confrontare contemporaneamente tutti i dati map nella library, aumentando drasticamente il carico di calcolo e allungando il tempo di initialization. L'utente può trovarsi in un solo centro commerciale alla volta, quindi caricare la map di un altro centro commerciale spreca risorse. Quando un centro commerciale ha molte request, rallenta anche il tempo di risposta dell'altro.
- Soluzione: creare localization library diverse per centri commerciali in luoghi diversi, ognuna con una sola map. Nell'applicazione, accedere dinamicamente alla localization library corrispondente in base alla posizione corrente dell'utente.
Scenario errato C: cross-time
- Idea: nello stesso luogo, raccogliere e creare map di giorno, poi raccogliere e creare map anche di notte, quindi aggiungere le map diurne e notturne alla library, sperando che gli utenti abbiano un'esperienza coerente nello stesso luogo in momenti diversi.
- Problema: questo scenario è simile allo scenario errato A; non è possibile garantire la relazione di posizione spaziale tra risultati di map construction separati.
- Soluzione: unire le raccolte diurne e notturne per la fusion map construction secondo la large-scale fusion task. Aggiungere alla localization library la single Block map finale generata.
Scenario errato D: cross-version
- Idea: nello stesso luogo, una map versione A è già stata creata ed è in uso; durante le operazioni successive viene creata una nuova map versione B e aggiunta alla localization library originale, sperando di usare la nuova map senza ripubblicare l'applicazione.
- Problema: poiché sono map di versioni diverse dello stesso luogo, durante positioning i risultati possono saltare tra due versioni di dati diverse.
- Soluzione: aggiornare la vecchia map construction secondo lossless full update, garantendo l'aggiornamento della versione dei dati map mantenendo invariato il coordinate system. Dopo aver aggiunto la map aggiornata, eliminare obbligatoriamente la vecchia versione della map dalla localization library.
Scenario errato E: supplementary update
- Idea: nello stesso luogo, una map versione A è già stata creata ed è in uso; durante le operazioni successive, per cambiamenti in un'area locale o necessità di raccogliere una piccola area aggiuntiva, viene creata una nuova map B e aggiunta alla localization library originale, sperando di usare la nuova map senza ripubblicare l'applicazione.
- Problema: la nuova map B della piccola area non ha correlazione di coordinate spaziali con la map originale A; l'esperienza tra dati vecchi e nuovi subirà positioning jumps.
- Soluzione: eseguire un supplementary update sulla vecchia map construction, garantendo che la piccola area appena raccolta mantenga lo stesso coordinate system della vecchia map. Dopo aver aggiunto la map aggiornata, eliminare obbligatoriamente la vecchia versione della map dalla localization library.
Riepilogo: tentare di unire più piccole map in un grande mondo non è adatto alle map ad alta precisione di Mega. La filosofia di progettazione di Mega è una rappresentazione 3D ad alta precisione, spazialmente continua, con coordinate unificate e coerente nello spazio-tempo.
Scenari in cui multi-map è davvero necessario
Quindi, quando è davvero necessario aggiungere più map (Block) in una library? Gli scenari principali sono "parallel tasks" o "multi-space selection", non "spatial stitching".
Scenario 1: multi-space selection
- Descrizione: l'applicazione serve più aree completamente diverse nello stesso luogo. Tuttavia, a causa della struttura dell'edificio o di problemi nella pratica di raccolta, queste aree non possono essere completamente collegate nei dati e gli utenti potrebbero dover scegliere prima l'area in cui si trovano. Ad esempio, piani diversi di un grande ospedale.
- Implementazione: dopo la selezione dell'area da parte dell'utente, usare questa prior information per attivare dinamicamente la single map corrispondente al luogo. Nello stesso momento, nella localization library resta una sola map che partecipa al calcolo. Quando l'utente passa a una nuova area, occorre confermare di nuovo la selezione dell'area.
Scenario 2: parallel tasks
- Descrizione: l'applicazione deve elaborare contemporaneamente due o più task indipendenti e noti di object tracking, e questi oggetti si trovano nello stesso luogo ma non sono correlati tra loro e hanno feature molto diverse. Ad esempio, più oggetti esposti in un museo.
- Implementazione: in questo scenario avanzato, è possibile creare una map indipendente per ogni oggetto e poi aggiungere queste "object maps" a una localization library. Tuttavia, occorre notare che la performance di positioning dipenderà dal numero di oggetti aggiunti alla localization library. Se gli oggetti sono moltissimi, potrebbe essere necessario bilanciare positioning performance e numero di localization library, classificando gli oggetti e creando più localization library separatamente.
Comportamento rendering usando multi-map
Occorre notare che, quando si usa multi-map positioning, il comportamento di 3D rendering varia tra piattaforme e versioni diverse.
Raccomandazioni di best practice
Se il proprio caso appartiene davvero agli scenari in cui multi-map è necessario, oppure se è indispensabile usare multi-map, seguire questi principi:
- Attivare su richiesta: quando l'utente effettua una scelta o entra in un'area specifica, fornire la prior information corrispondente quando si invia la positioning request e caricare solo il contenuto 3D corrispondente.
- Switching dinamico: fornire una UI chiara per consentire all'utente di selezionare la scene. Prima di caricare il contenuto 3D corrispondente alla nuova map, scaricare prima il contenuto 3D della vecchia map per liberare memory.
- State management: gestire esplicitamente nel codice la map attualmente attiva e ascoltare il Block ID nei risultati di positioning per distinguere il feedback di positioning delle diverse map.
- Performance monitoring: quando si usa multi-map, monitorare attentamente memory usage del dispositivo, positioning latency e consumo energetico, assicurando che l'applicazione funzioni fluidamente sul target device.
In sintesi, per la maggior parte delle applicazioni, mantenere il principio "una scene, una map" è la scelta migliore per garantire performance e stabilità di Mega positioning.