Calibrando numero aproximoado

[rafapereirabr]

contexto

Quando o numero do endereço de input não está presente na base de busca (cnefe), nós fazemos uma aproximação. Atualmente, essa aproximação é feita como um média das coordenadas do cnefe poderada pela diferença entre o numero de input e os numeros presentes no cnefe. Os resultados são razoáveis.

problema

No entanto, seria importante dar um peso maior para diferenças pequenas. Por exemplo, se o numero de input é 5 e o cnefe tem um numero 8, as coordenadas do ponto 8 deveriam ter um peso maior do que do ponto com número 100, por exemplo. Atualmente, o peso de diferenças grandes é descontado, mas apenas de maneira linear. Seria bom colocar um expoente de decaimento para dar ainda mais peso para numeros proximos.

solucao

O codigo do pacote desta operação é todo em {duckdb} e SQL. Mas para ilustrar a problema, apresento abaixo o codigo em R mesmo. O calculo atual é feito dessta maneira.

output <- df |>
  group_by(id) |>
  summarize(
    numero_input = first(numero_input),
    lat = sum((1/abs(numero_input - numero) * lat)) / sum(1/abs(numero_input - numero)),
    lon = sum((1/abs(numero_input - numero) * lon)) / sum(1/abs(numero_input - numero))
    )

Minha sugestão é elevar o a difença ao cubo. Assim:

output <- df |>
  group_by(id) |>
  summarize(
    numero_input = first(numero_input),
    lat = sum((1/abs(numero_input - numero)^3 * lat)) / sum(1/abs(numero_input - numero)^3),
    lon = sum((1/abs(numero_input - numero)^3 * lon)) / sum(1/abs(numero_input - numero)^3)
    )

reprex

Aqui um reprex que gera um exemplo dentro da funçao check_approx(). A função recebe um numero_input e um expoente expp. Quando expp = 1, o resultado da função é exatamente o comportamento do geocodebr hoje em dia.

library(dplyr)
library(sf)
library(sfheaders)
library(arrow)
library(mapview)

tudo <- geocodebr::listar_dados_cache()
tudo <- tudo[7]

cnefe <- arrow::open_dataset( tudo ) |>
  dplyr::filter(estado == 'RJ') |>
  dplyr::filter(municipio == "RIO DE JANEIRO") |>
  dplyr::filter(logradouro == "AVENIDA MINISTRO IVAN LINS") |>
  dplyr::collect()


check_approx <- function(numero_input, expp){

input <- data.frame(
  id = 1,
  logradouro = 'AVENIDA MINISTRO IVAN LINS',
  numero_input = numero_input,
  localidade = "BARRA DA TIJUCA",
  cep = '22620-110'
  )

df <- left_join(input, cnefe, by = c('logradouro', 'localidade', 'cep'))


output <- df |>
  group_by(id) |>
  summarize(
    numero_input = first(numero_input),
    lat = sum((1/abs(numero_input - numero)^expp * lat)) / sum(1/abs(numero_input - numero)^expp),
    lon = sum((1/abs(numero_input - numero)^expp * lon)) / sum(1/abs(numero_input - numero)^expp)
    )

sf_cnefe <- sfheaders::sf_point(
  obj = cnefe,
  x = 'lon',
  y = 'lat',
  keep = TRUE
)

sf_output <- sfheaders::sf_point(
  obj = output,
  x = 'lon',
  y = 'lat',
  keep = TRUE
)


sf::st_crs(sf_cnefe) <- 4674
sf::st_crs(sf_output) <- 4674

mapp <- mapview::mapview(sf_cnefe, zcol='numero') +
  mapview(sf_output, col.regions = "red")

return(mapp)
}

check_approx(numero_input = 6, expp = 1)
check_approx(numero_input = 6, expp = 3)

check_approx(numero_input = 760, expp = 1)
check_approx(numero_input = 760, expp = 3)

check_approx(numero_input = 400, expp = 1)
check_approx(numero_input = 400, expp = 3)

Os exemplos acima mostram duas coisas.

1. A localização do ponto aproximado é muito mais proxima do correto quando se usa expp = 3,
2. Essa diferença observada em (1) é mais pronunciada quando o input é um numero proximo do inicio ou do fim da rua. Para um input com numero proximo do numero mediano, o expp praticamente nao afeta o resultado.

[rafapereirabr]

Essa aqui foi a sugestão do @antrologos, de implementar uma interpolacao linear. Agora eu preciso ajustar o codigo para nosso caso, e testar se isso afeta muito a performance de tmepo de processamento.

tudo <- geocodebr::listar_dados_cache()
tudo <- tudo[7]

cnefe <- arrow::open_dataset( tudo ) |>
  dplyr::filter(estado == 'RJ') |>
  dplyr::filter(municipio == "RIO DE JANEIRO") |>
  dplyr::filter(logradouro == "AVENIDA MINISTRO IVAN LINS") |>
  dplyr::collect()


