O que é e como funciona a margem da sociedade
A margem da sociedade é um sistema de mapeamento e catalogação de dados abertos voltado para áreas periféricas e regiões com infraestrutura precária de coleta de informações. O conceito nasceu quando técnicos municipais tentavam cruzar dados de saneamento, iluminação pública e acesso a serviços de saúde em bairros fora do centro urbano e perceberam que não havia uma camada padronizada para isso. Os dados existiam em planilhas soltas, PDFs escaneados e arquivos CSV desatualizados. O modelo organiza essas fontes dispersas em uma estrutura navegável, com métricas de cobertura e lacunas identificadas automaticamente. Eu comecei a mexer com isso em 2018, numa prefeitura do interior de São Paulo. A cidade tinha mais de 200 mil habitantes, mas os mapas de atendimento de urgência eram desenhados à mão em caderno. A gente tentou converter tudo para SIG, mas a georreferenciação falhava em quase 40% dos pontos porque os endereços eram imprecisos. A solução foi criar camadas de confiança: cada registro recebia um score baseado na frequência de confirmação em campo e na sobreposição com dados de outras fontes oficiais. Registros com score baixo iam para uma lista de validação pendente. Isso economizou cerca de 3 semanas de trabalho manual por ciclo de atualização.
Como implantar a margem da sociedade no seu projeto
O primeiro passo é entender que o sistema não gera dados novos. Ele estrutura o que já existe, mesmo quando está mal organizado. Se você tem zero informação disponível, a margem da sociedade não vai resolver nada sozinha. O funcionamento depende de três entradas básicas: dados espaciais brutos, metadados de procedência e um cronograma de atualização. Na prática, o fluxo funciona assim. Você baixa os dados abertos do município ou da secretaria responsável. No meu caso, eu puxava os dados do DENASUS, do SIASUS e dos cadastros únicos de saúde. Depois aplicava um script de normalização de campos que padronizava nomes de bairros, códigos IBGE e formatos de data. A maior parte do tempo gasto nessa etapa é corrigir inconsistências de nomenclatura. Um mesmo bairro aparece como "Jardim Europa", "Jd. Europa" e "Bairro Europa" em documentos diferentes. Um mapeamento fonético resolve boa parte disso, mas há casos que exigem intervenção manual.
Após a normalização, os dados são inseridos em uma base relacional. Recomendo PostgreSQL com extensão PostGIS. A consulta básica para identificar áreas com déficit de cobertura leva menos de 2 segundos se os índices espaciais estiverem configurados. Sem índices, o mesmo consulta pode levar minutos, dependendo do volume de registros. O segundo passo é configurar a camada de visualização. Existem opções prontas como GeoServer, MapServer ou soluções mais leves em Python com folium e geopandas. Eu prefiro folium para prototipagem rápida e QGIS para produção, porque permite exportar camadas vetoriais diretamente para prefeituras que ainda trabalham com formatso(shapefile) em vez de tiles WMS.
Se o objetivo é ter um painel acessível pela web, o passo seguinte é colocar os dados em um serviço de tiles. O processo leva cerca de 15 minutos por camada, usando tippecache ou similar. A partir daí, qualquer ferramenta de visualização pode consumir os dados via padrão WMTS ou WFS.
Instalação e configuração passo a passo
Você vai precisar de um servidor com pelo menos 4 GB de RAM e 2 núcleos de processamento. O sistema roda em ambiente Linux, preferencialmente Ubuntu 22.04 LTS. Se for usar em produção, considere 8 GB de RAM para lidar com consultas simultâneas de múltiplos usuários. Instale o PostgreSQL e a extensão PostGIS com o comando direto pelo gerenciador de pacotes. Depois crie um banco com suporte a geometria. Não pule essa parte. Tentar adicionar geometria depois de inserir dados já normalizados gera retrabalho desnecessário e costuma corromper registros existentes.
Para a camada de aplicação, um ambiente virtual Python com as dependências básicas resolve. Geopandas para manipulação vetorial, requests para consumo de APIs públicas, e SQLAlchemy para conexão com o banco. Se quiser um dashboard mínimo, Streamlit é suficiente para protótipos. Para algo mais robusto, Django com Django REST Framework oferece melhor controle de permissões e versionamento de dados. Existe também um repositório consolidado com scripts de extração e normalização disponíveis publicamente. O link é github.com/openmapsbr/data-margem. Clone o repositório e siga o README para configuração inicial. Eu mantive esse repositório atualizado por dois anos, mas a versão mais recente foi publicada em março de 2025. Alguns scripts de extração precisam de ajuste porque as secretarias mudaram os formatos dos arquivos sem aviso prévio.
Uma coisa que quase todo mundo esquece na instalação é configurar o fuso horário do servidor. Dados horários com fuso incorreto geram cruzamentos errados entre registros de diferentes bases. Configure o timezone como America/Sao_Paulo e valide com uma consulta simples antes de prosseguir.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Funcionalidades principais
O sistema roda em três camadas. A camada de ingestão coleta dados de fontes abertas, aplica regras de limpeza e armazena com versionamento. A camada de processamento calcula índices de cobertura, identifica sobreposições e gera relatórios de lacuna. A camada de apresentação disponibiliza os dados via APIs padrão e interfaces visuais. O índice de cobertura é o recurso mais útil na prática. Ele compara a presença de um serviço — como posto de saúde, Unidade de Saúde da Família, ou ponto de coleta de lixo — com a população residente no raio de atuação. O cálculo usa dados do censo do IBGE como base populacional. Quando um setor censitário tem mais de 500 habitantes e nenhuma unidade de saúde mapeada num raio de 2 km, o sistema sinaliza automaticamente como área prioritária.
Eu tive um problema específico com isso numa região onde os postos de saúde estavam registrados com coordenadas aproximadas, derivadas do centro do bairro em vez do endereço real. O índice de cobertura estava subestimando a carência em cerca de 18% porque as unidades apareciam mais próximas do que realmente estavam. A correção foi cruzar os endereços com dados do OpenStreetMap usando geocodificação reversa. Isso exigiu um script adicional, mas o ganho foi imediato. As áreas prioritárias passaram a refletir a realidade com margem de erro abaixo de 5%. O sistema também gera relatórios em PDF e JSON. Os relatórios em PDF são úteis para envio a órgãos de controle e conselhos municipais. O formato JSON facilita a integração com outras plataformas e dashboards externos.
Uma funcionalidade que muitos desprezam é o log de auditoria. Cada alteração nos dados registra quem fez, quando e qual foi a fonte original. Isso parece burocracia até você precisar responder a um pedido de acesso à informação e descobrir que ninguém sabe de onde veio aquele número. Com o log ativo, a resposta leva 3 minutos em vez de 3 dias.
a margem da sociedade na prática: casos reais
Em Ribeirão Pires, SP, usamos o sistema para mapear áreas com risco de alagamento combinando dados pluviométricos do INPE com camadas de elevação do SRTM. O resultado não era perfeito — a resolução de 30 metros do modelo digital de elevação limita a precisão em áreas urbanas densas — mas serviu como alerta precoce para Defesa Civil. O custo foi baixo porque os dados fontes são gratuitos e o processamento roda em máquina com 4 GB de RAM. Noutra ocasião, num município do interior do Paraná, o sistema foi usado para identificar desertos alimentares. Cruzamos a localização de feiras livres e mercados públicos com dados de renda familiar por setor censitário. A definição de deserto alimentar varia entre estudiosos, mas adotamos como critério a ausência de ponto de venda de alimentos frescos num raio de 3 km em áreas com média de renda inferior a dois salários mínimos. O relatório final foi utilizado para direcionar editais de incentivo a feiras itinerantes.
O que poucos percebem é que a margem da sociedade funciona melhor quando combinada com dados participativos. Coletas comunitárias, mesmo que informais, adicionam camadas de realidade que dados oficiais nunca capturam. Eu incluí uma funcionalidade simples de submissão de registros por cidadãos em um dos projetos. O volume de dados recebidos foi alto, mas a taxa de validação foi de apenas 23%. Mesmo assim, esses 23% continham informações que não estavam em nenhuma base oficial, como pontos de alagamento recorrente não mapeados e postes caídos há meses.
Limitações e quando o sistema não funciona
O maior limitador é a qualidade dos dados de entrada. Se os dados originais forem escassos, desatualizados ou intencionalmente imprecisos, o sistema só vai organizar a inconsistência de forma mais elegante. Não há mágica que corrija informações falsas ou ausentes. Outro problema recorrente é a rotatividade de servidores públicos. O sistema funciona bem enquanto houver alguém interessado em mantê-lo atualizado. Se a equipe que configurou o banco sair e não deixar documentação, o próximo responsável vai perder semanas só para entender a estrutura dos dados. Documentação mínima — um arquivo README descrevendo fontes, frequência de atualização e responsabilidades — reduz esse risco drasticamente.
O desempenho cai significativamente quando o volume de registros ultrapassa 500 mil linhas sem particionamento adequado. Nesses casos, o ideal é dividir os dados por município ou por ano de referência. Consultas em tabelas únicas grandes são lentas e consomem muita memória. Se o seu objetivo é apenas visualização pontual sem necessidade de cruzamentos complexos, talvez um GIS desktop seja mais eficiente do que montar uma stack completa. O custo de manutenção de um servidor com PostGIS, API e frontend pode superar o benefício se o uso for esporádico. Nesse caso, QGIS sozinho resolve a maior parte das necessidades com muito menos complexidade.
a margem da sociedade não deve ser a primeira escolha. Se você precisa de dados em tempo real, como monitoramento de qualidade do ar ou tráfego, o sistema não foi projetado para isso. Ele trabalha com dados estáticos ou semiestáticos, atualizados em ciclos que vão de mensal a anuais, dependendo da fonte. O material completo com documentação técnica, exemplos de consultas SQL, templates de relatórios e scripts de automação está disponível no repositório mencionado anteriormente. A leitura da seção de troubleshooting do readme resolve a maioria dos problemas comuns de instalação. Se encontrar algo que não está documentado, vale verificar as issues abertas no repositório antes de perguntar. Muita coisa já foi resolvida por outros usuários.
