[Talk-br] Importação de aglomerados subnormais (aprox. vilas e favelas) do IBGE

Fernando Trebien fernando.trebien em gmail.com
Segunda Junho 10 01:18:38 UTC 2013


Hm você reuniu várias informações cuja importação automática seria
possível e deu até as instruções para Ubuntu (ótimo, eu uso Debian
:D). Mas a princípio o primeiro objetivo seria importar os conjuntos
"Lim_Bairro" e "Quadras", certo? Outros que me parecem possíveis são
"BACIAS_HIDROGRAFICAS" (como natural=wetland) e "Lim_RA" se estas
regiões forem algo como um nível administrativo acima dos bairros
(cada região administrativa contém um conjunto de bairros e cada
bairro pertence exatamente a 1 região administrativa). Talvez alguns
dos conjuntos que estão sem descrição possam ser importados também,
como o "SUB_BACIAS_HIDROGRAFICAS". Os conjuntos "BACIAS_AEREAS",
"Lim_CRE", "Lim_DCO" e "Lim_RegFisc" provavelmente seriam fáceis, não
sei se seriam interessantes (pois são bastante especializados, não há
tags no wiki que se aplicam a essas informações e não lembro de ter
visto discussões sobre esses dados em fóruns e listas de e-mail).
Talvez pudessem usar "place=locality" ou o esquema da relação "region"
e uma relação "master" identificando cada conjunto.

Alguns detalhes: o resultado da importação dos bairros seria um
conjunto de nós com "place=suburb" e várias relações agrupando as
fronteiras, uma por bairro. As fronteiras teriam a tag
"boundary=administrative" só porque sem isso elas aparecem direito no
Potlatch; tive problemas de usuários excluindo essas fronteiras aqui
em Porto Alegre por engano por culpa desse editor. Em alguns lugares
as fronteiras podem acabar coincidindo com ruas. Tem gente que prefere
usar a rua como fronteira, e pra isso seria necessário fazer ajustes
manuais após a importação. Usar as ruas como fronteiras economiza
espaço na base, facilita a edição e fica bonito no mapa, mas
iniciantes que não entendem como funcionam as relações podem
eventualmente excluir uma rua (e o Potlatch, ao contrário do JOSM, não
avisa quando são parte de uma relação), depois incluir ela de novo e
não atualizar a relação (sem nem saber que deviam fazer isso).

