Isso. Começando com o Lim_Bairro, que é o mais relevante na minha opinião. Deixa o quadras para um outro momento.
O que eu fiz na época foi importar esses segmentos um a um no JOSM criando as relações manualmente, mas não foi uma boa ideia. Se você puder e tiver tempo, pode excluir todas as fronteiras de bairros e importar tudo. Cheguei a criar nós para o nome dos bairros no centro deles, porque percebi que desta forma o mapa renderizado ficava mais interessante. []s Em 09/06/2013 22:19, "Fernando Trebien" <fernando.treb...@gmail.com> escreveu: > 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 <openstreet...@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" <openstreet...@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.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 > > > > > > -- > 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
