Formato simples e auditável para listar endereços

[ppKrauss]

Formato CSV ou GeoJSON?

Como já são previstas ferramentas eficientes de visualização e revisão, a sugestão é que se publique no git o CSV por questões de transparência e acesso, viabilizando a revisão humana sempre que desejado.

Formato tabular (CSV), pois qualquer um pode revisar e editar com uma planilha. Deve conter apenas os dados essenciais:

• Logradouro e número: endereço horizontal da via pública (sem complemento vertical ou de condomínio).

• Geohash: é tanto a referência LatLong como identificador, oferecendo boa garantia de não-duplicados.

• CEP: é uma maneira de garantir integridade do nome de logradouro, bairro e cidade. Ajuda a detectar falhas e vice-versa, afirmar com mais segurança que o endereço é confiável (depois de confirmado).

Na publicação git pode-se ordenar por logradouro e número, ou por Geohash (decidir qual melhor). Exemplo:

geohash	logradouro	numero	cep
6gmnbp71yr3	Avenida Comendador Franco	7329	81560-000
6gmnbpdefj6	Rua Augusto Zibarth	695	81560-360
6gmp81ztkbm	Rua Hilário Moro	526	82600-030
6gmp834cpzc	Rua Rio Japurá	648	82840-220

---

Já foi decidido usar Curitiba, portanto toda a discussão e testes estarão sendo feitos com os pontos de endereçamento de Curitiba do OSM:

• primeiro os dados de outubro de 2018 (nossa referência de "inicio do BEBA");

• depois, para comparar a evolução, os dados de final de 2019 ou 2020, mostrando o grande salto de volume e qualidade com o trabalho de https://apoie.me/osmbrasilcuritiba

Decisões pendentes (a discutir e votar)

1. Formato do arquivo (JSON ou CSV?)
2. Campos (os sugeridos ou outros?)
3. Volume de dados por arquivo (mínimo e máximo de endereços por arquivo ou tudo num só?)
4. Nome de arquivo (prefixo de Geohash ou outra coisa?)

As sugestão para os itens 3 e 4 são é seguinte:

Quanto maior a quantidade de dados, maior o número de arquivos. A proposta é que nunca tenham menos de 100 linhas nem muito mais do que 1000 a 2000 linhas por arquivo, para que sejam fáceis de auditar e gerenciar pelo ser-humano usando apenas planiha. Para tanto basta organizar os arquivos por prefixo de Geohash. Por exemplo os endereços da tabela acima fariam parte do arquivo pt_6gm.csv da pasta PR-Curitiba/.

[ThierryAJean]

Minhas respostas:

1. Para registrar no cartório, creio que o formato CSV é mais universal e mais fácil de acesso
2. Falta a proveniência da fonte e talvez o codigo Wikidata (Equipamentos sociais)
3. Creio que 5000 linhas de Excel é tranquilo
4. Geohash, ok mas precisamos ter um mapa mostrando os Geohash num mapa

[ignacio-arnaiz]

Tenemos un problema porque los datos de Curitiba solo tienen los eixos da rúa pero no tienen los números. Tampoco tienen los CEP, he buscado en IBGE sin éxito, OSM tiene los CEP?
En IBGE se pueden descargar los SHP de faces, setor y subsetor de todo Brasil pero tampoco tiene numeros solo las lineas de face

[ppKrauss]

Olá, obrigado pela participação! Respondendo ao Thierry depois ao Ignacio.

---

Respondendo ao @ThierryAJean:

• sobre seu item 2, a demanda por campo sobre proveniência do dado de endereço. Concordo. Vou incluir o campo fontes para indicar fontes que oferecem o endereço registrado. A Wikidata pode ser uma dessas fontes, vou inclusive buscar e tentar resgatar endereços por lá. Será necessário uma tabela "de para" dos identificadores de fonte. Editar aqui no Google-docs.

• sobre seu item 4, demanda por visualização dos quadriláteros de Geohash empregados como nome de arquivo de listas de endereço. Concordo, vou tentar montar um com os exemplos, depois que eu postar novos exemplos (mais tardar final de semana).

---

Respondendo ao @ignacio-arnaiz:

