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

Quarta Setembro 30 13:20:55 UTC 2015

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
>>
>>
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.openstreetmap.org/pipermail/talk-br/attachments/20150930/7ddea3ba/attachment-0001.html>