[Talk-br] RES: RES: OSM - CNEFE

[Lucas Ferreira Mation]

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 <ppkrauss em gmail.com>:

> Oi, só alguns lembretes/sugestoes pro Lucas, que talvez possam interessar,
>
> Em 1 de outubro de 2015 22:01, Lucas Ferreira Mation <
> lucasmation em gmail.com> 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 <ppkrauss em gmail.com>:
>>
>>> 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 <heroijapa em hotmail.com>
>>> 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: lucasmation em gmail.com
>>>> To: talk-br em openstreetmap.org
>>>> 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 <lucasmation em gmail.com>
>>>> :
>>>>
>>>> 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 <heroijapa em hotmail.com>:
>>>>
>>>> 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: lucasmation em gmail.com
>>>> To: talk-br em openstreetmap.org
>>>> 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 <
>>>> aguiar.marcio em gmail.com>:
>>>>
>>>> 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 <lucasmation em gmail.com
>>>> >:
>>>>
>>>> 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 <ppkrauss em gmail.com>:
>>>>
>>>> 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 <
>>>> lucasmation em gmail.com> 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 <ppkrauss em gmail.com>:
>>>>
>>>> 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
>>>> Talk-br em openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Talk-br mailing list
>>>> Talk-br em openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Talk-br mailing list
>>>> Talk-br em openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Talk-br mailing list
>>>> Talk-br em openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Talk-br mailing list
>>>> Talk-br em openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>
>>>>
>>>>
>>>> _______________________________________________ Talk-br mailing list
>>>> Talk-br em openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>
>>>> _______________________________________________
>>>> Talk-br mailing list
>>>> Talk-br em openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________ Talk-br mailing list
>>>> Talk-br em openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>
>>>> _______________________________________________
>>>> Talk-br mailing list
>>>> Talk-br em openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Talk-br mailing list
>>> Talk-br em openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>
>>>
>>
>> _______________________________________________
>> Talk-br mailing list
>> Talk-br em openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>>
>
> _______________________________________________
> Talk-br mailing list
> Talk-br em openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.openstreetmap.org/pipermail/talk-br/attachments/20151001/8ecc1bb7/attachment-0001.html>