Delivery Route Planner with CSV Import: The File Shape Q-Logos Reads and What Happens to Bad Rows

Who this page is for

You have a spreadsheet of delivery stops and you want a sensible visiting order without retyping every address. This page describes exactly how the CSV upload on the Q-Logos route page works in the current live version: the file shape it reads, what it does with rows it cannot use, and the one thing it deliberately does not do for you.

If you want the background on how the ordering itself is computed, read how the multi-stop route planner works first. This page only covers getting your stops into it from a file.

The file shape: address, latitude, longitude

The planner reads a plain CSV file with one stop per line and three columns in this order:

1. Address (or any label you like). This column is used as the stop's name on the list and the map. It is not looked up.

2. Latitude, as a decimal number.

3. Longitude, as a decimal number.

A header line such as `address,lat,lng` is optional. The parser treats the first line as a header when its second and third columns are not numbers and the line mentions something like lat, lng, lon or address. If your first line is already a real stop, it is read as one.

Two formatting details decide whether a row survives:

• Lines are split on commas. Each field then has surrounding double quotes removed, but the split happens first. So an address written as `12 High Street, Leeds` pushes `Leeds` into the latitude column, the coordinates move one column to the right, and the row is skipped. Remove commas from the address column before you export.
• Coordinates are range-checked. Latitude must be between -90 and 90, longitude between -180 and 180, and exactly 0,0 is rejected because it is almost always a placeholder. A swapped column order usually fails this check straight away, which is a useful early warning.

A blank address is allowed; the stop is labelled `Stop N` with its position in the imported list.

What happens to rows without coordinates

Rows whose second and third columns are missing, blank, non-numeric or out of range are skipped. After the upload the page shows a notice with how many rows were skipped and the first few of their line numbers, so you can go back to the spreadsheet and repair them.

What does not happen matters just as much: a skipped row is never placed at a default or guessed position, and the planner never tries to infer coordinates from the address text. If a stop is not on the map after import, it is because its row had no usable coordinates, and the notice tells you which line to look at.

Geocoding is your job before upload

This is the limit most people hit. The CSV path does not geocode. It reads the coordinates you give it and nothing else.

Geocoding on the Q-Logos route page exists, but only in the typed-address box: you type one address, pick a suggestion, and that lookup runs through OpenStreetMap Nominatim via the app's own server route. When the lookup fails, the stop is refused with a message rather than guessed. There is no bulk version of that lookup for a file.

So if your spreadsheet has addresses but no coordinates, the workflow is:

1. Geocode the sheet with whatever tool you already use for that, and add latitude and longitude columns.

2. Spot-check a few rows on a map, especially any with ambiguous street names.

3. Export as CSV in the address, latitude, longitude order.

4. Upload on the route page.

Doing the geocoding up front is more work than a one-click import, but it also means the positions the planner optimizes are ones you have seen and can defend.

Uploading and ordering

The upload appends the file's rows to whatever is already in the stop list; it does not replace it. If you are starting a fresh plan, use the Clear all button first. If the list was empty, the first row of the file becomes the origin.

That first stop matters because the solver keeps the first stop as the start and reorders the rest into an open path with no return leg. Put your depot or starting point on the first data line.

When you press the optimize button, the stops go to the Q-Logos server, which orders them with simulated annealing. The backend calls the method quantum-inspired; it is classical simulated annealing running on ordinary servers, with no quantum hardware involved. You get three alternative orderings on the map and as cards, with the server's note that they are three independent runs of the same distance objective, printed underneath.

Distances on those cards are straight-line between consecutive coordinates, and each card labels them as such. They are not road distances, and the durations shown are modelled estimates from that straight-line model, not measured drive times. If some of your stops sit across a river or a motorway from each other, treat the ordering as a first pass to review, not a finished plan.

What the CSV import does not do

To save you a wasted export:

• It does not read Excel or XLSX files; export to CSV first.
• It does not offer column mapping; the three columns must be in the address, latitude, longitude order.
• It does not geocode addresses in the file, in bulk or one at a time.
• It does not carry delivery time windows, package counts, vehicle assignments or any column beyond the first three; extra columns are ignored.
• It does not split one file across several vehicles. The route page plans one stop list for one vehicle, and it does not model traffic, weather, road networks or vehicle capacity.

Plan limits

Each plan allows a certain number of stops per route and routes per day. Those limits are listed on the pricing page rather than repeated here, because they change with the plan and the page is the source of truth. If a file has more stops than your plan allows, trim it before uploading.

To try it with your own list, create a free account, open the route page, and upload your CSV.