Como montar e usar um mapa de cidades de São Paulo com dados reais
Mapa cidades sp é algo que parece simples até você tentar construir um. A maioria das pessoas baixa um shapefile pronto, joga no QGIS e acha que tá resolvido. O problema é que os dados nunca chegam limpos. Coordenadas fora do padrão, nomes de municípios duplicados, fronteiras desatualizadas depois de divisões territoriais recentes. Você gasta mais tempo tratando dados do que realmente mapeando. O que eu recomendo é começar pelo IBGE. O Censo do IBGE disponibiliza arquivos de municípios com codeudos geodésicos atualizados. O código de cada município segue a resolução 1.105/2019, que reorganizou as divisões regionais. Se você está usando uma base anterior a 2020, pelo menos 12 cidades podem não bater com a realidade atual. Eu fiz isso na última atualização de um projeto e levei três dias para corrigir porque dois municípios tiveram alterações de perímetro que o shapefile antigo simplesmente não refletia.
Configurando o projeto certo desde o início
O erro mais comum é abrir o QGIS e já começar a carregar camadas sem definir o sistema de referência de coordenadas. Use o SIRGAS 2000, EPSG 4674, para dados tabulares e o projetado EPSG 4674 também funciona para visualização. Se você trabalhar com web, o EPSG 3857 é o padrão, mas ele distorce áreas e distâncias de forma significativa perto da linha do equador. São Paulo fica em latitude suficiente pra distorção incomodar em qualquer análise que envolva área ou distância real. Eu costumo manter duas visualizações abertas: uma em 4674 para conferência territorial e outra em 3857 para incorporação em dashboards web. Não adianta reclamar depois que os dados não batem. A maioria dos problemas que vejo em fóruns e demandas de clientes vem exatamente dessa confusão de CRS.
Fontes de dados confiáveis
Além do IBGE, o mapa cidades sp ganha densidade quando você cruza com outras bases. A SEADE tem dados socioeconômicos por município atualizados trimestralmente. O TSE tem informações eleitorais que valem a pena importar se o mapa for para análise política. O GeoSUS, do Ministério do Desenvolvimento Regional, traz dados de saneamento e habitação. O problema prático é que esses dados têm formatos diferentes. O IBGE entrega em DBF e SHP. A SEADE em XLSX com colunas que mudam de nome a cada ano. O TSE em PDF. Eu desenvolvi um script simples em Python que padroniza tudo para GeoJSON com código do município no padrão do IBGE como chave de junção. O script leva cerca de 15 minutos pra processar três anos de dados da SEADE. Sem ele, o mesmo trabalho levaria meia manhã.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Erros que todo mundo comete na primeira vez
A primeira coisa que dá errado é a junção de tabelas. Se o código do município na sua tabela não for com seis dígitos preenchidos com zero à esquerda, o join falha silenciosamente. O QGIS não avisa, simplesmente não conecta os dados. Eu já perdi uma tarde inteira achando que o problema era a camada, quando na verdade era um campo numérico sem formatação adequada. A solução é transformar tudo em string formatada antes de fazer qualquer join. O segundo erro crônico é não verificar a data de referência dos dados. Um mapa com PIB municipal de 2019 publicado em 2024 passa uma informação obsoleta que parece legítima. Sempre coloque no cabeçalho ou rodapé do mapa o ano base dos dados utilizados. Isso não é apenas boa prática, é ética básica em cartografia.
Exportação para web sem comprometer a qualidade
Se o objetivo é publicar online, o GeoJSON puro funciona para poucas camadas. Quando você ultrapassa 500 mil feições, o navegador começa a travar. A saída mais prática é usar o Mapbox GL com tiles vetoriais gerados pelo tippecanoe. O tippecanoe simplifica os polígonos automaticamente baseado no zoom level. Um shapefile de 800 MB vira um conjunto de tiles que carrega em segundos. O problema dessa abordagem é que a simplificação pode remover características relevantes em baixo zoom. Se você está mapeando pequenas ilhas ou faixas de fronteira, o tippecanoe às vezes as funde com o terreno vizinho. Minha workaround foi ajustar o parâmetro oflow com valor negativo e definir um tolerance menor para as camadas que exigem precisão. O tamanho do arquivo aumenta, mas a fidelidade spatial se mantém.
Limitações que ninguém gosta de
Um mapa de cidades de São Paulo nunca vai ser completo por si só. Ele depende inteiramente da qualidade dos dados que você injeta. Dados municipais sofrem com subnotificação crônica em regiões de fronteira e áreas rurais. O próprio IBGE reconhece que municípios pequenos têm margem de erro maior em indicadores sociais. Se você está construindo um mapa para tomada de decisão pública, precisa deixar claro onde os dados são frágeis. A alternativa quando o QGIS não resolve é migrar para PostgreSQL com PostGIS. O custo de configuração é maior, mas a capacidade de consulta espacial sobe ordens de magnitude. Você consegue fazer buffer analysis, overlay de camadas múltiplas e agregação por região metropolitana sem exportar e importar arquivos repetidamente. Se o projeto for grande ou exigir atualizações frequentes, o PostGIS compensa o tempo inicial de configuração em menos de uma semana de uso.
Aprendi isso na prática quando precisei cruzar dados de 187 municípios com quatro camadas de zoneamento ambiental diferente. No QGIS, a cada atualização de dado eu levava quase uma hora. Migrando para PostGIS, o mesmo processo ficou em cerca de 90 segundos.
