Closed MatthieuStigler closed 4 months ago
Hi @MatthieuStigler . Thank you for the heads up. The original data provided by IBGE somes with various issues like this one. One of the benefits of geobr is precisely to get rid of these problems and make a clean version of the data easily available. So thanks for pointing us to this issue. I'll address it in the next round of updates / corrections
great, glad to hear you can address this at the geobr level at least! Thanks for all the good work :-)
for what I could see, doing add_count(muni_code, year) %>% filter(n>1)
on a dataset row-binding all the data-output of mutate(data = map(year, ~geobr::read_municipality(year = ., simplified = TRUE)))
, where years were from 2000 to 2020 (except 2001), this was the only duplicate I found.
Hi @MatthieuStigler . This issue has now been fixed. I'm sorry it took a long time , but I believe this is now fixed for good. Please let me know if the problem persists or if you've found this or other similar issues elsewhere in the package
Oops; Reopening this issue because now there is an issue with column class incompatibility. I'll fix this tomorrow
df <- geobr::read_municipality(year = 2000)
Error in data.table::rbindlist(files, fill = TRUE) : Class attribute on column 8 of item 5 does not match with column 8 of item 1.
fixed
muito obrigado for your great work Rafael!
This problem seems more to be on the source data side than the geobr package, but there is a very strange duplicated 3509908 municipality in 2000. It appears twice:
Cananeia
(no accent) and as very small polygon of ~6 hectaresCananéia
(with accent) and as a more "normal-looking' polygon of 124,420 hectaresIdeally this could be repaired at the source, but if not, it might be good to add a warning in that case? It seems reasonable that the user can expect a unique municipality-year dataset?
Thanks!
Created on 2022-02-08 by the reprex package (v2.0.1)