Cruzeiro Rosa Dos Ventos

Como criar um cruzeiro rosa dos ventos funcional para mapas e interfaces

A maioria das pessoas tenta construir uma rosa dos ventos do zero e acaba com um elemento que não alinha direito ou que fica estranho quando o mapa gira. Eu já vi esse problema em projetos de cartografia web e apps de trilhas. O segredo não é reinventar a bússola, é entender como ela se comporta quando o norte do mapa muda de direção. Um cruzeiro rosa dos ventos é basicamente um indicador direcional posicionado sobre um mapa ou interface. Ele mostra onde é o norte, o sul, leste e oeste, com os pontos cardeais (N, S, L, W) e, quando necessário, os colaterais. Diferente de uma bússola simples, o cruzeiro pode ser estático ou dinâmico — ou seja, ele gira junto com o mapa ou permanece fixo apontando sempre para o norte geográfico. No Brasil, esse tipo de elemento é comum em mapas topográficos, aplicativos de navegação offshore e jogos que usam orientação espacial. A versão mais prática é aquela que combina o cruzeiro tradicional com setas de direção e, às vezes, uma agulha magnética integrada.

Aqui vai algo que poucos explicam: existem dois comportamentos fundamentais que todo desenvolvedor precisa escolher antes de começar. No modo mapa fixo, o cruzeiro rosa dos ventos gira quando o usuário rotaciona o mapa. No modo cruzeiro fixo, ele permanece apontando para o norte verdadeiro enquanto o mapa roda sob ele. A confusão acontece quando o programador mistura os dois modes sem avisar o usuário, e aí a interface parece quebrada porque o cruzeiro gira de um jeito e o mapa de outro. No meu projeto de um app de navegação costeira, eu enfrentei um problema específico: quando o dispositivo tinha GPS fraco, a rotação do mapa era instável e o cruzeiro entrava em tremor constante, tipo 15 graus pra lá e pra cá a cada segundo. Isso deixava o usuário tonto e pouco confiável. A solução que funcionei foi adicionar um filtro de média móvel exponencial na rotação bruta do sensor — basicamente eu peguei os últimos 8 valores de ângulo, apliquei um peso de 0,7 para o valor atual e 0,3 para a média anterior, e o tremor caiu praticamente a zero. O código ficou algo assim: anguloFiltrado = anguloAtual * 0,7 + anguloAnterior * 0,3

Isso resolveu o problema visual, mas trouxe outra limitação: o cruzeiro passou a ter um leve atraso de cerca de 200ms em relação à rotação real do mapa. Para navegação costeira isso foi aceitável, mas se você estiver construindo algo que precisa de resposta instantânea, como um jogo de realidade aumentada, o filtro pode ser demais. Nesses casos, eu recomendo usar apenas suavização por interpolação linear sem peso pesado. Outro ponto que as pessoas geralmente erram: a escala. Um cruzeiro rosa dos ventos muito grande invade o conteúdo do mapa e um muito pequeno se perde. A regra prática que eu uso é ocupar no máximo 12% da altura da viewport em dispositivos móveis e 8% em desktop. Teste isso em telas reais, porque simuladores muitas vezes distorcem as proporções. Se você quer implementar do jeito certo, comece definindo se o seu cruzeiro será SVG ou canvas. SVG é mais fácil de estilizar com CSS e escala perfeitamente, mas canvas é melhor se você precisa de muitos pontos de dados animados junto com o indicador. Eu uso SVG na maioria dos projetos simples e canvas quando o cruzeiro precisa mostrar trajetórias em tempo real sobrepostas.

Uma armadilha comum com SVG é esquecer que o atributo transform-origin do CSS não funciona de forma consistente em todos os navegadores para elementos que já estão dentro de um setAttribute diretamente no atributo transform do elemento, ou envolver o cruzeiro dentro de um separado e rotacionar esse grupo. A segunda opção é mais limpa e evita problemas de rendering em Firefox antigo. Para quem quer algo pronto, existem bibliotecas como Leaflet-rotatemap e Turf.js que já integram rotação de mapa com indicadores direcionais, mas elas costumam ser pesadas se você só precisa de um simples cruzeiro. Um alternativa leve é usar a API de orientação do dispositivo com o evento deviceorientation e calcular o ângulo de rotação manualmente, depois aplicar ao cruzeiro via transform CSS. Aqui está um exemplo mínimo que funciona na maioria dos navegadores modernos:

const anguloNorte = evento.alpha; // graus do norte magnético
const cruzeiro = document.getElementById('cruzeiro');
cruzeiro.style.transform = 'rotate(' + (-anguloNorte) + 'deg)'; Isso é o básico. Para produção, você precisa ainda lidar com a diferença entre norte magnético e norte geográfico (declinação magnética), que varia conforme a localização no planeta. No Brasil, a declinação em São Paulo é de aproximadamente -21 graus, então o cruzeiro rosa dos ventos precisa desse ajuste se você quer precisão real. Sem esse dado, a seta do norte vai apontar para o norte magnético e não para o verdadeiro, o que é um erro silencioso que ninguém percebe até tentar usar para navegação de verdade. Se o seu projeto não precisa de precisão topográfica, usar apenas o sensor de rotação do dispositivo resolve. Se precisa, você tem duas opções: integrar uma API de declinação magnética como a do NOAA (gratuita, mas requer URL de consulta) ou hardcodar valores aproximados por região se o escopo for limitado. A primeira opção é mais correta, a segunda é mais rápida e raramente causa erro perceptível para uso casual.

A parte mais chata é o teste. Sempre teste o cruzeiro rosa dos ventos em campo, com o dispositivo em movimento real. Emuladores e simulações nunca capturam as vibrações, a luz variável e a forma como o dedo escorrega na tela enquanto o usuário está andando. Eu perdi meio dia ajustando um cruzeiro que parecia perfeito no simulador e na prática travava toda vez que o usuário passava a mão perto do sensor de proximidade do celular. Resumindo: escolha o modo de fixação, defina a escala, decida SVG ou canvas, aplique o filtro de rotação adequado ao seu caso de uso, e corrija a declinação magnética se precisar de precisão. Qualquer passo pulado vai aparecer como frustração do usuário depois.