input <- data.frame(
  id = 1,
  logradouro = 'AVENIDA MINISTRO IVAN LINS',
  numero_input = 5,
  localidade = "BARRA DA TIJUCA",
  cep = '22620-110'
)


df <- left_join(input, cnefe, by = c('logradouro', 'localidade', 'cep'))

con <- geocodebr:::create_geocodebr_db()


duckdb::dbWriteTable(con, "data_frame_ruas", df, overwrite = TRUE, temporary = TRUE)


approximacao_sql <- function(numero_input, con) {
  query <- sprintf("
    WITH bounds AS (
      SELECT 
        (SELECT MIN(numero) FROM data_frame_ruas) AS min_num,
        (SELECT MAX(numero) FROM data_frame_ruas) AS max_num,
        (SELECT MAX(numero) FROM data_frame_ruas WHERE numero <= %f) AS lower_num,
        (SELECT MIN(numero) FROM data_frame_ruas WHERE numero >= %f) AS upper_num
    ),
    values_cte AS (
      SELECT 
        (SELECT lat FROM data_frame_ruas ORDER BY numero ASC LIMIT 1) AS min_lat,
        (SELECT lon FROM data_frame_ruas ORDER BY numero ASC LIMIT 1) AS min_lon,
        (SELECT lat FROM data_frame_ruas ORDER BY numero DESC LIMIT 1) AS max_lat,
        (SELECT lon FROM data_frame_ruas ORDER BY numero DESC LIMIT 1) AS max_lon,
        (SELECT lat FROM data_frame_ruas WHERE numero = (SELECT MAX(numero) FROM data_frame_ruas WHERE numero <= %f)) AS lower_lat,
        (SELECT lon FROM data_frame_ruas WHERE numero = (SELECT MAX(numero) FROM data_frame_ruas WHERE numero <= %f)) AS lower_lon,
        (SELECT lat FROM data_frame_ruas WHERE numero = (SELECT MIN(numero) FROM data_frame_ruas WHERE numero >= %f)) AS upper_lat,
        (SELECT lon FROM data_frame_ruas WHERE numero = (SELECT MIN(numero) FROM data_frame_ruas WHERE numero >= %f)) AS upper_lon
    ),
    interp AS (
      SELECT 
        b.min_num, b.max_num, b.lower_num, b.upper_num,
        v.min_lat, v.min_lon, v.max_lat, v.max_lon,
        v.lower_lat, v.lower_lon, v.upper_lat, v.upper_lon
      FROM bounds b, values_cte v
    )
    SELECT
      CASE
        WHEN %f <= min_num THEN min_lat
        WHEN %f >= max_num THEN max_lat
        WHEN lower_num = upper_num THEN lower_lat
        ELSE lower_lat + ((%f - lower_num) * (upper_lat - lower_lat)) / (upper_num - lower_num)
      END AS lat,
      CASE
        WHEN %f <= min_num THEN min_lon
        WHEN %f >= max_num THEN max_lon
        WHEN lower_num = upper_num THEN lower_lon
        ELSE lower_lon + ((%f - lower_num) * (upper_lon - lower_lon)) / (upper_num - lower_num)
      END AS lon
    FROM interp
    LIMIT 1;
  ",
                   numero_input, numero_input,           # For lower_num and upper_num in bounds
                   numero_input, numero_input, numero_input, numero_input,  # For lower_lat, lower_lon, upper_lat, upper_lon in values_cte
                   numero_input, numero_input, numero_input,  # For lat: conditions and numerator in interpolation
                   numero_input, numero_input, numero_input   # For lon: conditions and numerator in interpolation
  )
  
  res <- DBI::dbGetQuery(con, query)
  return(as.matrix(res))
}


approximacao_sql(100, con)

[gabriel-almeida]

Andei testando esse caso dos números com uma ajuda do ChatGPT e parece que o Rafael acertou na intuição, a exponenciação por 3 ou 2 já ajuda bastante. Testei várias coisinhas diferentes, e coloquei aqui uma tabela com alguns achados. Eu amostrei 10.000 logradouros da tabela 'municipio_logradouro_numero_cep_localidade.parquet' do CNEFE e fiz um KFolds (k=5) a nível de logradouro com alguns modelos para avaliar estatísticas da distância de Haversine em metros entre os pontos preditos e o pontos de teste daquele "fold". A tabela tem as médias agrupadas por modelo dessas estatísticas.

algoritmo	dist_mean	dist_median	dist_std	dist_q95	dist_max	dist_in	dist_ood
segment_knn	72.5747	56.139	57.5314	151.52	176.073	67.1049	112.813
segment	72.7762	55.784	58.5341	153.196	178.295	67.1049	116.129
idw3	73.092	56.6326	57.8887	152.492	177.278	68.2362	108.392
idw2	73.4805	58.0777	55.6574	149.61	173.061	68.1354	112.526
knn	73.5386	58.3691	55.4883	149.349	172.92	68.181	112.813
idw4	74.2283	56.9333	60.1384	156.652	182.621	69.5943	108.649
idw5	74.2283	56.9333	60.1384	156.652	182.621	69.5943	108.649
idw1	87.1655	74.3513	54.7833	161.574	181.799	80.277	141.329
linear	100.483	91.1408	54.4054	171.428	190.953	94.564	144.188
dummy_median	148.162	135.716	83.3749	256.579	274.981	139.698	217.446
dummy_centroid	150.294	142.538	70.556	240.999	256.508	142.143	216.695

