MapScale for fleet management

The dot on the map is moving. The map itself is the bill.

A tracking screen that stays open all day is the map view most likely to be priced by the load, and the geometry under it is often wrong in ways a straight line cannot show.

Live picture

Six vehicles, one shift, real roads.

Every line below is a route the engine actually returned. Press play to run the shift, or pick a vehicle to follow it — the trail behind each one is the road it has already covered, not the pings it sent.

What breaks

A dispatch map is not a one-off lookup. It is a screen a person watches for hours, redrawing as vehicles move, and the numbers next to each dot are only as good as the road geometry computing them.

The map that stays open all day is priced like the one that does not

Per-load or per-session pricing charges for every redraw, every pan, every vehicle update on the one screen dispatch never closes — the busiest map in the operation becomes the most expensive one it owns.

Straight-line progress and ETAs are wrong wherever a river or a one-way soi is involved

Progress and time-to-arrival computed from the distance between two points ignore the road between them. An expressway ramp, a canal crossing or a one-way soi turns a short line into a long detour, and Bangkok has all three.

A GPS trace is not the route a vehicle drove

Pings drift off the carriageway, cluster at intersections, and drop out under elevated roads and in basements. Plotting the raw points as “where it has been” shows the noise, not the road the vehicle actually took.

What it costs

Fleet ops already knows the fleet size and the hours the dispatch screen runs. The line worth checking is what each of those hours costs on a map billed per load.

vehicles tracked × hours the dispatch map stays open per day × per-session map-load cost

Put your own numbers in the calculator

The endpoints you would use

GET/styles/v1/{styleId}

The tracking map surface itself — the screen dispatch leaves open all day, not billed by the load.

POST/v1/route

The assigned vehicle's planned road geometry, the line the travelled trail and the remaining distance are measured against.

POST/v1/matrix

Every vehicle against the next job in one call, so reassignment is by drive time rather than by which pin looks closest.

GET/v1/isochrone

Whether a vehicle can still reach the stop inside the window, as a polygon you can test a point against instead of reading it off the map.

A request you can run

Every vehicle against the new job, then the assigned vehicle's road geometry. Both against the live API.

# Every vehicle already on the road against the new job, in one call —
# reassign by drive time, not by which pin looks closest on screen.
curl -X POST -H "X-MapScale-Key: $MAPSCALE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"sources":[[100.5018,13.7563],[100.5231,13.7367],[100.5601,13.7279]],"targets":[[100.5348,13.7466]],"profile":"driving"}' \
  "https://api.mapscale.io/v1/matrix"

# The assigned vehicle's actual road geometry — what "most of the route is
# done" gets measured against, not the straight line to the stop.
curl -X POST -H "X-MapScale-Key: $MAPSCALE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"coordinates":[[100.5231,13.7367],[100.5348,13.7466]],"profile":"driving"}' \
  "https://api.mapscale.io/v1/route"

What we can actually claim

Progress, remaining route and ETA run on the same Valhalla 3.5.1 engine over Thailand-wide OpenStreetMap road data behind the rest of this site — see the routing notes for the exact tileset date and where that road layer is thin, rather than a blanket coverage claim.

Bring us your data.

A 30-minute review against your own addresses — not a demo dataset. You will see the failure rate before you see a price.

Book a 30-min review Read the docs