Geographic and Projected Coordinate Systems

The previous chapter introduced coordinate frames. This one gets specific about the two families of coordinate systems you will actually encounter, how to choose between them, and how to recognize when you have chosen the wrong one.

The shape of the Earth, approximately

The Earth is not a sphere. It is an oblate spheroid, wider at the equator than pole-to-pole, with local undulations that can deviate from the mathematical shape by tens of meters. A datum is a mathematical model of the Earth’s shape, and it is the first decision every coordinate system rests on.

WGS84 is the datum used by GNSS. It defines an ellipsoid, an origin, and an orientation. When your GNSS receiver reports a latitude and longitude, it is reporting a position on the WGS84 ellipsoid. That is a good global reference. It is not a good local working plane.

Projected coordinate systems

A projected coordinate system flattens the curved Earth onto a plane. The result is a Cartesian grid measured in meters, which is what your planner and your vector editor actually need.

UTM, the Universal Transverse Mercator, is the most common choice for outdoor autonomous sites. It divides the Earth into 60 north-south zones, each 6 degrees of longitude wide, and projects each zone onto its own plane. The result is a coordinate system where distances computed in X and Y are actual meters, accurate to within about 0.1 percent within each zone.

That 0.1 percent has a mechanical explanation, and it is worth understanding because it is the root of a whole family of map errors. Picture the projection as a surface rolled over the rounded Earth: a cylinder for UTM, a cone for many State Plane zones. Where the surface meets the ellipsoid, scale is exact. UTM’s cylinder slices slightly inside the ellipsoid, so it crosses the surface along two standard lines, the transverse equivalent of standard parallels, near the middle of each zone: scale is exact on both lines, slightly small between them, and increasingly large outside them, growing toward the zone edges. That is why distortion grows with distance from the zone center rather than appearing at random. A projection is a smooth sheet, and its error is a smooth field across it.

Harbor Yard sits in UTM zone 10N. Every coordinate in its HD map is expressed as an easting and northing in that zone. The planner computes distances in meters. The GNSS receiver reports lat/lon, which is converted to UTM before it touches the map. One shared coordinate system, end to end.

The combined scale factor

The 0.1 percent figure is not a wall to live inside. It is a gap with a named bridge: the combined scale factor, the number surveyors use to convert between grid distances and ground distances. It is the product of two parts.

Grid factor. The distortion of the projection at your location. In UTM it is 0.9996 on the central meridian, exactly 1 on the two standard lines, and slightly above 1 near the zone edges. Read it off the zone’s distortion field for where the site sits.

Elevation factor. The distortion that comes from height. The projection is scaled to the ellipsoid, but the ground at altitude sits on a wider circle than the ellipsoid beneath it, because plumb lines converge toward the center of the Earth. A meter at elevation is a slightly longer meter in ellipsoid terms. The elevation factor accounts for the site’s height above the ellipsoid, and the effect is not exotic: roughly 1 part per million per 6 meters of height, so a site 600 m up is off by 100 ppm, 10 cm per kilometer, before the projection adds anything.

Multiply the two and you have the ratio between a grid distance and the same distance on the ground. Maps that come out subtly scaled when every datum and zone setting checks out are often this factor applied backward or not at all: going from grid to ground means dividing by the combined factor, and a workflow that skips the division quietly rescales the entire site.

Choosing a coordinate system

The decision tree is simpler than the GIS (geographic information system) textbooks make it sound:

• Is your site smaller than about 50 km across and entirely within one UTM zone? Use UTM.
• Is your site indoors or in a GNSS-denied environment? Define a local Cartesian frame tied to a fixed survey marker.
• Does your site span multiple UTM zones? You have a large site. Someone on your team has already solved this, probably with a custom local projection. Ask them.

For most controlled-environment autonomous sites, the answer is UTM. It is well-supported, globally understood, and the default in Autoware and ROS 2.

When coordinates go wrong

Coordinate failures are not subtle. They produce maps that are shifted, rotated, mirrored, scaled, or mysteriously 100 meters away from where they should be. But they are hard to diagnose because the map looks correct in isolation. A shifted map only looks wrong when you compare it to something else, like a satellite basemap, a GNSS trace, or the actual location of the robot.

Common failure modes:

Datum mismatch. The point cloud was captured in WGS84. The map was built in an editor configured for a local datum. Everything is offset by 30 to 200 meters, consistently.

Zone mismatch. The site straddles a UTM zone boundary. Half the map is in zone 10N and half in zone 11N. The join is not seamless.

Grid vs. ground mismatch. The planner expects ground distances, actual meters traveled on the asphalt, while the map carries grid coordinates, meters stretched or shrunk by the projection. Every distance in the map is off by the same fraction: near a UTM zone edge, about a meter per kilometer. The error is subtle and perfectly consistent, so the map looks right in every viewer. It surfaces only when a mapped distance is compared against a measured one, or when the robot’s odometry and the map disagree about how far it has driven.

Unit confusion. One tool outputs meters, another expects feet. The map is scaled by a factor of 3.28. Nothing lines up.

Axis swap. The X and Y axes are swapped. The map is rotated 90 degrees relative to reality. This happens more often than anyone wants to admit.

Altitude as height. The Z coordinate means different things in different systems: height above the ellipsoid, height above mean sea level, or height above a local reference. A robot that treats ellipsoidal height as local height will plan paths at the wrong elevation. Height also leaks into the horizontal: the elevation factor is computed from the site’s height above the ellipsoid, and what should feed it is the site’s mean elevation. On a site with significant vertical relief, a factor computed from the wrong reference elevation skews distance calculations across the entire HD map, compressing some levels and stretching others.

What comes next

Part II is complete. You know what a coordinate system is, why lat/lon is not enough for robotics, how projected systems like UTM work, and the failure modes that will save you weeks of debugging when you encounter them.

Part III begins the next stage of the pipeline: Capture. How do we turn physical reality into data a computer can work with? It starts with point clouds.