A CodePlayData é um projeto criado com a missão de simplificar os processos de gerência, tratamento e consumo de dados em aplicações e softwares de alguns setores da sociedade. Acreditamos na contribuição de forma significativa por meio de produtos e serviços que reduzam a complexidade de determinados métodos aplicados na manipulação de dados, como por exemplo, tornar acessível a análise de dados espaciais (esse repositório), facilitar a aplicação de técnicas de modelagem estruturais e extração de latent features, possibilitar aplicações de feature store e versionamento de fetures, reduzir a complexidade da didática em programação e muitos outros.

Prezamos pela simplicidade dos processos, satisfação do usuário e clareza nas relações. Nosso modelo prioritário de negócio é por meio de APIs públicas, FaaS e PWAs. Sempre que possível iremos optar por soluções open-source. Se quiser conhecer mais acompanhe nossas redes sociais:

• Twitter

Público: Esse repositório é destinado a cientistas de dados, desenvolvedores e afins, no Brasil.

Objetivo: Reduzir a complexidade de processos nos três pilares das análises espaciais:

• Geocodificação e Busca (back-end);
• Geolocalização e Mapas (front-end);
• Geoprocessamento e Modelos (data-science);

Integrações: API do IBGE, Nominatim e Geofabrik.

Status: Em desenvolvimento. Linguagens: Typescript. Frameworks: Deno e Fresh.

• src: o código fonte.

• test: pasta que contém todos os testes unitários disponíveis.

• bin: pasta que contém os binários do osmium-tool, usado para criar aquivos .pbf, e do osm_extract_polygon, usado para extrair objetos de arquivos osm. As duas ferramentas são utilizadas para o processo de extração dos polígonos do bairros (e serão usados para extração das ruas e outras coisas) e suas respectivas licenças estão copiadas no local.

• data: todos os arquivos necessários para converter nomes: string em códigos do IBGE que equivalem ao polígono solicitado. Os arquivos _double são os nomes duplicados, triplicados, quadruplicados ou quintuplicados das divisões geográficas do Brasil.

• neighborhoods_includes: Pasta que contém polígonos dos bairros corrigidos por municípios. Considerando que a divisão geográfica de bairro dos municípios brasileiros podem variar em precisão e acurácia, por exemplo, podem ter surgido bairros num curto espaço de tempo que não estão registrados em bases públicas, é necessário um mecanismo de correção, que nesse caso funciona da seguinte forma:

  1. Primeiro se corta exatamente a divisão do município que se deseja obter os bairros;
  2. Utiliza o osm_extract para buscar os polígonos que estão marcados como divisão bairros;
  3. Verifica se existe no repositório uma pasta com o nome do município em questão indicando que ou existem bairros a serem incluidos, ou caso existam polígonos com o nome de bairros já extraídos ele troca o polígono para que está presente na pasta do repositório.

Os bairros estão sendo coletados diretamente dos objetos OpenStreetMap (.osm), que de certa forma é uma contribuição coletiva, entretanto, no Brasil a divisão dos bairros é de prerrogativa dos municípios isso faz com que as divisões sejam alteradas com maior frequência do que as divisões acima. Sendo assim, na neigborhood_list.csv existe uma lista de bairros que serão considerados "errados" para serem removidos e link dos bairros considerados "corrigidos" para serem incluidos pela função antes de entregar o objeto geojson.

A Geocodificação é o processo de converter referências de localização, como endereços, CEP ou nomes de divisões geográficas como municípios ou estados, em dados referenciados geograficamente para os sistemas de informações geográficas (GIS), utilizando vetores (em casos de dados pontuais) ou arrays (em caso de polígonos) de valores de latitude e longitude¹.

Esse é um método já normalizado nos hábitos atuais quando buscamos corridas de aplicativos de carros, novos endereços ou buscamos a distância entre dois pontos para calcularmos o frete de uma entrega².

Atualmente a pioneira no fornecimento desse serviço é a Google com a sua Geocoding API. Muito do sucesso se deve a rotineira busca ativa (mapeamento) dos endereços feito pela empresa com veículos especiais.

