osm-codes / gridMap-draftPages

experimental and internal testing pages to map visualization and grid exploring
https://afa.codes/
Apache License 2.0
0 stars 0 forks source link

Proposta do changeLevel_byDigits #36

Closed ppKrauss closed 1 year ago

ppKrauss commented 1 year ago

Sobre a interface amarela de click "+1 dígito" e "-1 dígito", image

Ainda em teste, requer aprovação. Se aprovada, sugere-se as seguintes avaliações e correções:

  1. Avaliar se a interface seria mais amigável (ou indiferente) se não recarregasse a página inteira. Se for, aí o algoritmo fica mais complexo.
  2. Obter o valor máximo de dígitos, para max correto do país.
  3. Decidir, para a interface inteira, se os erros serão anunciados por alert() ou modal dialog.
  4. Conferir se existe alguma falha, ao combinar com outras ações.
function changeLevel_byDigits(x) {
  const max=8;
  const thisURL = window.location.href.replace(/#.*$/,''); 
  const code = document.getElementById('postalCode').textContent.replace('.','');
  let len = (code == null || code == '(click the map)')? 0: code.length;
  if (thisURL.indexOf('~')>0) {
   if (x>0 && len<max) {
      window.location.replace(thisURL+'7');
   } else if (x<0 && len>1) {
      window.location.replace( thisURL.substring(0,thisURL.length-1) );
   } else alert('check code or level limits');
 } else alert('Click a point first!');
}

Possível efeito colateral em células de fronteira

Por exemplo em https://osm.codes/BR-SP-SaoPaulo~47M ao clicar em "+1" vai cair numa célula externa

image

image

ppKrauss commented 1 year ago

Proposta geral da interface "±1 level" aceita. Próximo passo seguir sequência de simplicidade e prioridade nas melhoras:

  1. Conferir se é simples amarrar com o evento do botão "Decode", de modo a não recarregar a página.
  2. Incluir no Javascript informação sobre os limites e limitar removendo "+" ou removendo "-" conforme o último nível tenha sido alcançado.
  3. No geocódigo, melhorar a mensagem do on-mouse-over e incluir OnClick para centrar o ponto no geocodigo, caso o mapa tenha sido deslocado.
0e1 commented 1 year ago
  1. Avaliar se a interface seria mais amigável (ou indiferente) se não recarregasse a página inteira. Se for, aí o algoritmo fica mais complexo.

  2. Conferir se é simples amarrar com o evento do botão "Decode", de modo a não recarregar a página.

Fica mais amigável. É mais simples o algoritmo. Basta manipular o box fielddecode e chamar a getDecode(). Veja como ficou minha proposta para função (testar em http://test.osm.codes):

function changeLevel_byDigits(x)
{
    let input = document.getElementById('fielddecode').value

    if (input.length > 0)
    {
        if (x>0)
        {
            document.getElementById('fielddecode').value = input + '7';
            getDecode();
        }
        else if (x < 0 && input.length > 1)
        {
            document.getElementById('fielddecode').value = input.substring(0,input.length-1);
            getDecode();
        }
        else
        {
            alert('Check code or level limits.');
        }
    }
    else 
    {
        alert('Click a point first.');
    }
}

2. Obter o valor máximo de dígitos, para max correto do país.

Eu inclui no dicionário countries em def.js a chave maxLength para indicar a quantidade máxima de dígitos em cada base. Porém, é desnecessário. Na base 32nvu não sabemos a quantidade de dígitos máxima (a não ser que se inclua no retorno do decode). A quantidade máxima de dígitos depende da cobertura e do overlay.

Repare que na minha proposta, considero o caso do código ter pelo menos dois dígitos para ser possível reduzir 1. caso contrário é exibida mensagem.

O caso de código com mais dígitos do que o permitido já é tradado internamente pela api. Nessa situação o código é truncado e decodificado. Internamente é fácil fazer pois convertemos para base 16h, removendo o encurtamento do código. Nessa situação, gastaremos uma requisição. Essa requisição pode ser evitada, mas precisa gastar tempo para retornar no decode a quantidade máxima de dígitos na respectiva célula da cobertura ou overlay.

3. No geocódigo, melhorar a mensagem do on-mouse-over e incluir OnClick para centrar o ponto no geocodigo, caso o mapa tenha sido deslocado.

Manipulando fielddecode e usando getDecode() não é necessário OnClick. A interface já se comporta dessa maneira. Comportamento pode ser desabilitado no checkbox Disable zoom-click.

2. Incluir no Javascript informação sobre os limites e limitar removendo "+" ou removendo "-" conforme o último nível tenha sido alcançado.

Remover o '+' depende do decode retornar o tamanho máximo de um código na respectiva célula de cobertura ou overlay.

Eu não removeria '-' ou '+'. Apenas retornaria mensagem na situações:

  1. Se código em fielddecode tiver tamanho 1 impede de reduzir;
  2. Se fielddecode + 7 for maior que o permitido a api vai retornar a flag truncated_code e será exibida mensagem.
IgorEliezer commented 1 year ago

Possível efeito colateral em células de fronteira

Deixa-me avisar de algo relevante. De tempos em tempos eu escolho uma região do estado de São Paulo e faço correção de divisas de município. As diferenças são bem grande, e podem a chegar a 800 m.

Um exemplo:

image Acima é divisas do OSM comparadas com as cartas topográficas do Instituto Geográfico e Cartográfico do Estado de São Paulo, que é o órgão oficial para delimitação de divisas municipais e distritais, baseado na lei estadual que cria e descreve as jurisdições do estado. As cartas estão na escala 1:10.000 (1 cm = 100 m), topografia de 5 m de equidistância vertical {1}, produzidas nos anos 1970-80.

Por que isso acontece:

1) O IBGE tem os seus mapas municipais elaborados em cartas na escala 1:150.000 (1 cm = 150), com topografia de 25 m no eixo vertical, produzida também nos anos 1970-80.

2) Provavelmente as divisas vieram de um shapefile do IBGE de divisas com um grau de generalização {2}. O que já tinha um grau de generalização, o import simplificou os polígonos mais ainda.

