Rotas longas e muitos pontos

Muitos TMS e sistemas de planeamento calculam a rota sozinhos (por ex. com Azure Maps, Google ou TomTom) e depois precisam apenas da portagem para exatamente essa rota. Para isso, as coordenadas planeadas são enviadas como pontos para a API TollCalc.

Enviar pontos

POST /api/calculate aceita origin, destination e, opcionalmente, via (pontos intermédios). Cada ponto é um endereço ou uma coordenada no formato "lat;lon".

curl -X POST https://app.tollcalc.eu/api/calculate \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -d '{
    "origin": "48.1374;11.5755",
    "destination": "52.5200;13.4050",
    "via": ["49.0134;12.1016", "50.1109;8.6821"],
    "vehicle": { "weight": 40, "axles": 5, "emission_class": "euro6", "co2_class": "class_1" }
  }'

Limites e downsampling no servidor

O motor de routing processa um número limitado de pontos por pedido (atualmente 50 no total, ou seja, origem + destino + 48 via). O TollCalc gere isto de forma inteligente:

• Endereços (que têm de ser geocodificados primeiro): no máximo 48 via. Mais endereços → HTTP 400.
• Coordenadas ("lat;lon"): pode enviar mais. O TollCalc reduz a cadeia no servidor até ao limite (downsampling). A origem e o destino são sempre mantidos e a forma da rota é priorizada através de uma pré-seleção Douglas-Peucker. Nenhum troço é cortado.

Importante: O downsampling só se aplica se todos os pontos forem coordenadas ("lat;lon"). Assim que houver um endereço, continua a aplicar-se o limite de 48 via.

Controlo de desvio (garantia de qualidade)

Como uma cadeia reduzida pode, em teoria, distorcer a rota, o TollCalc verifica a qualidade automaticamente: a rota calculada é comparada com os seus pontos originais e o desvio máximo é avaliado em relação ao comprimento da rota.

• ≤ 2 % → resposta normal; o desvio está no campo geometry_deviation_km.
• > 2 % → HTTP 400 com error e um warning explicativo.

Exemplo de um pedido rejeitado:

{
  "error": "Downsampling-Abweichung zu groß",
  "warning": "Die aus den Stützpunkten berechnete Route weicht zu stark von der Eingabe ab: max. 67.87 km bzw. 2.14 % der Strecke (erlaubt 2 %). Bitte dichtere oder mehr Koordinaten im Format \"lat;lon\" senden."
}

(A mensagem da API está atualmente em alemão.)

Em caso de downsampling bem-sucedido, a resposta contém ainda:

Porquê routing com pontos em vez de map matching?

Poderia ajustar-se uma polilinha à rede viária através de map matching, em vez de calcularmos nós a rota. O TollCalc não o faz deliberadamente – por uma razão simples: a portagem depende exatamente da rota percorrida.

A portagem varia consoante o troço específico de autoestrada, o operador, os túneis e portagens especiais, o sistema (aberto/fechado) e o país. Uma saída diferente ou uma estrada paralela já dá uma portagem errada. A rota tem, portanto, de estar 100 % correta – não "aproximada".

O resultado do map matching depende, porém, fortemente da qualidade da entrada:

• ruído GPS, taxa de amostragem e projeção dos pontos enviados,
• lacunas por túneis, ferries ou perda de sinal,
• polilinhas "simplificadas" ou suavizadas de sistemas de terceiros.

De fora não conseguimos saber se a geometria enviada é realmente a rota percorrida ou uma versão simplificada/distorcida. Segundo o princípio garbage in, garbage out, indicaríamos uma portagem para uma rota que o cliente nunca percorreu – sem que se note.

Daí a abordagem deliberada:

• Os pontos enviados são pontos vinculativos, não meras "sugestões". O motor cria uma rota garantidamente transitável que passa por cada ponto na ordem correta.
• O resultado é reproduzível e o desvio em relação aos seus pontos originais é mensurável e é indicado.
• A garantia de qualidade (downsampling + controlo de desvio) é da nossa responsabilidade, não do cliente. O cliente não tem de fornecer uma rota a 100 % nem de fazer map matching: envia a rota planeada e nós tratamos da rota correta e elegível para portagem.

O compromisso é deliberado: preferimos um rejeição transparente (HTTP 400 com motivo) quando os pontos enviados não dão uma rota inequívoca, a uma portagem silenciosamente errada. Quando o nosso map matching for comprovadamente sólido, voltaremos a avaliá-lo – até lá, o routing com pontos continua a ser a escolha fiável.

Quando se torna difícil

O downsampling é muito fiável em viagens de longa distância normais. Torna-se mais difícil em:

• Viagens muito longas de vários dias – quanto mais longa a rota, maior o espaçamento entre pontos após o downsampling.
• Rotas de distribuição com muitas paragens pequenas e ciclos.
• Troços de ferry ou carregamento (grandes lacunas no traçado GPS): a rota rodoviária pode então desviar-se bastante.
• Valores atípicos de GPS (mau fix, túnel): um único ponto impreciso pode elevar o desvio.
• Rotas deliberadamente sem portagem: se o motor seguir outra estrada, a portagem também muda.

Boas práticas para integrações TMS

1. Uma viagem por pedido – não envie o histórico de posições de vários dias.
2. Coordenadas em vez de endereços quando tem muitos pontos.
3. Amostragem suficientemente densa – cerca de 1 ponto por quilómetro é suficiente.
4. Limpe o GPS: remova fixes imprecisos (gpsFix=false, accuracy elevada).
5. Troços de ferry/carregamento como pedidos separados.
6. Registe/monitorize geometry_deviation_km para vigiar a qualidade dos dados.

Avaliação honesta

O TollCalc calcula a portagem da rota que o motor de routing percorre. Com cadeias de coordenadas densas, a correspondência é muito alta (na prática, normalmente abaixo de 1 %), mas – ao contrário do map matching – não é uma garantia 1:1. O controlo de desvio torna esta incerteza transparente.

→ Calcular portagem agora