A coluna dist_in representa a média quando os números dos logradouros estão dentro do "range do treinamento" (o modelo não está extrapolando), e dist_ood é fora do range (out of distribution/extrapolação). O idw é a abordagem original, onde os números do final são os exponentes usados no denominador. segment é um modelo que usa um segmento de reta entre os números mais próximos para estimar as lat/longs. KNN é só essa chamada aqui do sklearn: KNeighborsRegressor(n_neighbors=3, weights="distance", algorithm='brute', metric='l1'). Linear é a regressão linear simples. segment_knn é o algoritmo de segmento de reta nos casos internos e o KNN nos casos fora do treinamento (percebi que eles são complementares). Os dummies são baselines usando a mediana e o média dos lat/longs.

Vendo os dados pontualmente, percebi que não adianta muito inventar nenhum método mirabolante porque os dados são bem inconsistentes, nenhum modelo vai conseguir apreender com tanto ruído. A melhor aposta me parece ser realmente algo na linha não-paramétrica. Tem muitos casos com outliers e clusters na base do CNEFE, não sei se é devido à coleta ou ao próprio fenômeno. Amanhã posso mandar alguns prints de tela com os casos específicos.

[rafapereirabr]

Legal ! Eu tô de volta semana que vem e dai a gente conversa sobre isso !Rafael H M Pereira -------- Original message --------From: gabriel-almeida ***@***.***> Date: 3/11/26 16:05 (GMT-05:00) To: ipeaGIT/geocodebr ***@***.***> Cc: Rafael H M Pereira ***@***.***>, Author ***@***.***> Subject: Re: [ipeaGIT/geocodebr] Calibrando numero aproximoado (Issue #36) gabriel-almeida left a comment (ipea/geocodebr#36) Andei testando esse caso dos números com uma ajuda do ChatGPT e parece que o Rafael acertou na intuição, a exponenciação por 3 ou 2 já ajuda bastante. Testei várias coisinhas diferentes, e coloquei aqui uma tabela com alguns achados. Eu amostrei 10.000 logradouros da tabela 'municipio_logradouro_numero_cep_localidade.parquet' do CNEFE e fiz um KFolds (k=5) a nível de logradouro com alguns modelos para avaliar estatísticas da distância de Haversine em metros entre os pontos preditos e o pontos de teste daquele "fold". A tabela tem as médias agrupadas por modelo dessas estatísticas. algoritmo dist_mean dist_median dist_std dist_q95 dist_max dist_in dist_ood segment_knn 72.5747 56.139 57.5314 151.52 176.073 67.1049 112.813 segment 72.7762 55.784 58.5341 153.196 178.295 67.1049 116.129 idw3 73.092 56.6326 57.8887 152.492 177.278 68.2362 108.392 idw2 73.4805 58.0777 55.6574 149.61 173.061 68.1354 112.526 knn 73.5386 58.3691 55.4883 149.349 172.92 68.181 112.813 idw4 74.2283 56.9333 60.1384 156.652 182.621 69.5943 108.649 idw5 74.2283 56.9333 60.1384 156.652 182.621 69.5943 108.649 idw1 87.1655 74.3513 54.7833 161.574 181.799 80.277 141.329 linear 100.483 91.1408 54.4054 171.428 190.953 94.564 144.188 dummy_median 148.162 135.716 83.3749 256.579 274.981 139.698 217.446 dummy_centroid 150.294 142.538 70.556 240.999 256.508 142.143 216.695 A coluna dist_in representa a média quando os números dos logradouros estão dentro do "range do treinamento" (o modelo não está extrapolando), e dist_ood é fora do range (out of distribution/extrapolação). O idw é a abordagem original, onde os números do final são os exponentes usados no denominador. segment é um modelo que usa um segmento de reta entre os números mais próximos para estimar as lat/longs. KNN é só essa chamada aqui do sklearn: KNeighborsRegressor(n_neighbors=3, weights="distance", algorithm='brute', metric='l1'). Linear é a regressão linear simples. segment_knn é o algoritmo de segmento de reta nos casos internos e o KNN nos casos fora do treinamento (percebi que eles são complementares). Os dummies são baselines usando a mediana e o média dos lat/longs. Vendo os dados pontualmente, percebi que não adianta muito inventar nenhum método mirabolante porque os dados são bem inconsistentes, nenhum modelo vai conseguir apreender com tanto ruído. A melhor aposta me parece ser realmente algo na linha não-paramétrica. Tem muitos casos com outliers e clusters na base do CNEFE, não sei se é devido à coleta ou ao próprio fenômeno. Amanhã posso mandar alguns prints de tela com os casos específicos. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>