Why Latitude and Longitude Don't Work in the Solver
Latitude and longitude cannot be entered directly into the Traveling Salesman Solver for reliable geographic distance, because the tool measures every segment using straight-line Euclidean distance on a flat coordinate plane, not degrees of arc on a curved Earth. The solver accepts three things per row — a name, an x value, and a y value — and treats those two numbers as Cartesian coordinates on that plane. A degree of latitude near the equator is roughly 111 kilometers, but a degree of longitude shrinks as you move toward the poles, and both numbers wrap or distort across the antimeridian. Plugging raw degrees into the distance formula sqrt((x2−x1)²+(y2−y1)²) yields a number whose meaning depends on where on Earth the points sit, so the route length becomes meaningless for real-world planning. The solver calls no map or routing API, sends nothing to a server, and applies only a deterministic nearest-neighbor plus 2-opt heuristic to whatever numbers you type, so the safety net is whatever projection or coordinate system you choose to feed it.
The traveling salesperson problem is the formal name for finding the shortest closed tour through a list of points, and the Traveling Salesman Solver tackles that objective by minimizing the sum of straight-line distances between consecutive stops plus the return-to-start leg, applying a bounded nearest-neighbor construction followed by deterministic 2-opt improvement. Latitude and longitude look like just two numbers, so it can feel natural to paste them into the x and y columns, but the math underneath assumes both axes share a single linear unit. A degree of longitude near London covers about 70 kilometers of ground; the same degree near Quito covers about 111 kilometers. The straight-line distance between two cities computed in degrees is therefore smaller than reality in some directions and larger in others, and the error compounds as the route grows longer or crosses latitudes with very different longitude scaling.
The same mismatch breaks at the antimeridian. If one stop sits at longitude +179 and the next at longitude −179, a naive Euclidean calculation walks the route the long way around the globe — across the date line and back — instead of the short hop across the Pacific. Real dispatch tools use geodesic libraries or a routing matrix that already knows about this; the heuristic on this page neither knows nor compensates.
What the Solver Actually Treats Coordinates As
The solver accepts one location per line as name, x, y, and assumes both x and y are numbers on a shared linear axis. Valid input includes meters on a local survey drawing, pixels in a layout grid, unitless classroom coordinates, and projected coordinates from a flat map. Three constraints gate the input: between 3 and 50 distinct coordinate pairs, no duplicate coordinates, and names that contain no commas. Duplicate coordinates are rejected because two separately named points at exactly the same location make route display ambiguous, and the 50-point ceiling keeps the quadratic 2-opt pass responsive on a normal browser.
The distance between any two consecutive stops is computed with sqrt((x2−x1)²+(y2−y1)²), which is the textbook Euclidean length on a plane. For example, using (0,0) and (3,4) as two stops, the segment length is sqrt((3−0)²+(4−0)²) = sqrt(9+16) = sqrt(25) = 5, in whatever unit both axes share. The tour starts at the first row, returns to it at the end, and visits every other point exactly once. The first row is fixed as the start so repeated runs with identical input produce identical output, and exact ties at the nearest-neighbor step keep the original input order to keep the construction stable.
Entering Coordinates Into the Traveling Salesman Solver
If your coordinates already live on a flat plane, the workflow is short and the only decisions you make are naming, ordering, and starting row.
- Open the Traveling Salesman Solver in your browser.
- List each stop on its own line as name, x, y, with x and y separated by commas inside the row and a line break between rows.
- Place the location you want to start from in the first row — that row is fixed as the start and is where the tour returns at the end.
- Confirm the input has at least 3 and at most 50 distinct coordinate pairs, no duplicates, and no commas inside the names.
- Build the approximate tour and read both the initial nearest-neighbor distance and the 2-opt-improved distance in the result.
- Inspect the closed route and the listed assumptions before copying it — copy the name sequence only when straight-line Euclidean distance is genuinely what your task needs.
- Compare several starting-point orders if solution quality matters; a different start lands in a different local minimum, and the fixed-start behavior makes each comparison reproducible.
Convert Lat/Lon to a Local Plane When You Need Real Geography
If your goal is genuinely a geographic route — a delivery route, a sales territory, a campus inspection — the cleanest workaround is to project your coordinates before pasting them in. A local projection treats a small patch of Earth as flat, so the Euclidean distance matches real ground distance to within a few centimeters over a city and within a few meters across a small region. Tools like UTM, State Plane, or a simple equirectangular projection centered on your route's bounding box all keep the solver's straight-line math honest. After the tour is built, you can map the names back to the original lat/lon points without loss.
If the region is too large to flatten — a transcontinental trip, anything crossing the antimeridian, anything spanning more than a few hundred kilometers in latitude — skip the projection and use a routing service that already knows about the curvature of the Earth. Latitude and longitude are a coordinate system, not a distance system, and the solver's input expects the latter.
What the Heuristic Does and Doesn't Guarantee
The solver runs in three visible stages. First, it fixes the first input row as the start. Second, it walks from the current location to the closest unvisited point by Euclidean distance, repeating until every point has been visited once and the route closes back at the start — that is the nearest-neighbor construction and the starting distance reported in the result. Third, 2-opt scans the closed loop for two edges whose replacement by reversing the segment between them strictly shortens the total, applies the first such improvement, and restarts the scan until no further improvement is found or a defensive limit is reached. The reported "passes" count is the number of times the scan had to restart after a successful exchange.
Two guarantees and one caveat come with that output. The guarantee is that 2-opt never makes the initial route longer, because every exchange requires a strictly shorter total before it is applied. Eight small geometric golden cases — triangles, squares, rectangles, collinear points, and a center point — verify exact perimeter distances, closure, one visit per location, and that 2-opt never lengthens the initial route. The caveat is that the result is locally optimal under two-edge exchanges, not globally shortest, because the traveling salesperson problem is computationally difficult and exact solutions do not scale to arbitrary inputs. Per Google OR-Tools' routing documentation, practical solvers can return non-optimal results, and this page deliberately uses a bounded, inspectable heuristic instead of claiming an exact solution for arbitrary inputs. A different starting point or construction rule can land in another local minimum, which is why the tool fixes the first row as the start so repeated runs are deterministic.
When to Use a Real Routing Service Instead
The solver ignores roads, one-way streets, traffic, travel time, obstacles, appointments, vehicle capacity, and multiple drivers, because none of those constraints are encoded in a flat list of x and y values. A straight segment between two points is not a claim that a vehicle can travel that way; it is just the geometric distance. For dispatch, navigation, cost commitments, or safety-critical routing, use a validated solver with real network data and independently verify the route rather than treating this local approximation as operational authority. The same applies if your goal is to minimize time rather than distance, if you have a fleet with capacity limits, or if you need to respect customer time windows.
| Constraint or feature | Traveling Salesman Solver | Routing service with map data |
|---|---|---|
| Distance metric | Straight-line Euclidean on flat x, y | Road network distance or geodesic on lat/lon |
| Latitude and longitude input | Not handled directly; projection required | Handled natively |
| Roads and one-way streets | Ignored | Honored |
| Traffic and travel time | Ignored | Honored |
| Antimeridian crossing | Distorts or fails | Handled |
| Vehicle capacity, time windows, multiple drivers | Not modeled | Modeled |
| Network call or data upload | None — runs locally | Yes — required for real network data |
| Solution guarantee | Local optimum under 2-opt, never longer than the start | Depends on service; still not always globally optimal |
For learning the TSP heuristic itself, exploring spatial ordering on a local drawing, planning an approximate inspection sequence on a known coordinate system, or building reproducible test fixtures, the Traveling Salesman Solver is the right tool. Paste your projected coordinates, treat the output as a constructive approximation, and compare several starting-point orders if solution quality matters.
For a broader background on the heuristic itself — including how nearest-neighbor and 2-opt fit into the wider family of TSP approaches — see Traveling Salesman Problem: A Best-Solution Route Builder.
If you're weighing options, 24 Game Solver Cool Math Games: Find Every Answer covers this in detail.