Real Road Distances for FLITO on Free Services

A free server, used politely

OSRM is an open-source routing engine built on OpenStreetMap roads. Its project runs a public demo server that anyone can use, on the understanding that you don't send it more than about one request a second. FLITO uses that server by default, and every request goes through one queue in the API that runs them one at a time, at least a second apart, with a 6-second timeout.

The server is a setting, not a dependency baked into the code. Point OSRM_URL at your own OSRM server and the one-a-second spacing switches off, since only the public server asks for it. Set OSRM_URL=off and FLITO never calls a routing server at all, which is what the test suite does so it never touches the network.

One request for many trucks

The busiest caller is truck matching. When a shipper looks for trucks for a load, FLITO needs the road distance from every candidate truck's base to the pickup point, and one request per truck at one request a second would take a minute for sixty trucks. OSRM's table service answers many distances in a single request, so FLITO sends all the bases as sources and the pickup as the one destination.

Bases are set by municipality, so several trucks often share the same starting point. Before asking, the API drops duplicates, then sends what's left in batches of 80 coordinates, under the demo server's limit of 100. Most searches cost one request, or none.

None, because every answer is cached for a week. The key is both points rounded to four decimal places, about 11 metres, and the cache keeps up to 20,000 pairs, dropping the oldest first. Roads between two towns don't change from one week to the next, so the second load picked up in Butwal that week gets the first one's distances for free.

When routing fails, nothing else does

A free server can be slow, down or rate-limiting you, and none of that should stop someone posting a load. Every distance call is best-effort. If the server times out, errors or can't find a road, FLITO falls back to an estimate: the straight-line distance between the two places multiplied by 1.4, rounded to whole kilometres and never less than 1. That factor is what turns Kathmandu-Pokhara's 143 km into its real 200, and it's close enough elsewhere to plan a trip on.

What it doesn't do is pretend. Each load stores the distance and where it came from, 'route' or 'estimate'. The app shows "200 km by road" for a real route and "About 200 km by road" for an estimate, and an invoice built from an estimated distance says "(approx.)" beside it. The routing tests cover each branch with a mocked server: a real answer, a cached one, a failure falling back to the estimate, and routing switched off.

Drawing the road without drawing too much

The trip map needs more than a number: it needs the line of the road. OSRM's route service returns the full geometry, and the full geometry is big. Kathmandu to Pokhara comes back as about 7,500 points, most of them a few metres apart on straight road where they change nothing on screen.

So the API thins the line before keeping it, with the Douglas-Peucker algorithm: keep the fewest points such that every dropped point is within 5 metres of the simplified line. Points are projected onto a flat plane around the line's average latitude, which is accurate enough across one country, and the result is stored and sent as an encoded polyline, the same compact string format OSRM and Google use. The line comes out several times smaller and looks the same at any zoom a phone will show.

Thinned lines are cheap enough to cache on the server, up to 2,000 of them. A trip's planned road from pickup to drop-off never changes, so it's kept for a week and the response tells the phone it may keep it for a day. The phone also keeps its last 20 trip routes on the device for a week, so opening a booking again draws the road without asking the server at all. A road from the truck's current position, used once a driver has left the planned route, goes stale fast: it's cached for 10 minutes on the server and 30 seconds on the phone.

If there's no route, the map shows both ends and the truck, with no line between them. A straight line drawn across a mountain would look like a route and be wrong, and a missing line is honest about what FLITO doesn't know.

A car's time isn't a truck's

OSRM's driving profile estimates time for a car. A loaded truck on Nepal's mixed highway and hill roads is much slower, so FLITO plans with 28 km/h, and an arrival estimate uses whichever is slower: OSRM's car time, or the distance at 28 km/h. On most roads the truck pace is the slower one, and OSRM's time only matters where it's already slower still.

The same 28 km/h decides how many days a booking blocks on a truck's calendar: driving time plus 2 hours for loading and unloading, at 10 driving hours a day, capped at 14 days. Kathmandu to Pokhara comes out at one day and Kathmandu to Nepalgunj at three. These are planning numbers rather than promises, and they only block the trip itself, not the drive home, so an owner can still pick up a return load.