excelente! vou ver como instalar estes slides explicam um pouco da intuição dos negócios fonéticos e das comparações por proximidade de Levihnsen: http://pt.slideshare.net/DiogoLVGRubert/palestra-diogo-rubert-pgday-campinas-2015
2015-10-01 19:49 GMT-03:00 Peter Krauss <[email protected]>: > Oi, só alguns lembretes/sugestoes pro Lucas, que talvez possam interessar, > > Em 1 de outubro de 2015 22:01, Lucas Ferreira Mation < > [email protected]> escreveu: > >> (...) O ambiente de trabalho que tenho a disposição tem R e Postgresql, >> > > parece que o grosso está em PostgreSQL+PostGIS: que tal usar o R como > parte do SQL? fica *embedded* como PL/R, > > http://www.joeconway.com/plr/ > http://www.postgresql.org/docs/9.3/static/external-pl.html > http://www.postgresql.org/docs/9.3/static/xplang-install.html > > >> .... um script (...) que faça a correção fonética >> >> > O PostgreSQL roda o melhor deles, > http://sourceforge.net/projects/metaphoneptbr/ > tem um driver para postgreSQL, facil de usar com UBUNTU. > > > >> >> >> >> >> >> >> >> >> 2015-10-01 17:20 GMT-03:00 Peter Krauss <[email protected]>: >> >>> Oi Marcos, que tal organizarmos essa ideia de "metodologia para a >>> organização" num Github? >>> Acho q qualquer um pode iniciar projeto sob https://github.com/OSMBrasil >>> voce inicia um? Se precisar de alguém mais "nerd" para o git, só avisar, >>> posso ajudar ;-) >>> >>> >>> Em 1 de outubro de 2015 15:13, Marcos Fedato <[email protected]> >>> escreveu: >>> >>>> Oi Lucas, >>>> >>>> Caramba vc tem pensado bastante nisso mesmo kkkk, vou tentar ajudar >>>> também. >>>> >>>> A) Até onde eu estudei, não existe base perfeita. Por exemplo, se a >>>> gente usa ponto coletado por GPS como referência pode ser algo bom, mas >>>> existem deformações também na coleta por GPS causados pela altitude, >>>> qualidade do GPS e tudo mais. Porém eu já vi um fabricante de GPS falar que >>>> pra ele, ele quer mesmo que a base dele tenha a mesma deformação do GPS >>>> pois os usuários dele vão usar GPS para se locomover na cidade, então se >>>> der 5m a esquerda na coleta, provavelmente o GPS do usuario também vai dar >>>> algo parecido a 5m a esquerda, no final o ponto cai no meio da rua. Então >>>> nada é perfeito, é preciso entender o que é a verdade conveniente para nós >>>> kkkkk. Eu acho que essa de assumir o OSM uma boa. >>>> >>>> B) O processo que um colega meu tinha desenhado uma vez era "faseado", >>>> primeiro se achava os que batiam tudo pelo nome, depois se ajustava eles >>>> com o arruamento, depois se ajustava os setores vizinhos, depois fazia uma >>>> junção espacial dos vizinhos com as quadras do arruamento abaixo deles, >>>> depois se validava os atributos entre eles... >>>> Uma época eu até estudei se a gente conseguiria fazer uma comparação de >>>> formas de polígonos para validar se a/as quadras do arruamento realmente >>>> batem com as do setor censitário, tipo se no setor censitário a forma é um >>>> quadrado, mas no processo a quadra do OSM abaixo desse setor é triangular, >>>> ou um quadrado girado x graus... >>>> Pois esse colega tinha feito comparações usando a área e o perímetro >>>> dos setores casados, o que já é bom. >>>> >>>> C) Não manjo nada de geometria direto no banco assim, mas talvez ele >>>> esteja reprocessando o buffer a cada rodada, talvez poderia se criar uma >>>> coluna da geometria com buffer preencher ela uma vez e então usar essa >>>> coluna. >>>> Menos impactante deve ser o join com os 2 ands, se eu me lembro bem no >>>> geocodigo do município já tem o estado, então não precisa fazer join com o >>>> estado, o municipio só já é estado e município. >>>> >>>> D) Já usei um processo parecido desse de ordem alfabética quando eu >>>> queria cruzar 2 bases de dados usando as esquinas para achar os pontos de >>>> referência. O que eu tinha em mente é que eu não precisava achar tudo, se >>>> eu achasse 40% sei lá, o resto eu faria o processo de alinhar pelos >>>> vizinhos, extrapolando o deslocamento de um para outro. Porém o que a gente >>>> pode fazer é usar comparação de nome a nome ao invés de somar tudo. de >>>> depois fazer o join de volta e ver quantos nomes bateram. >>>> >>>> Podemos implementar no post-gis, ou implementar uma ferramenta de >>>> carga, que crie um campo novo já tipo "nome_fonetico" e usar esse campo pré >>>> processado no processo. >>>> >>>> E) Fato, o que pode ser feito é usar o vizinho mesmo para veridficar >>>> qual é o correto e inferir o nome se o vizinho já tiver sido encontrado. >>>> >>>> F) Tem mesmo muita coisa diferente. Eu sou muito bom em regex, essa >>>> parada aí eu topo, da pra fazer alguma coisa com certeza, demora, não vai >>>> ser perfeito, mas com testes a gente chega lá. >>>> >>>> G) O cep tem n possibilidades dentro do DNE tem um tipo do cep, que >>>> podia ser igual dos dois lados, diferente, usando numeração sequencial e >>>> não metrica... fato é que nem sempre é igual, mas pode ser usado nos casos >>>> em que for igual. >>>> >>>> Att >>>> Marcos Fedato >>>> >>>> >>>> ------------------------------ >>>> Date: Wed, 30 Sep 2015 10:20:55 -0300 >>>> >>>> From: [email protected] >>>> To: [email protected] >>>> Subject: Re: [Talk-br] RES: RES: OSM - CNEFE >>>> >>>> ops, mandei acidentalmente antes de terminar. Retomando no ponto C >>>> >>>> C) De fato a podemos usar o shape de setores para aproximar mais o >>>> pareamento espacial (atualmente eu só usei os municípios) antes de parear >>>> as quadras pelo nome. E com isso podemos aumentar ao grau de tolerancia nos >>>> pareamentos fuzzy. Este pareamento OSM - poligonos de setor censitario >>>> também é útil para a outra grande metade do projeto (na qual ainda não >>>> avancei muito) que é sugerir nomes para ruas sem nome no OSM a partir do >>>> CNEFE. >>>> Eu já tentei rodar a query abaixo para fazer isso (resumindo, cruzar >>>> primeiro por uf e municipio, atribuindo codigos para estes nas duas bases, >>>> para reduzir o número de cruzamentos espaciais de fato entre setores e ruas >>>> apenas dentro de cada municipio): >>>> >>>> CREATE TABLE OSM_Streets_by_SetorCensitario2 AS >>>> SELECT OSM_Streets_by_Mun.*, setor_censitarioL.geom >>>> FROM OSM_Streets_by_Mun, setor_censitarioL >>>> WHERE OSM_Streets_by_Mun.cod_UF= >>>> substring(setor_censitarioL.cd_geocodi,1,2) AND >>>> OSM_Streets_by_Mun.cod_mun= substring(setor_censitarioL.cd_geocodi,1,7) >>>> AND >>>> ST_Intersects(way,ST_Buffer(setor_censitarioL.geom,0.005))=true >>>> >>>> O problema é que é um cruzamento muito grande. Se bem me lembro, são >>>> ~1.6milhoes de ruas no OSM brasil e 312 mil setores censitarios. Deixei >>>> rodando por 5 dias no servidor (relativamente potente, 126GB de ram, 4 >>>> nucleos) e não terminou. Nao sei se tem uma forma de otimizar esta query, >>>> talvez fazendo proceduralmente, num loop, muncipio a municipio (mas isso em >>>> tese as 1as duas condições do WHERE já impõem). Ou entao cruzando com >>>> layers espaciais intermediarios, como distrito e subdistrito antes de ir >>>> pro setor censitario direto (mas não estou conseguindo criar estes layers >>>> com base nos setores censitarios, por causa dos problemas topologicos >>>> destes). Enfim, vou perguntar no StackOverflow para ver se alguém tem uma >>>> idéia. >>>> >>>> D) melhorar as queries textuais, com filtros nos textos e fuzzy acho >>>> que é um ótimo caminho. Uma restrição, pelo menos como eu modelei os dados, >>>> é que estou fazendo pareamento de arrays contendo nomes de ruas, que >>>> internamente são ordenados alfabeticamente (uma linha da tabela representa >>>> uma quadra, e há uma coluna que é um array, e lá dentro tem todos os nomes >>>> de rua, ordenados alfabeticamente). Se o erro ou correção ocorrer no começo >>>> de certo nome de rua, isso vai afetar a ordem alfabetica dos nomes de rua, >>>> e não sei como o pareamento (possivelmente fuzzy) vai reagir a isso. >>>> >>>> Você tem alguma idéia melhor de uma estrutura de dados mais adequada >>>> pro pareamento? >>>> >>>> Outra coisa, estou trabalhando no PostGis-Postgresql então o ideal >>>> seria os "filtros foneticos" serem implementados no próprio Postgis. Tenho >>>> boa familiaridade com R também, então, se precisar sair, a 2a opção mais >>>> fácil de implementar seria o R. >>>> >>>> E) pensei também nos blocos que parearem apenas 3 das 4 ruas. Bom, >>>> considerando apenas quadras de 4 lados, para simplificar, seriam 2 quadras >>>> para cada conjunto de 3 ruas. precisamos de uma forma de definir qual é >>>> qual. Alguma idéia? >>>> >>>> F) voce mencionou uma outra idéia, na qual eu também já trabalhei um >>>> pouco, que é ir seguinto a descrição textual dos setores. Estes aquivos vem >>>> com dois campos: "ponto inicial" e "decrição do setor". Com banstante >>>> traquejo no uso de expressões regulares da para quebrar isso em seguencias >>>> de esquinas (cruzamentos). Mas uma dificuldade é que e linguagem não é >>>> padrão. Como os arquivos são produzidos de forma descentralizada, pelos >>>> ~500 escritórios locais do IBGE, há diferenças ao longo do brasil (talvez >>>> seja por estado). Tem setores que está com "esquina da rua A com a B". Em >>>> outros está "cruzamento rua A e rua B". Isso para o campo "ponto incial". A >>>> descrição de setor tem ainda mais variabilidade. >>>> >>>> G) Outro elelmento que ainda não eplorei, mas que vem de uma idéia do >>>> Peter Krauss, é que o CEP segue uma estrutura, tal que, cada seguimento de >>>> uma rua, tem o mesmo CEP para as quadras dos dois lados da rua. Isso pode >>>> ser mais um elemento para "amarrar" estes pareamentos de alguma forma. >>>> >>>> >>>> >>>> enfim, estes são menos comentarios sobre as idéias que você mencionou. >>>> Vamos pensar mais nisso para "espremer" tudo de informação últil no CNEFE e >>>> vice-versa >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 2015-09-30 9:53 GMT-03:00 Lucas Ferreira Mation <[email protected]> >>>> : >>>> >>>> fantástico Marcos, >>>> >>>> eu já "ataquei" várias linhas das que você sugeriu, mas ainda não >>>> completei. Tenho trocado algumas idéias a respeito, off-line do grupo para >>>> não tumultuar muito por aqui, com o Peter Krauss. Podemos te incluir na >>>> conversa. >>>> >>>> Vamos por partes: >>>> >>>> A) A primeira grande dúvida que eu tenho é quanto podemos confiar no >>>> posicoinamento das ruas do OSM? Por exemplo, quando o shape de setor >>>> censitário e o OSM não batem, como eu posse ter certeza que o certo é o >>>> OSM? Será que o mapeador não se baseou numa imagem de satélite que também >>>> estava deslocada? Enfim, no meu código estou de certa forma tomando o >>>> posicionamento de ruas do OSM como "verdade", mas seria bom pensar um pouco >>>> melhor nisso. Eu vi nos vídeos do SotM-Latin-America-2015 um cara da Mapbox >>>> apresentando como eles tem umas técnicas para corrigir o posicionamento de >>>> ruas do OSM, que aplicaram no Japao e em Lima. >>>> >>>> >>>> B) Agora de manhã estou trabalhando nesta idéia de usar os quarteiroes >>>> que parearem e que sejam setores de um só quarteirão como pontos de >>>> controle para corrigir a malha de setores censitarios. >>>> >>>> Dos 95mil quarteiroes que eu consegui parear, 952 são setores com um >>>> único quarteirão (que são os que de fato podemos parear no momento). Estes >>>> 952 setores são de 81 municípios (eu estava com esperança de que seriam >>>> mais). Para estes eu vou calcular a distancia (ST_distance) e o angulo >>>> (ST_Azimuth) entre os centroides das quadras pareadas do OSM e do CNEFE. >>>> Como você falou isso vai nos dar uma lista de pontos de controle. >>>> >>>> Com isso podemos: >>>> b1) ter uma lista de "margens de erro" do shape de setor censitário >>>> para cada municipio (ou melhor pros 81 muncípios em que há estes casos). >>>> Isso serve para definir o buffer (max(ST_distance) para usar quando parear >>>> o shape de setores censitarios com os ruas do OSM (como você sugere). >>>> b2) Usar os pontos de controle para corrigir o shape de setor >>>> censitario. Isto é, fazer uma transformação afim (que estica partes do mapa >>>> e contrai outras partes) com base nestes pontos. >>>> >>>> C) De fato a podemos usar o shape de setores para aproximar mais o >>>> pareamento espacial (atualmente eu só usei os municípios) antes de parear >>>> as quadras pelo nome. E com isso podemos aumentar ao grau de tolerancia nos >>>> pareamentos fuzzy. Este pareamento OSM - poligonos de setor censitario >>>> também é útil para a outra grande metade do projeto (na qual ainda não >>>> avancei muito) que é sugerir nomes para ruas sem nome no OSM a partir do >>>> CNEFE. >>>> Eu já tentei rodar uma query para fazer isso >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 2015-09-30 9:14 GMT-03:00 Marcos Fedato <[email protected]>: >>>> >>>> Caros, >>>> >>>> Eu trabalhei alguns anos com essa parte de endereçamento e tenho muito >>>> a ajudar nesse processo do CNEFE. >>>> >>>> Além dos acentos e da lógica fuzzy (que pode adicionar erros), podemos >>>> usar alguma coisa de fonética brasileira(que pode adicionar erros) e >>>> tabelas auxiliares(que pode adicionar erros) com nomes padrão, dando >>>> replace em erros conhecidos de grafia (AKA: juscelino kubitschek é >>>> difícil de escrever). >>>> >>>> Tem esse algoritimo em Delphi que eu achei uma vez, que faz um trabalho >>>> fantastico de fonética BR (tecnicamente não é BR é do Portugês) (AKA: >>>> soundex não é bom para matches exatos) http://pastebin.com/KpYxxw5e. >>>> >>>> Vamos supor que o "quarteirão" tenha 4 ruas e 3 delas tem nome no OSM e >>>> estes nomes batem, a gente pode supor que a rua que faltou no OSM tem o >>>> nome da rua que sobrou no CNEFE. >>>> >>>> A gente pode usar não só os municipios, mas também os setores >>>> censitários para achar exatamente onde estão os nomes faltantes. >>>> >>>> Os setores censitários tem uma tabela de descrição do entorno. É um >>>> campo de texto livre para cada setor falando as ruas por onde ele é >>>> delimitado. Com alguma inteligência a gente pode quebrar esse campo em ruas >>>> e cruzar com o OSM também. >>>> >>>> O problema conhecido de cruzar diferentes bases de dados espaciais é o >>>> deslocamento que pode haver entre uma e outra, tenho alguns esboços >>>> interessantes de como resolver isso saíndo do mundo tabular e utilizando >>>> GIS. >>>> >>>> Minha ideia se baseia em 2 coisas, achar alguns setores por cidade onde >>>> tudo bate e usar eles como referência de posicionamento. Depois extrapolar >>>> o erro destes setores para os setores próximos encaixando eles no lugar >>>> mais próximo do correto. (se o setor que a gente sabe que bate com o OSM >>>> estiver 5m para a direita, o setor vizinho dele estara provavelmente a algo >>>> próximo de 5m a direita também, pois eles tem paredes que se tocam) >>>> >>>> Existe também o problema de ruas que de fato mudaram de nome, podemos >>>> usar a tag old_name do OSM neste processo, se o nome do CNEFE constar lá, >>>> não é erro, realmente foi mudado o nome da rua. >>>> >>>> Então os dados seriam OSM(Vetor, Name, Alt_Name, Official_Name, Ref, >>>> Old_Name, No_Name), CNEFE, Shapes dos setores censitários, Descrições dos >>>> setores censitários. >>>> >>>> Pegar as áreas verdes (acho que village_green e park) com nome seria >>>> legal também, pois muitas praças dão nomes a logradouros, mas nem sempre >>>> isso se reflete na base de arruamento. >>>> >>>> Eu quero muito de ajudar nisso, estudei isso do OSM e do CNEFE bastante >>>> tempo e por isso tenho bastante conhecimento para tal, se tiverem interesse >>>> em expandir essa conversa além da lista (dá uma preguiça de escrever e a >>>> discussão demora, principalmente para brain storming) estou disposto a >>>> participar de discussões via áudio sobre o tema em horário não comercial e >>>> depois a gente pode colocar na lista um resumo para não perder o histórico. >>>> >>>> Sou programador experiente, posso ajudar a desenvolver rotinas de >>>> transformação de texto, consultas e análises espaciais necessárias para >>>> esse processo. >>>> >>>> Parabéns pelo trabalho até então, essa iniciativa é 10, somando >>>> esforços a gente vai destruir de deixar o OSM completo! >>>> >>>> Atenciosamente >>>> Marcos Fedato >>>> >>>> >>>> ------------------------------ >>>> Date: Wed, 30 Sep 2015 01:33:03 -0300 >>>> From: [email protected] >>>> To: [email protected] >>>> Subject: Re: [Talk-br] RES: RES: OSM - CNEFE >>>> >>>> >>>> coloquei agora. >>>> Mudei o codigo mesmo , que estava grande demais pro Readme para >>>> >>>> >>>> https://github.com/lucasmation/osm_cnefe_import/blob/master/OMS_and_CNEFE_blocks_matching.sql >>>> >>>> >>>> >>>> 2015-09-29 15:45 GMT-03:00 Márcio Aguiar Ribeiro < >>>> [email protected]>: >>>> >>>> Oi, Lucas! >>>> >>>> Muito bom! Eu venho planejando fazer isso faz um tempo já. Entrei no >>>> repositório e fiquei fuçando o código e o que eu entendi é que ainda não >>>> está disponível, certo? >>>> >>>> Marcio Aguiar Ribeiro >>>> >>>> 2015-09-28 13:19 GMT-03:00 Lucas Ferreira Mation <[email protected] >>>> >: >>>> >>>> Pessoal, >>>> >>>> retomando este assunto: >>>> consegui (finalmente!!!) cruzar os quarteirões do CNEFE com os do OSM. >>>> >>>> O Cnefe tem 2.1 milhões de quarteirões. >>>> O OSM tem 1.6 milhões de "quarteirões" (os quarteirões são algo que eu >>>> mesmo crio, a partir da interseção das Ruas do OSM). Destes apenas 480 mil >>>> tem todos os lados nomeados. >>>> >>>> O primeiro critério do cruzamento foi que os quarteirões tinham que >>>> cair no mesmo município (a partir do shapefile de municípios de 2010 do >>>> IBGE). O 2o critéiro foi que os nomes de todas as ruas que compõem o >>>> quarteirão batessem nas duas bases. >>>> >>>> Com este critério consegui identificar 95mil quarteirões do CNEFE no >>>> OSM. Para estes quarteirões temos todos os endereços que estão no CNEFE. >>>> >>>> Os municípios com mais quarteirões são: >>>> >>>> São Paulo - 5mil. >>>> Bejo Horizonte - 3,5mil >>>> Curitiba - 3.2mil >>>> Campo Grande - 2.7mil >>>> Fortaleza - 1.9mil >>>> Ribeirão Preto - 1.7mil >>>> Rio de Janeiro - 1.5mil >>>> >>>> e assim vai. Encontrei quarteirões em 1822 municípios, mas a maioria >>>> tem menos de 20 quarteirões encontrados. >>>> >>>> Isso foi com pareamento extato. Vou começar agora a testar com fuzzy >>>> matches. >>>> >>>> >>>> >>>> ao longo do dia vou migrar o código para: >>>> https://github.com/lucasmation/osm_cnefe_import >>>> >>>> >>>> >>>> Lucas >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 2015-07-14 12:12 GMT-03:00 Peter Krauss <[email protected]>: >>>> >>>> Oi Lucas, ótimo trabalho (!), assim que sobrar um tempo (algum final de >>>> semana) ponho a mão-na-massa, para entender o que voce fez e como podemos >>>> conversar mais tecnicamente ;-) >>>> (se tiver ilustrações, ex. UML, de modelo de dados para postar no git >>>> também ajuda) >>>> Como sou novato, pretendo seguir um pouco "pelas bordas" e no escopo >>>> mais geral das discussões... >>>> >>>> A ideia geral do projeto de Mapa-do-CEP ainda é rascunho mas pode ser >>>> apreciada em >>>> http://wiki.okfn.org/Open_Knowledge_Brasil/Mapa-do-CEP >>>> que tal começarmos pelo CEP2? >>>> >>>> - - - - >>>> Quanto os problemas legais (direitos autorais reclamados pela ECT bem >>>> como lei do monopólio) , precisamos de apoio internacional, inclusive da >>>> OSM... Comecei a busca por essa discussão (link abaixo), e senti >>>> receptividade, >>>> >>>> * http://opendata.stackexchange.com/q/5600/1313 >>>> <http://opendata.stackexchange.com/q/5600/1313>* >>>> a parte juridica é importante para não jogarmos nosso tempo no lixo... >>>> Até onde conversei com advogados, se criarmos uma metodologia (algoritmos) >>>> para espacialização do CEP (ver links Wikipedia com preliminares), não tem >>>> problema algum: o primeiro a publicar é o autor... Por isso acho importante >>>> termos resultado a curto prazo de um projeto-piloto com OSM e publicarmos >>>> no http://arxiv.org >>>> >>>> >>>> >>>> >>>> >>>> Em 14 de julho de 2015 11:13, Lucas Ferreira Mation < >>>> [email protected]> escreveu: >>>> >>>> Pessoal, estou colocando o que já tenho de código em: >>>> >>>> >>>> https://github.com/lucasmation/osm_cnefe_import >>>> (que perdoe a lingua portuguesa, escrevi em ingles para poder pegar >>>> mais feedback dos desenvolvedores do OSM no mundo, foruns, etc) >>>> >>>> Peter, bem vindo. Eu usei mesmo esta pergunta do gis.stackexchange. E >>>> elaborei em cima. Esta questão de dois lados do mesmo seguimento de rua >>>> teremo o mesmo CEP eu poderia explorar para melhorar o paramento, mesmo em >>>> quadras não pareadas. Mas o quão certo, 100% é isso? >>>> >>>> abs >>>> Lucas >>>> >>>> >>>> >>>> >>>> 2015-07-13 19:01 GMT-03:00 Peter Krauss <[email protected]>: >>>> >>>> Oi gente, acabo de me inscrever na lista... Posso participar da >>>> discussão? >>>> >>>> Eu tenho interesse no mapeamento do CEP e do CNEFE, que justamente >>>> ajudam a resolver ambiguidades e >>>> dar mais confiança à geocodificação... Até onde verifiquei, o >>>> Mapa-do-CEP não oferece problema jurídico... >>>> Postei um esboço metodológico da sua construção, na Wikipedia, >>>> >>>> https://en.wikipedia.org/wiki/Postal_code#Codes_defined_indirectly_to_administrative_borders >>>> que acham? >>>> Alguem falou em quadras por aqui, é justamente o foco metodológico... >>>> http://gis.stackexchange.com/q/80498/7505 >>>> >>>> PS: sobre pontos de endereçamento de utilidade publica, um bom projeto >>>> de referencia é o http://adresse.data.gouv.fr/ >>>> >>>> >>>> _______________________________________________ >>>> Talk-br mailing list >>>> [email protected] >>>> https://lists.openstreetmap.org/listinfo/talk-br >>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk-br mailing list >>>> [email protected] >>>> https://lists.openstreetmap.org/listinfo/talk-br >>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk-br mailing list >>>> [email protected] >>>> https://lists.openstreetmap.org/listinfo/talk-br >>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk-br mailing list >>>> [email protected] >>>> https://lists.openstreetmap.org/listinfo/talk-br >>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk-br mailing list >>>> [email protected] >>>> https://lists.openstreetmap.org/listinfo/talk-br >>>> >>>> >>>> >>>> _______________________________________________ Talk-br mailing list >>>> [email protected] >>>> https://lists.openstreetmap.org/listinfo/talk-br >>>> >>>> _______________________________________________ >>>> Talk-br mailing list >>>> [email protected] >>>> https://lists.openstreetmap.org/listinfo/talk-br >>>> >>>> >>>> >>>> >>>> _______________________________________________ Talk-br mailing list >>>> [email protected] >>>> https://lists.openstreetmap.org/listinfo/talk-br >>>> >>>> _______________________________________________ >>>> Talk-br mailing list >>>> [email protected] >>>> https://lists.openstreetmap.org/listinfo/talk-br >>>> >>>> >>> >>> _______________________________________________ >>> Talk-br mailing list >>> [email protected] >>> https://lists.openstreetmap.org/listinfo/talk-br >>> >>> >> >> _______________________________________________ >> Talk-br mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/talk-br >> >> > > _______________________________________________ > Talk-br mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-br > >
_______________________________________________ Talk-br mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-br
