Longs trajets et nombreux points

De nombreux TMS et systèmes de planification calculent eux-mêmes l'itinéraire (p. ex. avec Azure Maps, Google ou TomTom) et n'ont ensuite besoin que du péage de cet itinéraire précis. Pour cela, les coordonnées planifiées sont transmises comme points à l'API TollCalc.

Transmission des points

POST /api/calculate accepte origin, destination et, en option, via (points intermédiaires). Chaque point est soit une adresse, soit une coordonnée au format "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 et sous-échantillonnage côté serveur

Le moteur de routage traite un nombre limité de points par requête (actuellement 50 au total, soit départ + arrivée + 48 via). TollCalc le gère intelligemment :

• Adresses (à géocoder au préalable) : au maximum 48 via. Plus d'adresses → HTTP 400.
• Coordonnées ("lat;lon") : vous pouvez en transmettre davantage. TollCalc réduit la chaîne côté serveur jusqu'à la limite (sous-échantillonnage). Le départ et l'arrivée sont toujours conservés, et la forme de l'itinéraire est priorisée via une présélection Douglas-Peucker. Aucun tronçon n'est coupé.

Important : Le sous-échantillonnage ne s'applique que si tous les points sont des coordonnées ("lat;lon"). Dès qu'une adresse est présente, la limite de 48 via s'applique.

Contrôle d'écart (assurance qualité)

Comme une chaîne réduite pourrait théoriquement fausser l'itinéraire, TollCalc vérifie automatiquement la qualité : l'itinéraire calculé est comparé à vos points d'origine et l'écart maximal est évalué par rapport à la longueur du trajet.

• ≤ 2 % → réponse normale ; l'écart figure dans le champ geometry_deviation_km.
• > 2 % → HTTP 400 avec error et un warning explicatif.

Exemple de requête rejetée :

{
  "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."
}

(Le message de l'API est actuellement en allemand.)

En cas de sous-échantillonnage réussi, la réponse contient en plus :

Pourquoi le routage avec points plutôt que le map matching ?

On pourrait caler une polyligne sur le réseau routier via le map matching au lieu de router nous-mêmes. TollCalc ne le fait délibérément pas – pour une raison simple : le péage dépend exactement du trajet parcouru.

Le péage varie selon le tronçon d'autoroute précis, l'exploitant, les tunnels et péages spéciaux, le système (ouvert/fermé) et le pays. Une autre sortie ou une route parallèle donne déjà un péage erroné. L'itinéraire doit donc être exact à 100 % – pas « approximatif ».

Or le résultat du map matching dépend fortement de la qualité de l'entrée :

• bruit GPS, taux d'échantillonnage et projection des points transmis,
• lacunes dues aux tunnels, ferries ou pertes de signal,
• polylignes « simplifiées » ou lissées issues de systèmes tiers.

De l'extérieur, nous ne pouvons pas savoir si la géométrie fournie est réellement le trajet parcouru ou une version simplifiée/faussée. Selon le principe garbage in, garbage out, nous indiquerions alors un péage pour un itinéraire que le client n'a jamais emprunté – sans que cela se remarque.

D'où l'approche délibérée :

• Les points transmis sont des points contraignants, pas de simples « suggestions ». Le moteur en fait un itinéraire garanti praticable qui passe par chaque point dans le bon ordre.
• Le résultat est reproductible et l'écart par rapport à vos points d'origine est mesurable et indiqué.
• L'assurance qualité (sous-échantillonnage + contrôle d'écart) est assurée par nous, pas par le client. Le client n'a pas à fournir un itinéraire à 100 % ni à faire du map matching : il transmet son itinéraire planifié, nous nous chargeons de l'itinéraire correct et exploitable pour le péage.

Le compromis est délibéré : un rejet transparent (HTTP 400 avec motif) lorsque les points transmis ne donnent pas d'itinéraire univoque est préférable à un péage silencieusement erroné. Dès que notre map matching sera démontrablement fiable, nous le réexaminerons – d'ici là, le routage avec points reste le choix fiable.

Quand cela devient difficile

Le sous-échantillonnage est très fiable pour les trajets longue distance normaux. Cela devient plus difficile pour :

• les trajets très longs de plusieurs jours – plus l'itinéraire est long, plus l'espacement des points après sous-échantillonnage est grand ;
• les tournées de distribution avec de nombreux petits arrêts et boucles ;
• les tronçons en ferry ou de chargement (grandes lacunes dans la trace GPS) : l'itinéraire routier peut alors s'écarter nettement ;
• les valeurs aberrantes GPS (mauvais fix, tunnel) : un seul point imprécis peut faire monter l'écart ;
• les itinéraires volontairement sans péage : si le moteur passe par une autre route, le péage change aussi.

Bonnes pratiques pour les intégrations TMS

1. Un trajet par requête – n'envoyez pas l'historique de positions de plusieurs jours.
2. Des coordonnées plutôt que des adresses lorsque vous avez beaucoup de points.
3. Un échantillonnage suffisamment dense – environ 1 point par kilomètre suffit.
4. Nettoyez le GPS : supprimez les fix imprécis (gpsFix=false, accuracy élevée).
5. Tronçons ferry/chargement en requêtes séparées.
6. Journalisez/surveillez geometry_deviation_km pour garder un œil sur la qualité des données.

Évaluation honnête

TollCalc calcule le péage de l'itinéraire emprunté par le moteur de routage. Avec des chaînes de coordonnées denses, la correspondance est très élevée (en pratique généralement moins de 1 %), mais – contrairement au map matching – sans garantie 1:1. Le contrôle d'écart rend cette incertitude transparente.

→ Calculer le péage maintenant