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.geo...@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.fla...@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.treb...@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 <openstreet...@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.treb...@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 <openstreet...@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.treb...@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@openstreetmap.org >>> >> >> http://lists.openstreetmap.org/listinfo/talk-br >>> >> > >>> >> > >>> >> > >>> >> > _______________________________________________ >>> >> > Talk-br mailing list >>> >> > Talk-br@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@openstreetmap.org >>> >> http://lists.openstreetmap.org/listinfo/talk-br >>> > >>> > >>> > _______________________________________________ >>> > Talk-br mailing list >>> > Talk-br@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@openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-br >> >> >> _______________________________________________ >> Talk-br mailing list >> Talk-br@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-br >> > > > _______________________________________________ > Talk-br mailing list > Talk-br@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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
