Дълги маршрути и много точки
Много 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"). Ако има дори един адрес, продължава да важи лимитът от 48via.
Проверка на отклонението (осигуряване на качеството)
Тъй като намалената верига теоретично може да изкриви маршрута, 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 точка на километър е достатъчно.
- Почистете GPS: премахнете неточните fix-ове (
gpsFix=false, високаaccuracy). - Участъците с ферибот/товарене третирайте като отделни заявки.
- Логвайте/наблюдавайте
geometry_deviation_km, за да следите качеството на данните.
Честна оценка
TollCalc изчислява таксата за маршрута, по който е минал маршрутизиращият двигател. При гъсти координатни вериги съвпадението е много високо (на практика обикновено под 1 %), но – за разлика от map matching – не е гаранция 1:1. Проверката на отклонението прави тази несигурност прозрачна.