[Talk-br] Importar X mapear

Fernando Trebien fernando.trebien em gmail.com
Segunda Junho 10 17:24:50 UTC 2013


Ih, não vamos misturar os assuntos. Fronteiras são uma coisa, Brasília é outra.

Eu já ouvi algumas pessoas criticando as importações de dados. Eu acho
que depende muito da qualidade dos dados. Se a fonte é boa, por que
não importar? Se a fonte é razoavelmente boa e a informação ainda não
está mapeada, por que não importar? Um mapa com mais informações
(ainda que ligeiramente erradas - a exemplo do Google Maps) ainda é
muito mais útil do que mapa nenhum (ou não ter as informações). Um
mapa mais útil é mais acessado, mais divulgado, e atrai mais
colaboradores.

2013/6/10 Vitor George <vitor.george em gmail.com>:
> Concordo contigo Flávio.
>
> Na minha opinião, o caso de Brasília não é um "pior do OSM". O mapa está
> imcompleto, mas não parece ter erros. Provavelmente alguém mapeou a
> geometria das vias a partir de imagens de satélite, o que é melhor que nada.
> É claro que todos queremos ter o mapa mais detalhado possível, mas isso só
> vai acontecer, em Brasília ou em qualquer lugar, quando houver mais
> mapeadores locais.
>
> Atrair novos mapeadores é difícil e toma tempo, mas é muito melhor do que
> tentar satisfazer a nossa vontade de ver o OSM detalhado em todos os lugares
> fazendo importações. Acho que elas são válidas em poucos casos e se feitas
> de maneira extremamente cuidadosa. De maneira geral prefiro direcionar meus
> esforços a atividades que ajudem a atrair novos mapeadores, ou facilitar a
> vida de quem já mapeia, pois é assim que vamos ter um mapa bom mesmo.
>
> Vitor
>
> 2013/6/10 Flavio Bello Fialho <bello.flavio em gmail.com>
>>
>> O contorno da Lagoa dos Patos está bom porque eu corrigi ele a mão. Mapear
>> não é só importar dados. O traçado manual das linhas sobre imagens de
>> satélite é muito trabalhoso e muito preciso. Gostaria que os colegas se
>> preocupassem menos com volume e mais com qualidade. A importação em massa
>> pode apagar o trabalho de muitas semanas e incentivar usuários dedicados a
>> abandonarem o projeto. Deixem a importação para coisas que ainda não
>> existem, como a hidrografia. Por favor, não desconsiderem o trabalho que já
>> foi feito ou nunca chegaremos a lugar algum.
>>
>> 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
>>
>
>
> _______________________________________________
> 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