Algoritmo per la risoluzione del problema di vincolo planare ("Individuazione di mostri di Pokemon Go")

[Nota: questo problema è stato ispirato da Pokemon Go. Spiegherò prima il problema in termini matematici, quindi spiegherò la connessione a Pokemon Go. Il mio obiettivo non è imbrogliare nel gioco. Se volessi imbrogliare, sarebbero disponibili più facilmente informazioni migliori.]

Supponiamo che ci siano punti (i "punti sconosciuti") in un piano, chiamali , con coordinate sconosciute. Inoltre, abbiamo misurazioni prese in posizioni note .$N$$n_1,\dots,n_N$$M$$m_1,\dots,m_M$

Sia la distanza euclidea (generalmente sconosciuta) dal punto di misurazione al punto sconosciuto .$\text{dist}(m_i, n_j)$$m_i$$n_j$

Per ogni misura , abbiamo le seguenti informazioni:$m_i$

1. Le coordinate esatte di ciascun punto sconosciuto per il quale per una costante nota ; e$n_j$$\text{dist}(m_i, n_j)<d_\text{min}$$d_\text{min}$
2. Un elenco di tutti gli indici per i quali per una costante nota , ordinati per .$j$$\text{dist}(m_i, n_j) < d_\text{max}$$d_\text{max}>d_\text{min}$$\text{dist}(m_i, n_j)$

Esiste un algoritmo efficiente per calcolare le aree del piano in cui possono essere i punti sconosciuti o un dato punto sconosciuto ? All'algoritmo vengono fornite le coordinate dei punti di misurazione, le informazioni di misurazione sopra elencate e il numero di punti sconosciuti; l'obiettivo è restringere il più possibile la regione delle posizioni possibili per ciascuno dei punti sconosciuti .$n_j$$(X_i,Y_i)$$N$$n_1,\dots,n_N$

La connessione Pokemon:

In Pokemon Go, un gioco di realtà aumentata, l'obiettivo è trovare Pokemon nella natura. Di tanto in tanto, il gioco mostra i Pokemon in un "intervallo visibile" ( ) della posizione del giocatore. Inoltre, ha un "Pokemon finder" che mostra un elenco di Pokemon vicini ( ), ordinati per distanza. (Dovrebbe anche mostrare una distanza approssimativa di uno, due o tre passi, ma a quanto pare c'è un bug e mostra sempre tre passi.)$d_{min}$$dist<d_{max}$

Penso che potresti usare un "join spaziale". Non ho giocato al gioco, ma presumo$d_{max}$ è piuttosto piccolo, cioè ce ne sono nell'ordine di 10 o giù di lì $n$ e $m$ nel quartiere di ciascuno $m$. Suppongo inoltre che$N$ e $M$ sono grandi, diciamo 1.000.000 o più.

1. Metti tutto $m$ come punti 2D in un indice spaziale
2. Per ciascuno $m_1$ nell'indice, eseguire una query di intervallo spaziale con distanza $2*d_{max}$. Questo ti dà tutto il resto$m_x$ che può potenzialmente contenere lo stesso $n$ come $m_1$. Questo dovrebbe essere gestibile perché il numero di$m_x$ dovrebbe essere piccolo (come ho ipotizzato sopra).
3. Ora, ottenendo tutte le altre misurazioni stimate per un particolare $n$, puoi provare ad approssimare il corretto $n$
4. (Potenziale ottimizzazione): a seconda dell'indice spaziale, è possibile rimuovere il $m_1$ dopo aver elaborato tutto $n$. Questo rende il set di dati più piccolo per le seguenti query di intervallo. Anche,

In qualche modo dovresti anche identificarli in modo univoco $n$, in modo da non calcolare la posizione di $n$ di nuovo se si presenta durante l'elaborazione di un altro $m$.

Come ottimizzazione, potresti voler utilizzare query a finestra (rettangolari) anziché query a intervallo circolare. Le query alle finestre possono essere molto più veloci e dare solo leggermente più risultati. Inoltre, potrebbe darsi che il gioco in realtà non usi la distanza euclidea (cerchi) ma la distanza più veloce, che sarebbe esattamente un rettangolo.

Per tale unione spaziale puoi usare qualsiasi indice spaziale, come R-Tree, kd-Tree, quadtree o una qualsiasi delle loro varianti.

Per i set di dati di grandi dimensioni probabilmente non userei un R-Tree (R + tree, R * -tree, X-Tree) o una variante speciale del quadtree, il PH-Tree, che è adatto sia per le query di intervallo che per consentendo una rapida rimozione (o aggiunta) di punti.

Per Java, le implementazioni di R-Trees possono essere trovate ovunque su Internet, ad esempio nel framework ELKI o nella mia libreria di TinSpin Index . Il PH-Tree è disponibile anche in Java.

Un algoritmo di join spaziale generico si chiama TOUCH , ma non penso che sia open source.

Se qualche posizione dell'oggetto $n_j$ è noto esattamente (ad es. perché è dentro $d_{min}$ di alcune misurazioni), quindi ogni volta che questo $n_j$ appare nell'annulus per alcune misurazioni $m_i$ (senso $d_{min} \le dist(m_i, n_j) < d_{max}$), possiamo ridurre le possibili regioni per altre posizioni sconosciute nello stesso annulus. In particolare, possiamo semplicemente calcolare$d_{ij} = dist(m_i, n_j)$ poiché conosciamo entrambe le posizioni ($m_i$ e $n_j$) esattamente, e possiamo quindi dividere l'annulus per $m_i$ in due sub-annuli: un pezzo "vicino" (contenente tutti i punti $p$ tale che $d_{min} \le dist(m_i, p) < d_{ij}$) e un pezzo "lontano" (contenente tutti i punti $p$ tale che $d_{ij} \le dist(m_i, p) < d_{max}$). Ogni oggetto elencato prima$n_j$ per la misurazione $m_i$ è necessariamente confinato nell'annulus vicino e ogni oggetto elencato dopo $n_j$ è limitato al lontano annulus.

Cosa si può fare (oltre l'intersezione degli annuli già suggerita da Tom van der Zanden in un commento) per le posizioni degli oggetti che non sono correlate a posizioni di oggetti già conosciute in questo modo? Questo sembra molto difficile. La dichiarazione

"$n_j$ non può apparire a $p$"

è equivalente a

"Per tutti i possibili posizionamenti di tutti i restanti punti sconosciuti, impostazione$n_j = p$, insieme alle disparità di distanza implicite nell'ordine in cui sono elencati gli oggetti appartenenti all'anello di ciascuna misura, porta a una contraddizione ".

Mi sembra che per arrivare ovunque, dobbiamo avere (almeno) 2 posizioni di oggetti sconosciuti che compaiono nell'annulus di (almeno) le stesse 2 misurazioni. Ma mentre queste informazioni escluderanno molte coppie di posizioni per i due oggetti, non sono stato in grado di trovare alcuna circostanza in cui una posizione potesse essere esclusa per uno solo di essi, indipendentemente dalla posizione dell'altro oggetto.