Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Compatibilização da vizinhança na cobertura L0 #7

Open
ppKrauss opened this issue Oct 19, 2022 · 3 comments
Open

Compatibilização da vizinhança na cobertura L0 #7

ppKrauss opened this issue Oct 19, 2022 · 3 comments
Assignees
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@ppKrauss
Copy link
Contributor

ppKrauss commented Oct 19, 2022

Apesar da cobertura de nível ter uma ordem indiferente, sem compromisso com a curva de preenchimento (Morton ou Hilbert), os algoritmos de cálculo de vinhança podem se tornar mais simples e com menos exceções se for mantida aproximadamente a ordem da curva de preenchimento.

Exemplo do Brasil: abaixo seguindo a ordem dentro do possível.

image
image
image

ao invés da ordem totalmente arbitrária, apesar de "didática" para o leigo entender a ordem do alfabeto utilizado

image


Lembrete: essa é a orientação (zero em baixo) e ordem recorrente na base16, não temos dúvidas quando ao algoritmo de vizinhança... Na ilustração abaixo as vizinhanças de A0 com prefixo A são válidas, as demais estão comprometidas porque o prefixo arbitrário não permite o algoritmo avaliar recorrentemente. Por exemplo A0F tem A2, A3 e A1 como vizinhos válidos, mas a esquerda e abaixo de A00, 95 e DA estão comprometidos pela escolha arbitrária de ordem na corbertura.

image

@ppKrauss ppKrauss added documentation Improvements or additions to documentation enhancement New feature or request labels Oct 19, 2022
@ppKrauss
Copy link
Contributor Author

Ok, vamos com calma:

  1. Adequar a função de cálculo de vizinhança ao caso atual, onde toda a cobertura L0 será exceção à ordem esperada.
  2. Avaliar mais amplamente, com mais discussão e mais pessoas se vale a pena.
    Se o custo de resolução da vizinhança em L0 for desprezível não há porque se preocupar, já que a rigor L1 que recebe a primeira partição.
  3. Há provavelmente incompatibilidade entre vizinhança base32 e base16, dificultando a decisão.

... Não vamos alterar até ter certeza de que vale a pena.

@ppKrauss
Copy link
Contributor Author

ppKrauss commented Nov 5, 2022

Outra estratégia:

  1. Cuidado em manter fidelidade com base de referência (ex. hexadecimal é quadrado e não alterna mas base32 alterna);
  2. Vizinhanças no primeiro dígito hexadecimal (portanto cobertura) são calculadas por geometria;
  3. Demais (interior de célula de cobertura) calculadas por algoritmo string, sem uso da geometria.
  4. Os resultados podem ser sistematicados para otimizar o algoritmo string a cada país.

Como se busca minimizar as exceções no algoritmo string, será importante usar a "cobertura otimizada para vizinhança".

.... Acima usamos lógica da vizinhança da base32, abaixo usamos vizinhança base16:

image

Solução ótima para as relações de vizinhança (apenas uma falha no "5"), mas perdendo-se totalmente a curva Z descrita pela sequência:

image


A decisão final passa por 3 alternativas:

  1. Ignorar questão da otimização da vizinhança na cobertura (será integralmente por resolvida por exceção). (foi a decisão inicial e ainda não mudamos)
  2. Otimizar a sequência. (intuitivo mas sem resultado prático - melhor ficar com decisao 1)
  3. Otimizar as relações de vizinhaça. (oferece resultado relevante no algoritmo - compensa o ganho?)

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants