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

Fernando Trebien fernando.trebien em gmail.com
Segunda Junho 10 01:20:00 UTC 2013


Corrigindo, "só porque sem isso elas <não> aparecem direito no Potlatch".

2013/6/9 Fernando Trebien <fernando.trebien em gmail.com>:
> 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)



-- 
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