Propor estrutura em listas pro munis df

kauebraga commented 3 years ago

Considerar queo shape do municipio e o modo de transporte de cada cidade pode mudar a cada ano

mvpsaraiva commented 3 years ago

Fiz um gist com uma proposta inicial:

https://gist.github.com/mvpsaraiva/7a929bd1415d35899990bcad52ad47fa

rafapereirabr commented 3 years ago

Otimo! Só tem que acomodar agora que as algumas cidades são na verdades RMs com varios municipio.

mvpsaraiva commented 3 years ago

Otimo! Só tem que acomodar agora que as algumas cidades são na verdades RMs com varios municipio.

Isso... nesse caso, a ideia é adicionar uma linha em metro_munis pra cada município da RM, com o code_muni de cada município. Aí, todos municípios da RM ficam indexados pelo abrev_muni do município principal.

Inclusive, um município pode entrar sozinho em um ano e como parte de uma RM em outro.

kauebraga commented 3 years ago

Exato. Eu acho que é essa a estrutura. Eu acho também que vale a pena colocar tudo dentro uma lista principal, pra não poluir tanto a aba de data.frames. O mais chato vai ser substituir o munis_df em cada um dos scripts do projeto.

Dentro de uma lista, eu imagino que pra extrair os code_muni necessários a partir de um abrev_muni seria mais ou menos assim (assumindo que vão ter argumentos sigla_muni e ano na função):

codes_muni <- munis_df$metro_munis[abrev_muni == sigla_muni, ano == ano]$code_muni %>% stringr::str_split(",") %>% unlist()

Esse passo só vai ser necessário nas funções de variáveis demográficas/uso do solo e na criação dos hexágonos, acho. Depois, vai ser tudo baseado no sigla_muni que já vai tá com todos os municípios certinho. Também vai ser necessário fazer algumas modificações na parte do modo de transporte, mas isso vai ser mais no script de roteamento.

Vou fazer as modificações e dar um push no código pra gente discutir na terça. Mando antes pro @mvpsaraiva dar uma olhada!

rafapereirabr commented 3 years ago

Joia. Eu tinha pensado em fazer algo assim, mas me digam se tem uma maneira melhor de fazer isso:

library(sf)
library(geobr)
library(data.table)

# get metro areas
metro <- read_metro_area()

# metro areas in the project
metro_goi <- subset(metro, name_metro %like% 'Goiânia') 

# list of munis of our metro areas
df_metro <- setDT(metro_goi)[, .(list_code_muni = paste0(code_muni, collapse = '|')), by=name_metro ]

# test query
munis <- read_municipality()
query <- subset(munis, code_muni %like% df_metro$list_code_muni)

Tables teste essa alternativa usando list(), mas nao deu certo

df_metro2 <- setDT(metro_goi)[, .(list_code_muni = list(code_muni)), by=name_metro ]

subset(munis, code_muni %in% df_metro2$list_code_muni)
subset(munis, code_muni %like% df_metro2$list_code_muni)

mvpsaraiva commented 3 years ago

Joia. Eu tinha pensado em fazer algo assim, mas me digam se tem uma maneira melhor de fazer isso:

Eu acho que a lista de municípios na RM tem que ser feita manualmente, pq não necessariamente o GTFS vai cobrir a RM inteira do jeito q ela vem do geobr. Podemos usar esse código pra pegar a lista de cidades, mas depois temos q conferir pra ver se vai ser necessário remover ou adicionar alguma cidade.

kauebraga commented 3 years ago

Pronto. Deem uma olhada aqui: https://github.com/ipeaGIT/acesso_oport/commit/d1d615a875ff10a56eec582e76e32305e47dabc4

mvpsaraiva commented 3 years ago

Fiz um Pull Request do primeiro script. Agora tem que ir atualizando todos os outros scripts pra acessar o munis_df de dentro do munis_list.

kauebraga commented 3 years ago

Podemos fechar isso? Acho que agora só falta acertar e substituir o munis_list nos códigos.

rafapereirabr commented 3 years ago

Vocês ja implementaram as adaptacoes nos códigos do capitulo 1 para checar se a nova estrutura está funcionando?

kauebraga commented 3 years ago

Deve estar tudo funcionando agora. Detalhes:

Ainda não rodei as mudanças que fiz no script da RAIS pq acho melhor esperar a nova base de geocode;
Falta baixar a parte de topografia da RM de Goiânia (essa é com vc, @mvpsaraiva) e então organizar nas pastas

mvpsaraiva commented 3 years ago

Falta baixar a parte de topografia da RM de Goiânia (essa é com vc, @mvpsaraiva) e então organizar nas pastas

Essa eu tive que conferir, pois não lembrava direito. Já baixei a topografia da RM de Goiânia. O arquivo já está salvo na pasta topografia3 (acho que podemos apagar as pastas topografia e topografia2). O arquivo .pbf da malha viária também já cobre a RM inteira.

kauebraga commented 3 years ago

Então o arquivo de topografia de goi que tá lá na topografia3 é da RM de Goiânia, né? Vou deletar todas as pastas desnecessárias e passar essa pasta topografia3 pro data-raw (já que são dados não tratados)

mvpsaraiva commented 3 years ago

Então o arquivo de topografia de goi que tá lá na topografia3 é da RM de Goiânia, né? Vou deletar todas as pastas desnecessárias e passar essa pasta topografia3 pro data-raw (já que são dados não tratados)

Ok!

kauebraga commented 3 years ago

Acho que esse commit https://github.com/ipeaGIT/acesso_oport/commit/8429a29dd2247b288ee07c05647f21139b919857 termina de fazer a adaptação. Uma coisa pra discutir é como a gente vai fazer com a base final. Hoje, a gente disponibiliza a base final com todas as informações do município: nome, uf, sigla e código do município. Com a incorporação dos munis das RM, como ficaria o código do município? Eu vejo duas opções:

Deletar a coluna do código: nesse caso, acho que não seria ideal pq tiraria uma informação importante caso a pessoa queira fazer um join com outra base (pra pegar o shape do município, por ex);
Colocar o código real do município daquele hexágono: nesse caso, o código do muni seria como está hoje, com a diferença de que faríamos a identificação quando o hex está em um muni da RM, e colocariamos o código do muni da RM. Nesse caso, poderiam ter mais de um code_muni para o mesmo sigla_muni;

ipeaGIT / acesso_oport

Propor estrutura em listas pro munis df #87