A comunidade OSM Brasil está ciente que as divisas têm problema. Ver EDIT abaixo.

3) As divisas dos mapas do IBGE são ruins? Não. São tão precisas quanto ao do IGC-SP? Não; obviamente, 15 vezes menos, mas serviram muito bem para o propósito de servir de base para os censos e cadastrar localidades. Então mesmo que se use um shapefile do IBGE com zero de perdas, ainda assim é uma aproximação.

Portanto, sugiro que considerem a possibilidade de que um quadrante do OSMcodes que hoje esteja num município, na realidade deveria estar em outro porque a divisa está errada ou excessivamente simplificada.

Notas: {1} -- "equidistância vertical" é termo técnico para a distância no eixo vertical (y) de uma curva de nível para outra. {2} -- "generalização cartográfica" é o termo técnico para simplificação de geometrias por causa da escala.

Outros exemplos:

Div1 Div2 Divisa SP-MG


EDIT:

A Comunidade OSM Brasil está fazendo uma análise e revisão das divisas de municípios no país. Tem-se achado muita diferença entre as divisas mapeadas e as do IBGE. As diferenças podem passar de 80 a 100% de área. E talvez as divisas do IBGE podem estar erradas também. Aqui estão os resultados: http://gpsutil.com/DifLimitesMunicipaisOSMxIBGE.html

0e1 commented 1 year ago

Deixa-me avisar de algo relevante. De tempos em tempos eu escolho uma região do estado de São Paulo e faço correção de divisas de município. As diferenças são bem grande, e podem a chegar a 800 m.

Teoricamente, a grade logística seria definida pelo município, ou teria envolvimento dele. Momento onde questões de limites surgiriam. Consequentemente, existindo necessidade, alterações seriam feitas nas relações no OSM e a geometria seria preservada em um repositório stable.

Sem envolvimento, está sujeito ao momento em que a geometria foi obtida do OSM. Coberturas possuem alguma resiliência mas variações de area podem exigir novas células, que usariam as sobras da cobertura (que podem ter até 32 células).

Numa situação onde aconteceu um ajuste no limite, um código que fosse RXYZ no município A antes da alteração no limite, seria SXYZ num município B após a alteração, podendo ser R=S, caso a célula de cobertura possua o mesmo índice na indexação dos municípios.

0e1 commented 1 year ago

@IgorEliezer por favor testar o funcionamento dos botões amarelos (- +) . Eles devem aumentar ou diminuir o tamanho do código sem recarregar a página. Devem ainda, truncar código ou impedir a diminuição de código que tiver somente um dígito. Mensagem devem ser exibidas nesses casos. Avalie se está intuito e as mensagens exibidas fazem sentido.

Lembrar que esses botões só estão disponíveis na interface logística. Testar em https://test.osm.codes.

IgorEliezer commented 1 year ago

@0e1 Ok. Está funcionando.