TollCalc

Długie trasy i wiele punktów

Wiele systemów TMS i planowania samo oblicza trasę (np. w Azure Maps, Google lub TomTom), a następnie potrzebuje już tylko myta dla dokładnie tej trasy. W tym celu zaplanowane współrzędne przekazuje się jako punkty do API TollCalc.

Przekazywanie punktów

POST /api/calculate przyjmuje origin, destination oraz opcjonalnie via (punkty pośrednie). Każdy punkt to adres albo współrzędna w formacie "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" }
  }'

Limity i downsampling po stronie serwera

Silnik routingu przetwarza ograniczoną liczbę punktów na żądanie (obecnie 50 łącznie, czyli start + cel + 48 via). TollCalc radzi sobie z tym inteligentnie:

  • Adresy (które najpierw trzeba geokodować): maksymalnie 48 via. Więcej adresów → HTTP 400.
  • Współrzędne ("lat;lon"): możesz przekazać więcej. TollCalc redukuje łańcuch po stronie serwera do limitu (downsampling). Start i cel są zawsze zachowywane, a kształt trasy jest priorytetyzowany przez wstępny wybór metodą Douglasa-Peuckera. Żaden odcinek nie jest odcinany.

Ważne: Downsampling działa tylko wtedy, gdy wszystkie punkty są współrzędnymi ("lat;lon"). Gdy pojawi się adres, nadal obowiązuje limit 48 via.

Kontrola odchylenia (zapewnienie jakości)

Ponieważ zredukowany łańcuch może teoretycznie zniekształcić trasę, TollCalc automatycznie sprawdza jakość: obliczona trasa jest porównywana z Twoimi oryginalnymi punktami, a maksymalne odchylenie oceniane względem długości trasy.

  • ≤ 2 % → normalna odpowiedź; odchylenie jest w polu geometry_deviation_km.
  • > 2 % → HTTP 400 z error i wyjaśniającym warning.

Przykład odrzuconego żądania:

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

(Komunikat API jest obecnie po niemiecku.)

Przy udanym downsamplingu odpowiedź zawiera dodatkowo:

Pole Znaczenie
route_source "downsampled" (brak, jeśli redukcja nie była potrzebna)
waypoints_submitted liczba przesłanych punktów
waypoints_used liczba faktycznie wyznaczonych punktów trasy
geometry_deviation_km maksymalne odchylenie Twoich punktów od wyznaczonej trasy

Dlaczego routing z punktami, a nie map matching?

Przekazany polilinię można by dopasować do sieci drogowej za pomocą map matchingu, zamiast samemu wyznaczać trasę. TollCalc celowo tego nie robi – z prostego powodu: myto zależy dokładnie od przejechanej trasy.

Myto różni się w zależności od konkretnego odcinka autostrady, operatora, tuneli i opłat specjalnych, systemu (otwarty/zamknięty) oraz kraju. Inny zjazd lub równoległa droga daje już błędne myto. Trasa musi więc być w 100 % poprawna – nie „w przybliżeniu".

Wynik map matchingu zależy jednak silnie od jakości danych wejściowych:

  • szum GPS, częstotliwość próbkowania i projekcja przekazanych punktów,
  • luki spowodowane tunelami, promami lub utratą sygnału,
  • „uproszczone" lub wygładzone polilinie z systemów zewnętrznych.

Z zewnątrz nie możemy stwierdzić, czy przekazana geometria to rzeczywiście przejechana trasa, czy jej uproszczona/zniekształcona wersja. Zgodnie z zasadą garbage in, garbage out podalibyśmy myto dla trasy, której klient nigdy nie przejechał – niezauważenie.

Dlatego świadome podejście:

  • Przekazane punkty są punktami obowiązkowymi, a nie „sugestiami". Silnik tworzy z nich gwarantowanie przejezdną trasę, która przechodzi przez każdy punkt we właściwej kolejności.
  • Wynik jest powtarzalny, a odchylenie od Twoich oryginalnych punktów jest mierzalne i podawane.
  • Zapewnienie jakości (downsampling + kontrola odchylenia) bierzemy na siebie my – nie klient. Klient nie musi dostarczać trasy w 100 % ani uruchamiać map matchingu: przekazuje zaplanowaną trasę, a my dbamy o poprawną trasę nadającą się do naliczenia myta.

Kompromis jest świadomy: wolimy przejrzyste odrzucenie (HTTP 400 z uzasadnieniem), gdy przekazane punkty nie dają jednoznacznej trasy, niż po cichu błędne myto. Gdy nasz map matching okaże się niezawodny, wrócimy do tematu – do tego czasu routing z punktami pozostaje niezawodnym wyborem.

Kiedy staje się to trudne

Downsampling działa bardzo niezawodnie w normalnych trasach długodystansowych. Trudniej jest przy:

  • Bardzo długich, wielodniowych trasach – im dłuższa trasa, tym większy odstęp między punktami po downsamplingu.
  • Trasach dystrybucyjnych z wieloma małymi przystankami i pętlami.
  • Odcinkach promowych lub załadunkowych (duże luki w śladzie GPS): trasa drogowa może wtedy znacznie się różnić.
  • Odstających wartościach GPS (słaby fix, tunel): jeden niedokładny punkt może podnieść odchylenie.
  • Celowo bezpłatnych trasach: jeśli silnik pojedzie inną drogą, myto też się zmieni.

Dobre praktyki dla integracji TMS

  1. Jedna trasa na żądanie – nie wysyłaj historii pozycji z kilku dni.
  2. Współrzędne zamiast adresów, gdy masz wiele punktów.
  3. Wystarczająco gęste próbkowanie – około 1 punkt na kilometr wystarczy.
  4. Oczyść GPS: usuń niedokładne fixy (gpsFix=false, wysokie accuracy).
  5. Odcinki promowe/załadunkowe jako osobne żądania.
  6. Loguj/monitoruj geometry_deviation_km, aby pilnować jakości danych.

Uczciwa ocena

TollCalc oblicza myto dla trasy, którą przejechał silnik routingu. Przy gęstych łańcuchach współrzędnych zgodność jest bardzo wysoka (w praktyce zwykle poniżej 1 %), ale – inaczej niż przy map matchingu – nie jest gwarancją 1:1. Kontrola odchylenia czyni tę niepewność przejrzystą.

→ Oblicz myto teraz