Todavia, existem opções comunitárias para o mesmo tipo de serviço, como é o Nominatim (o "motor" de busca do OpenStreetMaps). Os dados são atualizados pela comunidade e exportados por empresas como a Geofabrik em bases de dados de mapas (tiles) para serem utilizadas no Nominatim em diversos usos. Especificamenete no caso de mapas brasileiros existem estudos que validaram a viabilidade de uso³ e até implementaram soluções para aumentar a precisão e estimular a contribuição da comunidade⁴.

A princípio, todas as funções estão autônomas, não necessitando de depedências além das que já estão na pasta ./src/. Porém, caso o exista um config.json (existe um exemplo na pasta root), ao alterar as urls, é possível utilizar as funções para buscar os polígonos em API privadas. Por default, serão utilizados o OpenStretMaps para localizar os pontos e o IBGE para buscar os polígonos. Entretanto, no OSM tenha cuidado com o limite de requisições!!!

Caso sejam utilizados múltiplos servidores privados o nome de cada um deles deve ser correspondente ao nome da macroregião em questão, por exemplo, caso o servidor seja apenas da região Sudeste, esse deve ser o nome.

No front-end faça uso de processamento paralelo com service-workers para não comprometer o event loop com requisições pesadas. Aproveite e utilize a Cache API para os arquivos estáticos, como o config.json, a pasta src/data ou para requisições na API.

Por se tratar de uma lib do Deno é possível simular um processo uma "instalação", nesse caso o Deno cria um Bash script no root com o call do Deno na frente para que seja possível chamar as funções, classes e etc... diretamente. Para isso basta:

deno install --allow-read --allow-write --allow-net mod.js

Os testes unitários estão no arquivo unit.test.ts e podem ser executados com:

deno test -A

A seguir aprentam-se os resumos das funções:

Nota nº1: Entre as divisões de estado e município existem 2 modelos propostos pelo IBGE. O primeiro deles é de 1990 e agrupa os municípios em microregiões e essas em meso-regiões, esse critério previa que os municípios com características sociais e econômicas semelhantes deveriam fazer parte de um mesmo grupo. Entretanto, esse conceito não se estabeleceu, uma vez que as próprias unidades administrativas se agruparam ao longo dos anos segundo os seus próprios critérios, assim em 2017 surge uma proposta de agrupamento em regiões imediatas e essas em regiões intermediárias (com nomes muito próximos do que conhecemos popularmente).

Nota nº2: A segunda classificação de 2017 ainda está sendo implementada, por exemplo: na API não contém a opção de dividir o Brasil, as macroregiões ou os estados em regiões imediatas ou intermediárias, isso significa que na opção getManyPolygons, não é possível fazer a economia de requisões; Ou seja, para usar essa classificação terá que fazer um loop com a função getOnePolygon (cuidado com o limite da API).

¹Zandbergen, P.A. Influence of geocoding quality on environmental exposure assessment of children living near high traffic roads. BMC Public Health 7, 37 (2007). https://doi.org/10.1186/1471-2458-7-37.

²Dapeng Li. Geocoding and Reverse Geocoding. Comprehensive Geographic Information Systems, Elsevier, 2018, p. 95-109, ISBN 9780128047934.

³ELIAS, Elias Nasr Naim; FERNANDES, Vivian de Oliveira; ALIXANDRINI JUNIOR, Mauro José and SCHMIDT, Marcio Augusto Reolon. The quality of OpenStreetMap in a large metropolis in northeast Brazil: Preliminary assessment of geospatial data for road axes. Bol. Ciênc. Geod. [online]. 2020, vol.26, n.3 [cited 2021-04-08], e2020012. Available from: http://www.scielo.br/scielo.php?script=sci_arttext&pid=S1982-21702020000300201&lng=en&nrm=iso. Epub Sep 21, 2020. ISSN 1982-2170. https://doi.org/10.1590/s1982-21702020000300012.

⁴John E. Vargas Muñoz, Devis Tuia & Alexandre X. Falcão (2020) Deploying machine learning to assist digital humanitarians: making image annotation in OpenStreetMap more efficient, International Journal of Geographical Information Science, DOI: 10.1080/13658816.2020.1814303.

Implementar a correção dos polígonos dos bairros.

ToDo

ToDo

Copyright Pedro Paulo Teixeira dos Santos

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.