On paper, load planning is a geometry puzzle. In a real trailer the puzzle has more rules. The drums for the last stop can't sit behind the pallets for the first. Fragile goods can't carry anything. And a plan that fits perfectly can still put too much weight on one axle.
Our packing engine handles those rules for trips inside Transportial, and it powers the load calculator on this website. It is now also a plain API call: POST /load-plan/calculate. You send load spaces and units, and you get back every unit's position. Nothing needs to exist in your account and nothing is stored.
What you send
A load space is either a catalogue code or your own inner dimensions. Units are whole millimetres and grams, which keeps the geometry exact.
{
"equipment": [{ "code": "EU_TRAILER_MEGA" }],
"items": [
{ "id": "eur-pallets", "quantity": 12, "lengthMm": 1200, "widthMm": 800, "heightMm": 1500, "weightG": 450000, "unloadStop": 1 },
{ "id": "drums", "quantity": 8, "lengthMm": 600, "widthMm": 600, "heightMm": 900, "weightG": 200000, "stackable": false, "unloadStop": 2 }
],
"options": { "timeBudgetMs": 500 }
}This run comes back as FITS, with all 20 units placed on 3.6 loading metres. The first unit placed is a drum at the very front of the trailer, because the drums come off last.
Step one: build greedy plans
The engine always starts with a few deterministic plans. It sorts the goods two ways (stackable before fragile and large before small, or largest face first) and tries each order with two ways of grouping identical units into blocks.
Each plan is built by placing units at extreme points: the corners that appear next to units already loaded. It's a small set of candidate positions, and it is what keeps the construction fast. Every placement has to pass the rules: the unit fits through the door, enough of its base is supported, nothing on top of it weighs too much, and it doesn't block an earlier drop.
Step two: search for a better one
Greedy plans are good but rarely the best. With the remaining time budget, the engine runs a biased random-key genetic algorithm. A candidate is a list of numbers that decide the loading order, how each unit is turned and how it is grouped. The best candidates are kept, others are crossed and mutated, and each one is decoded into a real plan by the same construction as step one. That means a candidate can never break a rule.
Plans are ranked by placed volume, then fewest units left behind, then shortest used floor, then lowest axle utilisation. When everything fits and nothing has improved for a while, the search stops early.
Rules that come from the road
Unload order
Units carry a stop number. Anything leaving later goes deeper, so nobody has to unload half a trailer to reach one pallet. Side doors and top-loaded equipment are handled too.
Axle loads
Give a load space two supports with their limits, or use a catalogue entry that has them, and each plan is checked against both. The response reports the load on each support, and the centre of gravity.
An honest "no"
If something doesn't fit, the status is DOES_NOT_FIT and unplaced names each unit and the reason: too large, overweight, axle limit, no space, unload order or out of time.
Try it
The load planning page has the endpoint, the limits and the full response. For a walkthrough, see the guide in our documentation. To plan the tours around these loads as well, have a look at our multi-modal VRP.