Tenemos un problema porque los datos de Curitiba solo tienen los eixos da rúa pero no tienen los números.

Apesar do OSM ser pobre em endereços completos (com CEP), é razoável em endereços com número e em eixos de rua com nomes consistentes (e alguns pontos de endereçamento a cada eixo). Acho que podemos usar OSM.

Em geral teremos que nos contentar com uma amostragem mínima de 5 endereços por rua, e daí endiante interpolar a numeração. Posteriormente confirmações de campo ou amostras mais precisas permitirão o ajuste fino entre posição e numeração.

Tampoco tienen los CEP, he buscado en IBGE sin éxito, OSM tiene los CEP?
En IBGE se pueden descargar los SHP de faces, setor y subsetor de todo Brasil pero tampoco tiene numeros solo las lineas de face

O IBGE de 2010 não tem endereços com número de porta pois em espaço urbano há o compromisso de anonimização. Já no Censo Agro de 2017 (ver issue 16) isso não ocorre.

Os dados de endereço do IBGE de 2010 podem ser utilizados como referências de CEP, dando integridade tanto às faces de quadra (todo endereço cujo ponto cair naquela face recebe aquele CEP) como aos próprios nomes de rua nos vetores de eixo. O algoritmo em PostGIS é complexo, mas é viável, já fiz alguns testes.

[ignacio-arnaiz]

OSM parece que tiene la numeración completa en Curitiba, todos los lotes tienen numero, lo puedes ver en
https://urbithings.com/dc8f9f7e-f5b9-4b8e-97a2-85c5ad336021.ms

[ppKrauss]

....
OSM parece que tiene la numeración completa en Curitiba, todos los lotes tienen numero, lo puedes ver en https://urbithings.com/dc8f9f7e-f5b9-4b8e-97a2-85c5ad336021.ms

Muito bom! E oportuno já usar como referência para alguns esclarecimentos ou discussões para decisão:

• Se o algortimo mágico do Urbithings que gera os pontos mais prováveis de "posição latitude/longitude da porta do lote" (algo dentro do lote porêm próximo à rua referenciada pelo endereço), então importante que ele doe esses dados (os pontos) para o Domínio Público (licença CC0).

• Se um determinado ponto não tem lote mas foi indicado como endereço no OpenStreetMap (OSM), também podemos utiliza-lo. Por ser fonte OSM sua licença será ODbL. Quando surgir outra fonte pode virar CC0. Ver tabela das fontes

---

Poderia enviar por email ou indicar aqui link arquivo, uma planilha com os endereços que o Urbithings gerou?
(pode usar latlong não precisa ser Geohash nem precisa CEP)

Vai ser nosso primeiro experimento de comparação entre duas fontes distintas (Urbithings e OSM).

[ThierryAJean]

Anderson, que fez a importação dos endereços de Curitiba para o OSM no fim de 2018, me deu o link de Curitiba: http://ippuc.org.br/geodownloads/geo.htm e me falou que os endereços deveriam estar disponíveis no arquivo sobre lotes. Ele fez um trabalho de deslocar os pontos dos endereços do centro das quadras para mais próximo da rua.

[ignacio-arnaiz]

En el SHP de lotes de Curitiba hay un campo "num_predia" que efectivamente contiene el mismo número que ofrece OSM, yo no entendí que fuese el numero de portal porque tienen unas secuencias raras, no son correlativos ni los intervalos entre ellos son constantes, quizá es la forma brasileira de numerar?. En todo caso lo he incluído en el localizador de Lotes Curitiba

Si hacemos una consulta en urbiThings utilizando todos los localizadores globales: Google, Here, Mapbox, TomTom, Nominatim, what3words, mas el localizador de Lotes Curitiba, todos los que devuelven número no siempre coinciden:
566 para Google
602 para Here
33 para Mapbox
566 para OSM
566 para urbiThings (basado en el campo "num_predia")
Si los números de OSM se basan en la tabla LOTES_SIRGAS descargada de Curitiba entonces OSM es igual a urbiThings: http://ippuc.org.br/geodownloads/SHAPES_SIRGAS/LOTES_SIRGAS.zip

