[Talk-br] Importar X mapear

Segunda Junho 10 18:09:17 UTC 2013

Na verdade esse post no "Worst of OSM" é quase cômico, justamente pela
razão que você apontou. Bem, em Brasília estamos esbarrando nas
barreiras legais, só depois que podemos pensar em importação (e ver se
é possível e se produzirá resultados interessantes). Postei uma
questão sobre isso no fórum na seção "Questions and Answers" e estou
aguardando uma resposta.

Mas no fundo eu acho que seria um grande desperdício que um usuário
tenha se dedicado tanto a mapear a cidade toda (provavelmente numa
época em que não conhecia o OSM) e que os dados não possam ser
aproveitados por restrições legais.

2013/6/10 Vitor George <vitor.george em gmail.com>:
> Fernando,
>
> Comentei de Brasília porque foi mencionada uma possível importação e toda
> importação precisa atender uma série de condições para ser feita:
>
> http://wiki.openstreetmap.org/wiki/Import/Guidelines
>
> Concordo contigo que depende muito da qualidade dos dados.
>
> Eu, pessoalmente, não gosto de fazer importações pelos motivos que falei.
> Mas não vou me opor se os dados forem de boa qualidade e não prejudiquem o
> trabalho de outras pessoas.
>
> Vitor
>
>
> 2013/6/10 Fernando Trebien <fernando.trebien em gmail.com>
>>
>> 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)
>>
>> _______________________________________________
>> 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)