#COVID-RADAR Metodologia: Carregamento das informações do OpenStreetMap

A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness.

Alfred Korzybski

Atualizado: 14/08/2020

OpenStreetMap (OSM)

OpenStreetMap é uma plataforma colaborativa de mapas onde diversos usuários são responsáveis por atualizar as informações de ruas, estações de metros, café, caixas eletrônicos dentre varias outras informações! Os dados são open-source e podem ser utilizados para qualquer aplicação (comercial ou não) desde que a fonte seja citada… bom fazendo nossa parte:

O estudo atual utiliza dados disponíveis através do OpenStreetMaps link para o copyright, aqui.

Aquisição dos dados do OSM

Citar a fonte… check! A primeira coisa que temos que fazer é baixar os dados do OpenStreetMaps. Por ser open-source, existe disponível literalmente dumps (arquivos que com os quais é possível replicar a base) das bases que compõem a plataforma e eles podem ser baixados através do site. Basicamente, é possível baixar o mundo inteiro que são os arquivos chamados de planet.osm, mas também algumas plataformas parceiras disponibilizam extratos de países individuais, como o Brasil. Já que o estudo inicialmente será focado no Brasil, vamos baixar os dados apenas para este, disponível no link.

O arquivo é grande por isso pode demorar um pouco para baixar. Esse arquivo contem todas as ruas com suas características, como pavimentação, limite de velocidade, sentido, e pontos de interesse, que vão desde bancos, restaurantes até banheiros públicos (que é por sinal um tema importante de arquitetura e urbanismo). Assim que terminar de baixar devemos subir o conteúdo do arquivo em um banco Postgres com extensão Postgis para poder trabalhar mais facilmente com esses dados

Subindo um Postgres com extensão PostGIS através do docker-compose

Para criar um servidor local Postgres com PostGis, vamos utilizar o docker-compose e mapear um disco para que a informação guardada não seja perdida caso o container seja excluído (se vc não tem a menor ideia do que eu estou falando… vale a pena dar uma olhada em Docker, é algo fantástico!). Primeiramente vamos criar um volume para persistir os dados:

docker volume create --name covid_radar_postgres --opt type=none --opt device=[caminho para a pasta]--opt o=bind

Abaixo segue a configuração do docker-compose.yml

version: "3.3"

services:
  db:
    image: kartoza/postgis:12.0
    ports:
      - 9999:5432
    environment:
      - POSTGRES_USER=projeto
      - POSTGRES_PASSWORD=projeto1234
      - POSTGRES_DBNAME=projeto
    volumes:
      - covid_radar_postgres:/var/lib/postgresql/

volumes:
  covid_radar_postgres:
  external: true

Usando o docker-compose com o comando docker-compose up criamos um banco local, servindo na porta 9999 o postgres.

Carregando os dados do OSM no Postgis

Para carregar os dados do OSM, no Linux pelo menos, é necessário instalar osm2pgsql. Após a instalação e com o Postgres rodando através do docker-compose pode-se carregar os dados usando o comando abaixo.

osm2pgsql --proj 4326 --slim --username projeto -W --database projeto -H 0.0.0.0 --port 9999 -d projeto dados_brutos/osm/brazil-latest.osm.pbf

Esse comando possui uma peculiaridade muito importante e que é um inferno na vida de qualquer cientista de dados georreferenciado… as projeções. E sobre isso vale a pena conversamos um pouco.

Sobre as projeções e as pequenas mentiras que nos contam os mapas

Como vimos anteriormente, a terra é redonda (ou quase redonda), e coisas redondas não ficam planas. Isso significa que não é possível ver o globo terrestre em uma cartolina na frente da sala de aula… mas todos nós um dia vimos um mapa na parede, então que diabos está acontecendo? Na verdade o que vimos nas nossas aulas de geografia, no Google Maps e Wase é o que chamamos de projeções cartográficas.

A projeção permite que algo esférico possa ser representado de forma plana, mas com um custo: a projeção distorce o espaço… Mas o que significa isso? Podemos ver o mapa abaixo, o mais tradicional de nossas aulas de geografia/Google Maps:

Basicamente o que a projeção de Mercator faz é tornar os espaços entre as latitudes e longitudes quadrados similares no mapa quando este é colocado de forma plana. Isso faz com que quanto mais próximos do polos, mais distorcida fica a área. Encontrei um site bem legal que mostra como são essas distorções, abaixo podemos ver um comparativo do tamanho do Canadá vs a África e da Groenlândia vs Brasil.

Bom agora que entendemos que os mapas planos não são reais, posso comentar que não existe só um tipo de projeção. Pensando no caso da Groenlândia, que utilidade tem usar a projeção de Mercator para um mapa do país? Basicamente nenhuma, a projeção de Mercator distorce tanto a Groenlândia que usando ele fica difícil ter uma ideia das distâncias entre as cidades do país . O que pode ser feito é gerar uma projeção centrada na Groenlândia (a de Mercator é centrada no equador por exemplo), o que daria uma aproximação visual das distâncias muito mais útil para os groenlandêses. É possível verificar algumas outras possíveis projeções nesse site.

Sobre as projeções e o infernos dos dataGIS

Voltando ao carregamento das bases do OSM, o parâmetro –proj 4326 diz qual projeção será usada para salvar os dados no PostGis, o número 4326 corresponde à projeção WGS-84 no EPSG (EPSG Geodetic Parameter Dataset) um repositório público de sistemas de projeção. Idealmente fica mais fácil se todas as bases georreferenciadas utilizadas em um projeto estejam no mesmo sistema de projeção, mas o que pode acontecer se não estiverem? Muitas coisas podem acontecer, o mais clássico é a cidade de São Paulo ir parar no meio do Atlântico quando carregar os dados no mapa ou qualquer coisa do tipo…

Acho que é isso, no final dessa etapa temos um banco de dados com todos os dados do OSM carregados em um PostGis. Usamos a projeção EPSG-4326 para carregar os dados, que deve facilitar nossa vida quando formos cruzar os pontos de interesse disponíveis do OSM com a grade de setores censitários do IBGE.