Considerar tambem corte para os hexagonos de destino na correcao do snap

[kauebraga]

Atualmente, o critério para identificar se um hexágono eh problemático eh quando este não consegue acessar mais de 10 outros hexágonos de bicicleta em 90 minutos. Acabei de perceber que o problema pelo destino também pode acontecer: hexágonos que não são acessados por outros muito hexágonos. E esse segundo problema pode acontecer sem o primeiro acontecer. Isso pode implicar por ex. em valores extremos do BFCA.

[rafapereirabr]

Pensando aqui se faria sentido mudarmos a estratégia de identificar se um hexágono é problemático, ja que poderíamos usar a nova função r5r::find_snap(). O que voces acham? Marcando @mvpsaraiva na conversa.

[mvpsaraiva]

Faz sentido repensar a estratégia sim, provavelmente incluindo o r5r::find_snap() em um dos passos iniciais. Mas acho que, mesmo assim, ainda vamos ter alguns hexágonos com os problemas que o @kauebraga mencionou no primeiro post.

Também temos que pensar na estratégia pra lidar com os resultados do r5r::find_snap(). Por exemplo, podemos marcar como problemáticos hexágonos que a distância do snap for maior que certo certo threshold (300m... 500m... ?) ou então que as coordenadas do snap cairem fora da área do hexágono. A questão é o que fazer com eles... não podemos simplesmente remover da análise pq eles podem ter população ou empregos associados. Talvez o melhor seja simplesmente marcar como problemáticos e, mais pro final do processo, fazer aquela atribuição dos tempos de viagem pela média dos vizinhos.

[kauebraga]

Eu acho que eh isso que o @mvpsaraiva falou. Eu suspeito que a principal causa desses hexágonos problemáticos tenha relação com os dados do OSM em si, principalmente as tags que são relacionadas as vias de cada local. Por exemplo, peguei um localidade problemática e observei que a via de entrada do local tava com allowed access pra somente 'destination'. Mas seria interessante pra ver se o R5 lida com isso de forma diferente do OTP.

[kauebraga]

Done.