Pois é, esta seria a ideia: se der pra usar addr:interpolation "no próprio eixo da via", contendo numeração impar/par (início cf. sentido da via ou critério local).
Creio que pode ajudar mais do que o sistema que tem sido usado atualmente, de adicionar 2 ways paralelos, resultando em 3 ways: eixo; lado esquerdo; lado direito. A primeira questão é: teria que ser proposto no talk-tagging mundial. Só antes poderíamos tentar testar separadamente pra ver como poderia funcionar e adicionar os dados que prefeituras tenham disponíveis. Vantagens: -para tentar agilizar o andamento das numerações de enderço (coisa que é cada vez mais necessária para popularizar o OSM); -evita ter que usar 3 ways para a mesma via e sobrecarregar de dados triplicados; -evita ter que "arrumar" 3 ways se tiver que realinhar alguma via; -evita poluição de ways; -evita problemas de outros mexerem (alterar, arrastar, etc) no way errado ao editar; Problemas eventuais (a verificar como contornar): -se alguém posteriormente fundir ways que estavam numerados em sequência, bagunça a numeração. -talvez uma tag adicional para receber feedback ou correções (pode ser o próprio "fixme": "=confirmar interpolação") - - - - - - - - - - -Da questão de lado e sentido de vias: Não serve colocar um padrão fixo, cada área tem o seu (ou nem tem): de todo modo teria que ser para verificar cada cidade/região a interpolar e se necessário inverter no ato de taggear: 1)Pensando melhor, pra adaptar a todos os casos, talvez tipo assim, 4 opções de namespace: addr:interpolation:left:odds=<inicio-fim> addr:interpolation:right:evens=<inicio-fim> ou addr:interpolation:left:evens=<inicio-fim> addr:interpolation:right:odds=<inicio-fim> 2)Se não tem lado bem definido, continua a usar apenas a tag básica: addr:interpolation=<inicio-fim> Ou outra ideia melhor se tiver. Sim, seria algo mais especializado. A princípio não é coisa simples para principiante fazer (mas a atual addr:interpolation, também não o é de todo modo) - - - - - - - - - - QUANTO ÀS OBJEÇÕES: 1)Uso indiscriminado de addr:interpolation : Obviamente não é necessário uso indiscriminado. Mas acho que temos que avançar na numeração e eventualmente com automatização e/ou aproximação para isso se necessário. Ou vamos esperar uns 20 anos pra ter numeração exata, ficando para trás na popularização, só nós mesmos usando. 2) O fato de eventualmente errar em numeração (lado da via, extensão da numeração (range)) não me parece grave. Mesmo que errar algo, já ajuda p.ex. ter número na área mesmo que só aproximada. Google libera assim, e faz bem. Alguns podem reclamar, porque ajuda de fato, já aproxima. Não é lixo inútil. As pessoas usam porque de fato ajuda. Em geral as pessoas não se perdem por causa de erro de posição da numeração no GPS. Se perde se não olhar os números nas portas também na realidade. Não dá para esperar perfeição. Tem que liberar pra uso. Ou então: não se populariza, não terá mais gente contribuindo, e não se avança. O resto é feedback e correção progressiva. 3) Endereçamentos do IBGE: No que vi no SHP face de logradouros (ways), não traz numeração de endereços: ftp://geoftp.ibge.gov.br/recortes_para_fins_estatisticos/malha_de_setores_censitarios/censo_2010/base_de_faces_de_logradouros Endereços só encontrei na lista TXT em: ftp://ftp.ibge.gov.br/Censos/Censo_Demografico_2010/Cadastro_Nacional_de_Enderecos_Fins_Estatisticos/ vem listado o numero da rua, quadra, CEP, etc. Por estados/cidades (código). Teria que processar a lista (no QGIS ou script), ver como poderia passar para os ways do OSM para adicionar. Acho que talvez teria primeiro que cruzar com o SHP das faces, pra só depois tentar ver como passar pras highways do OSM. Meio complicado, acho. Talvez alguém pense jeito mais fácil. Mas talvez sirva pra quem pretender extrair os CEPs. De todo modo ainda vi que do IBGE tem que confirmar o ajuste da camada: entrou em CRS SIRGAS2000, mas nem sempre fecha bem com o que já está correto no OSM com GPS, etc. No Centro de Porto alegre vi a diferença em torno de -40,-20m (x,y). Em Viamão diferença não homogênea. Creio que seja problema de resolução e imagem usada no Censo 2010. - - - - - - - - - - - - - - - - Sérgio - http://www.openstreetmap.org/user/smaprs
_______________________________________________ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
