Дълги маршрути и много точки

Много TMS и системи за планиране изчисляват маршрута сами (напр. с Azure Maps, Google или TomTom) и след това се нуждаят само от таксата за точно този маршрут. За целта планираните координати се подават като точки към TollCalc API.

Подаване на точки

POST /api/calculate приема origin, destination и по избор via (междинни точки). Всяка точка е адрес или координата във формат "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" }
  }'

Ограничения и сървърно намаляване

Маршрутизиращият двигател обработва ограничен брой точки на заявка (в момента 50 общо, т.е. начало + цел + 48 via). TollCalc се справя с това интелигентно:

  • Адреси (които първо трябва да се геокодират): максимум 48 via. Повече адреси → HTTP 400.
  • Координати ("lat;lon"): можете да подадете повече. TollCalc автоматично намалява веригата до лимита на сървъра (downsampling). Началото и целта винаги се запазват, а формата на маршрута се приоритизира чрез предварителен подбор по Дъглас-Пойкер. Никой участък не се отрязва.

Важно: Намаляването работи само ако всички точки са координати ("lat;lon"). Ако има дори един адрес, продължава да важи лимитът от 48 via.

Проверка на отклонението (осигуряване на качеството)

Тъй като намалената верига теоретично може да изкриви маршрута, TollCalc проверява качеството автоматично: изчисленият маршрут се сравнява с оригиналните ви точки и максималното отклонение се оценява спрямо дължината на маршрута.

  • ≤ 2 % → нормален отговор; отклонението е в полето geometry_deviation_km.
  • > 2 % → HTTP 400 с error и обяснително warning.

Пример за отхвърлена заявка:

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

(Съобщението от API е на немски език.)

При успешно намаляване отговорът съдържа допълнително:

Поле Значение
route_source "downsampled" (липсва, ако не е било нужно намаляване)
waypoints_submitted брой подадени опорни точки
waypoints_used брой действително използвани точки за маршрута
geometry_deviation_km максимално отклонение на вашите точки от изчисления маршрут

Защо маршрутизиране с точки вместо map matching?

Човек би могъл да напасне подадена полилиния към пътната мрежа чрез map matching, вместо да маршрутизира сам. TollCalc съзнателно не прави това – по проста причина: таксата зависи точно от изминатия маршрут.

Таксата се различава според конкретния участък от магистралата, оператора, тунелите и специалните такси, системата (отворена/затворена) и държавата. Друг изход или успореден път вече дава грешна такса. Затова маршрутът трябва да е 100 % верен – не „горе-долу“.

Резултатът от map matching обаче зависи силно от качеството на входа:

  • GPS шум, честота на семплиране и проекция на подадените точки,
  • пропуски от тунели, фериботи или загуба на сигнал,
  • „опростени“ или изгладени полилинии от външни системи.

Отвън не можем да разберем дали подадената геометрия наистина е изминатият маршрут, или е опростена/изкривена версия. По принципа garbage in, garbage out бихме посочили такса за маршрут, който клиентът никога не е изминал – без да се забележи.

Затова съзнателният подход:

  • Подадените точки са задължителни точки, а не просто „предложения“. Двигателят създава от тях гарантирано проходим маршрут, който преминава през всяка точка в правилния ред.
  • Резултатът е възпроизводим, а отклонението от оригиналните ви точки е измеримо и се посочва.
  • Осигуряването на качеството (намаляване + проверка на отклонението) поемаме ние – не клиентът. Той не трябва да предоставя 100 % маршрут, нито да прави map matching: подава планирания маршрут, ние се грижим за правилния маршрут, годен за таксуване.

Компромисът е съзнателен: по-добре прозрачно отхвърляне (HTTP 400 с причина), когато подадените точки не дават еднозначен маршрут, отколкото тихо грешна такса. Щом нашият map matching се докаже, ще го преразгледаме – дотогава маршрутизирането с точки остава надеждният избор.

Кога става трудно

Намаляването работи много надеждно за нормални дълги превози. По-трудно е при:

  • Много дълги, многодневни обиколки – колкото по-дълъг е маршрутът, толкова по-голямо е разстоянието между точките след намаляването.
  • Дистрибуционни обиколки с много малки спирания и завои.
  • Участъци с ферибот или товарене (големи пропуски в GPS следата): пътният маршрут може да се отклони значително.
  • GPS изключения (лош fix, тунел): една неточна точка може да вдигне отклонението.
  • Съзнателно маршрути без такса: ако двигателят поеме по друг път, таксата също се променя.

Добри практики за TMS интеграции

  1. Една обиколка на заявка – не изпращайте историята на позициите от няколко дни.
  2. Координати вместо адреси, когато имате много точки.
  3. Достатъчно гъсто семплиране – около 1 точка на километър е достатъчно.
  4. Почистете GPS: премахнете неточните fix-ове (gpsFix=false, висока accuracy).
  5. Участъците с ферибот/товарене третирайте като отделни заявки.
  6. Логвайте/наблюдавайте geometry_deviation_km, за да следите качеството на данните.

Честна оценка

TollCalc изчислява таксата за маршрута, по който е минал маршрутизиращият двигател. При гъсти координатни вериги съвпадението е много високо (на практика обикновено под 1 %), но – за разлика от map matching – не е гаранция 1:1. Проверката на отклонението прави тази несигурност прозрачна.

→ Изчислете таксата сега