Long Routes & Many Waypoints

Many TMS and planning systems already calculate the route themselves (e.g. with Azure Maps, Google or TomTom) and only need the toll for exactly that route. You pass the planned coordinates as waypoints to the TollCalc API.

Passing waypoints

POST /api/calculate accepts origin, destination and optionally via (intermediate points). Each point is either an address or a coordinate in "lat;lon" format.

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" }
  }'

Limits and server-side downsampling

The routing engine processes a limited number of waypoints per request (currently 50 in total, i.e. origin + destination + 48 via). TollCalc handles this intelligently:

• Addresses (which must be geocoded first): at most 48 via. More addresses → HTTP 400.
• Coordinates ("lat;lon"): you may pass more. TollCalc automatically reduces the chain to the limit server-side (downsampling). Origin and destination are always kept, and the route shape is prioritised via a Douglas-Peucker preselection. No leg is cut off.

Important: Downsampling only applies if all points are coordinates ("lat;lon"). As soon as an address is included, the 48-via limit still applies.

Deviation check (quality assurance)

Because a reduced point chain could theoretically distort the route, TollCalc checks the quality automatically: the calculated route is compared against your original points, and the maximum deviation is evaluated relative to the route length.

• ≤ 2 % → normal response; the deviation is returned in geometry_deviation_km.
• > 2 % → HTTP 400 with an error and an explanatory warning.

Example of a rejected request:

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

On a successful downsample the response additionally contains:

Why routing with waypoints instead of map matching?

One could snap a supplied polyline onto the road network via map matching instead of routing ourselves. TollCalc deliberately does not do this – for a simple reason: the toll depends exactly on the route driven.

The toll differs by specific motorway section, operator, tunnels and special tolls, toll system (open/closed) and country. A different exit or a parallel road already yields a wrong toll. The route therefore has to be 100 % correct – not "roughly".

A map-matching result, however, depends heavily on the quality of the input:

• GPS noise, sampling rate and projection of the supplied points,
• gaps caused by tunnels, ferries or signal loss,
• "simplified" or smoothed polylines from third-party systems.

From the outside we cannot tell whether a supplied geometry really is the route driven or a simplified/distorted version. Following garbage in, garbage out, we would then report a toll for a route the customer never drove – without it being noticed.

Hence the deliberate approach:

• The supplied points are binding waypoints, not merely "suggestions". The routing engine turns them into a guaranteed drivable route that passes every waypoint in the correct order.
• The result is reproducible, and the deviation from your original points is measurable and reported.
• Quality assurance (downsampling + deviation check) is handled by us – not by the client. The client should not have to deliver a 100 % route or run map matching: it submits its planned route, we take care of the correct, toll-capable route.

The trade-off is deliberate: a transparent rejection (HTTP 400 with a reason) when the supplied points do not yield an unambiguous route is preferable to a silently wrong toll. Once our map matching demonstrably holds up, we will revisit it – until then, routing with waypoints remains the reliable choice.

When it gets difficult

Downsampling is very reliable for normal long-haul tours. It becomes harder for:

• Very long, multi-day tours – the longer the route, the larger the point spacing after downsampling.
• Distribution tours with many small stops and loops.
• Ferry or loading segments (large gaps in the GPS track): the road route can then deviate noticeably.
• GPS outliers (poor fix, tunnel): a single inaccurate point can push the deviation up.
• Deliberately toll-free routes: if the routing engine takes a different road, the toll changes too.

Best practices for TMS integrations

1. One tour per request – do not send the position history of several days.
2. Coordinates instead of addresses when you have many points.
3. Sample densely enough – about 1 point per kilometre is sufficient.
4. Clean up GPS: remove inaccurate fixes (gpsFix=false, high accuracy) first.
5. Treat ferry/loading segments as separate requests.
6. Log/monitor geometry_deviation_km to keep an eye on data quality.

Honest assessment

TollCalc calculates the toll for the route driven by the routing engine. With dense coordinate chains the match is very high (in practice usually below 1 %), but – unlike map matching – it is not a 1:1 guarantee. The deviation check makes this uncertainty transparent.

→ Calculate toll now