Algoritmo para resolver o problema de restrição planar ("Pokemon Go monster discovery")

[Nota: Este problema foi inspirado no Pokemon Go. Vou primeiro explicar o problema em termos matemáticos, depois explicar a conexão com o Pokemon Go. Meu objetivo não é trapacear no jogo. Se eu quisesse trapacear, melhores informações estariam disponíveis com mais facilidade.]

Suponha que haja $N$ pontos (os "pontos desconhecidos") em um avião, chame-os $n_1,\dots,n_N$, com coordenadas desconhecidas. Além disso, temos$M$ medições realizadas em locais conhecidos $m_1,\dots,m_M$.

Deixei $\text{dist}(m_i, n_j)$ ser a distância euclidiana (geralmente desconhecida) do ponto de medição $m_i$ para o ponto desconhecido $n_j$.

Para cada medição $m_i$, temos as seguintes informações:

1. As coordenadas exatas de cada ponto desconhecido $n_j$ para qual $\text{dist}(m_i, n_j)<d_\text{min}$ por alguma constante conhecida $d_\text{min}$; e
2. Uma lista de todos os índices $j$ para qual $\text{dist}(m_i, n_j) < d_\text{max}$ por alguma constante conhecida $d_\text{max}>d_\text{min}$, classificado por $\text{dist}(m_i, n_j)$.

Existe um algoritmo eficiente para calcular as áreas do plano onde os pontos desconhecidos ou um dado ponto desconhecido $n_j$, pode ser? O algoritmo recebe as coordenadas$(X_i,Y_i)$ dos pontos de medição, as informações de medição listadas acima e o número $N$de pontos desconhecidos; o objetivo é restringir a região de possíveis locais para cada um dos pontos desconhecidos$n_1,\dots,n_N$ tanto quanto possível.

A conexão Pokemon:

Em Pokemon Go, um jogo de realidade aumentada, o objetivo é encontrar Pokemons na natureza. De vez em quando, o jogo mostra os Pokemons em um "intervalo visível" ($d_{min}$) da posição do jogador. Além disso, possui um "localizador de Pokemon" que mostra uma lista de locais próximos ($dist<d_{max}$) Pokemons, classificados por distância. (Também deve mostrar uma distância aproximada como um, dois ou três passos, mas aparentemente há um erro e sempre mostra três passos.)

Eu acho que você poderia usar uma "junção espacial". Eu não joguei o jogo, mas presumo$d_{max}$ é bastante pequeno, ou seja, existem na ordem de 10 ou mais $n$ e $m$ no bairro de cada $m$. Suponho ainda que$N$ e $M$ são grandes, digamos 1.000.000 ou mais.

1. Ponha tudo $m$ como pontos 2D em um índice espacial
2. Para cada $m_1$ no índice, execute uma consulta de intervalo espacial com distância $2*d_{max}$. Isso dá a você todos os outros$m_x$ que potencialmente podem conter o mesmo $n$ Como $m_1$. Isso deve ser gerenciável porque o número de$m_x$ deve ser pequeno (como assumi acima).
3. Agora, obtendo todas as outras medidas estimadas para um determinado $n$, você pode tentar aproximar o correto $n$
4. (Otimização potencial): dependendo do seu índice espacial, você pode remover o $m_1$ depois de processar tudo o que é $n$. Isso reduz o conjunto de dados para as seguintes consultas de intervalo. Além disso,

De alguma forma, você também precisaria identificar exclusivamente cada $n$, para que você não calcule a posição de $n$ novamente se aparecer ao processar outro $m$.

Como otimização, convém usar consultas de janela (retangular) em vez de consultas de intervalo circular. As consultas de janela podem ser muito mais rápidas e fornecer apenas um pouco mais de resultados. Além disso, pode ser que o jogo não use distância euclidiana (círculos), mas a distância mais rápida do manhatten, que seria exatamente um retângulo.

Para essa junção espacial, você pode usar qualquer índice espacial, como R-Tree, kd-Tree, quadtree ou qualquer uma de suas variantes.

Para conjuntos de dados grandes, eu provavelmente não usaria uma árvore R (árvore R +, árvore R *, árvore X) ou uma variante especial da árvore quad, a árvore PH, que é adequada para consultas de intervalo e permitindo a rápida remoção (ou adição) de pontos.

Para Java, as implementações de R-Trees podem ser encontradas em qualquer lugar da Internet, por exemplo, na estrutura ELKI ou na minha própria biblioteca TinSpin Index . O PH-Tree também está disponível em Java.

Um algoritmo genérico de junção espacial é chamado TOUCH , mas não acho que seja de código aberto.

Se alguma posição do objeto $n_j$ é conhecido exatamente (por exemplo, porque está dentro $d_{min}$ de alguma medida), então sempre que isso $n_j$ aparece no anel para algumas medições $m_i$ (significado $d_{min} \le dist(m_i, n_j) < d_{max}$), podemos reduzir as regiões possíveis para outras posições desconhecidas no mesmo anular. Especificamente, podemos simplesmente calcular$d_{ij} = dist(m_i, n_j)$ já que conhecemos as duas posições ($m_i$ e $n_j$) exatamente e, em seguida, podemos dividir o espaço anular para $m_i$ em dois sub-anéis: uma peça "próxima" (contendo todos os pontos $p$ de tal modo que $d_{min} \le dist(m_i, p) < d_{ij}$) and a "far" piece (containing all points $p$ such that $d_{ij} \le dist(m_i, p) < d_{max}$). Every object listed before $n_j$ for measurement $m_i$ is necessarily confined to the near annulus, and every object listed after $n_j$ is confined to the far annulus.

What can be done (beyond the intersection of annuli already suggested by Tom van der Zanden in a comment) for object positions that aren't related to some already-known object position in this way? This seems very hard. The statement

"$n_j$ cannot appear at $p$"

is equivalent to

"For all possible placements of all remaining unknown points, setting $n_j = p$, juntamente com as desigualdades de distância implícitas na ordem em que os objetos pertencentes ao anel de cada medição são listados, leva a uma contradição ".

Parece-me que, para chegar a algum lugar, precisamos ter (pelo menos) duas posições de objetos desconhecidos que aparecem no espaço anular das (pelo menos) as mesmas duas medições. Mas, embora essas informações descartem muitos pares de posições para os dois objetos, não consegui encontrar nenhuma circunstância em que uma posição pudesse ser descartada para apenas um deles, independentemente da posição do outro objeto.