[ignacio-arnaiz]

Here, Mapbox y TomTom asignan la consulta a la rua Brigadeiro y los demás a la rua Sao Januario, el lote en la capa de Lotes_sirgas está asignado a la rua Sao Januario. En las esquinas de quadra será frecuente. La realidad es que ese lote tiene su entrada por Sao Januario en Street View se ve el 566 en su face:

[ppKrauss]

Olá, ótimos leantamento e análise @ignacio-arnaiz !

En el SHP de lotes de Curitiba hay un campo "num_predia"

Em português expandido seria "numeração predial" (sinônimo de "número de porta"), que é um termo mais formal e utilizado pelas prefeituras.

que efectivamente contiene el mismo número que ofrece OSM,

Ok, acho que essa é a ideia do sistema de ingestão, comparar fontes em busca de confirmações para (ideia do score de confiabilidade)... Otimo que o Urbithings ja faz isso (!).

yo no entendí que fuese el numero de portal porque tienen unas secuencias raras, no son correlativos ni los intervalos entre ellos son constantes, quizá es la forma brasileira de numerar?

Depende do rigor fiscal de cada prefeitura, e da cultura da cidade: algumas permitem até numerologia... Quando existir o dado oficial, ou seja, uma parceria nossa com a prefeitura, será possível separar os 3 tipos de numeração predial: praticada, oficial e inferida (por interpolação). A oficial é aquela fornecida em mapa pela prefeitura, a praticada é a plaquinha que o dono da casa coloca.

En todo caso lo he incluído en el localizador de Lotes Curitiba
{imagem acima}
Si hacemos una consulta en urbiThings utilizando todos los localizadores globales: Google, Here, Mapbox, TomTom, Nominatim, what3words, mas el localizador de Lotes Curitiba, todos los que devuelven número no siempre coinciden:
566 para Google
602 para Here
33 para Mapbox
566 para OSM
566 para urbiThings (basado en el campo "num_predia")

Pois, é aí que nasce o score de confiabilidade. Neste caso de moda 3 em 5 amostras o score não será 100%, e a inferência estatística (ou regra heurística) do numero predial mais provável será 566. A confiabilidade depende do peso de cada fonte, acredito que Google tenha muito mais peso do que Mapbox, e até um pouco mais do que Here, porém o mesmo que OSM... Então a confiabilidade seria mais para 90%, do que os 60% diretos de 3/5.

PS: um score final maior depende da existência de CEP na fonte (não calculado mas dado a priori), reduzindo risco de erros ortográficos, etc.

Si los números de OSM se basan en la tabla LOTES_SIRGAS descargada de Curitiba entonces OSM es igual a urbiThings: http://ippuc.org.br/geodownloads/SHAPES_SIRGAS/LOTES_SIRGAS.zip

O atual OSM (2019 e 2020) esta batendo com a Prefeitura pois foi mesmo copiado, os edits OSM são do Anderson (user santamariense) conforme projeto https://apoie.me/osmbrasilcuritiba

[IgorEliezer]

Meio tarde, mas só para deixar para registro.

Deixe a base de dados de endereço como CSV por ser limpa e pode ser lida em qualquer situação. O JSON tem muitos caracteres de separação e de aninhamento dados: { [ ] } : , além das quebras de linhas.

O JSON seria mais para material derivado da base de dados, como por exemplo, um extrato/amostra de uma área para visualizar no mapa a posição dos endereços.

EDIT: Polígonos como geojson.

[ppKrauss]

Ola @IgorEliezer, obrigado pela participação. Estou entendendo o seguinte:

• Mais um voto para o formato CSV na pergunta "Representar pontos de endereço como CSV ou GeoJSON?"
• Mais um voto para manter os polígonos de município como GeoJSON.

Ok, registrado, seu voto traz mais confiança para essa decisão de projeto... Alias, como houve consenso, nenhum voto contra na discussão. Podemos enfim avançar!
Vou fechar a issue, mas fiquem a vontade para reabrir.

---

PS: podemos arregaçar as mangas e começar. São ~5570 municípios para incluir neste git, e todos os pontos e vias que aparecerem no OpenStreetMap de cada município.