2013/6/9 Arlindo Pereira <openstreetmap em arlindopereira.com>:
> Ops, faltou o link:
> http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/RJ/Rio_de_Janeiro/Import_IPP
>
> Em 09/06/2013 21:46, "Arlindo Pereira" <openstreetmap em arlindopereira.com>
> escreveu:
>
>> Não, me referia às fronteiras de bairros aqui do Rio de Janeiro (desculpe,
>> relendo aqui não fui nada claro :-P). Cheguei a montar no wiki uma página
>> com as informações, mas como na época (2009) era praticamente só eu aqui no
>> Rio dei uma desanimada.
>>
>> []s
>>
>> Em 09/06/2013 21:24, "Fernando Trebien" <fernando.trebien em gmail.com>
>> escreveu:
>>>
>>> Você quer dizer as fronteiras com outros países? Eu comecei a fazer
>>> isso na fronteira com o Uruguai a partir dos dados do LNCC
>>> (http://info.lncc.br) mas parei logo no começo por 2 motivos: foi
>>> exatamente quando começamos a discutir sobre classificação, e também
>>> acabei me envolvendo numa discussão com um uruguaio sobre como definir
>>> a tag "name" nos elementos compartilhados da fronteira (como rios)
>>> (chegamos a uma solução interessante e justa: além das tags "name:pt"
>>> e "name:es", a tag "name" teria ambos os nomes separados por " / ",
>>> como é feito na Europa, mas em ordem alfabética, não privilegiando
>>> assim nenhuma das duas línguas).
>>>
>>> Eu fui fazendo isso manualmente, primeiro pra ver se os dados tinham
>>> qualidade superior aos atuais (lembro que o contorno da fronteira veio
>>> da base de dados da CIA) e depois porque eu queria adicionar os marcos
>>> (boundary stones) e já fui aproveitando para melhorar a posição
>>> comparando com a imagem de satélite.
>>>
>>> Em alguns lugares os dados do LNCC estavam melhores (como sobre a
>>> Lagoa dos Patos), em outros a mudança não valia à pena (eram
>>> praticamente iguais).
>>>
>>> Nunca cheguei a fazer uma conflação automática, mas poderia começar a
>>> estudar como se faz com o JOSM. Você acha que o LNCC é uma boa fonte?
>>> Haveria outra melhor?
>>>
>>> 2013/6/9 Arlindo Pereira <openstreetmap em arlindopereira.com>:
>>> > Pode ser. Os dados do IPP são bem completos mas cobrem apenas a
>>> > capital. Uma
>>> > forma simples de fazer poderia ser abrir o arquivo osm no JOSM, excluir
>>> > as
>>> > comunidades dentro da capital, subir esses dados, criar uma coleção com
>>> > eles
>>> > e depois, num segundo momento, verificar se há alguma comunidade não
>>> > mapeada
>>> > nos dados do IPP que o IBGE tenha.
>>> >
>>> > Off-topic: precisamos de uma força com a importação das fronteiras,
>>> > você
>>> > poderia ajudar? Eu há alguns anos comecei a fazer segmento por
>>> > segmento, mas
>>> > não terminei. Poderíamos excluir estes dados e fazer de uma só vez.
>>> >
>>> > Em 08/06/2013 00:24, "Fernando Trebien" <fernando.trebien em gmail.com>
>>> > escreveu:
>>> >
>>> >> Hehe, aqui em Porto Alegre temos a "Vila Cachorro Sentado" (vai
>>> >> entender). Bem, colocar um prefixo é uma sugestão para diferenciar dos
>>> >> condomínios. Já que está tudo numa coleção, eu poderia acrescentar o
>>> >> prefixo facilmente com o JOSM se você quiser.
>>> >>
>>> >> Você teria interesse numa importação dos dados do IBGE do estado do
>>> >> RJ? Pode ser que complemente a informação do IPP. Acho que eu poderia
>>> >> resolver as "duplicações" manualmente, dá um certo trabalho mas pode
>>> >> ser interessante se você não tiver mapeado comunidades além das que
>>> >> estão na cidade do Rio.
>>> >>
>>> >> 2013/6/6 Arlindo Pereira <openstreetmap em arlindopereira.com>:
>>> >> > Legal!
>>> >> >
>>> >> > Por enquanto eu não poderia ajudar muito, uma vez que ainda não
>>> >> > consegui
>>> >> > importar todos os dados do IPP mesmo tendo começado há 4 anos atrás
>>> >> > (!),
>>> >> > mas
>>> >> > acho válido usar todo dado público no nosso mapa.
>>> >> >
>>> >> > Aqui no Rio eu deixei o nome original mesmo. Tem uns nomes muito
>>> >> > curiosos,
>>> >> > tipo "Vala do Sangue":
>>> >> >
>>> >> >
>>> >> > http://www.openstreetmap.org/?minlon=-43.7040901184082&minlat=-22.9206295013428&maxlon=-43.6957855224609&maxlat=-22.9115943908691
>>> >> >
>>> >> > []s
>>> >> >
>>> >> > 2013/6/6 Fernando Trebien <fernando.trebien em gmail.com>
>>> >> >>
>>> >> >> Pessoal,
>>> >> >>
>>> >> >> O IBGE possui um cadastro do que ele chama de "aglomerados
>>> >> >> subnormais"
>>> >> >> (populações de renda extremamente baixa) que na grande maioria das
>>> >> >> vezes são vilas e favelas. Há algum tempo eu importei esses dados
>>> >> >> em
>>> >> >> Porto Alegre manualmente (com ajustes) e agora me pediram para
>>> >> >> fazer o
>>> >> >> mesmo em BH. O cadastro é acessível aqui:
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> http://www.ibge.gov.br/home/estatistica/populacao/censo2010/aglomerados_subnormais/aglomerados_subnormais_tab_base_zip.shtm
>>> >> >>
>>> >> >> Como é necessário transformar alguns dados (tirar tags que estão em
>>> >> >> multipolígonos e passá-las para os próprios polígonos), acabei
>>> >> >> fazendo
>>> >> >> um script, e com isso há a flexibilidade de automatizar algumas
>>> >> >> outras
>>> >> >> coisas, como a formatação dos nomes.
>>> >> >>
>>> >> >> Já que foi feito esse script, eu pergunto: alguém mais tem
>>> >> >> interesse
>>> >> >> nessa importação? Alguém prefere que não seja feita na sua região?
>>> >> >> Sei
>>> >> >> que na cidade do RJ seria um pouco mais complicado uma importação
>>> >> >> automática porque lá as comunidades já foram importadas de outra
>>> >> >> fonte. Mas não sei de outros lugares que tenham feito o mesmo.
>>> >> >>
>>> >> >> Os dados importados seriam um polígono para cada comunidade,
>>> >> >> contendo
>>> >> >> uma tag "landuse=residential", uma tag "source=IBGE" e uma tag
>>> >> >> "name"
>>> >> >> devidamente formatada. Como "landuse=residential" também é usada
>>> >> >> para
>>> >> >> condomínios residenciais, o que eu fiz em Porto Alegre (e sugeri
>>> >> >> para
>>> >> >> BH) foi acrescentar um prefixo padrão (que aqui foi "Vila") para
>>> >> >> deixar claro para os usuários do mapa. Em alguns poucos casos foi
>>> >> >> necessário corrigir isso depois aqui em Porto Alegre (algumas das
>>> >> >> comunidades eram chamadas de "loteamentos" e não "vilas"). Talvez
>>> >> >> esse
>>> >> >> prefixo varie por cidade ou mesmo estado. Para ter uma idéia de
>>> >> >> como
>>> >> >> os nomes estão vindo, postei a lista de nomes em MG no fórum
>>> >> >> (http://forum.openstreetmap.org/viewtopic.php?id=21401).
>>> >> >>
>>> >> >> Como funciona esse processo: após baixar o KMZ do IBGE, abre-se o
>>> >> >> arquivo no JOSM com o plugin OpenData, faz-se a simplificação dos
>>> >> >> polígonos (para diminuir a quantidade de dados) e o resultado é
>>> >> >> salvo
>>> >> >> num arquivo .osm (que é um arquivo XML). O script que eu fiz lê e
>>> >> >> modifica esse XML para passar as tags "name" que estão em relações
>>> >> >> do
>>> >> >> tipo "multipolígo" para o único polígono contido na relação. A
>>> >> >> relação
>>> >> >> do multipolígono então é excluída, pois não é necessária. Para cada
>>> >> >> um
>>> >> >> desses polígonos também existe um nó que representa o seu centro, e
>>> >> >> esse nó também é excluído, pois não é necessário. Nada é feito com
>>> >> >> multipolígonos que contenham vários membros ou com nós cujo nome
>>> >> >> não
>>> >> >> corresponde ao de um desses polígonos, então algumas poucas
>>> >> >> correções
>>> >> >> manuais são necessárias antes de fazer o commit do changeset.
>>> >> >>
>>> >> >> --
>>> >> >> Fernando Trebien
>>> >> >> +55 (51) 9962-5409
>>> >> >>
>>> >> >> "The speed of computer chips doubles every 18 months." (Moore's
>>> >> >> law)
>>> >> >> "The speed of software halves every 18 months." (Gates' law)
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> Talk-br mailing list
>>> >> >> Talk-br em openstreetmap.org
>>> >> >> http://lists.openstreetmap.org/listinfo/talk-br
>>> >> >
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > Talk-br mailing list
>>> >> > Talk-br em openstreetmap.org
>>> >> > http://lists.openstreetmap.org/listinfo/talk-br
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Fernando Trebien
>>> >> +55 (51) 9962-5409
>>> >>
>>> >> "The speed of computer chips doubles every 18 months." (Moore's law)
>>> >> "The speed of software halves every 18 months." (Gates' law)
>>> >>
>>> >> _______________________________________________
>>> >> Talk-br mailing list
>>> >> Talk-br em openstreetmap.org
>>> >> http://lists.openstreetmap.org/listinfo/talk-br
>>> >
>>> >
>>> > _______________________________________________
>>> > Talk-br mailing list
>>> > Talk-br em openstreetmap.org
>>> > http://lists.openstreetmap.org/listinfo/talk-br
>>> >
>>>
>>>
>>>
>>> --
>>> Fernando Trebien
>>> +55 (51) 9962-5409
>>>
>>> "The speed of computer chips doubles every 18 months." (Moore's law)
>>> "The speed of software halves every 18 months." (Gates' law)
>>>
>>> _______________________________________________
>>> Talk-br mailing list
>>> Talk-br em openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-br
>
>
> _______________________________________________
> Talk-br mailing list
> Talk-br em openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-br
>



-- 
Fernando Trebien
+55 (51) 9962-5409

"The speed of computer chips doubles every 18 months." (Moore's law)
"The speed of software halves every 18 months." (Gates' law)



Mais detalhes sobre a lista de discussão Talk-br